Every team that runs IBM i, AS400, or Power Systems has a backup plan, and most teams can show a report that says last night’s jobs finished without errors. The trouble starts on the day something actually goes wrong.
- A library is missing from the save
- The IFS was never included
- Security data cannot be restored
- A journal receiver was not saved with its files,
- Or the offsite copy takes far longer to retrieve than the business can tolerate.
Yes, a completed job proves that a backup ran but it does not prove that your AS400 data backup can bring the business back on time.
So, we’ve curated this guide to help you spot the weak points in your backup strategy before an outage exposes them. Use it as a practical check during quarterly reviews, ahead of an audit or disaster recovery exercise, or before major infrastructure changes such as a Power11 upgrade.
1. Check that your backup covers everything that matters
Many backup gaps come from things added to the system after the original backup was designed. Go through your save strategy and confirm that it includes all production libraries, IFS paths, user profiles and security data, system configuration, and the details of your interfaces, job scheduler, and middleware.
On IBM i, different parts of the system are saved with different commands, and a plan that relies on only one of them will leave something out. SAVLIB covers libraries, SAV covers IFS directories, SAVSECDTA covers user profiles and authorities, SAVCFG covers configuration objects, and SAVSYS covers the operating system. If you use BRMS, review its backup control groups to confirm that each of these areas is actually part of a group that runs.
Two areas deserve extra attention. The IFS often holds integration files, documents, and application data that nobody thinks about until they are gone. Journals are the other one: if your applications depend on journaling, the journal receivers need to be saved along with the files they protect, or you may not be able to bring the data to a consistent point after a restore.
2. Agree on recovery targets with the business
Backup design should start from two numbers for each critical workload. The recovery point objective (RPO) tells you how much data the business can afford to lose, and the recovery time objective (RTO) tells you how long the business can afford to be down.
Once those numbers are written down, compare them with what your current design can really deliver. A nightly save to tape can work well for a workload that tolerates a day of data loss, but it will not meet a target of one hour. Tighter targets usually call for journaling, replication to a second system, or a high availability solution on top of regular saves. Make sure business stakeholders approve the targets, because the decision about acceptable loss belongs to them and not only to IT.
3. Review where your backups live
A backup that sits only on the same site, or on the same network as production, can be lost along with the system it protects. Identify every backup destination in use, confirm that offsite copies exist, and confirm that at least one isolated or immutable copy is available. Review your tape rotation, cloud retention, and encryption controls, and check the capacity and health of your backup storage so that a full volume or aging media does not cause a silent failure.
It also helps to think about your backup window. If your saves need the system to be restricted, or if they run so long that they spill into business hours, look at save-while-active options and at whether a second system could take the backup load off production.
4. Test the restore, not just the backup
Restore testing is where most teams discover their real problems. Plan a test that covers the restore of one critical application stack, IFS recovery, security data recovery, and access to your offsite copy. Measure how long the recovery actually takes, and record what you find along with the fixes you plan to make.
Pay attention to the order of the restore as well. User profiles, configuration, libraries, and authorities need to come back in a sequence that works, and a team that has never practiced it will lose time working it out during a real incident. A written runbook that has been tested at least once is worth far more than one that exists only on paper.
If you can only do one thing from this list, run a documented restore test from the same offsite or isolated copy you would depend on in a real event. That single test will tell you more than any backup report.
5. Prepare for ransomware and align with disaster recovery
Attackers often go after backups first, so protect your backup administrator credentials and keep the production and backup domains appropriately separated. Make sure offline or immutable copies exist, and include cyber incident decision points in your recovery runbooks, such as when to isolate systems, who approves a restore, and how you will confirm that the restored data is clean.
Your backup design should also match your disaster recovery runbooks and business priorities, so that both plans tell the same story. If the disaster recovery plan assumes a recovery in four hours and the backup design needs a full day, one of the two documents is wrong.
6. Revisit the plan whenever things change
A design that worked two years ago may not fit today’s workload. Review your backup after IBM i version changes, storage or network changes, new integrations, modernization work, and before any Power11 migration. Quarterly is a sensible baseline, with extra reviews after major infrastructure, application, or security changes. Also confirm that every backup job has a named owner, since unowned jobs are the ones that quietly stop working.
How finding the right AS400 service provider helps
Backup and recovery on IBM i is a specialized skill. Many organizations have a small team, or even a single administrator, who built the original design years ago, and that knowledge can disappear when people change roles or retire. A good AS400 Support service provider closes that gap and gives you an outside view of risks that are easy to miss from the inside.
When you evaluate a provider, look for these qualities:
- Hands-on IBM i experience. The team should work with IBM i, BRMS, journaling, and high availability tools every day, and should be able to explain how they would handle your specific environment.
- A focus on recovery, not only backup. Ask how they test restores and how they measure recovery time. A provider who talks only about job schedules is solving half of the problem.
- Clear reporting and ownership. You should receive plain-language findings, a prioritized list of fixes, and a named contact who is responsible for follow-up.
- Security awareness. Ransomware readiness, credential protection, and isolated copies should be part of the conversation from the start.
- Support for change. Upgrades, migrations to Power11, and modernization projects all affect backup design, so your provider should be able to review the plan before and after those changes.
- A practical approach. The best partners compare your environment with real recovery expectations instead of handing you a generic audit list.
The right provider will not replace your internal team. They will give that team a tested plan, a second set of eyes, and a faster path to recovery when it matters.
Common questions
Is a successful backup job enough?
No. It only shows that the job completed. It does not show that the environment can be restored correctly and within the time the business needs.
What do backup reviews usually miss?
IFS coverage, journal receivers, tested offsite recovery, security data restoration, and clear ownership are the most common gaps.
How often should the backup plan be reviewed?
Quarterly is a good baseline, with extra reviews after major infrastructure, application, or security changes.
Should this checklist be used before a Power11 upgrade?
Yes. Infrastructure change is the right moment to confirm that your backup design still fits the new environment.
Conclusion
A reliable backup is one you have proven you can restore. Cover every library and IFS path, set recovery targets the business has agreed to, keep an isolated copy, and test your restores on a regular schedule.
And when the environment is complex, you need a team that can understand how your IBM i is actually set up, spot the gaps that matter, and turn backup and recovery requirements into a plan that will work when you need it most.
