Snapshots and backups

Snapshots

A snapshot freezes the state of your server's disk (and optionally its memory) at a point in time. It is created in seconds on the same NVMe storage as the VM, costs nothing and can be rolled back in seconds. Take one before anything risky: OS upgrades, kernel changes, database migrations, "just trying" a new firewall rule.

Create

Server page → Snapshots → Create, give it a name like pre-upgrade. Or through the API: POST /api/v1/instances/{id}/snapshot with {"op":"create","name":"pre-upgrade"}. The server keeps running; there is a brief I/O pause.

Roll back

Choose the snapshot → Rollback. The server is stopped, the disk reverted, and it is started again — everything written after the snapshot is lost. Total time is usually under a minute.

Delete

Snapshots slow writes slightly and consume space as the disk diverges, so delete them once you are confident. Keep at most a handful.

Why a snapshot is not a backup

• It lives on the same storage as the server. If the node's NVMe fails, the snapshot is gone with it.
• It is deleted when the server is terminated or reinstalled.
• It is a full-disk state, not a file-level restore — you cannot pull one file out of it.

Snapshots protect you from your own changes. Backups protect you from hardware failure, ransomware and accidental deletion of the server itself.

Backups on Joy

Backup space (add-on)

Order backup space in 10 GB steps on the deploy page or from the server's Billing tab. Then, on the Backups tab, choose a schedule (daily / weekly), a retention count and a window. Backups are full-VM images stored on separate storage in the same region; restore replaces the disk (or creates a new server from the backup, keeping the original). Restore time depends on disk size — roughly a minute per 10 GB.

File-level backups you run yourself

For databases and application data, in-guest backups are still the best practice because they are consistent and granular:

# nightly MySQL dump, kept 7 days, pushed off-node
mysqldump --single-transaction --all-databases | gzip > /var/backups/db-$(date +%F).sql.gz
find /var/backups -name 'db-*.sql.gz' -mtime +7 -delete
rclone copy /var/backups remote:bucket/$(hostname)/   # to any S3-compatible target, another Joy server via SFTP, etc.

Put the commands in /etc/cron.daily/backup (mode 755) and test a restore once. Joy object storage (coming) will be a first-class target; until then any S3-compatible bucket, or a second Joy VPS in another region with rsync over SSH, works.

Windows

Use Windows Server Backup (wbadmin) to a network share or a second disk, or a third-party agent. Snapshots from the console work the same way for Windows servers; a snapshot with memory keeps running applications.

A sensible policy

1. Snapshot before every change you cannot easily undo; delete it a day later.
2. Daily full-VM backups with 7-day retention for anything that matters.
3. Nightly application-level dumps pushed off-node with 30-day retention for databases.
4. Test a restore quarterly — a backup you have never restored is a hope, not a plan.

API reference

POST /instances/{id}/snapshot with op = create | rollback | delete and name; returns a job id to poll. See the API reference.