Backup Omeka S module

Releases

1.5.0

Oct 27, 2026

  • Download links, to move a site server to server. Get download link below a complete archive on the Backups page makes a link that downloads the archive without signing in, for 48 hours. It is shown once, with a Copy button; paste it into the new site's From a link box (below). Revoke link stops it at once, and a new link replaces the old one. Only a SHA-256 fingerprint of the link is stored, every use is written to backup.log, and restoring a backup's database turns off the links in the restored list. From the shell: bin/backup.php link <id> --site=<address> and unlink <id>.
  • Download a backup from a link. The Upload Backup page has a new From a link box: paste a download link from another site, or a direct link to a backup ZIP, for example in cloud storage, and the server downloads it in a background job, with no upload limit. The archive is listed straight away as downloading, with the size received so far, then checked file by file like an archive copied in by FTP, and marked complete, ready to restore.
  • Dropped connections and server errors are tried again, up to five times in a row without progress, continuing where the download stopped when the other server supports ranges. A link that leads to a web page (a sign-in page, a cloud storage preview, or the Download button of another Omeka S site's Backups page) fails with a message saying so, and so does a backup made by Omeka Classic's Backup plugin. Deleting a downloading row, or stopping its job, ends the download and removes the partial file.
  • Links must point at public internet addresses, and so must every redirect, so a link cannot make the server reach the server itself or its local network. Set 'backup' => ['allow_private_links' => true] in config/local.config.php to move a site inside a private network.
  • Sites whose files are in cloud storage. When Omeka's file store is not the local files/ folder (a module for Amazon S3, Backblaze B2 and the like), backups download every file Omeka's records point at (media originals, thumbnails, assets) from the store, and restores store them back through it, so archives move between a files/ folder and cloud storage either way. Files the store does not have are listed in the archive's metadata.json (files_missing) and in the restore preview. They used to be missing from the archive without a word, as backups only copied the files/ folder.
  • Archives are kept where the site keeps its files. On such a site, with no backup storage path set, archives are made in a private folder in the server's temporary directory, stored in the file store under backups/<32 random characters>/, and removed from the server, so the site needs no lasting folder of its own. The random folder keeps an archive's address unguessable, uploaded ones with plain names included. Downloads and download links pass through the site with byte ranges, a restore copies the archive back and checks its checksum first, and Delete removes it from the store. Adding archives by FTP needs a backup storage path there. Archives brought in from elsewhere no longer take the name of one already in the list.
  • New command bin/backup.php fetch <url> [--allow-private] does the same from the shell, printing its progress.
  • The Upload Backup page is arranged as three ways in: From your computer, From a link and Copied to the server.
  • The Download button serves byte ranges, so a browser can continue an interrupted download, and no longer holds up the administrator's other admin pages while a large archive downloads.
  • Upgrading adds two columns to the omeka_backup table for download links.
  • A damaged archive's restore now ends with the module's own message (Failed to unpack the archive: … Nothing was restored.) on PHP builds where ZipArchive::extractTo() warns about a CRC error, instead of a raw PHP warning. Nothing was restored before either.
  • New documentation pages: Downloading from a Link, Download Links, and Sites with Cloud File Storage.

1.4.3

Oct 20, 2026

  • A Supervisor, or any other user who is not a Global Administrator, who opens a Backup page (for example from a bookmark made before 1.4.2) now gets Omeka's Forbidden page with HTTP status 403. They used to get Omeka's error page Omeka S encountered an error with status 500. Who may use Backup is unchanged: Global Administrators only. Visitors who are not signed in are still sent to the login page.

1.4.2

Oct 20, 2026

  • The cron line on the Settings page names the command-line PHP. Under PHP-FPM it used to name the PHP-FPM program, which cannot run the backup script, so the line failed when pasted into a crontab. The page now looks for the command-line PHP of the same installation (such as /usr/bin/php8.3 for php-fpm8.3), falls back to plain php, and puts a path containing spaces in quotes.
  • The list of CLI commands on the Settings page shows the script's full path instead of a relative one, and includes import.
  • The database option on the Create Backup page no longer claims the dump uses mysqldump --single-transaction: the module writes it in PHP, with no mysqldump needed.
  • The Backups list sizes its columns to their content. Every column used to get the same width, so long archive names wrapped over five lines and the Download, Restore and Delete buttons stacked; names now break after their hyphens and the buttons sit side by side.
  • Backup is now for Global Administrators only. Supervisors lose access. Supervisors (site_admin) could list, create, download, upload, import, restore and delete backups and change the settings: a database download holds every user and API key, and a restore replaces them, so a Supervisor could make themselves a Global Administrator. They no longer see the Backup menu, every Backup page refuses them, and /api/backups and /api-local/backups answer with a permission error. Give the Global Administrator role to anyone who still needs to manage backups. Scheduled backups run from cron are not affected.
  • The access-control note on the Settings page and the documentation say so. The documentation also no longer promises an HTTP 403 Access Denied page (refused users get Omeka's Permission denied error page) or that /api/backups accepts the admin session cookie (it needs an API key; signed-in browsers can read through /api-local/backups).

1.4.1

Oct 15, 2026

  • The Delete buttons on the Backups page now carry a CSRF token, so another website can no longer make an administrator's browser delete a backup. A delete without a valid token is refused with The page had expired, so nothing was deleted.
  • The Delete and Restore confirmation dialogs now work with any filename. Archives added from the backup directory (new in 1.4.0) keep their own names, and a name containing an apostrophe skipped the Delete confirmation, while a crafted name could run script in the administrator's browser.

1.4.0

Oct 15, 2026

  • Archives too large to upload can be copied into the backup directory with FTP, SFTP or SSH and restored from there. The Backups page lists ZIP files in the backup directory that are not in the list under Archives in the backup directory, flags files that may still be arriving, and adds one with Add to backups. A background job checks every file in the archive against the ZIP's CRC-32 checksums and records its SHA-256 checksum before it is marked complete, so a damaged transfer is caught before a restore.
  • New import command for bin/backup.php adds such archives from the shell, and list shows the ones not in the list yet.
  • The Upload Backup page shows the server's upload limit and where to copy larger archives.
  • Restores check every unpacked file against the ZIP's CRC-32 checksums and the free space in the temporary directory before changing anything. PHP's unzip reports success even when a file fails its checksum, so an archive with a damaged file used to be restored with that file corrupted.
  • After a database restore, the archive you restored from stays in the list as complete. It used to reappear as in progress, the state it was in when the dump was written, and could no longer be restored.
  • Backups that are listed but whose ZIP is missing, such as records restored from another server's database, show file missing instead of Download and Restore buttons.
  • New backups record the Omeka S version in metadata.json. The restore preview shows it, along with when the archive was made, and warns when the archive comes from a newer Omeka S than the one installed.
  • A restore holds the backup lock, so no backup can start while it runs.
  • Fixed the "files files" wording on the Create Backup and Restore pages.

1.3.1

Oct 15, 2026

  • The Backup entry in the admin menu showed its text in a serif fallback font: the link carried Font Awesome's fa class, which sets the whole link in the icon font. It now carries only the icon class, like the other menu entries.

1.3.0

No release notes.

1.1.0

No release notes.

1.0.5

No release notes.

1.0.4

No release notes.

1.0.3

No release notes.

1.0.2

No release notes.

1.0.1

No release notes.

1.0.0

No release notes.

Log in for Support