Offsite backups for a VPS

An offsite VPS backup is a copy of your server data that lives on another machine you control, not on the same hypervisor as your guest. Panel snapshots help with bad config changes, but they stay on our side of the fence. For host-level events you need dumps plus files copied with rsync, borg, or restic, and you should restore that copy once so you know it works.

Why panel snapshots are not enough

A snapshot in the VPS panel lives on the same hypervisor as the guest. It can roll back a bad sysctl or a broken package upgrade. It will not protect you if the host itself has a serious problem. Treat snapshots as a convenience before you clean a box, not as your only copy. Three copies, two kinds of media, and one offsite destination still apply.

How to build an offsite VPS backup

You have root on a KVM VPS, so you choose the tool and the destination. Dump databases while they are consistent, then copy dumps and site files to another VPS, object storage, or a machine in your office. The destination must not be a folder on this same VPS.

1. Dump databases while they are consistent. Run mysqldump --single-transaction (or mariadb-dump) against the schemas first. An rsync of a hot InnoDB datadir is not a backup. It looks complete until you start mysqld on it and recovery fails.
2. Copy the dumps and the site files to a machine that is not this hypervisor. Exclude /proc, /sys, /dev, /tmp, /run, and any restic or borg cache. Include /etc, /home, /var/www, /var/log, and the dumps.
3. Restore onto a second VPS once. A small sibling guest is enough. You will find a missing exclude, the wrong MySQL user, or TLS files you never copied.
4. Keep taking the copy on a schedule. Listed snapshots in restic are not proof. Proof is a second machine that serves the site with the database up.

mysqldump –single-transaction –all-databases > /root/all.sql && restic -r sftp:backup@offsite:repo backup /etc /home /var/www /root/all.sql

Change the restic destination to yours. borg create and rsync -aHAX --numeric-ids do the same job with different flags. borg and restic encrypt and dedupe. rsync is fine if the destination is already yours and you can live without history. A forgotten --exclude that drops the site directory only shows up at restore time, which is why the restore test is not optional.

Test the restore and write it down

If you cannot spare a sibling VPS, restore into a directory on a throwaway guest and run mysql < dump.sql there. Write down the destination, the exclude list, and the date of the last restore test. A backup you have never restored is only a rumor.

The usual failure is relying on snapshots alone, then opening a restore ticket with no dump after a host-level event. The second failure is rsync of /var/lib/mysql/ while MySQL is running. InnoDB files move under load and are not consistent. The restore may boot, then recovery can cost you a week.

If you need a snapshot revert, send us the guest id and the UTC time to rewind to. If you need help restoring an offsite copy, send the tool, the destination type, and whether the dump exists.