Server Backups: A Rotation Strategy That Actually Survives

Backups you have never restored are just files taking up space. This is the rotation scheme, retention maths and testing discipline that turn backups into a real recovery capability.

Every team says they have backups. Far fewer can restore a server at 3 AM without panic. The difference is not the tool, it is the plan: what is copied, where it lives, how long it is kept, and whether anyone has proved the restore works. Here is a backup scheme for servers that you can run without a dedicated team.

Start with RPO and RTO

RPO (Recovery Point Objective) is how much data you can afford to lose - it sets your backup frequency. If losing four hours of orders is unacceptable, you need backups at least every four hours. RTO (Recovery Time Objective) is how quickly service must be back - it determines whether you restore a snapshot, rebuild from images, or fail over to a standby system. Write both numbers down; they drive every decision below.

The 3-2-1 rule, adapted

Three copies of your data, on two different media types, with one copy off-site. Practically: your primary server, a local snapshot for fast recovery, and an off-site or cloud copy for disasters that take out the whole machine or datacentre. Add immutability if ransomware is a concern: off-site copies that cannot be modified for a retention window are the defence that actually works.

A retention scheme that balances space and safety

• 7 daily backups - catch everyday mistakes: bad deploy, deleted rows, botched config.
• 4-5 weekly backups - catch problems you notice later, like silent data corruption.
• 12 monthly backups - long-tail protection, regulatory needs and audit trails.
• Pre-change snapshots - one before every migration, upgrade or major config change.

Store them with clear naming (hostname-YYYYMMDD-HHMM), keep metadata about what was included, and prune automatically so nobody has to remember to delete old files.

What to back up (people miss half of this)

Web files and databases are the obvious half. Also include: DNS and server configuration, SSL certificates and keys, mail (if hosted), cron jobs and scheduled tasks, environment variables and secrets, container images and infrastructure definitions, and application settings stored outside the codebase. If you cannot rebuild it from backup alone, it is not covered.

Encryption and access

Encrypt backups at rest and in transit, and store the encryption keys separately from the backups - otherwise an attacker with both is an attacker with everything. Restrict who can delete backups, and use separate credentials so a compromised web application cannot reach your off-site copy.

The test that matters

Schedule a quarterly restore drill. Pick a random backup, restore it to a fresh server, run the application, verify data integrity against known records, and measure how long it took. Teams that do this discover the real problems early: a database dump missing tables, a config file never backed up, an RTO that was fantasy. Fix what the drill reveals, then repeat.

A backup plan is only real the first time you use it under pressure. Make sure the first time is a rehearsal, not a crisis.