A Practical VPS Backup Strategy (3-2-1 Rule)

Written by the ApexVPS team • Last updated: July 2026 • 7 min read

A reliable VPS backup strategy is the difference between a five-minute recovery and a very bad week. Servers fail, disks corrupt, deploys go wrong, and a single mistyped command can wipe a directory. The Cloudflare Learning Center and most infrastructure teams point to the same simple discipline: the 3-2-1 rule. This guide shows how to apply it to a real virtual server, which tools to use, and how to schedule and test everything so a restore actually works when you need it.

What the 3-2-1 Rule Means

The 3-2-1 rule is a decades-old backup principle that stays true no matter where your server lives:

• 3 copies of your data — the live copy plus at least two backups.
• 2 different media or storage systems — so a single failure cannot take out both copies at once.
• 1 offsite copy — physically or logically separate from the machine you are protecting.

On a VPS this usually means your running server, a local backup repository, and an encrypted copy pushed to remote storage in a different location. The point is redundancy without a single shared point of failure.

What to Back Up on a VPS

Backing up the whole disk block-by-block is wasteful and slow. A good backup plan targets the three things that are genuinely hard to recreate.

Application data and files

Uploaded files, website roots, container volumes, and anything users generate. Typical paths include /var/www, /srv, /home, and your Docker volume directory. If you self-host apps like a file server or wiki, this is where your irreplaceable content lives — see our guide to running a VPS for self-hosting for how those directories are usually laid out.

Databases

Never copy live database files while the service is running — you can capture a half-written, corrupt state. Instead export a consistent dump. For MySQL or MariaDB:

mysqldump --single-transaction --routines --triggers \
  -u backup -p mydatabase > /srv/backups/mydatabase.sql

The --single-transaction flag gives a consistent snapshot of InnoDB tables without locking them. For PostgreSQL, use pg_dump instead:

pg_dump -U postgres -Fc mydatabase > /srv/backups/mydatabase.dump

System and service configuration

The files that make your server yours: /etc (nginx, systemd units, cron, SSH config), package lists, TLS certificates, and firewall rules. Rebuilding these from memory after a failure is exactly the tedious work backups exist to avoid.

Choosing Your Backup Tools

Three tools cover almost every VPS case. Pick based on how much you value deduplication and encryption.

restic — encrypted, deduplicated snapshots

restic is a modern, single-binary backup tool that encrypts and deduplicates by default. Initialise a repository once, then run backups against it:

# One-time: create an encrypted repository
restic init --repo /srv/backups/restic

# Back up files and your database dump
restic -r /srv/backups/restic backup /etc /var/www /srv/backups/mydatabase.sql

# List what you have
restic -r /srv/backups/restic snapshots

BorgBackup — deduplicating archives

BorgBackup offers similar deduplication and compression with a slightly different workflow:

borg init --encryption=repokey /srv/backups/borg
borg create --stats /srv/backups/borg::'{hostname}-{now}' /etc /var/www

rsync — simple file mirroring

When you just need a fast mirror of files to another host, rsync over SSH is hard to beat:

rsync -aAX --delete /var/www/ [email protected]:/backups/www/

The -aAX flags preserve permissions, ACLs, and extended attributes; --delete keeps the mirror in step with the source. rsync alone does not version history, which is why many teams pair it with restic or borg.

Automate the Schedule With cron

A backup you have to remember to run is a backup that will not happen. Put your steps in a script, make it executable, and schedule it with cron. Edit your crontab with:

crontab -e

Then add lines like these:

# Full file + config backup every night at 02:15
15 2 * * * /usr/local/bin/vps-backup.sh

# Database dump every hour on the hour
0 * * * * /usr/local/bin/db-dump.sh

Log the output, and have the script exit non-zero on failure so you can wire it into the monitoring and alerting features that come with your plan. A silent backup failure is worse than no backup, because it feels safe.

Keep a Real Offsite Copy

The "1" in 3-2-1 is the part most people skip. A backup sitting on the same server it protects disappears with that server. Push an encrypted copy somewhere independent — object storage, a remote SFTP box, or another provider. restic and borg both write directly to remote repositories, for example over SFTP:

restic -r sftp:[email protected]:/backups/restic backup /var/www

Because restic and borg encrypt before the data leaves your VPS, the remote host never sees your plaintext. Prune old snapshots on a policy so storage does not grow forever:

restic -r /srv/backups/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Test Your Restores — Every Time

An untested backup is a rumour. Schedule a periodic restore into a throwaway location and confirm the files and databases come back intact:

# Restore the latest snapshot into a scratch directory
restic -r /srv/backups/restic restore latest --target /tmp/restore-test

# Verify repository integrity
restic -r /srv/backups/restic check

# Re-import a database dump into a scratch database
mysql -u root -p restore_test < /srv/backups/mydatabase.sql

If the restore succeeds and the data matches, you have a strategy. If it does not, you have just learned that on a Tuesday afternoon instead of during a real outage.

Snapshots Are One Layer, Not the Whole Strategy

Every ApexVPS plan includes automated backups — daily snapshots on Starter Pro and hourly snapshots on Business — and they are genuinely useful for quick rollbacks after a bad deploy or an accidental deletion. But be honest about what they are: a convenient first layer that lives on our platform. They are not a substitute for the offsite, independently verified copy that the 3-2-1 rule requires. Treat platform snapshots as your fast local restore point, and run your own restic or borg job to satisfy the offsite and tested-restore parts of the rule. That layered approach is what separates a hopeful setup from a resilient one, whether you self-host apps like Nextcloud or run a production database.

Your VPS Backup Strategy Checklist

Pulling the pieces together, a complete backup strategy for a virtual server looks like this. Work through it once, script it, and let cron carry it forward:

• Identify what matters — application files, database dumps, and the configuration under /etc.
• Pick a tool — restic or BorgBackup for encrypted, deduplicated, versioned backups; rsync for simple mirrors.
• Dump databases consistently — mysqldump --single-transaction or pg_dump, never a raw copy of live files.
• Automate it — schedule the script with cron and alert on any non-zero exit.
• Push one copy offsite — encrypted, on independent storage, with a sensible retention policy.
• Test restores regularly — restore to a scratch location and confirm the data is intact.

Do these six things and the 3-2-1 rule stops being theory and becomes a habit your infrastructure can lean on. The upfront hour of setup is trivial next to the cost of discovering, mid-incident, that your only copy was on the disk that just died.

Frequently Asked Questions

Do provider snapshots count as a backup strategy?

Snapshots are one useful layer, but not a complete strategy. Our daily and hourly snapshots protect against most short-term mistakes, yet they live on the same platform as your server. A full 3-2-1 backup strategy still needs an independent, offsite copy you control and restores you have actually tested.

How often should I back up a VPS?

Match frequency to how much data you can afford to lose. Static files and configs can be backed up daily, while active databases often justify hourly dumps. Use cron to automate the schedule so backups never depend on remembering to run them.

What is the best tool for VPS backups?

restic and BorgBackup are both excellent: they deduplicate, compress, and encrypt backups, and support offsite repositories. rsync is fine for simple file mirroring, and mysqldump or pg_dump handle database exports. Many setups combine a database dump with a restic or borg run.

How do I know my backups actually work?

Test restores on a schedule. Restore into a temporary directory, verify file contents and checksums, and import a database dump into a scratch database. A backup you have never restored is only a hopeful guess, not a recovery plan.