Backing up Restow itself

Restow protects its customers’ data; protecting the Restow installation itself is a separate, manual responsibility. Four things matter.

1. The PostgreSQL database

Holds every tenant’s metadata, the job queue, settings, license state and the audit log. Back it up with a normal pg_dump/pg_dumpall against the postgres service, or by snapshotting the pgdata Docker volume while the database is stopped (after you moved the database to another disk, since 0.4.0, the data lives in the host directory named by RESTOW_POSTGRES_DATA in .env instead, and that is what to snapshot), or with your storage layer’s own consistent-snapshot mechanism. This is not the chunk store: restoring only the database without the chunk store leaves you with metadata pointing at data that isn’t there. The optional updater dumps the database with pg_dump into its own volume before every update and keeps the last three dumps; that is a safety net for the update, not a replacement for your own database backup. Since 0.4.0 the Updates tab lists these dumps under Database backups, and the provider owner can download one (after a recent sign-in, recorded in the audit log). A dump holds the whole database, the encrypted secrets included: keep a downloaded one as carefully as the master key. See Database.

2. `.env` and `RESTOW_MASTER_KEY`

.env holds every secret Restow runs with: database passwords, BETTER_AUTH_SECRET, the Entra client secret, and RESTOW_MASTER_KEY. Losing RESTOW_MASTER_KEY specifically makes every encrypted tenant key, and therefore every backup and archive item, permanently unreadable. See the warning in Get started → Install. Keep an offline copy of .env (or at least of RESTOW_MASTER_KEY), apart from the server, the same way you would keep any other root-of-trust key.

3. The chunk store

Where the encrypted, deduplicated backup and archive data actually lives. If you use the default local storage target, that’s the restow-data Docker volume (STORAGE_LOCAL_PATH=/data/chunks inside the container); back it up like any other data volume. If your primary target is S3-compatible storage or a mounted NFS share, that storage already has its own durability; Restow additionally supports one or more copy targets per tenant so a single storage failure doesn’t take every copy (see Backups and schedules).

Servers and clients backed up with the Restow agent keep their restic repositories in the same storage target, below endpoints/<endpoint id>/ in the tenant’s primary target, so a backup of the target covers them. The server refuses to change the primary target while endpoints are active (HTTP 409, storage-active-endpoints), because an active agent keeps writing to the old primary while it is copied. To change it, revoke or uninstall the machines, change the primary target with a move, then enroll the machines again: they become new endpoints with new repositories in the new primary target. Since 0.4.2 a move copies the endpoints/ repositories of the revoked machines too, checked by size and SHA-256 (before 0.4.2 it copied only tenants/<tenant id>/), and their backups can be browsed and downloaded from the new primary. With “keep existing backups where they are” they stay on the old target, which becomes the previous target or a copy, and which cannot be removed while it alone holds them. Each repository has its own password. The server keeps it in its database and also next to the repository, sealed with the tenant key (endpoints/<endpoint id>/restow-repository-password.json), so RESTOW_MASTER_KEY and a copy of the storage are enough to get it back without this installation: restow-restore endpoint-password --storage <dir> --key <file|env> --endpoint <id>, then plain restic (see Restore for servers and clients).

Proxmox VE containers and file shares keep their restic repositories the same way, below pve-guests/<guest id>/ and file-shares/<share id>/ of the tenant’s primary target (since 0.4.0 for file shares), so a backup of the target covers them too. Since 0.4.2 a storage move copies these repositories with the rest, checked by size and SHA-256, and “keep existing backups where they are” is refused while containers or file shares have repositories (Replacing the primary repository); before 0.4.2 a migration copied only tenants/<tenant id>/. Each of these repositories has its own password, which the server keeps in its database and also next to the repository, sealed with the tenant key.

With immutable backups (since 0.4.0) the objects of a repository on S3 with Object Lock are locked for the period you chose, and a copy target does not inherit that: see Immutable backups.

4. Caddy’s certificate data

The caddy-data/caddy-config volumes hold the automatically obtained TLS certificate for RESTOW_APP_DOMAIN. Losing them is inconvenient (Caddy re-requests a certificate on next start) rather than dangerous, so backing them up is optional.

Standalone restore, without a running Restow server

The storage format is open and documented, specifically so a restore is possible even if the Restow server itself is gone: restow-restore, a small standalone CLI shipped in the product repository’s packages/cli workspace, reads the chunk store directly.

restow-restore restore \
  --manifest <path-or-key> \  # a snapshot manifest: a local file, or a key in the store
  --storage <dir>          \  # path to the local storage backend root
  --key <file|env>         \  # the tenant's exported keyring or KEK: a file path or an env var name
  --out <dir>                 # directory to write the reconstructed files into

restow-restore verify runs the same hash checks end to end without writing any files, useful to confirm a backup, or an offline copy of one, is intact:

restow-restore verify --manifest <path-or-key> --storage <dir> --key <file|env>

Both commands report every object’s outcome (ok / skip / FAIL) as they go and exit non-zero if anything failed, so they script cleanly into a periodic check. --key takes either of two things: normally, the installation’s RESTOW_MASTER_KEY (the key-encryption key); the same offline copy described in §2 above unwraps every tenant’s data-encryption key directly from the store; or, if you separately exported one tenant’s keyring, that export file instead. A dedicated “export a tenant’s keyring” action in the product itself is planned, not built yet. Today, keeping RESTOW_MASTER_KEY offline is what makes standalone restore possible without a running server. restow-restore endpoint-password opens the repository password of a server or client (under endpoints/) and, as built in 0.4.7, does not look under pve-guests/ or file-shares/: a container or file share repository is a plain restic repository, and its sealed password file (restow-repository-password.json, next to the repository) is there, but no command of restow-restore unseals it in 0.4.7. Keep the repository password of those repositories in your own records if you need to open them without this installation.