Releases

• Every archive is kept in a folder with a random name (32 characters), in the backup directory and in the site's file storage: backups/<folder>/<name>. Where the archives are served publicly (cloud storage, or a files folder that the web server serves without reading .htaccess, as nginx does), what keeps an archive private is that its address cannot be guessed. Archives made here always had a random part in their names, but uploaded, downloaded and added archives kept their own names (backup.zip), so their addresses could be guessed. Archives keep their names for downloads.
• Upgrading moves existing archives into such folders, on the server and in the file storage. One that cannot be moved stays, and the list says so if its address could be guessed.
• The log has a random name (backup-<32 characters>.log) instead of backup.log: it names archives and the addresses download links were used from, and it sits in the backup directory. Upgrading renames it.
• Working folders made during backups and restores have longer random names.

• Archives are kept where the site keeps its files. On a site whose files are in cloud storage (Omeka's storage.adapter, such as the Backblaze B2 storage of hosted sites), archives are made in a private temporary folder on the server and stored in that storage under backups/, so the site needs no writable files folder of its own. Downloads and download links pass through the site; a restore copies the archive back first and checks it. Sites with files on disk keep archives in files/backups as before, and a backup directory set under Settings still keeps them on the server.
• Check background jobs also checks where archives are kept: the backup directory, and for cloud storage a test file stored, read back and deleted.
• "The backup directory … cannot be created" gives PHP's reason (for example "Permission denied").

• Failed jobs always say why. A backup, restore or download records whatever stops it, PHP errors and running out of memory included. Before, a job that failed before it began (another job holding the lock, a backup folder it could not create) or with a PHP error stayed at "Waiting to start…" or "Working…" until it was marked stopped after 15 minutes, without a reason.
• Ended processes are noticed within a minute. Each job is linked to Omeka's background process, so the list marks a job failed, with what happened, when its process ended with an error, never began, or died.
• Check background jobs on the Settings tab: the PHP command-line program Omeka uses, its version and extensions beside the web server's, and a test job run with Omeka's background script, showing what PHP printed. It shows, for example, a command-line PHP too old for a plugin, which stops every background job on the site.
• Back up now and Restore say at once when another backup or restore is running, instead of starting a job that fails.

First version for Omeka Classic, the counterpart of Backup 1.4 for Omeka S, built for moving sites between servers.

• One archive per backup: the database (written in PHP through Omeka's connection, loadable with the mysql client), every stored file, and optionally the plugin and theme folders, with a manifest of the site, its Omeka version, plugins, theme, tables and files, and a README for restoring by hand.
• Any file storage: files on disk are copied from the files folder; files in cloud storage (which cannot be listed) are downloaded, six at a time, from the records that point at them: originals, derivative images, theme setting uploads and theme uploads that pages link to. A restore stores files through the site's own storage, so archives move between disk and cloud storage in either direction.
• Only this site's tables: tables with the site's prefix, without sessions, background processes or the plugin's own list. A restore renames the tables when the new site's prefix differs, and falls back to utf8mb4_unicode_ci for MySQL 8 collations older servers lack.
• Moving archives: uploads in pieces below the server's upload limit, with retries; download links (/backup-download/<id>/<token>, 48 hours, revocable, stored as a hash) that another site's Backups page downloads from directly, resuming after dropped connections and refusing private network addresses unless backup.allowPrivateLinks is set; archives copied in by FTP.
• Checked restores: every archive brought in is checked against the ZIP's CRC-32 checksums and gets a SHA-256 checksum, compared again before a restore. The restore page shows the archive's contents and what will change, warns about missing plugins and themes and older Omeka versions, refuses archives from newer ones, and asks for RESTORE. It backs the site up first by default.
• Keeps the server's own state: Backup's list, settings and plugin record, the hosting storage adapter's record, the ImageMagick path, and the current theme while the archive's is not installed. Everyone is signed out.
• Background jobs with live progress for backups, restores, downloads and checks; one at a time; stalled jobs are recognized.
• Command line (bin/backup.php): create, list, add, fetch, restore, link, delete and cleanup, for cron and very large archives.
• Keeps the newest backups made on the site (5 by default); archives brought in are never deleted automatically. Super Users only.