To back up an Omeka site you need three things together: the database, the entire files/ directory, and your configuration (including modules and theme). To migrate, you dump the database with mysqldump, rsync the whole Omeka directory, import on the new host, update config/database.ini, and fix permissions before switching DNS. The mistake that ruins most restores is backing up the database alone — the media lives on disk in files/, and without it you restore records pointing at nothing.

What exactly do I need to back up?

Three components, and all three are mandatory:

Component	Where it lives	What it holds
Database	MySQL/MariaDB	All metadata, items, sites, users
Media	files/ directory	Originals + derivatives (thumbnails, medium, large)
Config & code	config/, modules/, themes/	DB credentials, installed modules, your theme

A database-only backup is the classic trap: it restores cleanly and then every image is a broken thumbnail because the bytes were never copied.

How do I make a reliable backup?

Dump the database and archive the directory in one routine. A reusable script:

#!/usr/bin/env bash
set -euo pipefail
DATE=$(date +%F)
OMEKA_DIR=/var/www/omeka-s
DEST=/backups/omeka

# 1. database
mysqldump --single-transaction --routines omeka_db \
  | gzip > "$DEST/db-$DATE.sql.gz"

# 2. files, modules, themes, config
tar czf "$DEST/site-$DATE.tar.gz" \
  -C "$OMEKA_DIR" files modules themes config

echo "backup complete: $DATE"

--single-transaction gives a consistent dump without locking the whole database, so the public site keeps serving while the backup runs.

How do I migrate to a new server, step by step?

The order matters — copy data before you touch config:

1. Dump the database on the old host (mysqldump as above).
2. Sync the directory, media included:

   rsync -avz /var/www/omeka-s/ newhost:/var/www/omeka-s/

3. Create the database on the new host and import the dump:

   gunzip < db-2026-02-11.sql.gz | mysql omeka_db

4. Update config/database.ini with the new host's credentials.
5. Fix ownership so the web server can read media:

   chown -R www-data:www-data /var/www/omeka-s/files

6. Test on a temporary URL or hosts entry before changing DNS.

Only flip DNS once the new site renders items, thumbnails and admin login correctly.

What about derivative images?

Derivatives (the square, medium and large versions Omeka generates) live inside files/. If you copy the whole files/ directory they migrate intact. If you only brought the originals, regenerate them on the new host — the Easy Admin module has a "create derivatives" task that rebuilds thumbnails and medium sizes from the originals. Until you do, browse pages show broken images even though the data is fine.

How often should I back up?

Apply the 3-2-1 rule used across digital preservation: at least 3 copies, on 2 different media types, with 1 off-site. For an actively edited collection that means automated daily database dumps plus regular full archives, one copy pushed to off-site or cloud storage. Schedule the script with cron:

# /etc/cron.d/omeka-backup — daily at 02:30
30 2 * * * root /usr/local/bin/omeka-backup.sh

And the part everyone skips: test a restore quarterly. An untested backup is a hope. Spin up a throwaway instance, restore into it, and confirm items and media appear.

What breaks most often after a migration?

Two culprits dominate. First, file permissions — the new web server user can't read files/, so media 403s; fix with chown. Second, base URL and trusted-host settings still referencing the old domain, producing mixed links or rejected requests. Check your server URL configuration and the trusted/cookie settings, then click through admin and public pages before announcing the move.

Key Takeaways

• Back up three things together: database, files/ directory, and config/modules/theme.
• A database-only backup restores broken images — the media lives on disk.
• Use mysqldump --single-transaction for a consistent, non-blocking dump.
• Migrate by copying data first, then updating database.ini and fixing permissions.
• Derivatives travel inside files/; regenerate with Easy Admin if you only moved originals.
• Follow 3-2-1 and automate with cron; test a real restore quarterly.
• Post-migration, the usual breakages are file permissions and a stale base URL.

Frequently Asked Questions

What are the three things I must back up?

The MySQL/MariaDB database, the files/ directory (uploaded media and derivatives), and your config — config/database.ini plus any modules and your theme. Miss any one and the restore is incomplete.

Can I just copy the database without the files directory?

No. The database stores metadata and references, but the actual images and documents live in files/. A database-only backup restores records that point at missing media — broken thumbnails everywhere.

How do I move Omeka S to a new server?

Dump the database with mysqldump, rsync the whole Omeka directory including files/ and modules/, import the dump on the new host, update config/database.ini, and fix file ownership/permissions. Then test before switching DNS.

Do derivative images move with a migration?

Yes, if you copy the entire files/ directory they come along. If you only copy originals, regenerate derivatives on the new server using the Easy Admin module so thumbnails and medium sizes exist again.

How often should I back up, and where?

Follow 3-2-1: at least daily automated dumps for an active site, two media types, one off-site copy. Test a restore quarterly — an untested backup is a hope, not a backup.

What breaks most often after a migration?

File permissions and the base URL. Web server can't read files/, or absolute URLs still point at the old domain. Fix ownership on files/ and check ServerUrl/trusted settings before announcing the move.

Related reading

• Getting started with Omeka S
• Improve Omeka S performance
• The 3-2-1 backup rule for archives
• Fixity and checksums
• Choosing a data repository