Repository navigation
Filebrowser: Recycle Bin #156
Description
Activity
- added a parent issue
on May 21, 2026 Practical designs
-
Best general approach: enable versioning and treat delete as “create delete marker.” In a versioned bucket, a plain delete creates a delete marker, which makes the object appear gone while preserving older versions for recovery. A delete marker itself has minimal storage cost, and you can expire old noncurrent versions with lifecycle rules.
-
Add a recycle-bin index in your app database. Store the original key, version ID, deletion time, retention deadline, user, and restore target. Then your browser can show “Deleted items,” restore by version ID, and purge on schedule even if S3 lifecycle cleanup is delayed. This is the cleanest UX because S3 by itself is storage, not a trash folder UI.
-
Use lifecycle rules for automatic expiry. For example, keep deleted versions for 7/30/90 days, then permanently remove noncurrent versions. AWS explicitly supports rules to delete noncurrent versions and to retain only the newest N noncurrent versions.
-
For compliance-grade retention, use Object Lock instead. If your goal is “cannot be deleted before retention ends,” Object Lock is the right tool; if your goal is “trash can be emptied later,” versioning plus lifecycle is simpler and cheaper operationally. Object Lock is a policy mechanism, not a user-facing recycle bin.
-
- removed a parent issue
on Oct 7, 2026
Add a central management spot for restoring or finally deleting files and folders.
Recommended setup
Enable bucket versioning on the storage bucket.
On delete, create an app-level trash record and optionally a delete marker by deleting the current version.
Keep noncurrent versions for a fixed retention window with lifecycle rules.
Optionally move older trash data to cheaper storage classes before final purge, if restore speed requirements allow it.
Periodically purge expired trash and monitor noncurrent-version bytes with Storage Lens.
When this becomes expensive
It gets costly when your objects are large, deletions are frequent, and retention is long. It also gets expensive when users repeatedly overwrite the same keys, because every overwrite creates another billable version unless you expire old ones. If you replicate versions for disaster recovery, multiply that storage footprint across regions.