Undo anything.
To the exact second.
Snapshots only protect the moments you scheduled. SeaweedFS records every change in a retention window, so you can roll a folder, bucket, or single object back to any second — overwrites and renames included — with a full preview before anything moves.
Snapshots protect moments.
Mistakes happen between them.
Every snapshot system shares the same fine print: you can only restore to a point somebody scheduled in advance. Versioning keeps every copy of every overwrite, billed forever — but still can’t show you a bucket as of a moment. And most data-loss incidents aren’t deletes at all: the files still exist, they just hold the wrong bytes.
| System | Recovery model | The fine print |
|---|---|---|
| NetApp ONTAP | Scheduled snapshots (5-minute finest built-in) + SnapRestore | Restores a whole volume in seconds — but only to pre-captured instants, and a revert destroys everything after it, including later snapshots. 1,023 snapshots per volume means 1-minute cadence holds under 18 hours of history |
| CephFS | Scheduled .snap snapshots — 1-hour floor in the scheduler, ~99 per directory by default |
No rollback exists: “RADOS doesn’t support rollback of snapshots so it needs to be done manually” — recovery is an rsync out of .snap, and deleting big snapshots can stall cluster I/O |
| Qumulo | Snapshot policies, up to 40,000 per cluster | Recovery is copy-out from the hidden .snapshot directory — no in-place rollback or revert exists anywhere in the product |
| HDFS | Per-directory snapshots an admin enabled in advance | Restore is a DistCp copy job; renamed files show up as delete-and-create in diffs, and out-of-order snapshot deletion carries a vendor data-loss bulletin |
| WEKA / VAST | Cluster snapshot policies (VAST markets 15-second cadence) | Rollback is whole-filesystem with I/O stopped (WEKA) or per protected path (VAST) — and always to a captured instant, never an arbitrary moment |
| Amazon S3 | Versioning — every overwrite stores a full copy — plus AWS Backup for continuous PITR | Three versions bill as three whole objects; Backup’s PITR caps at 35 days, can’t restore the most recent 15 minutes, restores only to S3 Standard, and item-level restore is 5 objects per job |
| ZFS | The snapshot baseline — atomic, cheap, scriptable | zfs rollback discards everything newer and destroys intermediate snapshots; RPO equals the snapshot interval, and per-file restore is a manual copy from .zfs |
| SeaweedFS | Continuous — every change in the retention window stays recoverable, always on | Roll a folder, bucket, or object back to any second — overwrites and renames included — from a previewed, per-path plan. One flag to enable; no snapshot schedules, quotas, or trim jobs, ever |
Vendor mechanics and limits from their own documentation. Block-level CDP products (Zerto, Veeam CDP) do offer any-point-in-time — for virtual machine disks, not file or object namespaces, with 7–30-day journals. Continuous, previewable, namespace-level recovery is otherwise unoccupied territory — see the Point-in-Time Recovery docs for how SeaweedFS does it.
Plan, preview, then restore
PITR reconstructs what a prefix looked like at your chosen moment from the filer’s metadata change log, while delayed garbage collection keeps the underlying data alive for the whole retention window.
1. Record
One master flag — -deletionRetention=72h — turns the
window on. From then, every overwrite, rename, and delete in the cluster stays
recoverable for the window’s duration. Nothing else to deploy.
2. Plan
Pick a scope prefix and a target time in the Admin UI. SeaweedFS computes a restore plan — exact counts and a per-path table of every file it would restore, revert, or remove — before anything changes.
3. Restore
Apply the plan. Safe defaults stage into a fresh side-copy and only add what was lost; in-place and exact-mirror modes are there when you want them, behind a typed confirmation bound to the previewed plan.
Sees corruption, not just deletion
A bad migration or an AI agent rewriting files leaves nothing deleted — delete-recovery tools see a healthy tree. PITR works from the change log, so in-place overwrites and renames roll back too.
Per-object time travel
Open any file’s history inside the window and restore any past version — not just the latest one before a delete. One object or a whole subtree, same engine.
Safe by default
Side-copy destinations never touch live data; additive semantics never delete a current file. The dangerous modes exist — and they demand a typed confirmation that matches the plan you previewed.
From “what happened?” to restored, in minutes
PITR shares its retention window and restore engine with Data Recovery — undelete for the “someone dropped a folder” case, PITR for everything messier: bad deploys, wrong-target syncs, schema migrations gone sideways, an agent with too much access.
- Whole-subtree consistency — reconcile an entire prefix to one instant in a single operation
- Reviewable rollback — exact per-path changes on screen before you commit to anything
- No new moving parts — the window, the log, and the restore engine are already in your cluster
More reasons teams pick SeaweedFS
Metadata at Scale
Sealed directories shrink the filer store 18–58× for cold trees — metadata becomes ordinary, erasure-coded volume data, still readable in place. See how →
Kernel Mount
A native Linux mount — not FUSE — whose client memory stays flat as file counts grow, managed with standard mount and fstab tooling. Meet it →
Open Source vs Enterprise
Same cluster, same deployment, same APIs — see exactly what a license key adds, and what stays free. Compare editions →
The next bad deploy doesn’t have to cost data
Point-in-Time Recovery ships with SeaweedFS Enterprise — free for dev & test under 25TB, with a 1-hour window in the free trial. Turn on the retention window today; be glad you did later.