IBM i In The Cloud And The Case For Reversing Replication

November 9, 2026 Ash Giddings

When IBM i organizations start looking at the cloud, the conversation often follows a familiar path. Start with low-risk workloads such as development or test, consider running disaster recovery in the cloud, and keep production on-premise. Perfectly sensible. It’s relatively low risk, builds confidence, and gives the organization a manageable starting point.

But another approach deserves more attention. Run production in the cloud, replicate back to an on-premise system, take backups from that local target, and store them offsite. Turn the familiar arrangement around 180 degrees.

For organizations considering a hardware refresh, reviewing data center costs, or assessing the skills needed to maintain their infrastructure, this approach deserves a place in the discussion. The question is whether it gives the business a better practical recovery option if its production environment becomes unavailable.

Put Production Where It Makes Sense

IBM i organizations have several cloud options for production, including IBM Power Virtual Server, Kyndryl Cloud Uplift on Azure, and specialist private Power clouds. If the application, connectivity, service requirements, and economics stack up, production should be part of the evaluation rather than being ruled out by default.

Moving production changes where the system runs. It does not remove the need to recover it. Backup and recovery arrangements vary between providers and service packages, so make sure you understand exactly what is included, who manages it, and how recovery is tested. The business still needs a plan for an outage where its production environment is unavailable.

Cloud providers often have best-of-breed infrastructure with built-in redundancy. But network disruption, configuration errors, security incidents, and failures affecting a site or shared service can still interrupt the business. While a provider works to resolve the problem, your business still needs to operate.

Give The Local System A Different Job

The on-premise Power server could become the replication target for production running in a public or private cloud. Using Maxava HA, protected IBM i data and objects can be replicated back to that local system, providing a locally maintained recovery environment and a platform for suitable backup processing.

Taking suitable backups locally keeps that processing away from the production workload and users. You also have a current copy within reach and, importantly, outside the infrastructure hosting production.

Independence Needs More Than Another Location

IBM i administrators and those responsible for the architecture are used to looking for single points of failure. That thinking needs to follow the workload into the cloud. Two systems in different buildings may still depend on the same network connection, underlying identity service, or administrative credentials.

If users cannot authenticate, application servers remain unavailable, or essential interfaces still depend on the failed environment, having a local database will only get you so far. Recovery planning must cover how the business will actually operate from the target.

For some organizations, that independence will justify retaining an on-premise footprint. Others will find a second provider or cloud location a better fit. Maxava HA supports one-to-many replication, allowing multiple targets where the recovery requirements justify them. The useful question is which failures each target lets you recover from, and which dependencies remain shared.

Why Stop At One Recovery Target?

At Maxava, we are seeing more organizations adopt a three-node configuration, with one production system replicating to two targets. Those targets could be in public clouds, private clouds, or on-premise, depending on the business’s recovery requirements. With production in the cloud, one option worth considering is to keep a local target for recovery and backups, alongside another at a separate cloud location or provider.

The additional target gives the business another recovery option if production and one target become unavailable, or if a target is undergoing maintenance. Its value depends on how independently it can operate. Each target needs the capacity, connectivity, and tested procedures to support its intended role, with locations chosen to reduce the risk of one incident affecting multiple systems.

Tape Belongs In This Conversation

Anyone who has worked around IBM i for a while will remember when tape capacity was measured in megabytes, then gigabytes. LTO-1 arrived with 100 GB of native capacity while the wider LTO market now offers LTO-10 cartridges holding 40 TB native, or up to 100 TB when using compression. That is 400 times the native capacity of LTO-1 in one cartridge.

Capacity is only half the story. A bigger cartridge does not automatically deliver a shorter backup window. That strengthens the case for taking suitable backups on a separate target, away from production processing. The save must capture a consistent recovery point.

A Replica And A Backup Do Different Jobs

A current replica provides a route to resuming operations. Retained backups provide earlier recovery points. Both matter because unwanted changes can replicate too. A deletion or data corruption may reach the target before anyone realizes there is a problem.

Taking backups from that target, retaining multiple generations, and moving encrypted media offsite add another layer of protection. Removed, offline cartridges are separate from the live systems and cannot be overwritten through an online connection. Recovery keys and restore instructions need protection too. A cartridge in a vault is useful only if you can recover what the business needs from it.

Prove The Business Can Run There

Replication status is one part of recovery readiness. User profiles, application keys, communications settings, and swap procedures need attention as the environment changes. A target that was ready one month ago may have gaps today.

Maxava’s Simulated Role Swap provides a way to rehearse aspects of the process without interrupting production. Audits help prove that protected data and objects are synchronized, while the Swap Ready Audit service identifies exceptions requiring attention. Full role swap testing then demonstrates whether the business can operate on the target. These activities provide different evidence and should be used together.

Management needs that evidence, too. A service level agreement does not explain how the business will continue to operate during an extended outage. A tested recovery plan should establish which system will run the workload, how much data could be lost, and how long the switch will take.

Technology does go full circle. We spent years moving processing into our own computer rooms. Now organizations are considering moving it out again, but the system left behind may still have a valuable role.

When you next review cloud for IBM i, ask which way the replication should run.

For more information, check out https://www.maxava.com.

Ash Giddings is a product manager at Maxava and an IBM Champion.

This content is sponsored by Maxava.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search