> ## Documentation Index
> Fetch the complete documentation index at: https://docs.curator.interworks.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Disk Usage Management

> Understand what consumes disk space in Curator and how to manage log retention, backups, cache, and uploaded files to keep the storage footprint under control.

## 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.

<Note>
  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](/server_management/system_administration/disk_speed_metrics).
</Note>

## What Consumes Disk Space

| Contributor                         | Location                   | Retention / cleanup                            |
| ----------------------------------- | -------------------------- | ---------------------------------------------- |
| **System log files**                | `storage/logs/`            | Rotated daily, kept 14 days                    |
| **Event, usage, content-view logs** | Curator database tables    | Pruned on a schedule                           |
| **Backup archives**                 | Configured backup location | Manual deletion; pruned once a schedule is set |
| **Cache**                           | `storage/framework/cache`  | Cleared via **Clear Cache**                    |
| **Uploaded files and assets**       | `storage/app`              | Not auto-pruned                                |

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").

<Note>
  The Free Space meter is hidden on InterWorks hosted instances, where storage is managed for you.
</Note>

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](/server_management/system_administration/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.

<Note>
  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.
</Note>

## 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

<Warning>
  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.
</Warning>

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.

<Note>
  An invalid retention value (empty or greater than 10) is automatically treated as **2**.
</Note>

### 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](#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](#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.