Snapshots

Snapshots are point-in-time copies of a workload’s [[volume]], streamed straight from the node to your own S3 bucket (see Snapshot destinations for the BYO setup).

What’s in a snapshot

• A BRIGSNP2-framed tar of the volume contents at a consistent point.
• 64 KiB plaintext chunks, each AEAD-sealed with a key derived from your tenant DEK and the snapshot id.
• Object key: <tenant-id>/<workload>/<volume>/<timestamp>-<snap_id>.tar.gz.

Even if your S3 bucket is misconfigured for public read, the bytes are opaque ciphertext. Brig itself never sees the plaintext — encryption happens on the agent, on your VPS, before the bytes leave.

On-demand snapshots

brig snapshot create whoami

Defaults to the workload’s first declared [[volume]]. Add --volume <name> for any other. Pass --destination <name> to target a non-default snapshot destination.

brig snapshot list
brig snapshot inspect snap_xxx

Recurring snapshots

Two ways to set up the same recurring schedule:

A — declarative, in workload TOML

[[volume]]
mount                = "/var/lib/data"
size_gib             = 20
snapshot_every       = "24h"      # minimum 1h, parsed as Go duration
snapshot_keep        = 14         # 1..365
snapshot_destination = "prod"     # optional; omit = workspace default

brig deploy materialises a schedule row from this. The cp fires on a sweep interval and retains the N most-recent completed snapshots, deleting older ones from S3 in the same pass.

B — imperative, via the CLI

brig snapshot schedule create whoami \
  --daily \
  --keep 14 \
  --destination prod

Equivalent. Use whichever fits your workflow — the schedule rows are the same table either way.

Restore

brig snapshot restore snap_xxx                          # back into the original workload + volume
brig snapshot restore snap_xxx --workload whoami-clone  # into a different workload (same shape)

Restore streams the encrypted tar back to a node, decrypts it with the tenant DEK version recorded on the snapshot row (so DEK rotations don’t brick old snapshots), and untars into the target volume.

What if I rotated my destination credentials?

Each fire re-resolves the destination by name and pulls the current sealed credentials. So a credential rotation lands automatically on the next fire — no need to re-create the schedule.

If you delete the destination row entirely, Brig refuses to restore the snapshot until you re-add credentials for the original bucket. The error tells you which bucket needs matching credentials.