restorable docs
Operate

Moving blobs to a larger disk

Point the agent at a bigger volume for backup ciphertext and restore-test scratch without moving the rest of the state directory. Useful when /var/lib sits on a small boot volume and your database dumps do not.

Three directories under /var/lib/restorable/ can grow. Only blobs/ grows with dump size; the others are small enough to stay put:

  • blobs/: staged ciphertext, one file per backup. Sized proportionally to the compressed dump. Deleted after upload succeeds.
  • receipts/: DSSE receipts. Kilobytes each; one per restore test.
  • events/: append-only local event log. Kilobytes.

In managed mode, blobs upload to the orchestrator's object storage almost immediately and disk usage stays flat. The peak you need to size for is one concurrent dump. A 200 GB dump means 200 GB of ciphertext sitting on disk for however long the upload takes.

Override blobs_dir in config.yaml

Each directory is overridable independently under storage:. Missing fields fall back to the <root>/<name> default, so you can set just the one that matters: 

storage:
  blobs_dir: /mnt/big-disk/restorable/blobs

Leave receipts_dir and events_dir unset unless you also want them on the big disk. Keys, api_token, and the config itself are not affected.

Create the directory

The agent runs as the restorable user and needs ownership + 0700 to match the rest of the state dir's posture: 

sudo install -d -o restorable -g restorable -m 0700 /mnt/big-disk/restorable/blobs

Widen the systemd sandbox

The unit has ProtectSystem=strict and ReadWritePaths=/var/lib/restorable. Any path outside that list is read-only to the agent, so a fresh blobs_dir on /mnt/big-disk/ would fail with a read-only filesystem error. Add the new path via a drop-in override so the vendored unit stays untouched: 

sudo mkdir -p /etc/systemd/system/restorable.service.d
sudo tee /etc/systemd/system/restorable.service.d/storage.conf >/dev/null <<'EOF'
[Service]
ReadWritePaths=/mnt/big-disk/restorable
EOF
sudo systemctl daemon-reload
sudo systemctl restart restorable

One ReadWritePaths entry covers every subpath beneath it; one line is enough for the blobs dir and any future subdir under the same mount.

Restore-test scratch

Restoring a 200 GB backup needs 200 GB of scratch somewhere to hold the decompressed target database during the test. With the default restore_scratch.kind: auto the scratch container's storage lands under whichever runtime the agent detected: Podman's per-user storage at ~restorable/.local/share/containers/, or Docker's storage driver at /var/lib/docker/. If that path is also on the small boot volume, move it the usual way for that runtime (Podman: relocate ~restorable/.local/share via storage.conf; Docker: set "data-root": "/mnt/big-disk/docker" in /etc/docker/daemon.json). Nothing Restorable-specific.

Alternatively, switch to an external scratch endpoint on a host with the disk you want: 

restore_scratch:
  kind: uri
  uri: env:RESTORABLE_SCRATCH_URI

The agent drops and recreates a scratch database on that endpoint between sessions. Nothing persists. The credentials need permission to create and drop databases. See agent.yaml reference for the full restore_scratch shape.

Verify

Trigger a backup from the dashboard (or wait for the next scheduled one) and watch /mnt/big-disk/restorable/blobs/ grow then drop to empty after upload completes. If the write is blocked you will see mkdir blobs: ... read-only file system in journalctl -u restorable, which means the ReadWritePaths drop-in is not applied yet. Confirm with: 

systemctl cat restorable | grep ReadWritePaths

Both the vendored path and your override should appear.