VPS Backup Strategy: The 3-2-1 Rule, Immutable Copies and Restore Tests

What to back up and what to skip

Back up what you cannot recreate from a script or a package manager. For most small servers that is:

• Application data: uploads, user files and anything the app writes at runtime.
• Databases, as proper dumps rather than copies of live data files. Use pg_dump for PostgreSQL or mysqldump --single-transaction for MySQL so the dump is consistent while the database keeps serving traffic.
• Configuration: /etc, application configs, systemd units, crontabs, and Docker compose files and volumes.
• Secrets and keys you cannot regenerate, stored encrypted, plus the backup encryption passphrase itself, kept somewhere that is not the server.

Skip operating system packages, caches and temporary files, which you can reinstall. Logs are optional, but keep a copy of authentication and application logs elsewhere if you want evidence after an incident, as covered in the breach response guide.

The 3-2-1 rule, and what it misses

The rule says to keep three copies of your data, on two different kinds of storage, with one copy off-site. It is generally credited to photographer Peter Krogh, who described it in The DAM Book. The point is to remove single points of failure: a dead disk, a deleted volume or a lost data centre should never take every copy with it.

What the rule does not say is whether an attacker can reach those copies. Some vendors extend it to 3-2-1-1-0: one more copy that is immutable or air-gapped, and zero errors after automated verification. The naming varies by source, but the two additions are the right ones for a server that can be compromised. Follow the rule, then make sure at least one copy cannot be changed or deleted from the production server, and that you verify what you wrote.

Why provider snapshots are not a strategy

VPS snapshots are convenient, fast to take and useful before a risky change. They are a poor primary backup for three reasons. They usually live in the same provider account as the server, so one compromised account, one billing lock or one provider incident can remove the server and its snapshots together. They capture the whole disk, including whatever malware was already on it. And restoring typically means replacing the entire machine, which is a blunt tool when you only need last Tuesday's version of one directory.

Keep snapshots as a convenience, and keep independent file-level backups stored somewhere your VPS account cannot touch.

Encrypted backups with restic or Borg

Two open-source tools do most of what a small server needs: both deduplicate, compress, support retention policies and encrypt data before it leaves the server. According to the restic documentation, a password is required to access the repository, so protect it and store a copy offline, because without it the backups are unreadable. A minimal restic routine looks like this:

export RESTIC_REPOSITORY=sftp:backup@backup-host:/srv/restic/vps1
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /var/www /srv/data
restic check

Borg offers an important extra: an append-only mode. The Borg documentation explains that in this mode "Borg will never overwrite or delete committed data," and that it is mainly intended to protect backups if a client machine is compromised. You enable it by restricting the client's key on the backup host:

# ~/.ssh/authorized_keys on the backup host
command="borg serve --append-only --restrict-to-path /srv/backups/vps1",restrict ssh-ed25519 AAAA... vps1-backup

# on the VPS
borg init --encryption=repokey ssh://backup@backup-host/srv/backups/vps1
borg create --stats ssh://backup@backup-host/srv/backups/vps1::{hostname}-{now} /etc /var/www /srv/data

Read the caveats in the docs: append-only only protects the repository's low-level structure, pruning and deleting from a normal session can still permanently remove data, plain rm on the backup host bypasses it, and an attacker could still corrupt a few chunks. The Borg authors recommend running borg check --verify-data before pruning.

Make one copy impossible to delete

For at least one copy, take deletion off the table. With object storage this is called Object Lock. In Amazon's words, S3 Object Lock "can help prevent Amazon S3 objects from being deleted or overwritten for a fixed or variable amount of time, or indefinitely," using a write-once-read-many model, and it works only on buckets with versioning enabled. In compliance mode no user, including the account's root user, can delete a protected version during the retention period; governance mode lets specially permitted users override it. Other providers offer similar features under names such as immutable buckets.

CISA gives the same advice in security terms: "enable delete protection or object lock on storage resources often targeted in ransomware attacks." Treat it with some care, though. The same guide cautions that immutable storage "does not meet compliance criteria for certain regulations," and a lock protects only the versions you locked, so set retention long enough to outlast the time it takes you to notice a problem. A pull-based design helps too: have a separate backup host fetch data from the VPS, so the VPS never holds credentials that can erase history. The ransomware protection guide explains why this separation matters.

Test restores, or you have nothing

CISA's advice is to "regularly test the availability and integrity of backups in a disaster recovery scenario." Do two kinds of test. A light one monthly: restore a single file and a database dump to a scratch location and check they open. A full one at least quarterly, and after major changes: build a fresh VPS, restore onto it, start the application and confirm it works.

Use the full test to measure two numbers you should know before an incident. Your recovery point objective is how much recent data you can afford to lose, which sets how often you back up. Your recovery time objective is how long you can be down, which tells you whether your restore process is fast enough. Also run the integrity tools, restic check or borg check --verify-data, so corruption shows up in a drill rather than during an outage. Keep several generations: CISA warns that dropper malware must be identified before restoring, and an older clean copy gives you somewhere to go if the newest one is already infected.

Retention, schedule and monitoring

A reasonable starting point for a small server is a nightly backup, with retention of roughly seven daily, four weekly and six monthly copies, adjusted to how fast your data changes and how long a problem might go unnoticed. Run the job from a systemd timer or cron, and log its output. Most important of all, alert when it fails or does not run: a silent backup job is the commonest cause of discovering at the worst moment that there is nothing to restore. The server monitoring guide shows how to wire that up.

Finally, write the restore procedure down, including where the passphrase is, which host holds the repository and the exact commands. In an incident you will be tired and short of time, and a tested checklist is worth far more than good intentions. It also belongs in your wider hardening plan: see the VPS security checklist.

A recent reminder of why a copy must live outside the provider: the Yandex data center outages of October 2026.

Terms used here: RPO and RTO and Object Lock.