Backups & snapshots

Your Cube is a file you own.

Snapshots run on a schedule, restore in a click, and clone into a brand-new Cube. Export a whole machine as a portable .cube archive and take it with you — encrypted, deduplicated, and stored away from the host it runs on.

Launch a Cube See every platform feature

Automatic scheduleOne-click restoreClone to a new CubeExport & importNo per-GB snapshot charge

capture a known-good machine

krova snapshots create web-1 \

    --name pre-upgrade

✓ Created snapshot snap_8f2a (complete)

…and roll straight back to it

krova snapshots restore web-1 snap_8f2a

01What a snapshot is

Four things one snapshot can do

Most clouds give you a restore button and stop there. A Krova snapshot also clones, exports and imports — so the machine moves with you.

Restore it

Roll the same Cube back to how it was at any snapshot. The upgrade that broke your box is a few seconds of downtime, not an evening rebuilding it.

Clone it into a new Cube

Build a brand-new Cube from any snapshot — and give it a bigger disk on the way in. Staging that matches production exactly is one action, and the original is never touched.

Export it as a file

Turn any snapshot into a single portable .cube archive and download it over a private, time-limited link. Keep it wherever you keep your own backups.

Import it back

Upload a .cube archive and it boots as a running Cube, optionally on a larger disk. The round trip is the point: your machine is a file you own.

02Automatic

You don't have to remember to run them

The backup you forgot to take is the one you needed. Snapshots are scheduled, rotated and protected for you — your tier sets how often and how many, and snapshot storage is bundled into the plan, with no per-GB charge on top.

Taken on a schedule

Auto-snapshots run on your tier's cadence without you asking. A powered-off Cube is captured once rather than on every run, because a stopped disk isn't changing.

Kept on a real retention policy

Retention thins the history the way a backup system should — recent ones, then daily, weekly and monthly — so you can go back a long way without paying to store every copy.

Protected from accidents

Automatic snapshots are system-managed and can't be deleted by hand. Pin one you want to keep and it stops being rotated. Deleting a Cube also offers to keep a full backup of it first, checked by default on plans that include backups.

No downtime to take one

Snapshots run against a running Cube. Filesystem buffers are flushed inside the VM first, so what lands on disk is clean — and nothing you're serving goes offline for it.

See cadence and retention by tier

03Where they live

Where your snapshots actually live

A backup on the same machine as the thing it is backing up is not a backup. Here is the real arrangement.

Encrypted, with a key per Cube

Every Cube gets its own snapshot repository with its own randomly generated key, and that key is itself encrypted at rest. One Cube's snapshots are unreadable from another's.

Stored away from your host

Snapshots live in S3-compatible object storage, not on the bare-metal machine your Cube runs on — so losing the host doesn't mean losing the history of what was on it.

Only what changed is stored

Storage is content-addressed and deduplicated. The first snapshot stores the disk; every one after it stores just the changed blocks, which is what makes a frequent schedule affordable.

Want the whole isolation and data-handling picture? Read the security page →

A pattern worth stealing

Build the machine once. Stamp out copies.

Set a Cube up exactly how you want it, snapshot it, and clone that snapshot every time you need the same environment again — a fresh box per AI agent run, per CI job, per customer, per demo. Every copy starts from a known-good machine instead of a provisioning script you hope still works.

Clone reads the snapshot directly onto the new Cube's disk — no upload, download or archive step in between.
The source snapshot is read-only during a clone, so the base image can't be damaged by a bad run.
Each clone gets its own SSH key and its own network identity, so copies never collide.
Export the same base as a .cube archive when you want it off the platform entirely.

A Cube per agent Ephemeral CI runners

Portable, on purpose

Being able to walk away with your data is a feature, not an oversight. A .cube archive is a single checksummed file holding the whole disk — the same format on the way out and the way back in.

1ExportPick a snapshot, ask for an export, and get a private download link when the archive is ready.
2KeepStore it wherever you keep your own backups. It is an ordinary file at that point.
3ImportUpload it back and it boots as a running Cube — same disk, optionally more of it.

The quick answers

Do I have to power off a Cube to snapshot it?

No. Snapshots are taken against a running Cube, and nothing you are serving goes offline. Filesystem buffers inside the VM are flushed first so the captured disk is clean.

What is a .cube archive?

A .cube archive is a single compressed, checksummed file containing a Cube's whole disk. You can export any snapshot as one and download it over a private, time-limited link, then import it again later to boot it as a new Cube. It is the reason your data is portable out of Krova Cloud and not only inside it.

Can I build a new Cube from a snapshot instead of overwriting the old one?

Yes — that's cloning, and it's the usual way to make a staging box that matches production, or to hand every AI agent run an identical known-good machine. The clone is a separate Cube, the source snapshot is untouched, and you can give the new Cube a larger disk as you create it.

What happens to my data if I delete a Cube by accident?

Deleting a Cube offers to keep a full backup of it first, and on plans that include backups that option is checked by default. Unlike a snapshot, that backup survives the deletion and can be redeployed later as a new Cube with its original configuration. Automatic snapshots are also system-managed and cannot be deleted by hand, which keeps the recovery history intact even when someone is tidying up.

Are snapshots encrypted?

Yes. Each Cube has its own snapshot repository encrypted with its own randomly generated key, and that key is stored encrypted at rest. Snapshots are held in object storage separate from the host your Cube runs on.

Can I drive snapshots from the API?

Yes. Create, list, restore and delete snapshots from the v1 REST API, the typed TypeScript SDK, or the CLI (krova snapshots create, list, restore, rm). Cloning, exporting and importing a Cube are available from the dashboard and the API, so a whole "capture a base image, stamp out copies" pipeline can run from your own code.

Launch a Cube. It starts protecting itself.

Snapshots, restore, clone and export ship with every Cube — nothing to enable and nothing extra to buy. Your first top-up gets $5 in bonus credit, one-time.

Launch a Cube View pricing