Versioning, recycle bins and recovery

Versioning: recovery and its storage cost

Every document library keeps version history by default — each save is a restorable version. This is the everyday recovery tool (roll back a bad edit) and a ransomware backstop (previous clean versions survive an encrypting edit). Modern libraries use intelligent/automatic version history that thins older versions over time rather than a flat count, but the trade is real: versions consume the site's storage quota, and a frequently-edited large file can occupy several times its visible size (storage-model concept). Version limits (per library, or the automatic policy) are the single biggest storage-reclamation lever on most tenants.

The two-stage recycle bin

Deletion isn't immediate loss — it's a two-stage journey inside a 93-day total window:

1. First-stage (site) recycle bin — where a user's deleted item lands; self-service restorable by users.
2. Second-stage (site collection) recycle bin — when an item is removed from the first stage (by a user emptying it or by aging), it falls to the site-collection recycle bin, restorable by site collection admins.

The 93 days is the total across both stages, not per stage — a common misconception is that emptying stage one resets the clock. It doesn't; the item is gone from the recycle bins 93 days after the original delete regardless.

Restore this library / Files Restore (point-in-time)

Beyond per-item restore, SharePoint libraries and OneDrive offer "Restore this library" / Files Restore — roll the WHOLE library (or OneDrive) back to any point within the last 30 days using the version and activity history. This is the ransomware-recovery mechanism (its own concept): a mass-encryption event is undone by rewinding to just before it, self-service, no ticket.

The failure modes

• 93 days is not backup. Past 93 days, recycle-bin content is unrecoverable unless a retention hold preserved it (retention concept) or Microsoft 365 Backup is in place — the recycle bin is a grace period, not an archive.
• Version limits set too low lose recovery depth; set too high, they bloat storage. The automatic policy is the balanced default.
• Deleting under retention doesn't truly delete (PHL, retention concept) — recycle-bin behaviour and retention are different systems that both apply.
• Restore window is 30 days for point-in-time — a slow-burn corruption discovered on day 45 is past the rewind horizon.
• Second-stage needs admin rights — end users can't self-recover once an item ages into the site-collection bin.

What to watch (proofs)

• Version settings: Library settings → Versioning settings (or the automatic version-history policy) — the recovery depth vs storage trade, per library.
• Recycle-bin contents and age: the site's recycle bin (both stages) — what's recoverable and how close to the 93-day edge.
• Storage attributable to versions/bins: Get-SPOSite <url> | fl StorageUsageCurrent vs live content size — the multiplier made visible.
• Restore availability: the "Restore this library" / OneDrive Files Restore option present and within 30 days — the ransomware envelope confirmed.