Take a snapshot, and put it back

What a snapshot is here

A point-in-time copy of the instance disk, taken at the storage layer and written to different storage than the instance runs on. Slots are sold in packs; one slot holds one snapshot and is reused when you overwrite it. Taking one does not pause the instance, and the copy-on-write cost in the minutes afterwards is small enough that it rarely shows up in a latency graph.

It is not a backup. A snapshot lives at the same site as the instance, which protects you from your own rm and not from the site. Off-node backup is a separate add-on, encrypted on your side, written to a different city.

Taking one

curl -s -X POST https://paragonvps.com/api/v1/instances/<instance-id>/snapshots -H "Authorization: Bearer $Paragon_TOKEN" -H "Content-Type: application/json" -d '{"label":"pre-upgrade"}'

curl -s https://paragonvps.com/api/v1/instances/<instance-id>/snapshots -H "Authorization: Bearer $Paragon_TOKEN" | jq -r '.[] | .id + " " + .label + " " + .created'

Crash-consistent, and when that is not enough

A snapshot of a running instance is exactly what the disk would look like after a power cut. PostgreSQL, MariaDB and every journalling filesystem in our images recover from that state on start, because recovering from it is what they are for. The risk is not really the database. It is your own application, halfway through writing two files that have to agree with each other.

Where you need a clean line, flush and freeze the data volume for the second it takes:

sync
fsfreeze -f /srv/data
# take the snapshot here
fsfreeze -u /srv/data

Freeze the data volume. Never freeze /. A frozen root filesystem stops the process that is meant to unfreeze it from doing anything at all, and the way out is a hard reset.

For a database the tidier option is to snapshot and let the engine recover, then check that it did:

sudo -u postgres pg_isready
journalctl -u postgresql -n 50

Restoring

A restore stops the instance, swaps the disk for the snapshot, and starts it again. Seconds, not minutes. Addresses do not change, the reverse DNS you set stays set, and everything written since the snapshot is gone.

That includes whatever made you decide to restore. If there is any chance you will want to read the logs from the broken state, take a snapshot of it first and then restore over the top.

curl -s -X POST https://paragonvps.com/api/v1/snapshots/<snapshot-id>/restore -H "Authorization: Bearer $Paragon_TOKEN"

Scheduling

Per-instance schedules arrived with platform revision 5.4. Daily at a fixed hour with a rolling window is the common choice: the oldest is dropped once the slots are full.

curl -s -X PUT https://paragonvps.com/api/v1/instances/<instance-id>/snapshot-schedule -H "Authorization: Bearer $Paragon_TOKEN" -H "Content-Type: application/json" -d '{"cron":"20 3 * * *","keep":7}'

Pick an hour that is quiet for your workload rather than quiet for ours. The storage cost of a snapshot is proportional to what changes afterwards, so a schedule that fires during your nightly batch job holds far more data than one that fires an hour later.

Cancelling an instance deletes its snapshots

Immediately, with no grace period, because they are stored against the instance. Anything you want to keep past cancellation belongs in off-node backup or somewhere that is not us at all.