Reference-based snapshots
Snapshots can record layout state by reference. Large trees do not need to be physically duplicated just to make rollback possible.
Snapshots
Restore should be normal, not a last-resort incident path.
Cotton separates layout metadata from content storage so snapshots, versions, trash, restore, and garbage collection can work from references instead of copying every byte again.
Whole-layout recovery model
The layout graph is a first-class abstraction. That makes it possible to reason about recovery at the tree level instead of treating every file path as an isolated accident.
File versions
When content changes, Cotton can keep a version lineage that users can inspect, download, restore, or prune according to retention policy.
Reference model proof
Snapshots and versions rely on layout references, file version lineage, trash retention, manifest references, preview/share retention awareness, and cautious garbage collection before chunks are reclaimed.
Recovery becomes everyday UX
Recovery is a product feature when it is visible, cheap, and understandable. Cotton treats snapshots, file versions, trash, and restore as normal file-cloud workflows instead of emergency-only backend chores.
Trash as lifecycle
Trash, versions, shares, snapshots, manifests, and previews are retention surfaces. Cleanup needs to know about all of them before reclaiming chunks.
Reclaim-safe garbage collection
Unused chunks are scheduled, rechecked, and only then reclaimed. If content becomes referenced again before deletion, cleanup can cancel the reclaim path.
User-visible confidence
Recovery features matter because users experiment more safely when rollback is cheap and obvious. That is product value, not just storage theory.
Backups still matter
Reference-based recovery is not a replacement for off-box backups. It protects day-to-day mistakes and retention workflows; full server loss still requires tested backups and a restore plan.
Recovery proof
Rollback is cheap only when the model is built for it.
Cotton separates the visible tree from stored content. That makes snapshots, versions, trash, restore, and cleanup parts of the same lifecycle instead of separate jobs fighting over the same bytes.
Reference model
Restore the tree. Do not recopy the archive.
The product point is not that snapshots sound advanced. The point is that users can recover from mistakes without turning a large library into a slow background copy operation.
Tree state is metadata.
Folders and visible file nodes can move through recovery workflows without rewriting every stored chunk.
Content identity stays stable.
A visible file points to a manifest, and the manifest points to ordered content-addressed chunks.
Old content can remain reachable.
Updated files can keep a version lineage users can inspect, download, restore, or prune.
GC deletes last, not first.
Unused chunks are scheduled, rechecked, and reclaimed only after Cotton confirms nothing live needs them.
Snapshots by reference
Large layouts do not need to become large copy jobs just because a user wants a rollback point.
Version-aware restore
A bad overwrite can become a version decision instead of a permanent loss event.
Trash is retention state
Deleted visible files still need clear retention semantics before their chunks can disappear.
Cleanup respects live references
Shares, previews, versions, snapshots, manifests, backups, and live files all matter to reclaim safety.
Cleanup contract
Reclaim should be boring, delayed, and correct.
A content-addressed cloud only stays safe if cleanup knows what is still alive. Cotton treats GC as a coordinated retention workflow: schedule first, verify again, then delete only when references are truly gone.
- Mark unreferenced content as reclaimable
- Delay deletion instead of racing restore
- Recheck references before touching storage
- Cancel reclaim if the chunk becomes live again
Everyday recovery
Backups are still mandatory, but everyday recovery does not need to feel like disaster recovery. Cotton makes restore part of the file cloud workflow instead of an operator-only emergency path.
Backup boundary
Reference-based recovery depends on correct metadata and retention accounting. If a deployment needs protection from full server loss, it still needs tested backups and off-box storage.
FAQ
Direct answers
Are snapshots full copies?
No. The design is reference-oriented. The goal is to avoid copy-heavy recovery for large layouts.
Do snapshots replace backups?
No. Snapshots and versions help with normal user mistakes and rollback workflows. A serious deployment still needs tested backups, especially for full server loss or storage failure.
Why does garbage collection need to be cautious?
A chunk may be referenced by a file version, snapshot, share, preview, backup artifact, or live manifest. Cleanup must respect all retention paths.