Skip to main content

​
Introduction

Over time, a Curator installation accumulates data on disk: log files, database-backed logs, backup archives, cached files, and uploaded assets. It is normal for disk usage to grow as the portal is used, and a major version upgrade can cause a temporary spike while the migration runs and a fresh backup is retained. This guide explains the main contributors to Curator’s storage footprint, how to see current disk usage, and how to reduce it by adjusting retention settings, pruning backups, and clearing the cache.
This page is about storage capacity: what fills up the disk and how to reclaim space. If instead you are troubleshooting disk speed (sluggish reads/writes), see Disk Speed Metrics.

​
What Consumes Disk Space

System log files are handled by the daily log channel in config/logging.php. Database log pruning follows the Usage Log Retention and Event Log Retention settings in Portal Settings. Uploaded files are managed through the portal’s file and content areas.

​
Viewing Current Disk Usage

Curator shows free disk space directly in the backend:
  1. In the backend, open Backups (from the main backend navigation).
  2. At the top of the Backups page, the Free Space meter shows free space as a percentage, with a tooltip giving the exact free and total space (for example, “Free Space: 40 GB of 100 GB”).
The Free Space meter is hidden on InterWorks hosted instances, where storage is managed for you.
For a per-directory breakdown on a self-hosted server, connect over SSH (Linux) or RDP (Windows) and inspect the storage/ folder: storage/logs, storage/app, and storage/framework/cache are the usual large consumers, along with your backup location.

​
Adjusting Log Retention

Curator writes two kinds of logs:
  • System log files on disk (storage/logs), rotated automatically and kept for 14 days. This is controlled by config/logging.php and does not normally need tuning. If your logs are not rotating and are consuming excessive space, follow Updating Curator Logging.
  • Event, usage, and content-view logs stored in the database. These are pruned on a schedule according to two settings in Portal Settings.
To change database log retention:
  1. In the backend, go to Settings → Portal Settings and open the General tab.
  2. Set Usage Log Retention: how long usage-log data (and older log files and content-view records) are kept. Options are 1 Month (default), 3 Months, 6 Months, or 12 Months.
  3. Set Event Log Retention: an optional shorter window for pruning event-log data on top of the Usage Log Retention floor. Options are Never (Manual) (default), 1 Week, 2 Weeks, 1 Month, or 3 Months. “Never (Manual)” does not mean event logs grow without bound: the scheduled cleanup still deletes event-log rows older than Usage Log Retention. “Never (Manual)” only means no additional shorter-window pruning is applied beyond that floor.
  4. Save. Curator’s scheduled cleanup task applies the new retention window on its next run and deletes older records.
Retention works in two layers. Usage Log Retention is the outer floor: the scheduled cleanup prunes event logs, usage logs, on-disk log files, and content-view records older than this window. Event Log Retention adds an optional shorter inner window that prunes event logs more aggressively. Leaving Event Log Retention on Never (Manual) does not cause unbounded growth. Event logs are still pruned by the Usage Log Retention floor; it only skips the extra shorter-window pruning. Choose a finite Event Log Retention if you want event logs cleared sooner than the Usage Log Retention window on a busy portal.

​
Managing Backups

Full backups include a database dump plus portal files, so each archive can be large. They are one of the biggest disk-usage contributors, especially when several are retained.

​
Delete individual backups

  1. In the backend, open Backups.
  2. In the backup list, click the trash icon next to any completed backup and confirm the deletion.

​
Configure scheduled-backup retention

Pruning is enabled whenever a Backup Schedule is set. Once a schedule is in place, any backup run, whether scheduled or manually triggered, prunes the backup list down to the retention count, and manually created archives are pruned alongside scheduled ones. If there is a backup you want to keep indefinitely, copy it out of the backup location so it is not removed by a later pruning pass.
  1. On the Backups page, click the gear icon to open Backup Settings.
  2. Set a Backup Schedule (Daily, Weekly, or Monthly) if you want automatic backups. Leaving it on Manual disables both scheduled backups and automatic pruning.
  3. Set Backup Retention to the number of backups to keep (1 to 10). When any backup runs (scheduled or manually triggered), Curator prunes the backup list down to this count, always keeping at least one.
  4. Optionally set a Backup Location to store archives on a different disk or path (for example, a larger volume) to keep them off the primary disk. If the backup location is set by an environment variable, this field is disabled and must be changed via the environment.
  5. Save.
An invalid retention value (empty or greater than 10) is automatically treated as 2.

​
Backups fail even though the Free Space meter shows available space

Before a backup runs, Curator checks that free disk space exceeds the size of your most recent completed backup. That check is only a rough guard: backup creation is a multi-step process that temporarily needs more disk space than the final archive.
  1. A webroot ZIP is written to the backup location.
  2. A database dump (.sql file) is written alongside it.
  3. A final full-backup ZIP is assembled from the webroot ZIP and the database dump.
  4. The intermediate webroot ZIP and database dump are deleted once the final ZIP is complete.
During step 3 the webroot ZIP, the database dump, and the final ZIP all coexist on disk, so the peak temporary space requirement can be roughly two to three times the size of the finished backup. If the disk fills during this window, the final ZIP cannot be written and the backup fails, even though the Free Space meter appeared to show enough room before the backup started. To resolve:
  • Delete older backups (see Delete individual backups) to free up more space than the pre-backup check alone requires.
  • As a rule of thumb, keep free disk space at roughly 3x the size of your most recent backup before running a new one.
  • If your portal is large and backups routinely run out of space, set a Backup Location that points to a larger volume (see Configure scheduled-backup retention) to keep backups off the primary disk.
  • On Windows servers, also confirm that the account running the web server process is not subject to a per-account disk quota: a quota can cause ZIP creation to fail even when the overall volume reports free space.

​
Clearing the Cache

Curator caches compiled templates, combined assets, and other computed data under storage/. Clearing the cache reclaims that space and forces Curator to rebuild it on the next request.
  1. In the backend toolbar (top of the page), click Clear Cache.
  2. Wait for the operation to complete. The cache is rebuilt automatically as the portal is used again.
Clearing the cache is safe and non-destructive: it removes only cached files that Curator rebuilds automatically, never your content, settings, or uploads.

​
Disk Usage During Upgrades

A major version upgrade (for example, 2025.10 → 2026.04-01) can temporarily increase disk usage:
  • Migration artifacts and newly generated files are written during the upgrade.
  • Deprecated vendor files from previous versions are removed automatically by upgrade migrations, so some of the increase is reclaimed once the upgrade finishes.
Before upgrading, the upgrade screen checks for a recent backup and warns you if none exists; always take a fresh backup first. That backup counts toward your disk usage, so once the upgrade is verified you can prune older backups as described above to reclaim space.