How to back up and audit a large WordPress uploads folder before cleanup

Before deleting files from a large WordPress uploads directory, it is important to create a complete backup and understand what is actually consuming the space. In one support case, a site had an uploads folder of roughly 27 GB and nearly 40,000 Media Library items, while a related site was substantially smaller.

The developer created a complete archive of the uploads directory, uploaded it to secure cloud storage, and verified the backup against the server. The audit also showed that a large share of the disk usage was not ordinary Media Library content at all. Roughly 7 GB came from plugin backups, import leftovers, and other non-media files, while another 2.8 GB consisted of customer-uploaded documents that required a retention decision rather than automated cleanup. The review also raised a separate concern: the site had about 675,564 files for 39,475 media items, or roughly 17 files per item, which suggested that registered image sizes and regenerated thumbnails could be a major contributor to storage growth.

Issue background

A WordPress site had accumulated a very large wp-content/uploads/ directory. The Media Library contained roughly 39,475 items, and the uploads directory was around 27 GB.

A related site with similar content was much smaller, so the site owner wanted to clean up the larger installation.

Media Cleaner had already identified several gigabytes that appeared removable. However, before deleting anything, the owner wanted a complete copy of the uploads directory stored somewhere outside the web server.

The uploads directory was too large for a simple point-and-click backup workflow, so the task required direct server access.

Diagnosis

The developer connected to the server over SSH and reviewed the uploads directory before treating Media Cleaner’s results as the complete answer.

That review produced two important findings.

First, the file count was much larger than the Media Library count alone would suggest.

The site had approximately:

675,564 files
39,475 media items

That works out to roughly 17 files per Media Library item.

WordPress creates derivative files for every registered image size, so one source image can result in many thumbnails and resized copies. If one site registers more image sizes than another, the uploads directory can grow dramatically even when the Media Library contains a similar number of images.

This matters because Media Cleaner primarily identifies unused or orphaned media. It does not solve an excessive registered-image-size configuration. If derivative image files are deleted but WordPress still expects those sizes, they can be regenerated later.

Second, a large amount of storage was not normal Media Library content.

The uploads directory contained folders and files associated with plugins and historical maintenance, including:

  • ShortPixel backup copies of optimized images.
  • Old manual backup data stored inside uploads.
  • WP All Import and WP All Export working files.
  • Media quarantine data.
  • Legacy thumbnail/cache directories.
  • WooCommerce log files.

The developer estimated that around 7 GB could likely be removed safely after review, including repeated import files, image-optimizer backups, and an obsolete manual backup directory.

Another approximately 2.8 GB consisted of customer-uploaded invoices and documents. Those files contained real user data and could not be treated as generic cache or cleanup material. Their removal required a business retention decision.

The file distribution also showed that more than half of the files were concentrated in a single year, which pointed toward a historical bulk product import rather than ordinary organic growth.

Resolution steps

The documented backup and audit process was:

  1. Use direct server access for very large uploads directories. Because the folder was too large for a basic WordPress backup workflow, the developer used SSH access to work with the directory directly.
  2. Archive the complete uploads folder before deleting anything. The entire uploads directory was packaged into a single archive rather than selecting only Media Library files.
  3. Transfer the archive to external cloud storage. The completed backup was moved off the web server so cleanup could proceed without relying on the live filesystem as the only copy.
  4. Verify the archive against the server. The final backup was approximately 28 GB and was checked for completeness against the source files.
  5. Inventory non-media directories inside uploads. The developer identified plugin backups, import/export scratch files, quarantine data, old backups, logs, and other directories that Media Cleaner would not necessarily treat as Media Library cleanup candidates.
  6. Separate technical cleanup from data-retention decisions. Plugin caches and historical import artifacts can often be removed after verification, while customer-uploaded invoices and documents require an explicit retention policy.
  7. Compare registered image sizes between related sites. Before deleting large numbers of generated thumbnails, compare how many image sizes each WordPress installation registers.
  8. Investigate unusually dense years or import periods. A large concentration of files in one year can indicate a bulk import that generated many derivative assets at once.
  9. Use Media Cleaner only for the problem it is designed to solve. It can help identify orphaned media, but it should not be expected to remove plugin backups, historical import files, or fix excessive thumbnail generation.
  10. Handle restoration carefully. The developer documented a filename compatibility issue that could cause a few hundred files to be silently omitted if the archive were extracted naively on Windows, so restoration should be handled in a controlled server environment.

The task did not document the subsequent cleanup itself. The completed work was the verified backup and storage audit, along with recommendations for what to investigate before deleting files.

Final outcome

A complete backup of the WordPress uploads directory was created, transferred to external storage, and verified against the server. The resulting archive was approximately 28 GB.

The audit also showed that the size difference could not be explained solely by unused Media Library items. Roughly 7 GB was associated with removable plugin/import leftovers, approximately 2.8 GB was customer-uploaded documentation requiring a retention decision, and the extremely high file-to-media ratio suggested that generated image sizes deserved separate review.

The broader lesson is that wp-content/uploads/ is not always just a collection of images. Plugins often use it for backups, imports, logs, quarantine files, customer documents, and generated derivatives. Before running an automated media cleanup on a large site, back up the entire directory, inventory what is inside it, and distinguish orphaned media from plugin data and files that may need to be retained.

If your WordPress uploads folder has grown unexpectedly large and you need a safe backup and cleanup plan, contact Freshy. Our WordPress team can audit the directory, identify what is actually consuming storage, and help determine what can be removed without risking important media or customer data.