Appearance
Backups
A backup is an off-node export of a pod - a full copy kept on separate storage, away from the machine your pod runs on. When you restore a backup, you get a brand-new pod. Your original is never touched.
That's the whole point of backups, and the whole difference from snapshots. A snapshot rewinds the pod you have. A backup gives you a fresh pod built from a saved copy, which is what you want for disaster recovery, spinning up a copy to test against, or keeping the original safe while you experiment.
Slots and limits
Until paid backups start, each pod gets 5 backup slots, like snapshots: 4 manual plus 1 held back for the auto schedule. At the manual limit the request is refused (Backup limit reached. Maximum 4 manual backups per pod...); delete one before taking another. Five is the default; your account's Backups per pod limit is the real number, see account limits.
Once paid backups start, the limit goes away. You pay for each backup by its size, so keep as many as you like.
A backup runs in the background: it appears as pending, moves to running while the export is copied off the node, and lands on completed or failed. Only a completed backup can be restored.
Paid backups
Backups are becoming a paid resource, from a start date we announce by email at least 30 days ahead and show on the pricing page. Until that date nothing changes: backups are free, and the per-pod limit above still applies.
From the start date:
- Every backup taken from that date on (final backups aside, see below) is charged by the hour, from the moment it finishes until you delete it, for its size in GB (1 GB = 1024³ bytes). The rate is per GB a month, see the pricing page; a month there means 730 hours.
- There is no limit on how many backups you keep. Per-pod limits in Account Settings reads No limit for backups.
- Taking a backup still needs at least $3 of credit, as it always has.
- Each backup is its own line on your invoice, such as
backup - my-app (0.68 GB).
Snapshots stay free and keep their per-pod limit. Mailbox backups, which the platform runs for every mailbox, stay free as well.
A backup outlives its pod, and so does its charge: deleting a pod leaves its backups in place, billed until you delete them too. The Backups page lists them all, deleted pods included.
Backups from before the start date
Anything backed up before the start date stays free, and is deleted 60 days after the start date unless you keep it. A week before that, the account owner gets an email listing them. In the console each one carries a Free until badge with its date.
Automatic backups from before the start date don't count toward the number a schedule keeps, so for a while a pod holds its free older ones next to its new paid ones.
Older backups, restored on request
Backups made before our move to new backup storage show On request in the console. We restore those for you instead of in one click: choose Request next to one, and a support ticket opens with the backup's details filled in. They can't be kept, and they are deleted on the date shown under the badge, which we announce by email at least 30 days ahead.
Keeping a backup
Keep turns a free backup into a paid one that stays until you delete it. Billing for it starts at the later of the start date and the moment you kept it, so keeping one during the notice period costs nothing until the start date. Only a completed backup that is still free can be kept, and backups marked On request can't be. In the console it is the Keep link under the Free until badge; from code it is POST /api/backups/:backupId/keep.
Final backups
When an unpaid invoice ends with a pod being backed up and deleted (see when credit runs out), that last backup is labelled Final in the console. From the start date, a final backup is free and is deleted 60 days after it was taken, unless you keep it. A final backup taken before the start date is treated like any other backup from before then.
Auto schedule
Backups can run on a schedule, all at 3:00 AM UTC: Daily, Weekly (Sunday), Monthly (the 1st), or Disabled. Your manual backups are never touched by the schedule.
Until paid backups start, automatic backups rotate among themselves: with four manual backups there is room for one automatic one, so each run replaces the last, and with none the automatic ones fill all five slots before the oldest rotates out. A backup you have kept never rotates out.
From the start date, the schedule keeps the last N instead: 5, unless you pick another number from 1 to 365 in the Keep the last field beside the schedule (it appears once a start date is announced). After each scheduled backup finishes, the pod's automatic backups taken since the start date are trimmed to that number, oldest first. Automatic backups from before the start date are not counted; they stay free until their Free until date. Manual backups and kept backups are never pruned. A lower number takes effect after the next scheduled run, and turning the schedule off stops new automatic backups without deleting the ones you have, so delete those yourself if you would rather not pay for them. Pick the number you would actually restore from; a year of nightlies is mostly a year of invoices.
Restoring and cloning
Two ways to turn a saved pod into a running one, and both make a new pod:
- Restore takes an existing backup and rebuilds it as a new pod.
- Clone skips the saved-backup step and copies a live pod straight into a new one.
Either way the new pod inherits the source's workload, version, compute size, storage size, Region, network and firewall, and gets a fresh name, hostname and external port. Name it yourself, or let us pick a random name.
Because each creates a pod, both need at least $3 of credit and use a slot from your pod limit. At the limit, nothing is torn down - the request is simply refused with Pod limit reached for your account.
Snapshot vs backup
| Snapshot | Backup | |
|---|---|---|
| Where it lives | On the pod's own storage, beside it | Off-node, on separate backup storage |
| Restore gives you | The same pod, rewound | A new pod, built from the copy |
| Your original after restore | Overwritten, and left stopped | Untouched, still running |
| How long it takes | Seconds - nothing is copied off the node | Longer: the whole disk is exported and copied away |
| Survives losing the pod's node | No | Yes |
| Slots per pod | 4 manual + 1 auto | 4 manual + 1 auto until paid backups start, then no limit |
| Cost | Free | Free until paid backups start, then per GB a month (see the pricing page) |
| Reach for it when | You are about to do something risky to a pod you want to keep | You would want the pod back even if the original is gone |
Rule of thumb: snapshot before you change something; back up in case you lose something.
A note on the account-wide list
The console's Backups page, in the side panel under Workspace, lists every backup on the account, including backups of pods you have since deleted, with Restore and Delete on every row and Keep on free ones. The API has the same list as GET /api/backups.
Mailbox backups are not on it. The platform runs those for every mailbox, and they stay free.