Usage

Scheduled Backups

Automatic backups use the module's command-line script, modules/Backup/bin/backup.php, run from cron. The module has no built-in scheduler.

The cron line

Go to Admin > Backup > Settings. Under Scheduled Backups (cron) the page prints a line built from this server's PHP binary and the script's real path. It looks like this:

0 2 * * * /usr/bin/php /var/www/omeka-s/modules/Backup/bin/backup.php create >> /var/log/omeka-backup.log 2>&1
  1. Copy the line from the Settings page.
  2. Open the crontab of the web server user, for example sudo crontab -e -u www-data.
  3. Paste the line, adjusting the time and the log path as needed, and save.

This creates a full backup (database, files, themes, modules and API export) every day at 02:00. Add --no-api or --no-files after create to leave those components out.

Which user to run as

Run the script as the same user the web server runs as (www-data, apache, or similar). It needs write access to the backup directory and read access to files/, themes/ and modules/. Backups created this way show cron in the Created By column.

The script reads config/database.ini and the rest of the Omeka configuration exactly as the web application does, so it must be run on the same server with the same PHP installation. It expects to live at modules/Backup/bin/backup.php under the Omeka root and exits with Cannot find Omeka S root if moved elsewhere.

Retention

Every create run applies the retention limit afterwards, so a nightly cron job keeps at most the configured number of complete backups. You do not need a separate cleanup job unless you change the limit and want older archives removed straight away:

0 3 * * 0 /usr/bin/php /var/www/omeka-s/modules/Backup/bin/backup.php cleanup >> /var/log/omeka-backup.log 2>&1

Overlap with manual backups

Only one backup can run at a time. If a cron run starts while someone is creating a backup from the admin panel (or the other way round), the second run fails with Another backup operation is already in progress and exits with code 1. Schedule cron for a quiet time.

Differences from admin-panel backups

  • Command-line runs have no logged-in user. The API export therefore includes only public items, item sets and sites; private resources are omitted. The database dump and file copies are complete regardless.
  • Themes and modules are always included; there is no flag to leave them out.
  • Progress is printed to standard output and errors to standard error, which the >> and 2>&1 in the cron line send to the log file. The module's own backup.log in the backup directory records the run as well.

See CLI Commands for the full command reference.

Log in for Support