Backing up your VPS

What this is#

How to actually keep your data safe on a VPS. Your data is your responsibility with any self-managed host, and the good news is that a genuinely solid backup setup takes an evening to build and then runs itself.

First, a distinction that bites people: redundancy is not backup. Our nodes run RAID10 and redundant everything, which protects against a dead disk, but it faithfully replicates your mistakes too. Most real-world data loss is a deleted file, a botched upgrade, a bad migration, ransomware, or a compromise, and against all of those, only a backup helps.

What to back up#

Split your VPS mentally into two piles:

• Irreplaceable: your databases, uploaded files, application data, configs you've sweated over, TLS keys and certs. This is what backups are for.
• Rebuildable: the OS and installed packages. You can reinstall those in minutes, so most people don't image the whole OS themselves, they keep a note (or script) of how the server was set up, plus the data.

If you can answer "how would I get from a fresh reinstall back to a working server?", you know exactly what belongs in the backup.

The 3-2-1 rule#

The classic standard, and it maps neatly onto a VPS:

• 3 copies of your data (the live one counts as one),
• on 2 different systems,
• with 1 off-site, away from the VPS and ideally away from any single provider.

A copy that lives only on the VPS itself is not a backup: whatever takes out the server (compromise, deletion, a mistake with rm) takes the "backup" with it.

Databases need dumps, not file copies#

Copying a running database's files produces backups that may not restore. Dump instead, on a schedule:

• MySQL/MariaDB: mysqldump --single-transaction dbname > backup.sql
• PostgreSQL: pg_dump dbname > backup.sql

Run it nightly from cron to a folder like /var/backups/, then let your backup tool ship that folder off-site. Bonus: a nightly dump inside the VPS also makes our Nightly Backups image cleanly restorable, since the dump is a consistent copy sitting in the image.

Tools that work well#

Any of these, automated with cron or better, a systemd timer (logged runs, catch-up after downtime, no overlaps), is a real setup:

• restic (our default recommendation): encrypted, deduplicated, incremental, works with any S3-compatible storage or SFTP, and retention is one flag (restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune). One tool does the whole job.
• BorgBackup: the same virtues, best when your destination is another Linux box you control.
• rclone: syncs directories to almost any cloud storage; great for shipping a backups folder off-site.
• rsync to another server: simple and battle-tested, though it's a mirror rather than versioned history unless you add snapshots.
• Even a tar + cron job shipped off-site beats nothing, start simple rather than not at all.

Where to send them (off-site)#

• Object storage is the sweet spot for price and durability: Backblaze B2, Cloudflare R2, Wasabi, or any S3-compatible bucket. Pennies per month for typical site data.
• Another server you control, with a different provider or at home (a NAS), also works well.
• The principle: at least one copy should survive the total loss of this VPS and be independent of any single company, including us.

Test your restores#

An untested backup is a hope, not a backup. Twice a year, actually restore something: pull a file back from restic, load a database dump into a scratch database, and confirm it's all there. And make failure noisy, check that your backup job alerts you when it stops working (a cron email, or a dead-man's-switch ping service), because backup jobs love to die silently the month before you need them.

Where our Nightly Backups add-on fits#

Nightly Backups images your whole VPS once a night with 3-night retention, with self-service full restore, per-file recovery, and disk-image download. It's $5/month on Linux and Windows VPS (enable it here) and included free on Premium VPS.

Use it in addition to your own backups, not instead of them. The two cover different failures:

• Nightly Backups is the fastest way back from "I broke the server last night", a whole-server rollback or a quick file recovery, no setup required.
• Your own off-site backups give you long retention, history beyond three nights, and a copy that exists outside our platform entirely.

Together that's a genuinely robust setup. Either alone has a gap.

A solid starter recipe#

1. Enable Nightly Backups on the VPS.
2. Add a nightly database dump to /var/backups/ via cron.
3. Run restic daily to an off-site bucket (site files + /var/backups/ + configs), with --keep-daily 7 --keep-weekly 4 --keep-monthly 6.
4. Put a restore test in your calendar twice a year.

(Steps 2 and 3 are a script and a schedule, exactly the kind of thing an AI chatbot drafts correctly from your paths and bucket details, you review the retention flags and paste it in.)

An evening of setup, and every failure mode short of "the internet ends" is covered.

Still need help?#

You can open a support ticket. So we can help on the first reply, it's worth mentioning:

• the VPS hostname or IP,
• what data you're trying to protect, and what you've set up so far.

Related questions#

• "How should I back up my VPS?"
• "Do you back up my VPS for me?"
• "How do I back up my database properly?"
• "What backup tool should I use on a VPS?"
• "Where should I store my backups?"
• "Is the Nightly Backups add-on enough on its own?"
• "How do I know my backups actually work?"