Skip to content

Snapshots & backups

Two ways to save a pod, for two different situations:

  • A snapshot rewinds the pod you have, in place. Fast. Reach for it before a risky change.
  • A backup is an off-node copy that restores as a new pod. Your original stays put. Reach for it for disaster recovery, or to spin up a copy.

Same slots on both: 5 per pod, of which 4 are yours to take by hand and 1 is held back for the schedule. The concepts page has the side-by-side table if you want it. Keeping them costs nothing - both are free.

Getting to the controls

Both live on the pod's own page, one tab apart. Every task below starts here.

  1. Open Pods in the console, or click Pods in the side panel. You land on the pods table.
  2. Click the pod's name in the Name column. The name is the link, not the row.
  3. You land on the pod's page, on the Overview tab. Under the pod's name is a strip of tabs: Overview, Metrics, Snapshots, Backups, Networking, Connection Strings.

Snapshots and Backups are the two this guide is about, and they are laid out the same way: a New button on the left of the bar above the table, an Auto schedule picker on the right of it, and the table of what you already have underneath.

Snapshots

Take one

  1. On the pod's page, click the Snapshots tab.
  2. Click New, at the left of the bar above the table.

There is no form to fill in - we name the snapshot for you. It runs in the background and lands in a few seconds to a minute. The new row shows Type Manual and Status pending, and the tab refreshes itself until the status reads Available.

Four manual snapshots per pod. Full? Delete one first: click the trash icon at the end of a row, then Delete in the Delete snapshot dialog. Deleting cannot be undone.

Restore one

  1. On the pod's page, click the Snapshots tab.
  2. Find the snapshot in the table. Restore stays greyed out unless its Status reads Available.
  3. Click Restore at the end of its row.
  4. Read the Restore snapshot dialog - if the pod is running, it tells you the pod will be shut down first and then stay stopped - and click Restore.

The pod rewinds in place and shows Restoring while it works. It needs to be Running or Stopped first - you don't have to stop it yourself; the restore takes care of that. When it's done, the pod sits stopped on the snapshot's state - start it again when you're ready.

Restoring is destructive

Anything written after the snapshot is gone. Want to keep the current state too? Take a manual snapshot first, then restore.

Automatic snapshots

  1. On the pod's page, click the Snapshots tab.
  2. Find Auto schedule, on the right of the same bar as New. It reads "Select schedule" until you set one.
  3. Pick one:
    • Daily - every day at 3:00 AM UTC.
    • Weekly - every Sunday at 3:00 AM UTC.
    • Monthly - the 1st of the month at 3:00 AM UTC.
    • Disabled - off.

There is no Save button. Picking is the saving, and "Snapshot schedule updated" confirms it.

Automatic snapshots rotate among themselves, and the rows whose Type reads Auto are the ones at risk. How many are kept depends on how much of the pod's allowance your manual snapshots are using: with four manual snapshots 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. Your manual snapshots are never touched by the schedule.

Backups

Take one

  1. On the pod's page, click the Backups tab.
  2. Click New, in the same spot as on the Snapshots tab.

This is a full off-node export, so it takes longer than a snapshot. The row moves through pending and running before it reads Available, and the Size column fills in once it lands.

Four manual backups per pod, same as snapshots. The auto schedule works the same way too: the Auto schedule picker on this tab, with the same Daily / Weekly / Monthly / Disabled options.

Restore one (into a new pod)

Restoring a backup builds a new pod from the copy and leaves your original alone.

  1. On the pod's page, click the Backups tab.
  2. Find the backup. Restore stays greyed out unless its Status reads Available.
  3. Click Restore at the end of its row.
  4. The Restore backup dialog spells out that this creates a NEW pod and does not modify the original. Click Restore.

The console doesn't ask you to name the new pod - we pick a name and the confirmation message tells you which one. (The API takes an optional name if you care what it's called.)

Because it creates a pod, a restore uses a slot from your pod limit and needs at least $3 credit. The new pod comes up in Restoring, and you'll find it in Pods.

A pod's Backups tab only lists that pod's backups, so a backup whose pod you have since deleted has nowhere in the console to appear. The account-wide list still has it, and it can still be restored - through the API.

Clone a pod

Want a copy of a live pod without dealing with a saved backup first? Clone it - same Region, same network, brand-new pod. It also uses a pod slot and needs credit.

  1. On the pod's page, click the ... button at the top right of the header, next to Shell if the pod is running.
  2. Choose Clone. It is only in the menu while the pod is Running or Stopped.
  3. Confirm in the Clone pod dialog, which warns you that the copy gets its own address and its own billing, by clicking Clone.

You land back on the pods table, where the copy shows up as Cloning until it is Running.

Which do I want?

Snapshot before you upgrade a package, edit a config, or try something you might regret - you want the fastest possible undo on this pod. Back up when you'd want the pod back even if the original were gone - a bad disk day, a fat-fingered rm -rf, or migrating to a fresh copy.

Belt and braces: turn on an auto snapshot and an auto backup on anything holding data you can't recreate.

Via the API

Everything here is in the API too - see snapshots and backups.

Built for the long tail.