An archive that is too large for the Upload Backup page can be copied to the server with FTP, SFTP, SSH or your hosting control panel's file manager instead. Put it in the backup directory and the Backups page finds it, checks it and adds it to the list, ready to restore.
Copying the archive
- Find the backup directory. The Upload Backup page names it under Archive too large to upload?, and Admin > Backup > Settings shows it next to the storage path. Unless you changed the setting it is the
backupfolder in the Omeka S root, for example/var/www/omeka-s/backup. - Copy the ZIP into that directory, at its top level (not into a subfolder).
- Use binary transfer mode. Some FTP clients default to ASCII (text) mode or switch to it automatically, which corrupts ZIP files.
- Keep the
.zipextension. Any name works; it is kept as it is.
- Wait for the transfer to finish.
The web server must be able to read the file. If you copy it as a different user from the one PHP runs as, make it readable with chmod 644 <file>. The module also needs write access to the directory itself, as it does for its own backups, so it can delete the archive later.
Adding it to the list
- Go to Admin > Backup. Below the backup list, Archives in the backup directory lists every ZIP in the directory that is not in the list, newest first, with its size and modification time.
- Click Add to backups next to the archive.
The archive is opened and checked for metadata.json straight away, and appears in the list as in_progress. A background job then reads every file in the archive and compares it with the CRC-32 checksum stored in the ZIP, records the archive's SHA-256 checksum, and marks it complete. That takes about as long as unpacking the archive, so give a large archive a few minutes and refresh the page. The success message links to the job under Admin > Jobs.
Once the status is complete, click Restore. See Restoring Backups.
The archive stays where you put it: nothing is moved or renamed. Its record is credited to you and dated when you added it. The restore preview also shows when the archive itself was made.
When an archive cannot be added
| Message or status | What to do |
|---|---|
| Changed in the last two minutes under the modification time | The file may still be arriving. Wait until the transfer has finished before adding it. |
| The file is not a complete ZIP archive | The copy is unfinished, or it was transferred in ASCII mode. Copy it again in binary mode. |
| The archive does not appear to be an Omeka S backup (missing metadata.json) | The ZIP was not made by this module, or it was unzipped and re-zipped with an extra parent folder. See Backup Archive Format. |
| The web server cannot read this file (instead of the button) | Make the file readable by the web server user, for example chmod 644. |
| Status failed after adding | A file inside the archive did not match its checksum, so the copy is damaged. The job's log names the file. Delete the record, which also deletes the damaged copy, and transfer the archive again. |
From the command line
With shell access you can skip the web page and add the archive from the command line, which has no time limits:
# Add one archive from the backup directory
php modules/Backup/bin/backup.php import site-backup.zip
# Add every ZIP in the backup directory that is not in the list
php modules/Backup/bin/backup.php import
The command runs the same checks as the Backups page and prints the new record number, ready for restore. list also shows the archives that are not in the list yet. See CLI Commands.
Retention
Added archives count toward Retention: keep last N complete backups like any other complete backup, dated when they were added. See Configuration.