IBM Power disaster recovery
Protect AIX and IBM i without standing up a second data center. Replicating to cloud Power gives you failover, and a low-risk first step toward migration.
Disaster recovery for IBM Power has traditionally meant a second physical site with its own Power hardware, expensive to buy and maintain. Power DR-as-a-Service (DRaaS) replaces that with a cloud Power target you replicate to, so you get failover coverage without owning a second data center. For many teams it's also the lowest-risk way to prove out cloud Power before committing to a full cloud migration.
What DRaaS gives you, and what to watch
Plan around RTO and RPO
Two numbers shape every Power DR design. RTO (recovery time objective) is how quickly you must be back online; RPO (recovery point objective) is how much data you can afford to lose. Tighter targets mean more frequent replication and higher cost, so set them deliberately, by workload, rather than applying one standard to everything.
- Rank workloads by how much downtime and data loss each can tolerate
- Match replication method and frequency to those RTO/RPO targets
- Test failover and failback on a schedule, not just at setup
- Keep runbooks current so recovery doesn't depend on one person
Frequently asked questions
What is Power DR-as-a-Service?
It's replicating your AIX and IBM i workloads to a cloud Power target you can fail over to, giving you disaster recovery without owning and maintaining a second physical DR site.
What are RTO and RPO, and why do they matter?
RTO (recovery time objective) is how quickly you must be back online; RPO (recovery point objective) is how much data you can afford to lose. Together they drive the replication method, and the cost, so set them per workload.
Is DRaaS the same as migrating to the cloud?
No. DRaaS protects production that still runs on-prem. It's often a low-risk first step that proves out cloud Power on your real workloads before you commit to a full migration.
How do I know my Power DR actually works?
Only by testing it. DR should be failover-tested on a schedule, with current runbooks, not just configured once and assumed to work when you need it.
What Power DR looks like in practice
DR-as-a-Service is often the first, lowest-risk step onto cloud Power. Two representative engagements.
Situation. Production staying on-prem for now, but no real failover beyond tape.
Approach. Replicate the tier-one AIX and IBM i systems to cloud Power, with failover tested quarterly.
Outcome. Recovery measured in hours instead of days, and a proven cloud Power target for a later production move.
Situation. A single data center, with an audit flagging the lack of a recovery site.
Approach. Stand up DRaaS to a second region sized to defined RTO/RPO, with no second site to build.
Outcome. The audit satisfied without capital for a second facility, and failover that's tested rather than theoretical.
Representative scenarios reflect common IBM Power migration patterns and typical ranges, not specific named client engagements.
A Power DR readiness checklist
DR-as-a-Service is often the lowest-risk first step onto cloud Power. These questions size the design, and tell you what to test.
Scope a Power DR plan
We'll set RTO/RPO targets with you and design DR to cloud Power that you can actually test.
Free, no obligation. Foretel responds within one business day.