Map the mess before deleting anything
Run a disk-usage scanner over the shares first — WizTree or WinDirStat on Windows, du -h --max-depth=2 on a NAS — because the folder everyone blames is rarely the one eating the space. The usual suspects on an office box of this age: backups that outlived their retention policy, duplicate installers and ISOs hoarded in three departments, PST archives scattered across user folders, and profiles of people who left in 2022. Two more hide by design: the $RECYCLE.BIN folders Windows keeps per volume for shares, and volume shadow storage that previous-versions snapshots quietly consume — vssadmin list shadowstorage shows the real number.
Only once you have a ranked list should anything be deleted. A cleanup driven by a map takes an evening; a cleanup driven by frustration takes a weekend and usually deletes the wrong folder first. Keep the map afterwards too: next year's pass starts from a diff, not from zero.
The zero-downtime rules we follow
The goal is not speed but invisibility: nobody should file a ticket because of your cleanup. These six rules are what keeps it that way.
- Work in the quiet window — early morning or lunch — and never delete from a share mid-write; open files are the ones that break things
- Archive-then-delete: move candidates to a staging share with a README naming the purge date, and auto-purge after 30 days — users rescue their own files
- Go one category at a time, smallest blast radius first: temp folders, logs and recycle bins before anything a user can see
- Take a VSS snapshot before bulk operations on user-visible folders; for legally or financially sensitive data, a real backup copy comes first, no exceptions
- Keep a one-line changelog per pass — "2026-06: removed 180 GB of pre-2024 backups" — it kills the where-did-my-file-go tickets three months later
- Record free space before and after every category, so the next cleanup gets scheduled by data instead of by panic
Windows landmines and the fix that prevents round two
On the system partition, stay away from the classics: never delete inside WinSxS by hand — DISM /Online /Cleanup-Image /StartComponentCleanup is the only supported way to shrink it — and leave the pagefile, the NTFS journal and hiberfil.sys alone. Shadow storage is worth capping deliberately (vssadmin resize shadowstorage) after a cleanup, otherwise snapshots grow back into the space you just freed within weeks. The same discipline applies to logs: IIS and friends will happily refill any gap you leave, so cap their size in the service's own settings, not by deleting them manually every quarter.
The structural fix is boring and effective: set quotas per share — File Server Resource Manager on Windows Server, or your NAS's quota feature — so one user's video archive cannot silently eat the volume again. Pair that with a written retention rule per folder class (projects kept forever, scans kept three years, backups kept two generations) and the spring cleanup stops being an annual rescue mission. At that point the yearly pass shrinks to an afternoon of checking numbers against quotas, which is the entire point of the exercise.
Questions and Answers
How do I free up space on a file server without deleting user files?
Start with the invisible consumers: server-side $RECYCLE.BIN folders, aged logs, backups past retention, departed users' profiles and shadow-storage bloat. That alone typically returns tens or hundreds of gigabytes before touching a single live document.
Is it safe to delete the $RECYCLE.BIN folder on a server share?
Yes, during a quiet window: it holds files users deleted from that share in Explorer. Announce it beforehand so anyone planning to fish something out of the bin has a chance to speak up first.
Know what is included before you buy.
The one-time 30-minute trial covers core tools. PRO-labelled features stay locked until a paid license is activated.
Read next
Write to us: [email protected]