Snapshots & Backups

Backups don't make money, so they are the easiest thing to deprioritize. That holds right up until the first outage where the lost data actually mattered. The return on a backup is invisible until the one moment it is the only thing standing between you and a dead business. This page exists so that moment is boring instead of catastrophic.

ServersCamp gives you two distinct ways to protect a disk: snapshots and backups. They look similar in the cabinet 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. One is for "undo", the other is for "the cluster is gone, rebuild from nothing".

This page defines exactly what we count as each, how a backup is built end to end, why every backup on ServersCamp is disaster recovery by design, and which one to reach for. If you have ever assumed a snapshot would save you when a disk died, read the next two minutes carefully.

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 the whole point of this page: a snapshot is a full copy, but it is 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: download, decrypt with your key, decompress, re-verify the raw SHA-256, and only then write the image back. A backup can be restored to the same VM, and the archive is portable enough that you can pull it yourself and decrypt it with your key, outside ServersCamp entirely.

Every backup is disaster recovery

On some platforms a "backup" is just another snapshot in the same datacenter, on the same storage, behind the same blast radius. We deliberately do not do that. On ServersCamp there is no such thing as a local-only backup:

• 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 and can be restored, or decrypted by you, even if ServersCamp infrastructure is unavailable.
• Geographically separable. You can send it to a different country 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 only go to a DR backend (Wasabi or ImpossibleCloud), or to Random, which spreads each run across the available DR targets. ServersCamp S3 is intentionally excluded from automatic schedules, because a copy in the same region as your compute is not real 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 cabinet under Backups → Encryption key and keep your own copy.
• Portability. With that key you can decrypt any of your archives yourself, off-platform.
• 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: it is what lets you read an archive independently of us.

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 decompressed image is re-hashed and must match this value before it is written over your disk. A corrupt restore is refused, not 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.

RTO and RPO: measure, don't promise

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 cabinet, and the principle is to show what we can actually measure, not a number off a sales page.

• RPO is measured, today. It is the real age of the backup: the exact gap between now and the point the copy was taken. No estimate, no rounding to a marketing figure.
• RTO is an estimate, today, and labelled as one. It is derived from the image size and the destination backend. Once scheduled restore tests are live (see the note above), RTO becomes a measured value: the time the last successful test restore actually took for your configuration, not a promise.

That is the whole philosophy. A recovery objective you can see, that reflects your real data and (soon) your real last restore, beats a confident SLA number nobody has ever exercised.

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 you have never restored is a hope, not a guarantee. Restore one occasionally and confirm the data is what you expect.

Pricing and further reading

Backups are €35 per TB per month, snapshots €50 per TB per month, billed only on compressed data. A typical 20 GB VM costs about €0.70 a month to keep backed up. See the Backups & Snapshots pricing page for worked examples and a full failure matrix.

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