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

# Curator Backup

> Learn about Curators comprehensive backup options beyond basic Import/Export functionality.

The Import / Export is a great way to backup your Curator data but sometimes a more complete backup is
needed. The Full Backup will export an entire snapshot of all your Curator data (it's a full database and
filesystem backup of the Curator webroot directory). Curator will even show you up-to-date stats on how much
free space you have available on your server to ensure you have room.

<Note>
  Moving Curator onto new server hardware is built on top of a full backup. See
  [Moving Curator to a New Server](/upgrading_migration/migration/moving_to_a_new_server) for the end-to-end
  process.
</Note>

***Modifying the Full Backup Settings***

1. Login to the backend of your Curator instance (e.g. `http://curatorexample.com/backend`).
2. Navigate to the **Settings** > **Curator** > **Backups** in the left -hand menu.
3. Click on the gear icon to display a popup.  From here you can modify the location/frequency and retention options.

***Backup Retention and Disk Space***

This section applies to Curator On-Prem. For Curator SaaS, see the
**Curator SaaS (InterWorks-Hosted) Notes** at the end of this page.

Curator defaults to a **weekly** backup schedule that keeps **2** backups. Both values live in the gear icon
popup. **Backup Schedule** offers Manual, Daily, Weekly and Monthly. **Backup Retention** ranges from
**Keep 1** to **Keep 10**.

Curator purges old backups only while a full backup runs, and only when **Backup Schedule** is set to
something other than **Manual**. A purge deletes the oldest completed backups until the retained number
remains, and it always leaves at least one in place. On the **Manual** schedule, Curator never deletes a
completed backup, so backups build up until you remove them.

Curator purges at the start of a backup, before the new file exists, and again once the new backup is
packaged. Lowering **Backup Retention** and then taking a backup removes the extra copies straight away,
even if that backup later fails.

To reclaim space:

* Delete backups one at a time from the Backups list view using the trash icon in the **Actions** column.
* Delete the `full_backup_*.zip` files from the directory shown in **Backup Location**. That path is
  `<web root>/storage/temp` by default. Each filename
  includes the date and time of the backup. Deleting one gives up that restore point, but it does not touch
  the live Curator database or files.

To make Curator clean up on its own, set **Backup Schedule** to Daily, Weekly or Monthly and pick a
retention count that fits the free space you have. Cleanup only happens when Curator's scheduled tasks run.
If scheduled backups never appear, see the cron troubleshooting guide for
[Linux](/server_management/system_administration/linux_cron_troubleshooting) or
[Windows](/server_management/system_administration/windows_cron_troubleshooting).

***Troubleshooting Failed or Stuck Backups***

The cron guides above cover the case where the schedule never fires at all. A backup that does start but never
finishes is a different problem, and the place to look first is
**Settings** > **Curator** > **Queued Processes**.

Every full backup, scheduled or manual, runs as a "Curator Backup" job in that queue. While it runs, the job's
status moves through "Step 1 of 3: Backing up the Curator filesystem.", "Step 2 of 3: Backing up the Curator
database." and "Step 3 of 3: Packaging the full backup file." Step 1 can take a long time on a large webroot,
so a job sitting on that step is not necessarily stuck. A job that stays on **Pending** instead usually means
the queue itself is not being processed rather than that the backup failed. Two backups queued back to back
run one after the other, never at the same time. See
[Queued Processes](/site_administration/performance/queued_processes) for how to read, unblock and clear that
list.

When a backup fails part way through, Curator normally removes the job from the queue just as it does for a
successful one, so a failed backup usually leaves nothing behind in **Queued Processes**. The signal to watch
for is the job disappearing from the list without a new archive appearing under **Settings** > **Curator** >
**Backups**. Some failures do leave a job in the list with a status beginning with "Error:", which you can
remove with **Clear Errors** once you have read the log.

Either way, the reason is written to the log. Search `storage/logs/system-*.log` for the date the backup ran
(the same entries appear in the Event Log). The backup job records one of these:

* `ERROR: Unable to dump Curator database during backup` — the database dump step failed, or produced a file
  smaller than 100 KB. Confirm that `mysqldump` is on the PATH of the account that runs Curator's scheduled
  tasks, that the database credentials in Curator's configuration work from the Curator server, and that the
  installed `mysqldump` matches the database server version.
* `ERROR: Not enough space for full backup.` — free disk space on the server is smaller than the size of the
  last backup. Free up space or lower **Backup Retention**, then take a new backup. This check does not apply to
  Curator SaaS, where InterWorks manages the server and its storage.
* `ERROR: Unable to backup Curator files` — the **Backup Location** is not writable by the user Curator runs
  as, or the webroot zip step failed. The log entry names the path. See
  [Filesystem Permissions](/server_management/system_administration/filesystem_permissions) to correct the
  permissions on that folder.

A failed database dump does not stop the rest of the backup. Curator finishes packaging the files and appends
`_NO_DATABASE` to the archive name, and the Backups list shows "Does not include a database export!" against
it. A backup with that suffix cannot restore your database, so treat it as incomplete: fix the cause and take
a new backup.

***To Manually Create a new Curator Backup:***

1. Login to the backend of your Curator instance (e.g. `http://curatorexample.com/backend`).
2. Navigate to the **Settings** > **Curator** > **Backups** in the left-hand menu.
3. Click the "Take New Backup" button to start a backup.  If you would like to check the status of the backup
   while it is running, you can view the active status under the
   **Settings** > **Curator** > **Queued Processes** in the left navigation.

***To Queue a Backup From a Script:***

Automation (for example a scheduled job that refreshes a test environment) can queue a backup and check on
it through the Curator API instead of the backend. Call `/api/v1/portal/queueBackup` with an API key to
queue one, then poll `/api/v1/portal/listBackups` until the new archive shows a `Ready` status. If the queued
row disappears from that list and no new archive appears, the backup failed; check the system log under
`storage/logs/` for the error. Both endpoints are described under
[Curator API](/curator_api/api_docs/curator_api#portalqueuebackup).

***To Restore From a Full Backup:***

1. Login to the backend of your Curator instance (e.g. `http://curatorexample.com/backend`).
2. Navigate to the **Settings** > **Curator** > **Backups** in the left navigation.
3. Find the backup from the list view (NOTE: They are all appended with a timestamp from when they were
   taken), and click the "Restore Backup" icon (counter clockwise arrow) to restore Curator to exactly mirror
   the time the backup was taken.

***Curator SaaS (InterWorks-Hosted) Notes***

On Curator SaaS instances, InterWorks hosts your instance and manages its storage. The behavior described
above differs in two important ways:

* **The Backups list view shows only the 10 most recent `.iwe` backups**, even when more exist. Older
  backups are retained by InterWorks and are still recoverable, but they will not appear in the backend list
  view. If you need to restore from a backup older than the 10 most recent, contact InterWorks support.
* **The configured retention schedule does not purge `.iwe` or `.iwgz` backup files on SaaS.** These backup
  files accumulate indefinitely, and they are held under a compliance lock that prevents deletion or
  modification for the duration of the lock period. Retention settings in the backend gear icon popup have no
  effect on `.iwe` / `.iwgz` retention for SaaS deployments. To manage these files on SaaS, contact InterWorks
  support.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.