From the admin panel
- Go to Admin > Backup (
/admin/backup) and click Create Backup. - Choose which components to include. All five are selected by default.
- Click Create Backup.
The backup runs as an Omeka S background job. You are returned to the backup list with a message that links to the job (Admin > Jobs). Refresh the list after a moment to see the new archive.
Components
| Checkbox | What it adds to the archive |
|---|---|
| Include database dump (db.sql) | Every table and view in the Omeka database, dumped in pure PHP through Omeka's database connection. No mysqldump is used. |
| Include files (files/ directory) | A copy of Omeka's local file store: original/, large/, medium/, square/, asset/ and anything else under files/. |
| Include themes directory (themes/) | A copy of themes/, including any theme customisations. |
| Include modules directory (modules/) | A copy of modules/, including the Backup module itself. |
| Include API JSON-LD export (export/*.json) | JSON-LD snapshots of items, item sets, vocabularies, resource templates, properties, resource classes and sites, fetched through the internal API as the user who started the backup. Informational only; the export is not re-imported on restore. |
The database dump and the files copy are what a restore needs. Themes and modules make the archive a complete copy of the installation. The API export is useful as a human-readable record or for migrating data to another system.
What happens during a backup
- A record with status in_progress appears in the list immediately, so a crashed job is visible.
- The module checks for at least 100 MB free in the backup directory and takes an exclusive lock (
.backup.lock). A second backup started while one is running fails with Another backup operation is already in progress. - Components are gathered into a temporary directory under the system temp path, zipped into the backup directory as
omeka-backup-YYYYMMDD-HHmmss-<token>.zip, and the temporary copy is removed. - The archive's size and SHA-256 checksum are recorded and the status becomes complete. If anything fails, the status becomes failed and the reason is written to
backup.logand to the job's log. - Retention cleanup runs, deleting complete backups beyond the configured limit. See Configuration.
The backup list
Each row shows the record number, filename, size, creation time, who created it and its status (in_progress, complete or failed). The Created By column links to the user's page; backups made by cron or the CLI show cron.
| Button | Available for | Action |
|---|---|---|
| Download | complete backups | Streams the ZIP to your browser. |
| Restore | complete backups | Opens the restore preview. See Restoring Backups. |
| Delete | every record | After a confirmation dialog, removes the ZIP from disk and the record from the list. |
Deleting a failed or stuck record does not affect any other archive. A complete record whose ZIP is no longer on disk shows file missing in the Status column and offers only Delete.
Below the list, Archives in the backup directory shows any ZIP files in the backup directory that are not in the list, such as archives copied there by FTP, with an Add to backups button for each. See Adding Archives by FTP.
From the command line
# Full backup (database, files, themes, modules, API export)
php modules/Backup/bin/backup.php create
# Skip the API export
php modules/Backup/bin/backup.php create --no-api
# Database only (themes and modules are still included)
php modules/Backup/bin/backup.php create --no-files --no-api
Run the script as the user that owns the Omeka files and the backup directory. Command-line backups have no logged-in user, so the API export contains only public resources. The full option list is on CLI Commands; for cron setup see Scheduled Backups.
What is inside an archive
See Backup Archive Format for the full layout, the metadata.json manifest and the SQL dump format.