CLI Commands

The script is modules/Backup/bin/backup.php. Run it with the PHP CLI from any directory; it locates the Omeka root three levels above itself and bootstraps the application without handling an HTTP request.

php /var/www/omeka-s/modules/Backup/bin/backup.php <command> [options]

Run it as the web server user so that file permissions match the admin panel. Exit code 0 means success and 1 means failure. Progress messages go to standard output and errors to standard error, each prefixed with a timestamp.

create#

Create a new backup and apply the retention limit afterwards.

php modules/Backup/bin/backup.php create [--no-db] [--no-files] [--no-api]

Themes and modules are always included from the command line. The command prints the chosen options, then Backup complete: <filename> (<bytes> bytes). Because there is no logged-in user, the record's creator is empty (shown as cron in the admin list) and the API export contains only public resources.

list#

Print every backup record, newest first.

php modules/Backup/bin/backup.php list

Columns are ID, Filename (truncated to 38 characters), Size in MB, Created At and Status. Prints No backups found. when the table is empty.

ZIP files in the backup directory that are not in the list follow under Not in the list, with their size and modification time. Add them with import.

cleanup#

Delete complete backups beyond the Retention: keep last N complete backups setting, from disk and from the list.

php modules/Backup/bin/backup.php cleanup

restore#

Restore a backup by its record ID (from list or the first column of the admin list).

php modules/Backup/bin/backup.php restore <id> [--no-db] [--no-files]

The command first prints the dry-run summary (the same What will happen list as the admin page), then prompts Type RESTORE to confirm (or anything else to abort). Anything other than RESTORE (case-insensitive) prints Aborted. and exits with code 0. Themes and modules are restored whenever the archive contains them; there is no option to skip them.

The checksum check, extraction and component handling are identical to a restore from the admin panel. See Restoring Backups.

import#

Add archives copied into the backup directory (for example with FTP, SFTP or scp) to the list.

php modules/Backup/bin/backup.php import [<filename> ...]

With one or more filenames, adds those archives. A path is accepted as long as it points into the backup directory; a file anywhere else is refused, so move it there first. With no filename, adds every ZIP in the backup directory that is not in the list.

Each archive goes through the same checks as Add to backups on the Backups page: it must be a complete ZIP containing metadata.json, and every file inside it must match its stored CRC-32 checksum. The archive's SHA-256 checksum is recorded and it is listed as complete, with no background job. The command prints Added as backup #<id> with the matching restore command for each archive, or an error for any that fail, and exits with code 1 if any failed. An archive that fails the content check stays in the list as failed.

See Adding Archives by FTP.

help#

Any other command, or no command, prints the usage summary.

Requirements for CLI runs#

• The PHP CLI must be able to read config/database.ini and connect to the database, as the web application does.
• The same zip extension requirement applies.
• The script writes to the same backup directory and backup.log as the admin panel, so the running user needs write access there.