The 3-2-1 backup rule, and the restore test nobody runs

Nearly every organisation says it backs up its data. Far fewer can say when they last restored a backup, and how long it took. Yet that is the only question that matters on the day a disk fails, a computer is stolen or ransomware encrypts the registry's files.

The 3-2-1 rule, without the jargon

The 3-2-1 rule is an old, simple method that still holds. It comes down to three numbers.

3 copies of your data

The live data, plus two backup copies. A single backup is a single point of failure: if it is corrupted, you have nothing left.

2 different types of media

The copies should not all sit on the same kind of storage. For example: the server, an external drive and storage space on another server. If all three copies are on the same hard disk, one failure takes them all.

1 copy off site

At least one copy must be kept in a different building. A fire, a flood, a theft or a burst pipe in the server room must not destroy the original and every backup at once.

Three copies, two types of media, one elsewhere: if one disappears, the others are enough.

Adapting the rule to a Congolese institution

The rule is universal; the conditions are not. A few points to watch in our context:

• Power cuts. A backup interrupted by load shedding can be incomplete without anyone noticing. Schedule backups when the power supply is most stable, protect the hardware with a UPS, and check that each run actually finished.
• Connectivity. Sending an entire database to another site every night can saturate a modest link. Incremental backups, which only transfer what has changed, ease the load considerably.
• The external drive in the drawer. It is often the only backup there is, and it lives in the same office as the computer. It counts as a copy, not as an off-site copy.
• Ransomware. A backup drive permanently connected to the network will be encrypted along with everything else. At least one copy should be disconnected, or protected against changes.

The restore test nobody runs

Here is the problem: a backup is a file. Until you have tried to read it back, you do not know whether it really contains what you think it does. Unpleasant surprises are common:

• the backup ran, but an important folder was never included;
• the file exists, but it is corrupted;
• the backup is complete, but nobody knows how to restore it any more, because the person who set it up has left;
• the restore works, but it takes three days, and the institution cannot afford to stop for three days in the middle of enrolment.

Testing a restore does not mean checking that a backup file exists. It means rebuilding the system from it, on another machine, and confirming that everything works.

How to go about it

1. Pick a date and put it in the calendar. One test per quarter is a reasonable pace.
2. Restore onto a separate machine, never onto the live system.
3. Check with real cases: find a specific student's file, the last mark entered, the last payment recorded.
4. Time it. Restore time is management information: it is how long your services would be down.
5. Write the procedure down as you go, so someone else can repeat it without you.
6. Record the result: date, duration, problems encountered, fixes applied.

Questions to ask your provider

If a third party hosts your data, ask them:

• how many copies exist, on what media, and where;
• whether there is an off-site copy;
• when the last restore test took place, and what it showed;
• how long a full restore would take.

These are commitments we make ourselves in our hosting offer in Kinshasa: a written backup policy, an off-site copy, a recovery procedure tested every quarter, and a restore carried out in front of you when the service goes live. The details are on our solutions page.

Not sure what state your own backups are in? That is exactly why now is a good time to check. Get in touch if you would like to do it with us.