Routine storage hygiene maintains optimal performance and prevents an overrun of contracted storage limits as applications grow.
File system storage use increases mainly because of accumulated log files, uncompressed assets, temporary files, or old environment backups. The following section provides instructions on how to manage and reduce storage volumes:
Clear temporary files: Open the temporary file directory at /mnt/tmp/ and delete old or unnecessary temporary files.
Clean up orphaned managed files: Drupal tracks uploaded files in the file_managed table. Cron must purge files that never attach to content.
Remove old backups: Check for manual database dumps with sql or sql.gz extensions, or codebase archives with tar.gz extensions left behind in the file system after deployments or testing, especially in non-production environments.
Audit log directories: Massive, unrotated log files consume gigabytes of space. Ensure that custom log mechanisms rotate and archive logs properly, and delete outdated logs.
Offload large media assets: For applications that host large media libraries, move assets from the file system allocation of the subscription to external object storage such as Amazon S3 with the S3 File System Drupal module.
Clear image styles: Drupal generates image styles such as thumbnails and resized images, which bloat the sites/default/files/styles directory over time. Clear image styles through Drush to delete these generated images safely and free up space.
Clear aggregated assets: Compiled asset bundles accumulate in sites/default/files/css/ and sites/default/files/js/. Deletion of these bundles is safe because they regenerate when needed.
Avoid file duplication: Do not copy the entire production sites/default/files directory to lower environments unless you actively test media features. Stage file directories often contain years of orphaned assets that remain uncleaned.
Database storage use increases mainly because of large tables, accumulated cache data, application logs stored in the database, excessive content revisions, retained database backups, binary logs, inefficient data models, or a lack of regular maintenance. The following section provides instructions to manage and reduce storage volumes:
Identify large tables first: Surface the largest tables before you act.
Truncate cache tables: Run Drupal cron periodically to manage the size of cache tables such as cache_form and cache_page.
Clear the watchdog database log table: Truncate the watchdog table because the table becomes large if the application logs errors to the database instead of the file system. You must configure Syslog to route logs to the file system.
Clean up revisions: Drupal stores a revision every time content updates. Use modules such as
Contact your Account Manager or Acquia Support to discuss right-sizing your storage entitlement to accommodate growth if the application genuinely requires additional storage capacity.
Process and purge queue tables: The queue table can accumulate a backlog from inactive modules. Check for stale items.
Optimize tables: After you delete a large amount of data, such as when you truncate tables or delete revisions, the database retains the allocated space. Run an OPTIMIZE TABLE command to reclaim this unused, fragmented space.
Sanitize database synchronizations: When you copy a production database to a staging environment, do not synchronize unnecessary tables such as watchdog or massive cache tables. Use Drush aliases to exclude these tables during synchronizations and help reduce non-production database storage.
Remove unnecessary database backups: Check for manual database dumps stored in the file system and remove those that are no longer required, particularly in non-production environments.
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Process and purge queue tables: The queue table can accumulate a backlog from inactive modules. Check for stale items.
Optimize tables: After you delete a large amount of data, such as when you truncate tables or delete revisions, the database retains the allocated space. Run an OPTIMIZE TABLE command to reclaim this unused, fragmented space.
Sanitize database synchronizations: When you copy a production database to a staging environment, do not synchronize unnecessary tables such as watchdog or massive cache tables. Use Drush aliases to exclude these tables during synchronizations and help reduce non-production database storage.
Remove unnecessary database backups: Check for manual database dumps stored in the file system and remove those that are no longer required, particularly in non-production environments.
If this content did not answer your questions, try searching or contacting our support team for further assistance.