Every weekday at 5:40pm, someone at an Oklahoma City valve manufacturer brought the AS400 down and started the backup. They had until 6:20pm. One shift had ended, the next had not begun, and the entire daily protection of a live production system fit inside that forty-minute gap. If the operator called in sick, or a job ran long, the choice narrowed to skipping the backup or holding up the next shift.
That company was not careless. They were doing what a lot of IBM i shops still do, which is protecting a critical system with a routine that depends on one person being in the right place at the right time. We have seen that pattern repeatedly across 15 years of AS400 work. Nalashaa's IBM i team eventually replaced theirs with a three-step automated process that completes inside the same window without anyone standing over it. You can read that one in full in our AS400 backup automation case study.
Even when that backup ran perfectly, it answered only one question: can we get the data back. It said nothing about how fast the business could run again after a fire, a failed Power server, or ransomware reaching the IFS through a mapped drive. Those are disaster recovery questions, and most AS400 environments answer them far less confidently than they answer the backup question.
This guide starts where the decision gets made. We compare the four AS400 disaster recovery solutions side by side on recovery time, data loss and cost, so you can see which one your business case supports before anyone quotes you for it. From there we cover how to set your RTO and RPO honestly, which AS400 backup solutions hold up under a real restore, what belongs in an AS400 disaster recovery plan, and the five places we most often find those plans breaking during assessments. We close on a deadline worth putting in your planning calendar: standard support for IBM i 7.4 ends on 30 September 2026, which changes the arithmetic for a lot of shops still running it.
Backup and disaster recovery are not the same purchase
A backup protects you against loss. Someone deletes a library, a disk unit fails, a job corrupts a file, and you restore from the last good save. The question a backup answers is "can we get the data back."
Disaster recovery protects you against downtime. The data center floods, the Power server dies, ransomware encrypts the mapped IFS shares. The question DR answers is "how fast can we run the business again, and how much work do we lose in the process."
Those two questions get answered by two numbers. Your Recovery Time Objective is how long you can be down. Your Recovery Point Objective is how much data you can afford to lose. Every AS400 disaster recovery decision comes down to buying the RTO and RPO your business needs at a price it can justify. Pick the numbers first, then pick the architecture.
Two projects from our AS400 portfolio
Here is what both halves of that distinction look like in practice. Two engagements, two different clients, each of whom believed they had the other half covered.
Valve manufacturer, Oklahoma City: a backup that depended on one person showing up
This client had a backup that worked, in the narrow sense that it produced a save most days. What it did not have was a process. Running it meant bringing the AS400 down, which meant it could only happen between shifts, which meant a fixed 40-minute window from 5:40pm to 6:20pm with an operator standing there to drive it.
That design put a person in the critical path of data protection every single day and capped recovery at whatever had happened since the previous evening. Our IBM i team rebuilt it as a three-step automated process that finishes inside the same window without supervision, which turned a daily judgement call into a routine that simply runs.
Read the full breakdown in the AS400 backup automation case study .
Tier-1 automotive supplier, North America: an integration built to survive one side going down
This parts supplier runs three plants and manages its assembly lines through a modern MES, while an AS/400 holds the system of record for inventory, bills of material and orders. The two did not talk in real time, so planners worked from stale stock figures and lines stopped waiting for material that was already in the building.
The part relevant to disaster recovery is how we built the connection. Shop-floor events travel between the MES and IBM i over a durable IBM MQ queue, so when either system goes offline, events wait in the queue and process once the link returns. Nothing gets lost and nothing gets processed twice. That is a continuity decision rather than an integration convenience, and it is what a dependency chain needs if your AS400 is going to be usable after an outage rather than merely running.
The integration cut line stoppages by 50%, brought shop-floor-to-inventory latency under five seconds, and reduced inventory carrying costs by 15%, without rewriting the AS/400 logic underneath.
Read the full breakdown in the Tier-1 automotive AS/400 integration case study.
The Four AS400 Disaster Recovery Solutions Compared
| Approach | Typical RTO | Typical RPO | Relative cost | Best fit |
|---|---|---|---|---|
| Cloud or hosted high availability replication | Minutes | Near zero | Highest | Order entry, warehouse, claims, anything where an hour of downtime has a hard dollar number attached |
| SAN to SAN replication | Under an hour | Minutes | Moderate to high | Shops that already run compatible external storage at two sites and want strong protection without HA software licences |
| Online backup with daily replication to cloud VTL | Several hours to a day | Up to 24 hours | Moderate | Important systems where a day of reprocessing is survivable |
| Tape backup with off-site storage | Days | Up to a week, depending on rotation | Lowest | Archival, compliance retention, and systems the business can run around manually |
Some detail behind those four rows:
Logical replication keeps a second IBM i environment continuously in step with production using journal data, so failover means switching users to a machine that is already current. You pay for that with software licences, a second environment, and the ongoing discipline of keeping both sides synchronised. It buys the shortest outage available.
SAN to SAN replication moves the problem down a layer to the storage arrays and leans on IBM i and Db2 recovery mechanisms for consistency. It removes the replication software licence, and it commits you to compatible storage hardware at both ends.
Daily replication to a cloud virtual tape library is the option most mid-market IBM i shops land on, because it removes tape handling and physical courier risk while keeping costs down. Your exposure is defined by the replication schedule. If it runs at 2am, a 4pm outage costs you a full working day of transactions.
Tape remains defensible for retention and archive. As a primary DR strategy it fails on the maths, because recovery time includes locating the media, transporting it, staging hardware and restoring serially, and because tape degrades in ways nobody notices until a restore.
Not sure which of these your RTO justifies?
Our IBM i team will review your current save strategy and tell you where the gaps are
Start with your RTO and RPO
Both numbers are business decisions before they are technical ones, which is why the infrastructure team usually cannot set them alone. Four questions get you most of the way there.
What does an hour of downtime cost?
Add up lost orders, idle staff, expedited freight, contractual penalties and the cost of catching up afterwards. If an hour costs little, tape may be adequate. If a day would threaten the business, you need high availability.
How much re-keying can your team absorb?
An RPO of 24 hours means someone re-enters a day of transactions from paper, email and memory. Ask the people who would actually do that work how long it would take them and whether the source documents even exist.
What else has to come back with the IBM i?
Almost no AS400 runs alone now. There are EDI feeds, integration middleware, reporting databases, web front ends and third-party services. A perfect IBM i recovery is worth very little if the systems it exchanges data with are still down. Your DR scope has to cover the dependency chain, not just the box.
Who is contractually entitled to ask?
Customer agreements, cyber insurance policies and regulatory frameworks including HIPAA, SOX and GDPR all impose expectations about data protection and recoverability. Those obligations usually set a floor under your targets, and they are worth reading before you design around them rather than after.
Not sure of the answers yet? We will work through them using your own business data.
What AS400 backup solutions look like when they work
Everything above this point assumes one thing: that the copies of your data are good. If they are not, no recovery architecture sitting on top of them can save you. Most AS400 backup solutions that fail an audit fail right here, at the copying stage, rather than at the sophisticated replication layer above it.
A save strategy answers four questions. What gets copied, when it runs, how it gets managed, and how you know the copy actually works.
What gets copied
IBM i has a built-in menu called GO SAVE that handles the copying, and it offers three options your team will refer to by number. Option 21 copies the entire system, which is what you need if you ever have to rebuild a machine from nothing. Option 22 copies the operating system's own data only. Option 23 copies all of your business data.
A typical pattern runs Option 21 monthly or quarterly during planned downtime, Option 23 weekly, and daily copies of just the files that changed. Daily full copies are usually impractical, because a full copy takes hours and the system has to be quiet while it runs.
Those daily copies come in two flavours, and the difference decides how painful your restores are.
An incremental copy captures only what changed since the last copy of any kind. It finishes fastest and uses the least storage, but restoring means loading the last full copy and then every incremental copy since, in order. Lose or damage one link in that chain and the ones after it become useless.
A differential copy captures everything that changed since the last full copy. Each one is larger than the last as the week goes on, so it costs more time and storage. In exchange, restoring needs only two things: the last full copy and the most recent differential. Fewer moving parts, faster recovery, which is why shops with tight recovery windows lean this way.
There is no universally correct answer. Incremental favours the backup window, differential favours the restore. Choose based on which one your business feels more acutely.
Your AS400 also runs a mix of eras at once, and the backup has to cover all of it. Business logic in RPG and COBOL sits alongside Java, open source packages and integration components added in the last decade. A routine designed around the first group and never revisited will miss the second, which is the most common way a save that looks complete turns out not to be.
When it runs
Frequency follows how fast your data changes. High transaction volumes justify more frequent copies, because the gap between them is exactly what you lose. Most shops run the heavy jobs overnight or at weekends, when the system is quiet enough to spare the resources.
Beyond the routine schedule, four moments deserve a copy of their own.
Take one before any major update, PTF install or software change, so you have a clean point to return to if the change misbehaves. Take another after the change succeeds, because that copy becomes your new baseline and the pre-change one is now out of date.
Take one before an audit. Data gets moved, queried and occasionally damaged during audit activity, and you want a known-good state on record beforehand.
Take extra copies during your busiest trading periods. The quarter that generates the most revenue also generates the most data you cannot afford to re-enter, and a schedule set for a quiet month will not fit it.
Compliance may also set the floor for you. HIPAA, Sarbanes-Oxley and GDPR all carry expectations about how data is retained and recovered, and where they apply, your schedule has to satisfy them before it satisfies anything else.
How the copying gets managed
BRMS, short for Backup, Recovery and Media Services, is IBM's tool for running all of this. It schedules the jobs, tracks which tape or disk holds which copy, retires old media, and prints the recovery reports you will be reading at 2am during an actual incident.
Many shops skip BRMS and run their backups through custom scripts instead, often written years ago by someone who has since left the company. That works until the day it does not, and by then nobody remaining understands what the script was doing.
How you know the copy works
Three things separate a backup routine that will actually save you from one that merely runs on schedule.
Journaling is IBM i keeping a running log of every change made to your important files, like a receipt for every transaction. With that log you can rewind to any moment you choose. Without it, the best you can ever do is return to last night's copy, no matter how much you spend on everything else. Journaling is also what makes continuous replication to a standby machine possible, so skipping it closes off your fastest recovery options permanently.
The IFS needs to be in the backup, and often is not. The Integrated File System is the part of IBM i that stores ordinary files, meaning documents, archived print output, Java and open source components, and data being exchanged with other systems. Many AS400 backup routines were written back when everything lived in traditional database libraries, and they still quietly skip this area. It also happens to be how ransomware reaches an IBM i: if a Windows PC has a mapped drive pointing at the IFS, ransomware on that PC will encrypt whatever it finds there, and it does not care which operating system is on the other end.
Verification and testing are different things. Verification means the backup job reported that it finished without errors. Testing means somebody actually restored that backup onto separate hardware and confirmed the data was usable. A backup can report success every night for two years and still restore into something unusable. The only way to find out which one you have is to try it before you need it. If you have not looked at the underlying environment in a while, our guide to running an AS400 system health check is a reasonable place to start.
Where AS400 disaster recovery plans actually break
Across the IBM i estates we assess, the same five failures repeat.
- The recovery documentation lives on the system being recovered.
- Configuration details, LPAR settings, network addresses, contact lists and the recovery runbook itself sit in a folder on the production box, or in a wiki hosted on infrastructure that went down with it.
- A printed copy stored off-site solves it. The more serious version of this problem is having no documentation at all.
An Indiana food processing company came to us running its ERP on AS400 across plants in several US cities with nothing written down, so we documented it from the ground up, hundreds of modules covering data models, jobs, archives, reports, configurations and process flows. You cannot rebuild or fail over to a system that exists only in the working memory of whoever is still employed.
Encryption keys share the fate of the data, Backups get encrypted and the key management stays on the environment being restored. The tapes survive and nobody can read them.
The DR environment runs a different OS level, or an unsupported one. A release mismatch stops the standby receiving the production save, so it will not work when you need it.
Nobody has authority at 3am. Failover is a business decision with real consequences, and if the decision rights are not written down in advance, the first hour of every incident gets spent finding someone willing to make the call.
The plan was tested once, at go-live. Applications change, data volumes grow, dependencies get added. A DR plan tested three years ago describes a system that no longer exists. Annual failover testing is the minimum, and testing after any significant application or infrastructure change is better.
September 2026 changes the calculation for a lot of shops
IBM has confirmed that standard support for IBM i 7.4 ends on 30 September 2026, after which the release moves to Service Extension, a paid and narrower form of support that runs through September 2029. IBM i 7.3 passed the same milestone in September 2023. That leaves 7.5 and 7.6 as the releases receiving full standard support.
This matters for disaster recovery in two ways. Building a DR plan on a release that stops receiving new security fixes means your recovery target inherits every vulnerability disclosed after that date. And because IBM i 7.6 runs on Power10 and later, while Power9 tops out at 7.5 and Power8 at 7.4, an OS decision and a hardware decision are now the same decision for many sites.
If a DR refresh and a release upgrade are both on your roadmap, they belong in the same project. We have covered the detail in our IBM i 7.4 end of support guide and our breakdown of what IBM i 7.6 brings.
Bottomline
Most IBM i teams already know where the soft spot is. Someone on the team can tell you the backup has never been restored end to end, or that the standby is a release behind production, or that the only person who really understands the save routine retires in two years. What they usually cannot do is put a number on it, and without a number the conversation never gets past the infrastructure team.
That is why these gaps survive for years. Recovery is never the most urgent thing on the list until the morning it is the only thing on it, and the people who could close it are the same people keeping the system running the rest of the time.
30 minutes is usually enough to see where you stand. Walk us through how your saves run today, what is journaled, and what you would actually do if the production machine did not come back on Monday morning. We will map that against the downtime and data loss your business can absorb. Book a 30-minute call with our IBM i team
Frequently asked questions
What should an AS400 disaster recovery plan include?
A usable AS400 disaster recovery plan documents six things: your agreed RTO and RPO, the recovery architecture that meets them, a step-by-step restore runbook covering LPAR and network configuration, where the encryption keys and media live, who holds authority to declare a disaster and trigger failover, and the schedule for testing all of it. Keep a printed copy off-site, because a plan stored only on the system being recovered is not available when you need it.
What is a realistic RTO for an AS400?
It depends entirely on the architecture you fund. Logical replication to a warm standby brings recovery down to minutes. Cloud VTL replication typically lands in the several hours to one day range. Tape with off-site storage runs to days once retrieval and staging are counted.
How often should we back up our AS400?
Daily saves of changing libraries, weekly user data saves, and a full system save monthly or quarterly is a common baseline. Journaling on critical files closes the gap between saves. High data turnover, regulatory obligations and seasonal peaks all push the cadence up.
How does AS400 cloud backup work?
Cloud backup for AS400 replicates your saves to a cloud-hosted virtual tape library rather than to physical cartridges. The IBM i writes to what it treats as an ordinary tape device, and the data lands in cloud storage instead. Most setups replicate once a day, which puts your data loss exposure at up to 24 hours. It removes tape handling, courier costs and off-site storage fees, and it makes recovery onto cloud-hosted Power hardware possible without shipping anything anywhere.
What is the difference between AS400 online backup and tape backup?
Online backup writes your saves across a network to disk or cloud storage, so nobody handles media and nothing gets driven off-site. Tape backup writes to physical cartridges that somebody rotates and stores elsewhere. Online backup typically recovers in hours rather than days and removes the risk of degraded or misplaced media. Tape stays cheaper for long retention and remains reasonable for archive, provided it is not your only copy.
What AS400 backup software do we need?
IBM i ships with the essentials. The GO SAVE menu handles the saves themselves, and BRMS, meaning Backup, Recovery and Media Services, handles scheduling, media tracking and recovery reporting. BRMS is a licensed IBM product and covers most requirements on its own. Third-party AS400 backup software earns its place mainly for cloud replication targets, deduplication, or managing IBM i alongside other platforms from a single console. General-purpose enterprise backup tools vary in how well they support IBM i and usually need an agent, so confirm current compatibility rather than assuming it.
What are our AS400 backup options?
Four, in rising order of cost and falling order of recovery time. Tape written to cartridges and stored off-site. Online backup replicated daily to a cloud virtual tape library. SAN to SAN replication between two sites. Continuous high availability replication to a standby IBM i. Which one fits depends on how long you can be down and how much data you can afford to re-enter by hand.
