---
title: Backups That Survive Losing the Machine
summary: Local snapshots, optional off-site replication to your own S3-compatible bucket, and a recovery kit: the one thing that makes a backup readable if the machine that made it is gone.
date: 2026-09-09
---

# Backups That Survive Losing the Machine

Local snapshots, optional off-site replication to your own S3-compatible bucket, and a recovery kit: the one thing that makes a backup readable if the machine that made it is gone.

## Snapshots

Create a snapshot of your installation from **Settings → System**: your database, configuration, and platform state as of that moment. Restoring replaces all current data with the snapshot's, so taking one before a risky change is worth doing on its own, even with nothing else below configured.

## Off-site replication

Point replication at your own S3-compatible bucket, AWS S3 or a compatible provider such as Cloudflare R2, Backblaze B2, MinIO, or Wasabi, and every snapshot after that copies there automatically. Losing this machine no longer means losing every backup with it. Test the connection before enabling it: the test writes and deletes a small marker object using the exact permissions replication needs, and nothing is saved until that test passes.

## Why a Recovery Kit exists

Every snapshot is encrypted with a key derived from this machine's own secret. That's what keeps a snapshot sitting in your bucket unreadable to anyone else, but it also means a snapshot is normally only ever readable by the machine that made it. If that machine is the one you lost, the encrypted backups in your bucket are unopenable by design, not by mistake.

A Recovery Kit is a second, independent way to unlock the same backups. Enabling off-site replication issues one automatically. Downloading it is not enough on its own: verifying it, by entering the code printed inside it back into the settings page, is what actually confirms the kit works. Only a verified kit lets a snapshot be restored on different hardware, and only a verified kit unblocks a later key rotation.

Store the kit somewhere that survives losing the server itself: a password manager or a vault, not the machine it protects.

## Rotating the key

Rotating a Recovery Kit is deliberately two steps, so there's never a moment where no kit works: rotating adds a new key to every archive without removing the old one, and a separate, explicit "finalize" step drops the old key only once the new kit is downloaded and verified. Finalizing is permanent: the previous kit stops opening anything afterward. It still can't reach a copy someone already downloaded elsewhere, which is a limit of any recovery key, not a defect in this one.

## What this doesn't protect against

A stolen Recovery Kit can't fetch anything from your bucket by itself: it carries no bucket credentials, only the ability to decrypt an archive someone already has in hand. It also can't revoke a copy already sitting on someone else's disk, which is exactly why it belongs in a vault, not an individual laptop.

## Related

- [Setting Up and Restoring From Backups](/en/docs/guides/backup-recovery-guide): the actual steps, including the four-step restore flow
- [Security](/en/docs/features/security): the same local-first, per-installation design this system extends to backups
- [Self-Hosting](/en/docs/guides/self-hosting): where snapshots and off-site replication matter most, on infrastructure you're responsible for keeping running