Backup and recovery

#What exists today

Both are taken by hand. There are no scheduled backups: nothing is copied for you daily or weekly, and a machine's Snapshots tab says so. If you need copies on a schedule, take them yourself, as below.

#Snapshots are not off-site

A snapshot lives in the same region as the disk it copies, on our hardware. It protects you from your own mistakes, like a bad upgrade or a deleted table, but it is not a second copy somewhere else. If you need an off-site copy, pull one down yourself.

#Losing a machine does not lose its snapshots

Destroying a virtual machine keeps the snapshots you took of it, and they keep billing until they are removed.

#A routine that works

1. Keep data on volumes, not the root disk. A root disk is wiped by a rebuild and goes with the machine. A volume outlives both, and you can snapshot it on its own.
2. Snapshot before every change you might undo. An OS upgrade, a schema migration, a config change you are not sure of. Name the snapshot after the change, like pre-postgres-16.
3. Back up your data from inside the machine too. pg_dump, mysqldump, or a copy of the files you care about, sent off the platform on a schedule with cron and a tool such as rsync or restic. This is what gets you back if the region itself is the problem.
4. Test a restore now and then. Restore a volume snapshot to a new volume, mount it, and check the files are there.

#Recovering