VPS Backups and Snapshots: What Each Provider Line Offers

Quick answer: backup options depend on which provider line your server runs on. Hetzner and DigitalOcean have automatic backup add-ons, the Lightsail lines sell snapshot allowances, and the other lines currently have no backup add-on at checkout, so you should run your own. Either way: a provider-side snapshot is not an offsite backup, keep an independent copy of anything you cannot afford to lose.

What each line offers today

• Hetzner Cloud: automatic backups add-on from $20 per month, plus snapshot storage billed at $0.65 per GB per month.
• DigitalOcean: backups add-on from $15 per month, plus a snapshot allowance option from $15 per month.
• Amazon Lightsail (Linux and Windows): snapshot allowance option from $10 per month.
• Vultr (Linux, Windows, GPU), Google Cloud, Alibaba Cloud (international and mainland China), Amazon EC2, and our custom Linux line: no backup add-on in the order form today. If you want provider-side protection on one of these, ask us via ticket what can be arranged for your server; otherwise plan on self-managed backups from day one.

These reflect our current catalog; add-ons for existing servers are arranged through a support ticket rather than switched on from the order form.

Snapshots versus backups

The two words get used loosely, but they are different tools:

• A snapshot is a point-in-time image of the whole disk, taken when you ask for one. It is ideal right before risky work: a distro upgrade, a big config change, a migration.
• A backup schedule takes images automatically on a cadence, so you have recent restore points without thinking about it.

Both live with the same provider that runs your server. That means they protect you against your own mistakes and disk-level problems, but not against everything: they are not an independent, offsite copy of your data.

The independent copy

For anything irreplaceable, keep at least one copy that does not depend on the VPS or its provider. A simple, battle-tested approach is restic pushing to any SFTP-capable destination (another VPS, a NAS at home, a storage box anywhere):

restic -r sftp:user@backup-host:/srv/restic-repo init
restic -r sftp:user@backup-host:/srv/restic-repo backup /etc /var/www /home
restic -r sftp:user@backup-host:/srv/restic-repo snapshots

restic encrypts and deduplicates, so repeated runs are fast and the destination host never sees your data in the clear. If you prefer plain file copies, rsync does the job too; our guide on scp and rsync covers the syntax in both directions.

Databases need a dump first

Copying a live database's files can produce a corrupt backup. Dump first, then back up the dump:

mysqldump --single-transaction --all-databases > /root/db-$(date +%F).sql

For PostgreSQL the equivalent is pg_dumpall. Schedule the dump a few minutes before your backup job so every run captures a consistent copy.

Test your restores

A backup you have never restored is a hope, not a plan. Once a quarter, restore a file or a database dump somewhere harmless and confirm it opens. This takes ten minutes and is the difference between an inconvenience and a disaster when you actually need the copy.

What to back up (and what not to)

• Yes: application data, databases (as dumps), /etc configuration, TLS certificates and keys, crontabs, anything hand-edited.
• Usually no: the operating system itself, package caches, and anything you can reinstall from a package manager in minutes. Reinstalling the OS and restoring data is often faster and cleaner than restoring a full-disk image of a sick system.

How often, and how many to keep

Match the cadence to how much work you can afford to lose. A busy application database deserves nightly dumps at minimum; a mostly-static site is fine with weekly runs plus a snapshot before changes. Keep more than one generation: a corrupted file quietly backed up for a week destroys every copy if you only keep one. A simple retention that works for most servers is seven daily, four weekly, and a few monthly copies; restic can enforce that automatically:

restic -r sftp:user@backup-host:/srv/restic-repo forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Automating the run

A backup that depends on you remembering it will eventually be a backup that did not happen. Put the dump and the backup into cron:

15 3 * * * mysqldump --single-transaction --all-databases > /root/db-$(date +\%F).sql
45 3 * * * restic -r sftp:user@backup-host:/srv/restic-repo backup /etc /var/www /root/db-*.sql

Stagger the times so the dump finishes before the backup starts, and check the job output for a while after setting it up.

Snapshot before you change things

On lines with snapshot support, the single highest-value habit is taking one immediately before risky work: major version upgrades, kernel changes, big migrations. If the change goes wrong, you roll back in minutes instead of rebuilding. Where snapshots are not available, take a fresh restic run and copy your configs aside before you start.