How to Set Up a Backup and Restore Strategy for MediaWiki Sites

Why a Backup Strategy Matters

MediaWiki stores its critical data in two places: the relational database (pages, revisions, users, logs, etc.) and the file system (configuration, extensions, skins, uploaded images). A single‑point failure – a corrupted database, a lost LocalSettings.php, or a missing images/ directory – can render a wiki unusable. Regular backups give you the ability to recover quickly and to test upgrades on a safe copy.

Core Components of a Complete Backup

• Database dump – a logical mysqldump (or pg_dump for PostgreSQL) that captures the schema and all rows. Use the --no-tablespaces and --single-transaction options to avoid lock‑related errors on newer MySQL versions.
• XML content dump – generated with maintenance/run.php dumpBackup. This produces an .xml file that contains every page revision and can be imported with importDump.php. It does not include user accounts or images but is an excellent secondary safeguard.
• File‑system archive – a tar/zip of the MediaWiki root (or at least the images/, extensions/, skins/ and LocalSettings.php directories). Permissions and ownership must be preserved for the web‑server user.

Preparing the Wiki for a Consistent Backup

Before dumping the database, put the wiki into read‑only mode to freeze writes:

$wgReadOnly = 'Backup in progress – please try again later';

Most backup scripts (e.g., Duesentrieb’s backup.sh) automate this step by inserting the line into LocalSettings.php, performing the dump, and then removing it.

Database Backup – Practical Example

# Adjust these variables for your installation
DBNAME="wikidb"
DBUSER="wikiuser"
DBPASS="secret"
DBHOST="localhost"
BACKUP_DIR="$HOME/wiki-backups"
DATE=$(date +%Y-%m-%d)

mysqldump --host=$DBHOST \
    --user=$DBUSER --password=$DBPASS \
    --single-transaction --no-tablespaces \
    $DBNAME | gzip -9 > $BACKUP_DIR/${DBNAME}_$DATE.sql.gz

The --single-transaction flag works only with InnoDB tables; it gives a point‑in‑time snapshot without locking tables for long periods.

XML Dump with dumpBackup.php

php maintenance/run.php dumpBackup --full \
    --output=gzip:$BACKUP_DIR/wiki_content_$DATE.xml.gz

The --full switch includes every revision. Adding --include-files --uploads will embed file metadata (but not the binary files themselves) in the XML stream.

File‑System Archive

Only the directories that change at runtime need to be archived. A minimal set is:

cd /var/www/mediawiki
tar --numeric-owner -czf $BACKUP_DIR/wiki_files_$DATE.tgz \
    LocalSettings.php images extensions skins

The --numeric-owner flag preserves UID/GID so that the restored files keep the correct ownership on the target host.

Automation – Cron vs. Systemd

On a typical Linux host you can schedule the three commands above with a single script and run it daily. Example cron entry (run at 2 am):

0 2 * * * /usr/local/bin/wiki-backup.sh >> /var/log/wiki-backup.log 2>&1

For systems using systemd, create wiki-backup.service (ExecStart points to the script) and a timer wiki-backup.timer with OnCalendar=*-*-* 02:00:00. Systemd gives better logging via journalctl and handles missed runs after reboots.

Restoring a Backup – Step‑by‑Step

1. Adjust LocalSettings.php
   • Update $wgDBname, $wgDBuser, $wgDBpassword if they changed.
   • Confirm $IP and $wgScriptPath match the new server layout.
2. Verify the restore
   • Log in as a sysop and check page view, edit, and image upload.
   • Run php maintenance/run.php rebuildrecentchanges if the recent‑changes table appears empty.

Run the update script

php maintenance/run.php update

This brings the schema up to the version of the MediaWiki code you have installed.

Restore the file archive

tar -xzf $BACKUP_DIR/wiki_files_2024-08-01.tgz -C /var/www/mediawiki

Import the SQL dump

gunzip -c $BACKUP_DIR/wikidb_2024-08-01.sql.gz | mysql -u wikiuser -p wikidb

Re‑create the database and user

CREATE DATABASE wikidb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wikiuser'@'localhost' IDENTIFIED BY 'newpass';
GRANT ALL PRIVILEGES ON wikidb.* TO 'wikiuser'@'localhost';
FLUSH PRIVILEGES;

Handling Character‑Set Pitfalls

Older wikis often used a latin1 database. When dumping with mysqldump, add --default-character-set=latin1 to avoid MySQL silently converting characters to UTF‑8 and corrupting the dump. After restoring, you can change the tables to utf8mb4 with:

ALTER TABLE <table> CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Running the MediaWiki update.php script after the conversion will adjust internal caches.

Optional: Full‑Site Backup Scripts

The community‑maintained Fullsitebackup script bundles the database dump and a tarball of the entire wiki directory in one step. It is useful for migrations between hosts but requires careful review of the hard‑coded paths.

Best‑Practice Checklist

• Schedule daily mysqldump + weekly full‑site tarball.
• Store backups off‑site (e.g., rsync to a remote server or an S3 bucket).
• Test restores quarterly on a staging server.
• Document database credentials, file locations, and any custom extensions.
• Keep LocalSettings.php version‑controlled so you can re‑apply customizations after a fresh install.

Conclusion

A robust MediaWiki backup strategy combines a reliable SQL dump, an optional XML content export, and a file‑system archive. Automating the process with cron or systemd, putting the wiki into read‑only mode during the dump, and verifying restores regularly will protect your knowledge base against hardware failures, accidental deletions, and security incidents.