Solutions · Business continuity

Continuity built in.
Not bolted on.

Disaster recovery usually runs as a separate project, with its own tools, its own runbooks and its own third-party site. On Oasis Stack it is part of the platform your teams already operate, sized to each workload.

Talk to an architect Architecture overview
Per-workload recoveryOne consoleFederated by agreement
A primary data hall linked by replication lines to a standby hall, with a partner site further away
The question

DR is usually a second platform nobody runs until the worst day.

It lives outside the primary estate, with its own tooling and its own dependency on a third-party site, so it is tested least when it matters most. Continuity should be a property of the platform, not a separate programme.

Topology

Where a workload can recover to.

Recovery targets are set per workload: another site of your own, a partner Oasis cloud by agreement, or a public cloud for the non-sensitive workloads you select. The DR site can be a full deployment, or Oasis Edge Cloud: a mini deployment for just the critical workloads.

1
Primary site
An in-country data centre or colocation facility, running the workloads.
2
In-country DR
A second site with synchronous or asynchronous replication, ready to take over.
3
Federated DR
Optionally, a partner Oasis cloud, by agreement.
4
Public DR
Optionally, a public cloud, for non-sensitive workloads only, through the integrations with Acronis Cloud and Commvault.
Sized to the workload

Recovery targets per application, not per platform.

Tier 0 · Cannot stop
Active-active across sites, for systems such as core banking and health records.
Tier 1 · Core business
Warm standby in a DR site, for ERP and customer platforms.
Tier 2 · Operational
A pilot light, or a trusted partner cloud, for internal applications and batch work.
Tier 3 · Archive
Cold storage for data you keep but rarely touch, such as audit logs.
One console

The runbook is the platform.

Failover from the everyday console
Recovery is orchestrated from the same console and APIs operators use every day, with no separate runbook.
One operating model
Primary, DR and federated sites are run the same way, with fewer tools and fewer surprises.
Options per workload
Each application gets the recovery objective it needs rather than one plan for everything.
Tested like everything else
Recovery is ordered, tested and governed like any other service in the catalogue.
What moves

Data goes where you place it, and nowhere else.

Recovery moves data by design, so the rules about where it may go are written down in advance.

Targets chosen per workload
Replication destinations are set per workload. Nothing is copied to a site you have not chosen.
Federation by agreement
A federated DR site is used under an agreement between clouds. Customer data never moves between clouds automatically.
Public DR for what can go there
A public cloud is an option only for the non-sensitive workloads you select.
When a partner cloud goes away
Degraded, not broken: your own services never depended on it, and they keep running. Federation model
Business continuity

Make continuity part of the platform.

Start with your workloads and the recovery each one needs.

Talk to an architect Architecture overview