Skip to main contentYour first top-up gets $5 in bonus credit — one-time, for every new account. Create your account
Krova CloudKrova Cloud

Back up a Cube and bring it back

Create a Backup that outlives a Cube, redeploy an identical Cube from it, and move a Cube between spaces by downloading and importing its archive.

A Backup stores a Cube's disk and its configuration — vCPU, RAM, disk size, image, region and its mappings — so you can bring an identical Cube back later. Unlike a snapshot, a Backup survives deleting the Cube it came from.

There are two ways to use one: Redeploy, which builds a new Cube in place, and Download plus Import, which moves it to another space or account.

Step 1 — Create the Backup

Two routes to the same thing:

  • From a snapshot — Save as Backup on any snapshot in the Cube's Snapshots tab.
  • While deleting — the delete dialog's Preserve backup before deleting, which is ticked by default.

Backups are billed per GB-month for as long as they exist, and the archive is compressed: a 10 GB Cube whose disk is mostly empty produces a few hundred MB, and the Backups page shows both the size and the monthly cost before you commit to keeping it.

Step 2 — Redeploy into a new Cube

On the Backups page choose Redeploy. This creates a new Cube with the same disk state — the original, if it still exists, is untouched.

Three things about the form are worth knowing before you use it:

  • Disk can only grow. vCPU and RAM move freely within your plan, but the disk cannot shrink below what the backup recorded — shrinking the filesystem would corrupt it.
  • An SSH key is required, even though the disk already contains the old one. Supply the key you intend to use for the new Cube.
  • Mappings are re-attempted, and conflicts are skipped. Domains and TCP mappings stored in the backup are re-applied on boot — but if the original Cube still holds one, the new Cube simply boots without it. Nothing is stolen and nothing errors; the mapping is just absent, and you add it manually if you meant to move it.

The last one is the surprise in practice. Redeploying alongside a live original gives you a Cube with all the data and none of the domains, which is exactly right for a staging copy and exactly wrong if you expected a failover.

The hostname comes from the disk

The name you give the new Cube is the name in the dashboard. Inside it, hostname still returns whatever the original was, because that lives on the restored disk. If anything you run keys off the hostname, set it explicitly after the first boot.

Step 3 — Check what actually came back

Connect to the new Cube and confirm the state you expected, rather than trusting that a green status means your data is there:

systemctl is-active <your-service>   # enabled units come back on their own
curl -s http://127.0.0.1:<port>/    # the app answers
ls -la /path/that/should/exist      # your data is on the disk

Services you enabled start by themselves, because that state is on the disk too. Services you only ever started do not.

Step 4 — Moving a Cube somewhere else

Redeploy works within the same space. To move a Cube to a different space or account, download the Backup and import it there.

Download gives you a .cube file — a tar archive whose first entry is a manifest.json describing the Cube's resources and image. Two things to note:

  • The link is presigned and expires in 15 minutes.
  • Anyone holding that URL can download the archive during that window, with no further authentication. It is a copy of your whole disk — treat the link as a credential and do not paste it anywhere shared.

In the destination space, use Import Cube from the Cubes page and upload the .cube file. The manifest fills in the resources, and the same rule applies as on redeploy — you can raise the disk but not lower it. If the archive's disk is larger than your plan allows, the import is blocked until you upgrade rather than failing partway.

Backups are not a backup strategy on their own

Everything here lives in the same platform as the Cube. That covers the cases you will actually hit — a bad deploy, a deleted file, a Cube you removed too eagerly — but it is not an off-platform copy. If the data matters, keep something of your own as well: a database dump to your own object storage, a Git remote you control.

Next steps