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). Stopped, Suspended and Trashed VMs are the same mechanism — the disk is archived and nothing bills; they differ only in how long they're kept (stopped/Suspended ~30 days, Trash 24h).
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 VM has to be running (or crashed). A restore rewinds the disk of a VM that is there — it relaunches in place, on the host, into the network it already has. A stopped VM has none of that: no host, no IP, no disk on any machine. So if the VM is stopped, start_vm first, then restore.
When a VM isn’t running: stopped, Suspended & Trash
All three are the same mechanism. Whichever way a VM comes to rest, the platform does the same thing: it halts the VM, releases every resource it held (CPU, memory, IP, disk on the host), and archives the disk — and any attached volume — to object storage. Nothing bills in any of these states.
They differ only in who triggered it, how long the archive is kept, and whether the VM stays listed:
| State | How it starts | Visible in list_vms? | Billing | Data window | How it comes back |
|---|---|---|---|---|---|
| Stopped | you call stop_vm | yes | nothing | archive kept ~30 days | start_vm |
| Suspended | auto, at zero balance or your monthly spend cap | yes | nothing | archive kept ~30 days | a top-up (or raising the cap) — automatic |
| Trash | you call destroy_vm on a VM older than ~1h | no (hidden; see list_trash) | nothing | archive + backups kept 24 hours | resume_vm |
Notes:
- Stopping is how you stop paying. A stopped VM costs nothing, and
start_vmbrings it back — you don’t have to destroy anything to save money. See Billing FAQ. - Coming back takes about a minute, and scales with your disk. Starting a rested VM pulls its whole archive back out of object storage onto a host with capacity, then boots it — roughly 45 seconds for a typical VM (a few GiB of data), and longer the fuller the disk. That download is most of the wait; the boot itself is the usual ~15 seconds. In-memory state is lost — treat it as a power cycle. Services launched ad-hoc need relaunching; put persistent ones in
/etc/rc.local. - A stop/start is not a reboot. If you just want to bounce the machine, use
restart_vm: seconds, same host, same IP, disk untouched. Stopping and starting releases everything and hauls the disk to object storage and back — the right thing when you’re done for a while, the wrong thing when you wanted a reboot. - A rested VM isn’t tied to its old host. It restores onto whatever host has capacity, so a stop/start can move it. Its id and public URLs survive the round trip, so anything bound to those keeps working.
- Suspended stays visible on purpose, so you can see you need to top up. Full detail in the Billing FAQ.
- Trash is the destroy recovery window:
resume_vmbrings a destroyed VM back with its backups intact for 24 hours, then the row, domains, backups, and their stored objects are permanently reclaimed together. A VM destroyed within its first hour of life skips Trash — no recovery window (the undo is for “I deleted my prod thing”, and a minutes-old VM has nothing to recover). Terminal-state VMs (crashed/error/lost) also skip Trash.
So a destroy_vm you regret is recoverable for a day (unless it was minutes old); a stopped or Suspended VM has a longer ~30-day window, and a Suspended one revives the moment you top up.
To require a confirmation step before a destructive action like destroy_vm runs at all, turn on email confirmation on destructive actions.