Backups are only half of disaster recovery. The other half is knowing exactly how to get back online, and having practised it. When a server is hacked, a disk fails, a bad update breaks everything, or someone deletes the wrong directory, a written plan turns panic into a checklist. Here’s a practical template for one or a few Linux servers.

1. Decide your targets: RTO and RPO

Term Question Example
RTO (recovery time objective) How long can the service be down? Blog: 1 day. Shop: 1 hour
RPO (recovery point objective) How much data can you afford to lose? Blog: 24 h. Shop: 15 min

These numbers drive everything else: backup frequency, replication, standby servers. See VPS uptime and SLAs.

2. Inventory: what makes up each server

Write it down per server:

  • OS and version, server location and plan;
  • installed software and versions (web server, PHP, database, Docker);
  • configuration locations (/etc/nginx, /etc/php, app .env files, cron jobs, systemd units);
  • data locations (databases, /var/www, uploads, Docker volumes);
  • external dependencies: DNS provider, domain registrar, email service, payment gateway, CDN, API keys;
  • who has access, and where credentials are stored.

3. Backups that match your RPO

Data Method Frequency
Databases Dumps (or binlog/WAL archiving for low RPO) Hourly to daily
Files and uploads restic / Borg / rsnapshot Daily
Configuration /etc in backups + etckeeper or Ansible Daily / on change
Docker volumes Volume backups + Compose files in Git Daily

Store copies off the server, ideally with a provider or location that’s independent from your main server, and protected against deletion. See restic backup, Borg vs restic, etckeeper, and Docker volume backups.

4. Make rebuilding fast

The quickest recovery is often a fresh server plus restored data, not repairing a broken one:

  • automate the base setup with Ansible or cloud-init. See Linux configuration management;
  • keep application code and Compose files in Git;
  • document every manual step that isn’t automated yet.

Reinstalling the OS from the VPS control panel, or ordering a new VPS in another location, then running your setup scripts, can bring a server back in under an hour. See reinstall the OS.

5. Runbooks for common disasters

Server compromised:

  1. Isolate it (firewall to your IP only, or shut it down). Preserve logs if you need forensics.
  2. Rotate all credentials (SSH keys, database passwords, API keys).
  3. Rebuild on a clean OS. Restore data from a backup taken before the compromise. Don’t restore old binaries or configs blindly.
  4. Patch the entry point before going live. See detect a compromised server.

Bad update / broken configuration:

  1. Roll back the config (etckeeper/Git), or the package version.
  2. If the system won’t boot, use the VNC console to fix it. See VPS VNC console.

Accidental deletion:

  1. Stop writes to the affected data, if possible.
  2. Restore the specific files or tables from the latest good backup.

Server or data centre unavailable:

  1. Provision a new server in another location.
  2. Restore from off-site backups, update DNS (keep TTLs short for critical records). See DNS propagation.

Disk full / service down: see disk full troubleshooting and VPS performance troubleshooting.

6. Practise: restore drills

At least twice a year:

  1. Spin up a test VPS.
  2. Rebuild using only your documentation and backups.
  3. Time it, and compare with your RTO.
  4. Fix every gap you found (missing secrets, outdated steps, forgotten cron jobs).

An untested backup or plan is a hope, not a plan. See backup strategy (3-2-1).

7. Keep the plan accessible and current

  • Store the plan and credentials outside the servers it describes (a password manager plus a shared document).
  • Update it whenever the setup changes.
  • Make sure more than one person can follow it.

Quick reference

Step Output
Targets RTO and RPO per service
Inventory What, where, dependencies
Backups Off-site, deletion-protected, frequency = RPO
Rebuild Scripts/Ansible + Git
Runbooks Compromise, bad update, deletion, outage
Drills Timed restore, twice a year

Related: VPS high availability and clone a Linux server.

  • Backup
  • Linux
  • Reliability