3-2-1 backups and the restore test almost nobody runs

Having backups is not the same as being able to recover. Seven practices so the copy exists, stays out of an attacker’s reach and restores when you need it.

Almost every IT team has backups. Far fewer have really restored one. The day it matters they find the copy was incomplete, nobody knows the key, or the attack also encrypted the disk where it was stored. An untested backup is, in practice, a hope.

1. Apply the 3-2-1 rule

Three copies of the data (the original and two backups), on two different kinds of media, with one of them off-site. It is not a recent invention: it remains the baseline because it covers the three things that fail: a disk, a building and a human error.

2. A copy ransomware cannot touch

Many ransomware variants look for and encrypt backups reachable from the same network. That is why the rule is often extended with an immutable or offline copy: storage with locked retention (WORM), offline tape, or a backup account whose credentials are separate from the domain’s.

• Backup credentials different from daily administration ones.
• No network drives permanently mounted on the server being backed up.

3. Define what is backed up and what is not

List your systems by importance: email, ERP, file servers, databases, network configurations, repositories. What is not on the list is not backed up, and it is often exactly what someone needs: the firewall configuration, encryption keys, DNS.

4. Set two numbers: how much you can lose and how long you can wait

The recovery point objective (RPO) is how much data you accept losing; the recovery time objective (RTO) is how long the business takes to be back in operation. A firm that bills daily cannot have a one-week RPO. Ask the people who use the system; do not decide it from IT alone.

5. Really restore, and on a schedule

Once a quarter, restore something in a separate environment and time it. Rotate what you test: a single file, a database, a full virtual machine. Record who did it, what failed and how long it took; that real time is your true RTO.

6. Encrypt backups and keep the keys elsewhere

An off-site backup is a privacy risk if it is stored in clear. Encrypt it, but keep the key somewhere different and known to more than one person. An encrypted backup whose key left with someone who resigned is useless too.

7. Document the procedure and watch the alerts

Write the recovery steps so someone who did not design them can follow them at three in the morning. And review the job reports: a backup failing silently for weeks is more common than it seems. Set alerts for failed jobs, not just successful ones.

To start this week

• Pick one important system and restore it in a test environment.
• Check that at least one copy is outside the main network.
• Write down the real times and compare them with what the business expects.

What that first test teaches you is usually more useful than any written policy.

IT backups continuity security best practices

← Back to the index