Snapshots & Backups

Backups are easy to put off. They cost time and money and give nothing back until the day something breaks, so they slip down the list until the first outage that actually loses data. This page covers how snapshots and backups work on ServersCamp, what each one survives, and how to set them up so that day is uneventful.

ServersCamp gives you two distinct ways to protect a disk: snapshots and backups. They look similar in the Cloud Panel and people often treat them as the same thing. They are not. A snapshot is a fast, in-cluster rollback point. A backup is a full, compressed, encrypted copy shipped off the cluster to independent storage. A snapshot undoes a change you just made. A backup rebuilds a disk after the cluster it lived on is gone.

This page defines what we count as each, how a backup is built and verified end to end, how a local backup on separate storage differs from an off-site DR backup, and which one to reach for.

At a glance

Snapshots

A snapshot on ServersCamp is a full, standalone disk image of a VM root disk or a cloud disk at a point in time, materialized inside the same software-defined storage (SDS) cluster that runs your live disk. The storage engine captures the disk and copies it into an independent image, so what you keep is a complete, self-standing copy of the disk, not a chain of deltas that depends on the original.

• Faster than a backup, but not instant. It is a real data copy, so it takes time roughly in proportion to the disk size. Because everything stays inside the cluster, with no compression, encryption, or upload to remote storage, it completes much faster than a backup.
• A real, independent disk. It is a full image in the SDS, not a thin delta. It does not break if the original disk later changes or is deleted, and it occupies real space in the cluster (the size of the captured data).
• Two ways to restore. Roll a VM back in place, or spawn a brand new VM from the snapshot and keep the original running. Restore is also an in-cluster copy, so it is quick, but not literally instant.
• Schedulable. Auto-snapshot policies take daily or weekly snapshots and keep the newest N per resource.

The catch is where it lives: a snapshot is a full copy, but a full copy in the same SDS cluster as the disk it protects. It is the quick, in-cluster option for "I am about to run a migration, give me a fast way back". It does nothing for you if that cluster is gone.

When a snapshot is the right call

• Right before an OS upgrade, a package update, or a schema migration.
• Before a risky deploy you might want to roll back quickly.
• As frequent, in-cluster recovery points in addition to backups.
• Cloning: spin up a copy of a disk to test something without touching production.

Backups

A backup is a full, sequential, compressed and encrypted copy of an entire disk, streamed off the hypervisor and stored as a single self-contained archive on an independent object-storage backend. Unlike a snapshot, it carries every block, so it can be restored even if nothing of the original remains.

Here is what actually happens when you create one, end to end:

1. Consistent read. We take a momentary storage snapshot so the disk is read at a single consistent point, even while the VM keeps running.
2. Stream. The disk is read sequentially as a block device. Nothing is written to a temporary file.
3. Fingerprint the raw data. A SHA-256 of the uncompressed disk is computed in-line, in parallel, as the bytes flow.
4. Compress. The stream is compressed with zstd.
5. Encrypt. The compressed stream is encrypted with your organization's key (age) before it leaves the host.
6. Upload. The result is streamed straight to the chosen S3 backend as a multipart upload, and a second SHA-256 (of the stored archive) plus its exact size are recorded.
7. Verify the upload. The bytes we sent are checked against the object the backend reports. A short or partial upload fails the backup rather than registering a corrupt one.

In one line, the pipeline is:

Restore runs the same path in reverse: the archive is downloaded, decrypted with your key, and decompressed onto a fresh disposable disk while the raw SHA-256 is recomputed on the way in. That disk is handed to a VM (a rollback in place, or a brand new server) only once the hash matches the one recorded at backup time, so a corrupted archive never becomes a booting disk. The format is standard age + zstd, so given the archive bytes and your key it can be decrypted off-platform.

Off the cluster, off-site for DR

On some platforms a "backup" is just another snapshot in the same datacenter, on the same storage, behind the same blast radius. Ours never do that. Every backup leaves the SDS cluster entirely, and a DR backup leaves the provider and the country as well:

• Always off the cluster. A backup always lands on an independent object-storage backend, separate from the storage that runs your VM.
• Self-contained. One archive holds the entire disk. Restoring it needs nothing from the original cluster.
• Encrypted and portable. It is encrypted with your key, in standard age + zstd, so given the bytes and your key it can be decrypted off-platform.
• Geographically separable. A DR backend puts the copy in a different country and a different provider than where your compute runs.

Backends

A backend is the destination object storage a backup is written to. Each backup records which backend it used and the region and country it lives in, so you always know where a given archive physically sits.

• Manual backups can target any enabled backend, including ServersCamp S3 if you just want a fast local copy.
• Auto-backups go wherever the policy points, chosen when you create the VM or edit its schedule: any enabled backend, including ServersCamp S3 for a local copy, or several at once for multibackup. The Random option is DR-only, it picks one off-site DR target per run, so a random pick is never a same-region copy mistaken for disaster recovery.
• Each backend is tuned independently for upload throughput, so a far backend can still saturate the link.

Encryption

Every backup is encrypted before it leaves the hypervisor with your organization's key, using age (X25519 key exchange, ChaCha20-Poly1305 payload). The archive that lands on the backend is already ciphertext.

• Managed, but yours to hold. We generate and store the key for you, so restore is one click. You can view and copy the key in the Cloud Panel under Backups → Encryption key and keep your own copy.
• Portability. With that key and a copy of the archive, you can decrypt it yourself off-platform, with standard age tooling.
• Threat model. This protects your data against compromise of the storage backend, which matters most for third-party DR targets. Keep your copy of the key somewhere safe.

Integrity & verification

Every backup carries two SHA-256 fingerprints, and we store them in our own metadata, not inside the archive. That distinction matters: if the only checksum lived inside the file and the storage corrupted the file, you would be comparing damaged data against a damaged checksum. Holding the hashes separately lets us check a downloaded archive against an independent reference.

• Raw disk hash. SHA-256 of the uncompressed disk, taken as the backup is read. On restore the image is re-hashed as it streams onto a fresh disk, and that disk is attached or swapped in only once the hash matches this value. A corrupt archive is refused before it can become a live disk, never booted.
• Archive hash. SHA-256 of the stored, compressed, encrypted object. This is the cheap check for the cold copy: re-download, re-hash, compare, without decompressing anything.
• Upload check. Right after upload we compare the bytes we streamed against the object size the backend reports, so a truncated upload fails loudly.

Verified backups

A checksum proves an archive is byte-for-byte intact. It does not prove the disk inside it boots. A backup can pass every hash and still fail to start, because of a broken bootloader, a bad fstab, or a half-applied change that was live at the moment the disk was read. Verification closes that gap by actually starting the backup.

Turn it on and, after each backup completes, we do a full restore into an isolated sandbox VM on the fleet and boot it:

1. Restore into a sandbox. The archive is pulled back, decrypted, and written into a throwaway VM with its own private network. It never touches your running VM.
2. Boot under real firmware. The sandbox starts under OVMF, exactly as a normal VM would, with a cloud-init seed that hands it a throwaway login and DHCP address.
3. Probe from two sides. We wait for the QEMU guest agent to answer from inside the guest, and for an SSH connection to open from outside. Both have to come up for a pass.
4. Record the evidence. We capture a console screenshot and the exact time the restore-and-boot took.

The outcome is written onto the backup:

• Bootable, with a measured restore time. That number is your real RTO for that archive on that backend.
• Failed, with the stage it stopped at. You find out a backup is unbootable now, on an ordinary day, instead of during the incident when you finally reach for it.

Verification is billed per run on the data it moves, whether the boot passes or fails, because the work (a full download, decrypt, and boot) is the same either way. Prices are in the pricing section below.

RTO and RPO

Two numbers decide how bad a real incident is: how far back you can recover to (RPO, the recovery point) and how long recovery takes (RTO, the recovery time). We surface both per backup in the Cloud Panel, and the principle is to show what we can actually measure, not a number off a sales page.

• Recovery-point age is measured, today. Per backup we show its real age, the exact gap between now and the point the copy was taken. That is the concrete input to your RPO, not an RPO target we promise.
• RTO is measured when verification is on. For a verified backup it is the time the last boot-test restore actually took for that archive and that backend. With verification off, RTO is an estimate derived from the image size and the destination, and it is labelled as one.

Auto-backup & GFS retention

Automatic backups are off by default for everyone. You turn them on per organization (and optionally per VM or disk) from Backups → Auto-backup, choosing a retention preset and a time window. Backups are captured daily inside the window; retention then keeps a grandfather-father-son (GFS) set:

GFS keeps recent points dense and older points sparse, so you get fine-grained recovery for the last week and a long tail of monthly and yearly restore points without storing a copy for every single day forever. The scheduler is concurrency-capped and runs in small serial batches, so a fleet-wide backup window never hammers your VMs or the agents.

Which one to use

Common mistakes this page is here to prevent

• Treating snapshots as backups. They die with the cluster. Snapshots alone are not a backup strategy.
• No off-site copy. If every copy is in the same region as your compute, one regional incident takes all of them. Send backups to a DR backend in another country.
• One recent backup only. If corruption or a bad change went unnoticed for a week, a single latest backup may already contain it. Keep history (Weekly or GFS).
• Never testing a restore. A backup nobody has ever restored is unproven. Turn on verification so each backup is boot-tested automatically, and still restore one by hand now and then to confirm the data is what you expect.

Pricing

Storage is billed per terabyte per month, prorated by the hour, so you pay only for the hours a copy actually exists.

• Snapshots: €35 per TB per month, on the full provisioned disk size. A snapshot is a full, uncompressed image on the SDS, so a 100 GB disk is billed as 100 GB whatever it holds inside.
• Backups: €35 per TB per month on ServersCamp S3, €70 per TB per month on an off-site DR backend, charged on the compressed archive size. Every backend you write to is a separate copy at its own rate.
• Verification: €15 per TB of the archive it downloads, charged once per run on any result. A 1 TB archive verified nightly is €15 a night; a 100 GB archive is €1.50.

A 20 GB compressed archive kept on ServersCamp S3 runs about €0.70 a month. See the Backups & Snapshots pricing page for worked examples and a full failure matrix.

Why it costs what it costs

This is a managed data-protection pipeline, not a bucket you drop bytes into. Every backup is read consistently off the live disk, hashed, compressed, encrypted with your key, streamed to object storage, and checksum-verified against what the backend reports. With verification on, it is then restored and booted on real hardware to prove it comes back. Off-site copies leave our network for independent providers in other countries, so the price carries their storage and the egress to reach them. Snapshots sit on the same enterprise NVMe SDS as your VM, on live replicas, which is why they price on the full disk rather than a compressed archive.

Multibackend runs turn that into real geographic redundancy: one backup, several storages, several countries, each copy independently checksummed, restorable, and billed. You are paying for the copy that is still there when a disk, a cluster, a region, or a whole storage vendor is not.

Further reading

For the thinking behind treating every backup as disaster recovery, read the blog post Most people think they have backups.