An untested backup is not a backup

The question is not "do you have backups?" — the answer is always yes. The question is: when did you last restore a complete system from backup, and how long did it take?

Start with two numbers - Recovery Point Objective (RPO): how much data can you afford to lose? An hour? A day? - Recovery Time Objective (RTO): how much downtime can the business absorb?

These two numbers drive the design and the cost. Without them, any backup discussion is theoretical.

The three-copy rule Three copies of the data, on two different media types, one of them off-site. A copy sitting on the same server is not a backup — it is a second file that dies with the server.

The immutable copy Modern ransomware looks for backups first. If the backup account can overwrite an old archive, that archive is exposed. A copy protected against modification for a defined retention window changes the outcome entirely.

Restore testing Make the test scheduled and documented: 1. Pick a system. 2. Restore it into an isolated environment. 3. Measure the time end to end. 4. Record what didn't work. 5. Close the gap.

Most companies discover on the first test that recovery takes several times longer than expected, and that some important file or service was never in scope.

Commonly forgotten - Network device and firewall configurations. - SSL certificates and signing keys. - Mailboxes. - The credentials themselves — if they live in an encrypted system you cannot open after the failure.

In short Backup is not a product you buy; it is a procedure you test. The only number that matters is the real time measured in the last restore test.