Backups and disaster recovery: the 3-2-1 rule, RPO and RTO

Every business eventually loses data. A laptop is stolen, a database is deleted by mistake, a supplier closes an account, or ransomware locks the shared drive. Whether that is a bad afternoon or the end of the company depends on decisions made long before, about what gets backed up, where copies live and how fast you can get running again.

This guide covers three ideas that make those decisions concrete: the 3-2-1 backup rule, the recovery point objective (RPO) and the recovery time objective (RTO). It ends with a simple way to plan and test recovery for a small business.

Backups and disaster recovery are not the same thing

A backup is a copy of data you can restore from. Disaster recovery is the wider plan for getting the business working again after a serious incident: which systems come back first, who does what, where you run from and how you tell customers. Backups are an essential ingredient, but a pile of backup files with no tested way to restore them is not a recovery plan.

The UK’s National Cyber Security Centre, in its small organisations guide to backing up your data, puts the two together. It says to back up the data your business needs to operate, such as “websites, emails, invoices, documents, contacts and customer information”, and stresses that it is “important you know how to restore it”.

The 3-2-1 rule

Backblaze’s guide to the 3-2-1 backup strategy summarises the rule as keeping “three copies of your data on two different media with one copy off-site”. It cites a 2012 Carnegie Mellon publication for US-CERT that recommended the method.

• Three copies: the live data plus two backups, so one failed backup doesn’t leave you exposed.
• Two different media or devices: so one type of failure can’t destroy every copy. Backblaze notes that with cloud storage you don’t strictly need different types of media, but you do need copies on separate devices.
• One copy off-site: so a fire, flood or burglary at your office doesn’t take every copy with it.

Ransomware adds a further consideration. The NCSC advises that a backup storage device “should not stay connected to your device when not in use”, because some malware also affects connected devices. In practice this means at least one copy should be offline or protected so that an attacker who gets into your systems can’t alter or delete it. Backblaze mentions extended versions of the rule, such as 3-2-1-1-0, that build on this idea.

RPO: how much data can you afford to lose?

NIST, the US standards body, defines the recovery point objective as “the point in time to which data must be recovered after an outage”. Put simply, it is the maximum amount of recent work you are willing to lose, measured in time.

If you back up every night at midnight and the server fails at 5pm, you lose 17 hours of changes. Your RPO is effectively up to 24 hours. If losing a day of orders would be unacceptable, you need more frequent backups or continuous replication. AWS’s guidance on disaster recovery options puts it directly: “How often you run your backup will determine your achievable recovery point.”

RTO: how long can you be down?

NIST defines the recovery time objective as the overall length of time a system can be in the recovery phase “before negatively impacting the organization’s mission or mission/business processes”. It is the longest you can be without a system before the damage becomes serious.

RTO is about more than restoring files. It includes noticing the problem, deciding to act, getting replacement hardware or accounts, restoring data, checking it works and switching people back. A backup that takes two days to download doesn’t meet a four-hour RTO, however complete it is.

Matching the approach to the targets

AWS describes four disaster recovery strategies, from cheapest and slowest to most expensive and fastest. The names come from cloud engineering, but the logic applies to any business.

AWS adds a warning that matters for every strategy: continuous replication “may not protect against disaster events such as data corruption or malicious attack”, because a deletion or corruption copies across too. That is why point-in-time backups remain necessary even with live copies.

A worked example

An example (illustration only). A small online retailer lists its key systems and agrees targets with the founders:

Each quarter, one person restores a sample from each backup to a test location and records how long it took. The first test reveals that the order export lacks customer phone numbers, so the export settings are fixed. Without the test, nobody would have known until they needed it.

A simple planning method

1. List the systems and data the business depends on, including those run by suppliers.
2. For each, agree an RPO and an RTO in business terms: how many hours of lost work, and how many hours of downtime, can you live with?
3. Check what each supplier actually backs up and how you would restore. Software-as-a-service providers protect their platform, but their terms may not cover your own mistakes, such as deleting records.
4. Apply 3-2-1 to the data that matters, with at least one copy offline or protected from deletion.
5. Write a short recovery runbook: who decides, who restores, in what order, and how to contact suppliers and customers.
6. Test restores on a schedule and record the time taken against the RTO.

Common mistakes

• Never testing a restore. A backup you haven’t restored is a hope, not a plan.
• Keeping every copy in one account. If an attacker or a billing problem locks that account, every copy goes with it.
• Treating sync as backup. Sync tools copy deletions and encrypted files as faithfully as good ones. You need version history or separate backups.
• Forgetting supplier-held data. Your shop, CRM and email all hold data you may need to export yourself.
• Setting targets nobody has costed. Very short RPOs and RTOs are expensive. Agree them with the people paying for them.

A sole trader with a laptop and a few cloud services may need nothing more than cloud backup plus an occasional offline copy and a yearly restore test. A business processing orders around the clock needs written targets, tested restores and probably a warm standby for its core system. The method is the same; the targets decide the spend.