Skip to main content
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.
Moving Curator onto new server hardware is built on top of a full backup. See Moving Curator to a New Server for the end-to-end process.
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 or Windows. 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 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 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. 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.