Most small teams do backups backward. They buy storage first, turn on a schedule, and only later ask whether the backup can rebuild the business. The better order is simpler: decide what must come back, how fast, how much data can be lost, and who can restore it under stress.
The three questions that matter
- RPO: how much data can you afford to lose if the server disappears now?
- RTO: how long can the service be down while you rebuild it?
- Restore order: what has to return first so customers or staff can keep working?
Those answers decide the tooling. A blog may tolerate a nightly database dump and a weekly media archive. A small commerce site may need frequent database backups, tested payment webhooks, and a documented DNS failover path.
Use 3-2-1 as a baseline, then add isolation
The classic 3-2-1 rule keeps three copies, on two media types, with one copy offsite. It is still a good memory aid, but ransomware changed the practical bar. A backup that the compromised server can delete is a convenience copy, not a recovery guarantee.
- Keep one copy outside the hosting account.
- Use credentials that the production server cannot use to delete history.
- Encrypt backups before they leave the machine or storage boundary.
- Keep restore instructions somewhere that does not require the failed server to read.
A restore test is the audit
A backup job can succeed while restoring still fails. Common causes are missing environment variables, expired database credentials, large uploads excluded by accident, incompatible package versions, and DNS or certificate assumptions that were never written down.
| Asset | Minimum restore test | Cadence |
|---|---|---|
| Database | Restore into a disposable instance and run app migrations | Monthly |
| Uploaded files | Sample recent and old files, then check checksums | Monthly |
| Server config | Rebuild a new VM from notes or automation | Quarterly |
| Secrets | Verify access to the secret store without the old server | Quarterly |
Read drive stats the right way
Backblaze publishes a rare public dataset about storage hardware at scale. Its Q1 2026 snapshot reported 341,263 drives, 1,030 failures, and a 1.24% annualized failure rate. The point for a small site is not to buy the same drive model. The point is that hardware failure is ordinary enough to design around.
Small-server backup pattern
- Nightly database dump to encrypted object storage.
- Hourly or daily application data sync depending on RPO.
- Weekly full archive copied to a second provider or account.
- Monthly restore into a throwaway server.
- Quarterly full rebuild from documentation or infrastructure as code.