An AS400 or iSeries disaster recovery plan is usable only when the business can restore the IBM i service within its agreed data-loss and downtime limits. A daily backup report does not prove that result. The recovery team needs an offsite copy, a suitable Power or hosted recovery target, the restore sequence, application dependencies, and a measured exercise.
Start with the recovery outcome
Record a recovery point objective (RPO) for each business service: how far back can its data be restored without unacceptable loss? Record a recovery time objective (RTO): how long can that service remain unavailable? The numbers belong to the business owner, then the IBM i team tests whether the design meets them. IBM's disaster recovery plan guidance uses those objectives to shape the strategy, roles, communication, and exercises.
| Event | Recovery dependency | Evidence to record |
|---|---|---|
| Site outage | Offsite save or replica, compatible recovery target, network and user access. | Age of recovered data, elapsed time to business acceptance, and any missing service. |
| Corruption or ransomware | Known-good recovery point and copy isolated from compromised credentials. | Copy integrity, clean restore result, and the rollback decision. |
| Partition or hardware failure | System-state save, licensed programs, partition configuration, and dependencies. | Full-system restore sequence, restart order, and application validation. |
Inventory what the business actually needs
List the IBM i release and machine type, logical partitions, licensed programs, libraries, IFS data, user profiles, security objects, application interfaces, job schedules, certificates, network routes, and the owners who can authorize recovery. A restored library is not a recovered service if the application cannot sign in, reach a database, or exchange files with another system. Keep configuration and contact information available outside the failed site.
Choose recovery copies by event, not by habit
Local saves can help with routine restores. Offsite saves or replication address site loss. An isolated copy gives the team a recovery option after credential compromise. High availability can shorten a hardware or site failover, but it does not supply a clean earlier recovery point after bad data is replicated. The IBM Power backup guide explains the save layer; the high availability versus backup guide explains the separate roles.
If the offsite copy uses cloud storage, verify how save media is returned to the IBM i restore process. IBM's Cloud Storage Solutions for i and BRMS restore instructions require cloud volumes to be retrieved for restore. Transfer time must be included in the measured RTO, along with target provisioning and application validation. Compare this with the tape versus cloud backup guide.
Write a runbook someone else can execute
For each scenario, name the incident lead, recovery target, save or replica identifier, access and credential process, restore commands or vendor procedure, restart order, communications owner, and business acceptance checks. Identify the checkpoint at which the team stops trying a failed method and switches to an alternative. Store the runbook away from the production environment, and test access to it during the exercise.
Measure the exercise and close the gaps
Start the clock when the incident is declared. Record the age of the recovered copy, time to acquire the target, time to restore system and data, application acceptance time, and each failed dependency. Compare the observed data loss and total elapsed time with the agreed RPO and RTO. An exercise that only confirms a save job finished has not tested disaster recovery. Set the next exercise based on business impact and after material hardware, IBM i version, application, network, or backup-design changes.
Use a server refresh to retest the plan
A move to Power 11 hardware or an IBM i release upgrade can change machine compatibility, partitions, licensed programs, and restore order. Recheck the disaster recovery target before the cutover, then document what the post-change exercise actually proved. Do not assume the earlier restore result transfers to the new design.
FAQ
What is the difference between IBM i backup and disaster recovery?
Backup creates recoverable copies. Disaster recovery combines those copies with a usable target environment, a tested restore sequence, people, and business acceptance steps.
What are RPO and RTO for AS400 disaster recovery?
RPO is the maximum data loss the business accepts, measured back from the outage. RTO is the maximum time allowed to restore the service. Test the actual recovery design against both.
Does IBM i disaster recovery require high availability?
No. High availability may help meet a short downtime target, but backup-based recovery can be appropriate when a longer RTO and its measured restore time are acceptable.
How often should an IBM i disaster recovery plan be tested?
Choose an exercise schedule based on business impact, system changes, and unresolved recovery risks. Record the result of each test and repeat after material changes.