Backup and Recovery
How to design backups that actually restore: how many copies, which media, offsite rules, retention, and the restore tests that prove any of it works.
A backup is not a job that finished successfully. A backup is a copy from which you have actually restored. Everything on this page follows from that distinction, because it is where most environments quietly fail: the schedule runs green for two years and the one restore that matters does not work.
Think of a backup system the way you would think of a fire escape in a building. Nobody judges it by how tidy it looks. It is judged once, under load, on the single occasion someone needs it, and the only meaningful test is walking it end to end while nothing is on fire.
What this guide covers
The articles in this cluster take the pieces one at a time: how many copies you need and where they live, what retention actually buys you, how ransomware changed the rules, and how to run a restore test that produces evidence rather than reassurance.
Where to start
If you are building a backup design from nothing, start with the 3-2-1 rule, which governs how many copies exist and where. If you already have backups running and want to know whether they are real, start with restore testing instead.
Backup questions administrators actually ask
Articles in this guide
-
Restore Testing: Turning a Green Job Into Evidence
A backup job that reports success proves the job ran. A restore test proves the data comes back. Here is how to run one that gives an auditor real evidence.
3 min read
-
The 3-2-1 Backup Rule, and Where It Stops Being Enough
Three copies, two media types, one offsite. What each number is actually protecting you from, and why ransomware forced most teams to add a fourth condition.
3 min read
On this page