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, 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.

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/SMB 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. A storage target migration currently copies only tenants/<tenant id>/, not endpoints/. Copy the endpoints/ folder by hand before you switch the primary target. Until you do, agents and retention find an empty repository on the new target. Each repository has its own password, stored on the server and encrypted with the tenant key; keep a copy in a password manager if you want to restore without this installation (see Restore for servers and clients).

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.