Most businesses have backups. Far fewer have backups they’ve restored recently. The difference shows up on the worst possible day, when a disk fails, a server is encrypted by ransomware or someone deletes the wrong folder.
The 3-2-1 rule
The classic rule is simple:
- 3 copies of your data: the original plus two backups.
- 2 different types of storage, so one failure mode can’t take out both.
- 1 copy off-site, away from fire, flood and theft.
It’s still a good foundation. Ransomware added two more numbers.
3-2-1-1-0: the ransomware update
Modern ransomware looks for backups and encrypts or deletes them before demanding payment. So the extended rule adds:
- 1 copy that is immutable or offline: object storage with a retention lock, write-once media, or a disconnected copy. An attacker with your admin password still can’t change it.
- 0 errors when you verify and test-restore your backups.
Immutability only helps if the credentials are separate too. Backup storage should use its own accounts, with multi-factor authentication, that aren’t reused anywhere on your network.
Decide what “recovered” means: RPO and RTO
Before choosing tools, agree on two numbers for each important system:
- RPO (recovery point objective): how much data you can afford to lose. If it’s one hour, nightly backups aren’t enough.
- RTO (recovery time objective): how quickly the system must be working again. A four-hour RTO rules out restoring terabytes over a slow connection.
These numbers turn backup decisions into business decisions. Your accounting database and your marketing file share probably don’t need the same answer.
Back up databases properly
Copying the files of a running database often produces a backup that won’t restore. Use the database’s own tools or consistent snapshots. For MySQL and MariaDB with InnoDB tables, for example:
mysqldump --single-transaction --routines --triggers --all-databases \
| gzip > /backup/mysql-$(date +%F).sql.gz--single-transaction takes a consistent snapshot without locking InnoDB tables, so the store or application keeps running while the backup is taken.
Don’t forget the less obvious things: server configuration, TLS certificates and keys, scheduled tasks, DNS records, and data held in cloud services your team relies on.
Test restores on a schedule
A backup you haven’t restored is an assumption. A simple routine:
- Monthly: restore a few random files and one database into a scratch environment. Check they open and the data is current.
- Quarterly: restore a complete critical server or application from scratch, following your written runbook, and time it.
- After major changes: test again whenever you move servers, change backup software or add a new system.
Record what you restored, how long it took and anything that went wrong. If the time is longer than your RTO, you’ve found the problem in time to fix it.
A quick self-check
- Do you have at least one copy off-site, and one immutable or offline?
- Are backup credentials separate from your normal admin accounts, with MFA?
- Is every important database backed up with a consistent method?
- When did you last restore a full system, and how long did it take?
- Could someone other than you follow the restore instructions?
If any answer is “not sure”, that’s the place to start. We design and test backup systems for offices, online stores and servers across the GTA. Talk to us if you’d like a second opinion on yours.