Backup and restore
The simplest and cheapest form of disaster recovery. Copies of your data are kept somewhere safe, away from the main site. If the main site is lost, you build servers, restore the data and start the applications again.
What happens in a disaster
This is what runs at each site on a normal day. Press Simulate a disaster to watch the primary site fail and the DR site take over, step by step.
How the pieces fit together
| Part | What it does |
|---|---|
| 1 Backup jobs | The backup server copies applications and databases on a schedule, usually every night, with database log backups more often if a lower RPO is needed. |
| 2 Local repository | The first copy lands on disk at the primary site. Most everyday restores, such as a deleted file or a corrupted VM, come from here because it is fast. |
| 3 Offsite copy | A copy job sends the backups to a second location. This copy is immutable: once written, it cannot be changed or deleted until its retention period ends, even by an administrator. |
| 4 Offline copy | Optionally, a periodic copy to tape or a disconnected disk. It is the last line of defence if both online copies are compromised. |
| 5 Restore on disaster day | After a disaster, servers are built at the recovery location and data is restored from the offsite copy, starting with the most important systems. |
Most teams follow the 3-2-1 rule: three copies of the data, on two different types of storage, with one copy offsite. A common extension, 3-2-1-1-0, adds one copy that is immutable or offline, and zero errors in restore tests.
The weak point of this pattern is time. Nothing is running at the DR location, so everything has to be built and restored after the disaster. Restore speed is limited by bandwidth and disks: restoring 10 TB over a 1 Gbps link takes close to a full day even at full line speed, and real restores are often slower.
How failover works
- Declare the disaster and confirm which backup point you will restore from.
- Get compute at the recovery location: a cloud account, spare hardware, or a pre-agreed rental contract.
- Rebuild the foundations first: network, firewall rules, Active Directory and DNS.
- Restore databases, then application servers, in the priority order agreed with the business.
- Have application owners test before users are let in.
- Point DNS at the recovered systems and announce the service is back.
Failback: Once the primary site is rebuilt, take a fresh backup at the recovery location and restore it to the primary in a planned maintenance window.
When to use it
- Development, test and training systems
- File shares, archives and internal tools
- Smaller organisations without a second data centre
- The base layer under every other pattern: you always need backups, even with replication
When it is not enough
- Customer-facing or revenue systems that must be back within hours
- Large databases where a full restore would take days
- Systems where losing a day of data is unacceptable
What to watch out for
- Restore speed. Test how long a full restore of your largest system really takes. That number, not the backup schedule, is your realistic RTO.
- The backup server itself. If the backup server and its catalogue are lost with the primary site, restores stall. Keep its configuration and catalogue offsite too.
- Ransomware. Attackers look for backups first. Use immutable storage and separate credentials: the backup administrator account should not be a domain administrator.
- Hardware on the day. If you plan to restore onto your own hardware, make sure it will actually be available. Lead times for servers can run into weeks.
Typical tools for this pattern
Examples only. We recommend tools based on what you already run, your team's skills and your licences.
| Layer | Common choices |
|---|---|
| Backup software | Veeam, Commvault, Veritas NetBackup, Bacula or Bareos (open source) |
| Immutable storage | S3-compatible object storage with Object Lock, hardened Linux repositories |
| Offline copies | LTO tape, rotated disks |
| Rebuilding servers | VM templates, Terraform, Ansible |
Comparing options? See all five patterns side by side in the DR patterns guide, or read what DR really costs.
Not sure where your DR stands?
Send us your application list and a short note on how backups work today. We will come back with a plain gap review: which systems are exposed, what a realistic recovery time looks like, and what it would take to close the gap.