A backup is only useful if the data comes back when you need it. A backup job reporting "success" only means the data was copied, not that it's readable or that the restore will actually work in an emergency.
Follow the 3-2-1 rule
Keep three copies of your data: the original plus two backups. Store them on two different kinds of storage, for example a local server and a cloud service. Keep at least one copy off-site, so a fire or theft at the office doesn't take out every copy at once.
Protect against ransomware
Ransomware can spread across a network and encrypt your backups along with the originals, if the backups are reachable from the same network. Keep at least one copy in an immutable format: a copy nothing and nobody can change or delete for a set period, so there's always a clean version even if everything else is compromised.
Decide what gets restored first
You usually can't restore everything at once, so decide the order in advance:
- Critical systems: accounting, payroll, core databases.
- Communication: email and internal messaging.
- Everyday files: shared folders and documents.
Also decide how much data loss you can tolerate: if the most you can afford to lose is the last hour of work, your backups need to run at least that often.
Watch the alerts, not just the job status
A failed backup, from a full disk, a dropped connection, a corrupted file, usually raises an alert. The alert doing nothing is the real risk. Review backup logs regularly, give one person the job of clearing failed-backup alerts, and store the decryption keys somewhere that isn't reachable from the network you're protecting.
Actually test a restore
A backup you've never restored is a guess, not a plan. On a schedule (monthly or quarterly is common):
- Pick a sample of files from different departments.
- Restore them to a separate, isolated machine.
- Open them and check nothing is corrupted.
- Time how long the restore took.
The time matters for planning: if a small folder takes hours to restore, a full system restore will take much longer, and that's the downtime you should expect during a real incident.
Monthly test checklist:
Put the restore test on a recurring calendar invite so it's routine, not something that only happens after something has already gone wrong.
