A production site had grown to 36 GB against a plan sized for a fraction of that. The working theory was that an image-optimization plugin was hoarding pre-optimization backups.
The theory was wrong, and it was checkable in about a minute: the plugin's backup settings were already disabled, and a filesystem search for its backup files returned zero.
The space was in ordinary operation, not in anything anyone had done wrong. Uploads accounted for 35 GB across 104,280 files — 16.5 GB of generated thumbnails across 94,059 files, 13.6 GB of platform-retained pre-scale originals, 3.7 GB of served originals, and a small remainder orphaned on disk with no database reference at all.
Nineteen registered thumbnail sizes means every uploaded image quietly becomes twenty files. Nobody chose that; it accumulated as themes and plugins each registered their own.
And there was no room for a full backup before deleting anything — the situation that usually stops this work entirely, because the safe move is unavailable.
The reframe: split the reclaim by reversal path, not by size. Sorting by what is biggest tells you what to delete and nothing about what it costs if you are wrong. Sorting by how you would undo it turns one dangerous operation into three with different risk profiles — regenerable thumbnails the platform rebuilds on command, self-rebuilding caches and logs, and the genuinely irreversible retained originals, which get archived off-server first and removed second.
The impossible problem dissolves once you notice that most of the target does not need a backup at all.
Two verification instruments, because they catch different things
A crawl of every URL in every sitemap gives the positive set — what is actually rendered. Thirty days of origin access logs give what was actually requested. The crawl found zero retained originals rendered anywhere; the logs found thirty actively requested, via direct links and lightbox targets no crawler can see. Acting on the crawl alone would have broken live images on a production site.
Behind a CDN, origin logs undercount real usage
Requests served from the edge never reach the origin, so they never appear in its logs. Absent from the logs is therefore unproven, never proven unused. Logs are used strictly as an exclusion filter — anything requested is kept — and never as permission to delete.
The storage bill was an architecture question nobody had asked
How many derivative files does every upload generate, which of them does anything actually serve, and what is retained forever by default. Answer those and the bill stops growing, rather than growing more slowly.
Client, vendor, product and industry details are removed, along with any figures belonging to the client. The technical detail is unchanged. This shows how we work — it is not a claim about a business result, which would require the client’s consent and a baseline measured before the work began.