Quarantine, not deletion

The thing that made me start frostvex was an rsync --delete at 1 a.m. on the wrong directory. Twelve gigabytes of family photos went to the great /dev/null in the sky, with no shadow copy and no recourse. I learned two things that night: backups are not the same as sync, and the principle of least catastrophe is worth a few extra disk pages.

Since 0.2.0, frostvex doesn't actually delete anything when a sync would normally remove a file. It moves the file to .frostvex/quarantine/, retains the original mtime and permissions, and writes a small breadcrumb that records why it ended up there.

What gets quarantined

• Files removed on the source. The destination quarantines, doesn't delete.
• Files that would be overwritten with a strictly older version. The "loser" goes to quarantine first; only after the new content is verified is the old version freed for pruning.
• Files that fail parity verification. The bad copy goes to quarantine, and if any peer has a good copy, that's pulled to replace it.

Quarantine entries cost real disk space — there's no magic dedup with the chunk store; we keep the file as-is. That's by design. If your sync removes 50 GB of stuff and you immediately realize it was a mistake, you don't want to be racing against a chunk-store GC.

Pruning

By default, files spend at least 7 days in quarantine before frostvex prune will collect them. You can set a longer window in config:

[quarantine]
retention_days = 30
auto_prune     = false

If you set auto_prune = true, frostvex will collect aged-out quarantine entries automatically at the end of every sync. Most users want this. The default is conservative because the first time you accidentally delete something important and recover it from quarantine, you'll thank me.

The downside

Steady-state disk overhead is real. On a 200 GB pool with normal churn, expect 1–3% extra space tied up in quarantine. If you're tight on disk, lower retention_days or enable auto_prune.

The other downside is mental: people read "sync" and assume the destination is a mirror of the source. Frostvex's destination is almost a mirror, with a small grace period. frostvex stat always shows quarantined entries separately so you can tell what's going on.

Why not just use a trashcan

I considered putting deleted files in ~/.local/share/Trash on Linux desktops. It's almost-but-not-quite right:

• The trash is per-user, but frostvex pools are often run as a daemon under a service account.
• The trash isn't pool-scoped — restoring a quarantined file should put it back in the right place, with the right permissions and the right pool membership.
• Some filesystems don't have a trash convention at all. Frostvex is supposed to work on a NAS or a VPS, where there is no desktop trash daemon.

So we have our own. It's boring; it's correct; it has saved my photos exactly twice now.

Related: frostvex prune in the CLI reference.