Backups that actually work when it matters

Almost every business that calls us after losing data had a backup. The problem was never that nobody had thought of it. It was that the backup had saved something other than what everyone assumed, or that it could not be restored.

A copy is not a backup

A file stored twice on the same drive protects you against an accidentally deleted folder. It protects you against nothing else: not a failing drive, not ransomware working its way through every reachable volume, not a fire in the server room.

A backup is a copy that lives elsewhere, is independent of the original, and whose restore path has been tested. Miss one of the three and it is a copy.

The 3-2-1 rule

The old rule of thumb still holds:

• 3 copies of the data in total (the original plus two backups)
• on 2 different media or systems
• with 1 of them in another location

The third point is where it fails in practice. An external drive permanently attached to the same server sits in the same room and is reachable on the same network, so it satisfies neither "another location" nor "independent".

Many people now add a 0: zero errors in the last restore test.

How to spot a backup that only pretends

A few warning signs we see regularly:

• The job reports success but saves less than you think. A database directory is copied while the database is running. The files are there; consistent they are not.
• The backup runs, but nobody reads the reports. A job that has been failing for eight months, with its mail landing in a spam folder, is not a backup.
• Retention is too short. If corruption is only noticed after three weeks but the backup reaches back seven days, every good version has already been overwritten.
• The backup hangs off the same account. Anyone who gets into the administrator account also reaches the backup. Separate credentials are not optional.

The test is the actual job

A backup only becomes one once somebody has restored it. Not in theory, but actually, onto a test system, with a stopwatch running.

Two numbers are worth knowing for every important system:

• How long may a restore take? That decides whether backup to tape is enough or whether a second system has to stand ready.
• How much data loss is bearable? That decides how often you back up. Nightly backups mean losing up to a working day.

Both are business decisions, not technical ones. They belong in a conversation before any technology is chosen.

A realistic start

Starting from nothing, four steps get you a long way:

1. Write down which systems exist and which of them stop the business when they are missing.
2. Set the two numbers above for each of those systems.
3. Set up the backup, with separate credentials and one copy off site.
4. Put a date in the calendar: test a restore once a quarter and write down the result.

The fourth step is the one most often dropped, and the only one that proves the first three were worth anything.