Buy backup storage from Images. It is one pool for the organization: $1.00 per 10 GB per month, billed hourly from account credit on the payer. Snapshots and backups on every tenant share it. Increase any time. Cancel schedules for 00:00 UTC on the 1st; copies stay for seven more days, then every copy in the organization is deleted.
Keep an off-server copy too
Cluster backups are on the same Proxmox connection as the guest. They are not an off-site archive. Copy irreplaceable databases and files somewhere you control, and test a restore once.
Buy storage
On Images, choose a size in 10 GB steps. The first hour is charged immediately. The Backups tab on a server uses that pool; it does not bill per server. Unmanaged servers can still be snapshotted or backed up if the pool has space and the guest is on a connection with backup storage configured.
Snapshots
Up to 5 QEMU snapshots on this server's disk. They die if you destroy the server. They still count against the pool. Rollback stops the guest, restores that point, and starts it again. Rollback only works on the source server, and only while the pool is active.
Backups
vzdump copies on the cluster backup drive. They stay until you delete them or the pool's grace window ends. They survive destroy. They count against the organization pool, but Images and deploy list only this tenant's copies.
- Restore this server overwrites the guest from a backup of this server.
- Deploy new on Images or checkout Backups creates a new VPS from the archive. Pick a plan with at least as much disk as the backup. There is no Cloud-Init password to set; the guest is as it was when the copy ran.
- Reinstall does not offer backups as a source.
Cancel
Cancel from Images. Billing continues until the 1st. Copies on every tenant are then kept for seven days before they are deleted. You can withdraw the cancel before the 1st, or increase the pool (that also withdraws the cancel).
Off-server copies
Cluster backups are not a substitute for a copy you control. A practical baseline is the working copy on the VPS, a vzdump or snapshot you can restore, and at least one copy on a different system.
Copy files off with rsync
From your own machine, pulling:
rsync -avz --delete [email protected]:/var/www/ ~/backups/web/
From the server, pushing to somewhere else:
rsync -avz /var/www/ [email protected]:/srv/backups/web/
Dump a database first, always
Never copy a live database's data directory. Dump it.
# PostgreSQL
pg_dump -Fc mydb > /var/backups/mydb-$(date +%F).dump
# MySQL or MariaDB
mysqldump --single-transaction --routines --triggers mydb \
| gzip > /var/backups/mydb-$(date +%F).sql.gz
Automate it
A daily cron entry is better than a perfect plan you never write:
sudo tee /etc/cron.daily/layerone-backup >/dev/null <<'EOF'
#!/bin/sh
set -eu
[email protected]:/srv/backups/$(hostname -s)
STAMP=$(date -u +%Y%m%dT%H%M%SZ)
install -d -m 700 /var/backups/layerone
pg_dump -Fc mydb > "/var/backups/layerone/mydb-$STAMP.dump"
rsync -az /var/backups/layerone/ "$DEST/db/"
rsync -az --delete /var/www/ "$DEST/www/"
EOF
sudo chmod +x /etc/cron.daily/layerone-backup
Use an SSH key with no passphrase restricted to that command on the far side, not a password.
Set retention before the disk fills
Decide how many daily, weekly, and monthly copies you need, then enforce that policy at the backup destination. Do not keep only the newest copy: corruption, accidental deletion, and compromise may be copied successfully before you notice them.
Monitor both backup age and destination capacity. A scheduled command that has not produced a recent file is a failed backup even if cron itself ran.
Protect the backup
- Encrypt the connection in transit, such as SSH for
rsync. - Use encryption at rest at the destination, or encrypt the archive before it leaves the server.
- Give the backup credential write access only to that server's destination.
- Keep deletion credentials separate where possible, so a compromised VPS cannot erase every retained copy.
- Never put database passwords directly in a world-readable script.
Test a restore
On an isolated test system, restore the newest file and prove the application can read it. For a PostgreSQL custom-format dump:
createdb appdb_restore_test
pg_restore --clean --if-exists -d appdb_restore_test mydb-YYYYMMDDTHHMMSSZ.dump
psql appdb_restore_test -c 'select now();'
dropdb appdb_restore_test
Use a disposable database and the correct application checks for your workload. Record the restore steps and how long they take. Repeat the test after changing database versions, storage layout, encryption, or backup tooling.
Before anything destructive
Take a cluster backup or a copy by hand before you reinstall, resize or destroy. Especially destroy: snapshots on this disk are gone with the server. vzdump copies stay on Images.
Rebuilding instead of restoring
The best answer for a lot of servers is to not have state on them. If a server can be rebuilt from a script and a data dump, an outage is an inconvenience rather than a disaster. The Client API exists for exactly that: deploy, configure, restore, in one script.