"Omeka could not start a background job"
Omeka runs backups, restores and downloads as long-running jobs, which start PHP on the command line. The message gives Omeka's reason. Usually Omeka cannot find the PHP command-line binary, or the server does not allow PHP to start programs (exec is disabled). Set background.php.path in application/config/config.ini to the PHP binary (which php shows it), or ask your host. Meanwhile, the command line does the same work.
A backup, restore or download failed, or never started
The list says why after Failed:. A job records whatever stops it, including PHP errors and running out of memory, and the list notices within a minute when the job's background process ended without finishing. The common reasons:
- "The background job never began": Omeka started PHP on the command line, but PHP stopped before running the job, so it stops every background job, not only Backup's. Run Check background jobs on the Settings tab (see Configuration): its test job shows what PHP printed. A common cause is a command-line PHP older than the site's, which cannot load a plugin written for a newer PHP: the check then shows a
PHP Parse errorin that plugin's file. Setbackground.php.pathinapplication/config/config.inito the PHP binary of the same version as the site (for example/usr/bin/php8.2). - "The background job's process ended unexpectedly": PHP ran out of memory, or the server restarted or stopped the process. Delete the entry and start again; for out of memory, raise
memory_limitfor PHP's command line. - "Another backup or restore is running": only one runs at a time. Wait for it to finish; the list shows its progress. The Backups page also says so when you click Back up now or Restore while one runs.
- A PHP error with a file and line: the error PHP met in the job. The command line runs the same job in a terminal and shows the whole error.
Delete a failed entry and start again once the cause is fixed.
A backup or restore says "Stopped: no progress for 15 minutes"
Its process stopped reporting progress. This only appears for jobs whose background process cannot be followed (jobs started before Backup 1.0.1, or on sites that run long jobs inside the web request). Delete the entry and start again. Check the server's PHP error log for the cause, and run Check background jobs.
"The archive is damaged: … does not match the checksum stored in the ZIP"
The archive changed on its way to the server. Copy it again; with FTP, use binary mode, since text mode damages ZIP files. For uploads and links, try again: interrupted transfers resume, but a file damaged before the transfer must be made again on the old site.
"This is a backup of an Omeka S site"
Omeka S and Omeka Classic store sites differently, so Classic cannot restore an Omeka S archive.
"This archive was made on Omeka Classic … Upgrade Omeka here first"
The new site runs an older Omeka than the old one did. Upgrade Omeka on the new server, then restore.
"The link points at a private network address"
Download links must point at a public server. Moving between servers on a private network? See Configuration.
"The link does not work (HTTP 404)"
The download link expired (after 48 hours), was revoked, or was replaced by a newer link for the same archive. Make a new one on the old site.
The upload stops or fails
Uploads go in pieces sized below the server's upload limit, and each piece is retried after a dropped connection. If it still fails, use a download link or copy the archive to the server by SFTP.
After the restore I cannot sign in
The accounts are the archive's: sign in with an account from the old site. Use Lost your password? if needed; the site's email settings come from the archive too.
Some images are missing after moving from cloud storage
The archive's manifest lists files that could not be downloaded when the backup was made (files.missing); the restore page says how many. They were missing from the old site's storage too, or are images that pages link to in a way Backup does not recognize. Copy them across by hand.
A plugin's pages are missing after the restore
Its records came back with the database, but the plugin is not installed here. Install the same plugin (the same or a newer version) and activate it.
"The archive could not be stored in the site's file storage"
The backup was made, but the cloud storage refused it; the message ends with the storage's reason. Check background jobs on the Settings tab stores a small test file the same way. Until it works, set a backup directory under Settings to keep archives on the server. Delete the failed entry to remove the archive left on the server.
"The archive could not be copied from the site's file storage"
A restore copies an archive kept in cloud storage to the server first. "HTTP 404" means the archive is no longer in the storage (deleted there by hand, or the storage changed). Other errors are retried a few times first.