The follow-through patch: the 0.10.2 audit's remaining limits closed — encrypted volume snapshots, atomic restores, cross-process operation locks and destination-recorded remote backups.
Security
- Volume snapshots are now encrypted at rest with the same streaming AES-256-GCM master-key envelope as database dumps — a stolen data directory or backup bucket no longer leaks volume files in the clear. Downloads and restores decrypt transparently; legacy plaintext archives written before this change keep restoring unchanged.
Fixed
- Volume restores no longer empty the volume before extracting. The archive is fully extracted into a hidden staging directory inside the volume and only then swapped into place with same-filesystem renames, so a corrupt member or a full disk during extraction aborts the restore with the volume's previous contents untouched (a disk or filesystem failure mid-extraction could previously leave a partial restore and lose the old data). The staging copy transiently needs space for both the old and the restored contents.
- Backup and restore operations on the same database or volume now hold a cross-process lock file, so an overlapping panel process (systemd restart overlap, a second instance on the same data directory) can no longer interleave a backup with a restore; a busy lock answers 409 and a lock abandoned by a crashed process is reclaimed after its liveness heartbeat goes stale. Volume operations also gained the in-process serialization databases already had.
- Remote backups record which destination received their object (migration 0062), so switching the active destination no longer orphans earlier recovery points: restores and remote deletions resolve the bucket that actually holds the object, and only rows whose destination was deleted fall back to the active one. Previously every
remoteKeyresolved against the currently active destination, making old recovery points unrestorable after a destination change.