Coming soon · a SafeHelm project

vBackup

Backups go in. Only ciphertext comes out the other end.

A stateless, encrypting backup gateway written in Rust. Your services stream database dumps, containers and files to it; vBackup compresses them, encrypts them and stores them in Hetzner Object Storage or any other S3-compatible bucket.

1
Stream

pg_dump, docker or tar stream straight in. A dump that fails never becomes a backup.
2
Compress

zstd before encryption, because encrypted data can't be compressed afterwards.
3
Seal

A fresh 256-bit data key per object, XChaCha20-Poly1305 in the STREAM construction.
4
Lock away

Stored in an S3-compatible bucket, with optional Object Lock retention.

Built to be the boring, trustworthy part

Stateless

No database, no cache, no disk. Credentials and keys arrive per request, live only for that request and are zeroized. Scale it behind any load balancer and restart it freely.

Envelope encryption

Each object gets its own data key, wrapped by your key-encryption key. Tampering, truncation, reordering and swapped objects are all detected on restore.

Sealed mode

Encrypt on your side and vBackup only ever stores ciphertext. One switch makes the service refuse any request that carries a key.

Verified manifest

A client-held, hash-chained record of every backup. It catches a service or storage that hides the newest backup or serves an old one as "latest".

Ransomware-resistant

Optional S3 Object Lock retention per backup: GOVERNANCE by default, or COMPLIANCE, which not even holders of the storage credentials can shorten.

Restore without the service

The format is self-describing. Any S3 client plus the offline CLI can decrypt a backup, writing a .partial file until the whole stream checks out.

Key rotation

Move backups to a new key by re-wrapping only the data key, without decrypting or re-encrypting the data.

Small and contained

A single static Rust binary in a distroless image. Storage endpoints come from a server-side allowlist, so it can't be turned into an SSRF proxy.

One line in your cron job

The client runs next to your database or containers and reads its secrets from the environment, so they never show up in ps. Name a milestone before a risky migration and restore it by name later.

$ vbackup-client backup -t acme -s pg-main -k postgres \
    --retain-days 30 -- pg_dump -Fc -Z0 "$DATABASE_URL"

$ vbackup-client backup -t acme -s pg-main -k postgres \
    -n pre-migration-v42 -- pg_dump -Fc -Z0 "$DATABASE_URL"

$ vbackup-client restore -t acme -s pg-main \
    -n pre-migration-v42 -o pre-v42.dump

When things go wrong

The bucket leaks: Only ciphertext is at rest.
Someone tampers with stored objects: Authenticated encryption bound to each object's key: the restore fails loudly.
Storage credentials leak: Object Lock retention keeps backups from being deleted.
The service is hiding or rolling back backups: Sealed mode with the verified manifest detects it.

Want early access?

vBackup is being built and tested now, including against Hetzner Object Storage with and without Object Lock. Tell us what you need to back up.

rmartins@safehelm.com