Glossary
Disaster recovery as a service (DRaaS)
Disaster recovery as a service (DRaaS) is a model in which a provider continuously replicates an organization's servers and data to infrastructure the provider operates, and runs those servers there when the organization declares a disaster.
The recovery site becomes a contracted service, billed largely by protected capacity, in place of a second facility the organization owns and staffs.
Why DRaaS matters
A second data centre with idle servers, network links and staff is one of the most expensive ways to hold capacity that is rarely used. DRaaS turns that standing cost into a subscription: storage for replicas is paid continuously, while compute is paid for mainly during tests and declared events. For organizations without a suitable second site, or with workloads spread across regions, it is the fastest route to an off-site recovery capability.
The same model is a business line for service providers, who build the replication targets, the recovery compute and the long-term retention behind it, and who carry the storage cost of every tenant they protect.
How DRaaS works
- Initial synchronization: a full copy of each protected server's disks is sent to the provider, over the network or on shipped devices.
- Ongoing replication: changes are captured at the source and sent continuously or at intervals, often into a journal that allows recovery to a chosen point in time.
- Standby: replicated data waits in storage, with little or no compute running.
- Failover: on declaration, the provider creates virtual machines or cloud instances from the replicated disks, attaches networks and starts systems in the order defined in the recovery plan.
Replication can be captured by an agent in each server, by the hypervisor, by the storage system or from backup copies. Agent and hypervisor methods reach recovery points of seconds; backup-based services recover to the last backup and take longer, because data is restored before servers start. When the primary site is back, changes made during the event flow back through failback.
Service models
| Model | Provider handles | Customer handles |
|---|---|---|
| Self-service | Replication platform and target infrastructure | Configuration, recovery plans, testing, declaration and execution |
| Assisted | Platform plus support during tests and events | Recovery plans and application validation |
| Managed | Plan design, testing, execution and failback, often against contracted recovery times | Declaration and application acceptance |
Providers include public cloud platforms replicating into their own regions, managed service providers running dedicated recovery infrastructure, and backup vendors whose platforms can start protected machines in a cloud. DRaaS differs from backup as a service: one delivers a running environment in which servers resume, the other delivers off-site copies of data.
What DRaaS means for enterprises and service providers
For the organization buying the service, the first constraint is the initial copy. Seeding 50 TB over a 1 Gb/s link takes 50 × 10¹² × 8 ÷ 10⁹ = 400,000 seconds, about 4.6 days at full utilization, and large estates often ship media instead. After that, the link has to keep pace with the daily change rate at its peaks, or replication lag, and with it the recovery point, grows during batch windows.
The second constraint is shared capacity. In a regional event many customers of the same provider declare at once, and the compute available at that moment bounds how many systems start in parallel. Contracts describe recovery times; the provider's capacity during a crowded event decides them. Returning afterwards can also carry egress fees on every terabyte replicated back.
Replicas protect against site loss and replicate corruption with equal reliability. A DRaaS copy taken from an encrypted server is an encrypted copy, so organizations relying on a provider service typically keep an independent point-in-time copy under their own control. Location matters too: a provider-hosted recovery site places data in the provider's infrastructure and jurisdiction, which brings residency and sovereignty rules into the contract.
For service providers the economics are mostly storage. Each tenant needs replica capacity, journal capacity for the recovery window and long-term retention for aged recovery points. A journal that keeps seven days of changes at 500 GB per day holds 3.5 TB beyond the replica; extending the window to thirty days raises it to 15 TB, which is why long histories are moved from journal storage to lower-cost object storage.
Scality storage alongside DRaaS
Scality ARTESCA is software-defined S3 object storage for backup, and for Zerto, a journal-based replication platform used in DRaaS offerings, it holds ARTESCA Validated Design status as an immutable S3 target for long-term retention, receiving aged recovery points offloaded from Zerto's journal storage. With S3 Object Lock in compliance mode, those retained copies cannot be deleted by any user, including the root account, until their retain-until date, which gives an organization or provider a copy that sits outside the replication path. For larger multi-tenant estates, Scality RING provides software-defined object and file storage on standard x86 servers, holding up to 300 billion objects in a single RING.