AS400 High Availability vs Backup: How They Differ and How to Choose 

One of the more common misunderstandings we come across in IBM i environments is the belief that a good backup setup automatically means the business is protected from downtime. The opposite happens too. Some teams invest in high availability and assume that because a second system is always available, backup becomes less important. 

In reality, the two solve very different problems. 

• Backup is there to give you a clean point you can return to when something goes wrong.  
• High availability is there to reduce the amount of time the business has to stop when production becomes unavailable.  

You may need one more than the other, or you may need both, but the decision should come from how your business actually operates rather than from the technology itself. 

A simple way to understand the difference is to imagine that your production IBM i environment goes down at 10:30 in the morning. Your overnight backup completed successfully, the media is healthy, and the data is recoverable. From a backup perspective, everything has worked exactly as intended. 

The problem is that the business is still down. Someone now has to prepare a system, restore the operating environment, restore the application data, reconnect everything around it, validate that the applications are working, and then bring users back in. Depending on the size of the environment and the way recovery has been designed, that could take a few hours or much longer. 

That is where the distinction between AS400 backup and high availability starts to matter. 

What Backup Actually Protects You From 

Backup is mainly about preserving history. It gives you copies of your libraries, objects, IFS data and system information so that you can go back to a known point if something is deleted, corrupted, encrypted or changed incorrectly. 

That matters in more situations than people sometimes realize. A developer may deploy a change that affects data in an unexpected way. Someone may delete the wrong object. A ransomware incident may encrypt production files. An auditor may ask for information from several months ago. In each of these situations, the ability to return to an earlier clean copy is what matters. 

For many IBM i environments, BRMS helps automate much of this by managing schedules, media and retention. The backup itself may sit on tape, virtual tape, disk or cloud storage. Journaling can also reduce the amount of transaction data that is lost between saves. 

The limitation is that backup does not keep the business running while recovery is happening. 

You can have a perfectly valid backup and still face several hours of downtime before the system is usable again. That is why a successful backup job should not be confused with a successful recovery strategy. The backup tells you that a copy exists. It does not tell you how quickly operations can resume. 

Where High Availability Comes in 

High availability starts from a different assumption. It assumes that the business cannot afford to wait for a full restore. 

So, instead of relying on a backup that needs to be restored after a failure, a second IBM i system or partition is kept synchronized with production through replication. If production becomes unavailable, or if planned maintenance needs to be carried out, operations can be moved to the standby environment. 

The main benefit is time. Rather than spending hours rebuilding the environment from a saved copy, the business may be able to resume much more quickly because the standby is already running and already contains recent data. 

For organizations where IBM i supports order processing, manufacturing, warehousing, billing or customer-facing operations, that difference can be significant. 

But high availability has an important limitation of its own. Replication copies what happens on production, and that includes mistakes. 

If someone deletes the wrong file, that deletion can be replicated. If a table becomes corrupted, the corruption may appear on the standby as well. If ransomware encrypts data and the replication process sees the change, the second environment may receive the same encrypted data. 

This is why high availability does not remove the need for backup. The standby gives you another place to run the workload, but it does not necessarily give you an older, clean version of the data to return to. 

The Real Question is not Backup or High availability 

Once this is clear, the decision becomes much easier. You are not really choosing between two competing technologies. You are trying to answer two separate business questions. 

• The first is how long the business can afford to be unavailable. 
• The second is how much data or work the business can afford to lose. 

Those two answers tell you far more than a feature comparison ever will. 

If the business can tolerate several hours of downtime and your tested restore process fits inside that window, backup may be enough for that workload. If production needs to resume within minutes or within an hour, then waiting for a full restore is unlikely to work, and some form of high availability becomes much easier to justify. 

The same applies to data loss. If you back up once every night and the system fails late in the afternoon, you may have many hours of transactions that are not in the last backup. Journaling or replication can reduce that gap, but the important point is to understand what losing that work would actually mean. 

A useful way to discuss this with finance or operations is to move away from phrases like “we could lose eight hours of data” and translate it into real work. How many orders were entered during those eight hours? How many invoices were posted? How many production updates were made? How many people would have to recreate that information, and how long would it take them? 

That is usually when the cost of recovery becomes easier for the business to understand. 

Another question matters just as much: how far back might you need to go? 

This is the part that often gets missed when teams become focused on uptime. Not every incident is a hardware failure. Sometimes the system is still running, but the data is wrong. 

A program may have updated records incorrectly. An interface may have loaded bad information. A user may have deleted something important. A security incident may have been present for several days before anybody noticed. 

In those situations, failing over to a standby system may not solve the problem because the standby may contain the same bad change. 

What you need then is a known-good point from before the issue happened. 

That is why backup remains necessary even in environments with strong high-availability setups. High availability helps reduce interruption, while backup gives you the ability to recover an earlier state. 

They solve different risks, and most mature recovery strategies use them together where the business case supports it. 

Do not design recovery around IBM i alone 

Another common problem is treating the IBM i partition as though it exists by itself. A team may have an excellent recovery plan for the core system, but when they test the process, the business still cannot operate because other pieces have not recovered with it. 

EDI connections may still be unavailable. A web application may still point to the old environment. Middleware may be down. Reporting systems may depend on another database. Authentication, file transfers or third-party integrations may not be ready. 

From a technical point of view, IBM i may be back. From the business point of view, the process is still broken. 

This is why recovery planning should follow the full business transaction rather than stop at the server. If an order starts in one system, passes through IBM i and then moves to another platform, the whole chain needs to be considered. 

A fast failover of the IBM i environment does not help much if the systems around it remain unavailable. 

What Should Drive Your Backup vs HA Decision? 

Decision factor	Backup may be enough when…	High availability makes more sense when…
Downtime tolerance	The business can tolerate several hours of downtime while the environment is restored.	Even an hour or two of downtime creates a serious operational or financial impact.
Transaction loss	Some recent transactions can be recreated without major disruption.	Losing recent transactions would create significant rework, financial exposure, or customer impact.
Restore time	A tested restore brings the environment back within the business’s recovery window.	The tested restore time is longer than the business can realistically wait.
Operational dependency	Teams can continue temporarily through manual workarounds or delayed processing.	Production, order entry, customer service, or other critical operations depend on continuous access.
Maintenance windows	Planned outages can still be scheduled without major disruption.	There is no practical maintenance window because the system needs to stay available almost all the time.
Workload criticality	The workload can return later without affecting core operations.	Certain workloads need recovery in minutes, even if other systems can wait.
Cost justification	The impact of downtime is lower than the cost of maintaining a standby environment.	The cost of downtime is high enough to justify the second environment and ongoing HA management.

Choose the Right Recovery Plan 

The mistake is treating this as a choice between backup and high availability. 

Backup protects your ability to recover an earlier, clean version of the system. High availability protects the business from having to wait while recovery happens. 

Some IBM i environments need both. Others genuinely do not. 

The goal is not to build the most elaborate recovery architecture possible. It is to know what would happen if the system went down tomorrow morning, how quickly the business could resume, how much work would be lost, and whether everyone involved is comfortable with that answer. 

If you are still unsure where that line sits for your environment, get in touch with an AS400 support provider that can assess your current backup, journaling, restore, and standby setup against the recovery targets your business actually needs.