IBM i high availability is not a single product, and the three common architecture families differ more than many proposals suggest. IT leaders should compare logical replication, PowerHA SystemMirror, and FlashSystem-based SAN replication by cost, bandwidth, recovery, and acceptable data loss.

Choosing more capability than the business needs can raise costs, while an undersized design may leave a wider recovery gap than planned.

A Manual Failover Decision Point for Mid-Market IBM i Environments

Before comparing the three architectures, one design principle applies to all of them. Maintaining a human decision point can help prevent unnecessary failovers and the complications they create.

A power fluctuation, brief network interruption, or temporary process error can sometimes resemble a server failure to an automated system. If an unnecessary switch occurs, the IT team may have to reverse a failover that production never actually required. A human decision point can help the team confirm the situation before moving users to the backup environment.

Fully automated failover can still make sense when staffing, testing, orchestration, and application design support that operating model. Source Data often favors manual approval when a team does not maintain that level of round-the-clock operational coverage.

Logical Replication Remains the Most Widely Deployed IBM i HA Option

The most common IBM i high availability architecture uses IBM i OS logical replication built around local and remote journaling.

When a journaled database record changes on production, IBM i sends the related journal entries to the target system. High availability software then updates those changes against the backup database.

The result is a closely synchronized production and standby environment that can support a planned role swap or failover. That leaves one production environment active while the second remains ready to take over.

Products including MIMIX, iTera, Maxava, and Robot HA use journal-based approaches to keep the target environment current. Because logical replication sends changes rather than complete storage blocks, its internet bandwidth needs can remain comparatively modest.

Some mid-market environments operate comfortably with reliable bandwidth connectivity around 20 to 50 megabits per second. Actual requirements depend on peak change volume, file sizes, latency, and the replication product being used.

That flexibility keeps infrastructure costs manageable and makes logical replication practical across many geographic arrangements.

Recovery times vary by architecture and operating model. Logical replication can support recovery in minutes, but the actual RTO depends on failover procedures, user counts, networking, target readiness, and the specific environment. For organizations running a standard business-hours model, a recovery window measured in minutes may be entirely workable.

PowerHA SystemMirror for Tight Synchronization Requirements

The second architecture operates closer to the storage layer through IBM PowerHA SystemMirror for i and supported mirroring technologies.

For this comparison, the focus is on designs that replicate storage at the disk or block level between production and target environments. Synchronous approaches confirm remote writes before production continues, while asynchronous approaches allow more distance with some recovery point tradeoff.

Source Data often uses approximately 28 miles as a practical planning point for tightly synchronized designs requiring low-latency connectivity. IBM supports Metro Mirror over longer distances, but latency and bandwidth matter more as physical separation grows.

At longer distances, asynchronous options may make more sense because production does not wait for every remote write acknowledgment. The exact design depends on storage technology, network performance, recovery objectives, and the independent auxiliary storage pool configuration.

PowerHA-based mirroring can carry the highest infrastructure cost of these three approaches in demanding configurations. PowerHA requires expert assessment to estimate required bandwidth. Be aware that bandwidth expenses can reach $10,000 to $20,000 per month in high-volume environments requiring sustained dedicated connectivity.

The design also requires expertise with PowerHA, storage, clustering, and Independent Auxiliary Storage Pools, or IASPs. That makes it best suited to organizations whose recovery requirements justify tighter synchronization and the supporting infrastructure.

This architecture is not necessary for every IBM i shop. For regulated or highly time-sensitive operations, tighter recovery objectives can justify the additional cost and design work.

IBM FlashSystem SAN Replication for Cost and Performance

The third approach uses IBM FlashSystem storage, point-in-time copies, and replication capabilities to support a recovery environment.

FlashCopy can create point-in-time logical pointers that take effect immediately (seconds), while physically copying or migrating 1 TB of backup data typically takes between 3-4 hours at 100 MBPS bandwidth.

Replication to the remote site is asynchronous and may lag by seconds to minutes (or longer) depending on bandwidth, latency, and system activity.

Compared to either logical replication or PowerHA, SAN replication typically takes longer. Failover requires SAN cleanup and consistency checks during IPL before the system can be restarted.

Failover relies on a SAN ‘freeze’ process, where replication is paused to ensure a consistent recovery point. Under high I/O workloads, this can take longer.

Advanced configurations using FlashCopy snapshots on the DR side can provide point-in-time test environments without interrupting ongoing replication, though this adds complexity and consumes additional storage.

For many small-to-mid-sized operations running a single shift, SAN replication may fit the business requirement.

The business can resume with a recovery point that matches its actual operating tolerance instead of paying for tighter synchronization unnecessarily.

For most configurations, FlashSystem-based SAN replication costs less than logical replication by reducing third-party HA software and target-resource requirements. That makes it worth considering for organizations balancing recovery needs against ongoing infrastructure cost.

Choosing the Right IBM i High Availability Architecture

With the three approaches in view, the selection criteria become easier to compare.

• Logical replication is a strong fit when geographic flexibility, modest bandwidth, and broad application support matter most. Many mid-market IBM i shops choose this model because it balances recovery speed, distance, and operating cost.
• PowerHA SystemMirror deserves consideration when tighter synchronization is required, and the organization can support the related storage and network design. Its value rises when recovery requirements justify the added infrastructure and technical coordination.
• IBM FlashSystem SAN replication fits organizations seeking modern storage performance, flexible recovery design, and potentially lower ongoing HA costs. It deserves a close look when a recovery point falls within the business’s acceptable data-loss window.

One more factor belongs in the decision: the licensing terms attached to your ISV applications. Some vendors charge transfer or secondary-use fees when software moves to a hosted or recovery target. Understanding ISV transfer fee exposure before selecting an architecture can protect both the project schedule and budget.

"High availability basically means that if the primary server goes down, a secondary or tertiary server will pick up the slack quickly, and in some cases, in a matter of minutes. We typically recommend that somebody make a decision to throw the switch. Don’t do it automatically because there could be a power fluctuation or other issues. It might come right back." – Bob Losey, Founder and President, Source Data Products

The right architecture should match more than the recovery time objective alone. It should also fit monthly costs, staffing, application licensing, geography, and the evidence auditors expect to see.

Those factors don't always point to the same design, so a structured comparison is more useful than choosing by product name alone.

IBM i High Availability Architecture Questions

What does IBM i high availability actually mean?

IBM i high availability means a secondary environment can resume production within a defined recovery window after the primary becomes unavailable. IBM i can combine cluster services with logical replication or hardware-based replication to protect data and support planned or unplanned switching. The goal is to reduce both downtime and potential data loss within limits the business has already defined. For more on testing, our post about IBM i disaster recovery testing explains lessons from an initial failover test.

What is the difference between logical replication and PowerHA system mirroring on IBM i?

Logical replication sends journaled changes and replicated objects from production to a standby IBM i environment. PowerHA SystemMirror uses IBM-supported technologies to replicate or switch storage through Independent Auxiliary Storage Pools (IASPs) and cluster services. Logical replication often requires less specialized storage infrastructure and can work across greater distances. PowerHA designs can provide tighter storage-level integration when the business requirements justify it.

How much bandwidth does IBM i logical replication require?

Some mid-market IBM i environments can run logical replication with reliable connectivity around 20 to 50 megabits per second. Actual requirements depend on peak transaction volume, file sizes, replication method, network latency, and the amount of change being transmitted.

Why does Source Data often recommend a manual failover decision?

We recommend a human decision point because temporary network or power events can resemble a larger production failure. Manual approval gives the team time to confirm conditions before moving users to the recovery environment. Automatic failover can still be appropriate when the environment is designed, tested, staffed, and monitored for that operating model.

What recovery window can IBM FlashSystem SAN replication support?

Replication lag describes a possible recovery point objective, not the full recovery time objective. Actual RTO also includes validation, target activation, networking, application checks, and reconnecting users to the recovery environment. Talk to an expert to assess your FlashCopy Recovery Time Objective (RTO) target. With 1 TB of storage utilization, a realistic recovery time is in a range of 3-4 hours with 100 MBPS bandwidth.

Do IBM i high availability solutions require special software licensing from IBM?

Licensing depends on the architecture, IBM i configuration, PowerHA use, and the target system's status. IBM PowerHA SystemMirror is separately licensed, while IBM i backup and recovery licensing follows IBM's applicable HA and disaster recovery terms. ISV applications may also carry transfer, secondary-use, or hosted-target fees that should be confirmed before finalizing the architecture.

How far apart can IBM i HA servers be located?

The practical distance depends on the replication method, latency, bandwidth, and the recovery objective the business needs to meet. Source Data often treats approximately 28 miles as a practical planning point for tightly synchronized, low-latency PowerHA designs. IBM documents Metro Mirror across longer distances, although synchronous performance becomes more sensitive to latency as distance increases. Logical replication and asynchronous SAN replication can support much greater geographic separation when the network is sized correctly.

How do I know which IBM i HA architecture my current environment can support?

Start with four questions covering acceptable recovery time, acceptable data loss, monthly infrastructure budget, and geographic separation between production and recovery sites. Then review application licensing, network capacity, storage design, staffing, and the failover process your team can support. Logical replication fits many mid-market environments needing geographic flexibility and manageable bandwidth. PowerHA suits tighter synchronization requirements, while FlashSystem replication can balance modern storage performance with flexible recovery points. Our post on IBM i right-sizing explains how experienced teams evaluate workload needs before sizing infrastructure.

Match Your IBM i Risk Profile to the Right Architecture

A working HA environment depends on matching the architecture to the way the business actually operates. A mismatched design can cost more than necessary or deliver a wider recovery window than the organization intended.

Source Data has structured hosted IBM i HA environments across a broad array of industries, including those with strict continuity requirements. The Cloud400 High Availability platform gives mid-market organizations a managed HA option backed by IBM i specialists.

Reach out to the Source Data team to compare IBM i HA options against your recovery goals, infrastructure, and budget.