Snapshot and restore a Cube

A snapshot is a point-in-time copy of a Cube's disk, saved to cloud storage. Taking one does not interrupt anything — the Cube keeps running while it uploads. Restoring one does interrupt: the Cube is stopped, its disk is replaced, and it starts again.

Snapshots and Backups are not the same thing

Both copy your disk, and the difference only matters at the moment you need one:

• Snapshots live with the Cube. They are cheap, incremental, and ideal for "undo the last hour". They are deleted when the Cube is deleted.
• Backups outlive the Cube. A Backup stores the disk and the Cube's configuration — CPU, RAM, disk, domains, TCP mappings — so you can redeploy an identical Cube later, after the original is gone.

If a copy needs to survive deleting the Cube, it must be a Backup. You can promote any snapshot with Save as Backup.

How many of each you get, and how often automatic snapshots run, depends on your tier. The Welcome tier has no automatic snapshots and no Backups — manual snapshots only. Higher tiers add automatic snapshots on a cadence and a retention ladder.

Step 1 — Take a snapshot

Open the Cube's Snapshots tab and choose Create Snapshot. Give it a name that says what state it captures — before-upgrade is useful six weeks later in a way that snapshot-3 is not.

The Cube stays up throughout. The list separates Auto from Manual, and each snapshot reports the Added size — the deduplicated new data it contributed, not the size of your whole disk. The first snapshot uploads everything; later ones only what changed, which is why they are cheap to take often.

Take one before anything you might want to undo: a distribution upgrade, a database migration, a config change you are not sure about.

Step 2 — Restore

On the snapshot you want, choose Restore. The confirmation is worth reading, because it describes exactly what happens:

"This will stop the Cube, replace the disk with snapshot …, and restart it. Any data written since the snapshot was taken will be lost."

All three parts are literal. The Cube goes down, the whole disk is replaced — not merged — and everything written after the snapshot is gone, including data you wanted to keep that happens to live on the same disk. If some of it matters, take a fresh snapshot before restoring the old one; then you can move between the two.

The Cube reboots as part of the restore, so services come back the way they would after any reboot — which is to say, only the ones you systemctl enabled.

Step 3 — Check it actually came back

A restore that reports success is not the same as a Cube that works. Reconnect and confirm the things you know should have changed:

uptime -p                        # up 0 minutes — the Cube did cycle
systemctl is-active <your-service>
curl -s http://127.0.0.1:<port>/

If you serve the Cube on a domain, check that too — it should return to normal once the app is listening again. A 503 means Krova is reaching the Cube but not your app, so the service has not come up yet.

The other things you can do with a snapshot

• Save as Backup — promote it to a copy that survives deleting the Cube.
• Clone — build a new Cube from this snapshot and leave the original untouched. This is the safe way to test a restore, or to fork production into a staging copy.
• Export — download the snapshot.
• Pin — exempt it from automatic pruning, so a snapshot you care about is not aged out by the retention ladder.

Prefer Clone over Restore when you are unsure. Restore overwrites the Cube you have; Clone gives you a second one to inspect first, at the cost of running two for a while.

When you are deleting a Cube

The delete dialog offers Preserve backup before deleting, and it is checked by default. That is the right default when you might want the Cube back — and it keeps billing you for the stored disk afterwards. If you are deleting something disposable, uncheck it deliberately rather than leaving a backup you did not mean to keep. See Cubes for how stored data bills.

Next steps

• Cubes — resizing, power states, and how running versus stopped billing works.
• Deploy PostgreSQL on a Cube — a database is the usual reason to want a snapshot before a change.