Backups & restore
Every VM is snapshotted daily, with a rolling retention (5 by default, set by your account entitlements). Take an on-demand backup before risky changes with create_backup; restore in place with restore_vm_from_backup (same VM, disk rewound). Destroyed VMs are recoverable for 24h via resume_vm; stopped VMs keep billing.
Superjolt protects VM data two ways, and gives destroyed VMs a recovery window.
Scheduled vs on-demand
- Scheduled (automatic): every VM is snapshotted daily, with a rolling retention (5 by default, set by your account entitlements) — old scheduled snapshots roll off automatically. Nothing to set up; there is no schedule to attach. (You can’t delete a scheduled backup — retention governs them.)
- On-demand: call
create_backupbefore a risky change. On-demand snapshots persist until you delete them (delete_backup).
list_backups shows every snapshot for a VM (newest first) with its kind (scheduled / on_demand), takenAt, and sizeBytes.
Restore
restore vm-abc123 from yesterday's backup
restore_vm_from_backup replaces the rootfs and reboots the VM. It’s the same VM — same id, same IP, same ports, same attached domains. Only the disk goes back in time. Anything written since that snapshot is lost, so it’s a deliberate, destructive roll-back, not a copy.
The 24-hour graveyard
What happens to a VM’s data when it goes away depends on how:
stop_vm— VM is off but intact. Still billing at the tier rate;start_vmresumes instantly. (See Billing FAQ.)destroy_vm— a long-lived VM moves to the graveyard: IP/RAM freed, but rootfs + backups preserved for 24 hours, recoverable withresume_vm. After 24h everything is permanently reclaimed (row, host state, domains, backups, S3 objects). A VM destroyed within its first hour of life skips the graveyard — no recovery window.- archived (balance hit zero) — rootfs preserved 24h; top up +
resume_vmto restore.
So a destroy_vm you regret is recoverable for a day (unless it was minutes old); a top-up revives an archived VM within the same window.