What Is an Enterprise Wiki

A MediaWiki database holds everything that makes a wiki what it is: every page, every revision, every user account, every uploaded file reference, and every permission setting. Without a tested, working backup, any of this can be lost permanently following a server failure, an accidental deletion, a botched upgrade, or a security incident.

Database maintenance for MediaWiki covers three distinct areas: regular backups that allow recovery from any point in time, a restore procedure that has been tested and confirmed to work before it is ever needed in an emergency, and a set of maintenance scripts that keep the database consistent and accurate as the wiki grows and changes.

This guide covers all three areas with specific, verified commands drawn from MediaWiki's official documentation.

For context on the hosting environment these commands assume, see "How to Install MediaWiki on Ubuntu Server". For information about database performance tuning, see "MediaWiki Performance Optimisation".

What Needs to Be Backed Up

A complete MediaWiki backup consists of three separate components. All three are needed for a full recovery. Backing up only one or two is a partial backup.

MediaWiki Backup Components

Component	What It Contains	Method	Recovery Use
Database dump	All wiki content, revision history, user accounts, permissions, settings	mysqldump	Primary recovery method for most failure scenarios
XML content dump	Page content and revision history only - no user accounts, no images	dumpBackup maintenance script	Secondary safeguard; useful for migrating content to another wiki
File system backup	Uploaded files in images/, installed extensions, skins, and LocalSettings.php	tar archive	Required to restore uploaded media and site configuration

The database dump and file system backup together constitute a complete backup. The XML content dump is an additional safeguard that is particularly useful for content portability - it can be imported into a fresh MediaWiki installation without needing to match database credentials, table prefixes, or server configuration.

Understanding MediaWiki's Database Tables

Not all tables in the MediaWiki database are equally critical to back up. Understanding which tables hold irreplaceable data and which hold regenerable cache data helps when designing a backup strategy.

Key MediaWiki Database Table Categories

Table or Group	Contents	Backup Priority
page, revision, text / slots, content	Every page and every revision ever saved - the core of the wiki	Critical; must always be included
user, user_groups, user_properties	All registered user accounts, group memberships, and preferences	Critical; must always be included
logging, archive	Deletion and administrative logs; deleted page content	High priority
image, oldimage, filearchive	File metadata (not the files themselves - those are in images/ on disk)	High priority
pagelinks, categorylinks, imagelinks, templatelinks	Internal link tables, regenerable by running refreshLinks	Include by default; regenerating on large wikis can take hours or days
objectcache	Object cache fallback; regenerated automatically on next use	Safe to exclude from backups; confirmed regenerable by MediaWiki.org
l10n_cache	Interface localisation cache; regenerated automatically when needed	Safe to exclude from backups; confirmed regenerable by MediaWiki.org

The practical recommendation is to include all tables in the standard backup. Excluding cache tables reduces dump file size slightly, but requires extra steps during restore to regenerate them, and the size saving is rarely worth the added complexity. The option is documented here because it is frequently discussed in the MediaWiki community, not because it is recommended for routine use.

Step 1: Enable Read-Only Mode Before Backing Up

For a consistent backup that captures a clean point-in-time snapshot, the wiki should be placed into read-only mode before the database dump begins. This prevents new edits from being written to the database while the dump is running, which would otherwise produce an inconsistent backup.

Add the following line to LocalSettings.php:

$wgReadOnly = 'Maintenance in progress. The wiki will be available again shortly.';

Reload the wiki in a browser to confirm the read-only banner appears. Then proceed with the backup. Remove the line from LocalSettings.php when the backup is complete.

For automated backups via cron, this step can be scripted by adding and removing the line from LocalSettings.php around the backup command, though this adds complexity. For most small to medium wikis, scheduling automated backups during low-traffic hours without read-only mode is an acceptable trade-off, since the window of inconsistency during a fast dump is narrow.

Step 2: Database Backup Using mysqldump

mysqldump is the standard command-line tool for creating a complete SQL dump of a MariaDB or MySQL database. The resulting file contains SQL statements that fully recreate the database structure and all data.

Navigate to a suitable directory for the backup file:

cd /var/backups/mediawiki

Run the dump with the recommended options:

mysqldump --user=wikiuser --default-character-set=binary --single-transaction wikidb > wiki_backup_$(date +%Y%m%d).sql

You will be prompted for the database user password. Breaking down the key options:

• --default-character-set=binary - MediaWiki's official restore documentation specifically recommends this flag to prevent silent character encoding conversion during the dump, which can corrupt non-ASCII content.
• --single-transaction - Issues a single transaction around the dump, which allows InnoDB tables to be read consistently without locking them. This is important for wikis that remain writable during the backup.

To compress the backup file immediately to save disk space:

mysqldump --user=wikiuser --default-character-set=binary --single-transaction wikidb | gzip > wiki_backup_$(date +%Y%m%d).sql.gz

Verify the backup file was created and is not empty:

ls -lh /var/backups/mediawiki/

Step 3: File System Backup

The database backup alone is not sufficient for a complete recovery. Uploaded files (images, PDFs, and any other media) are stored on the file system in the images/ directory, not in the database. Extensions, custom skins, and LocalSettings.php also need to be backed up.

Create a compressed archive of the key directories:

tar -czf /var/backups/mediawiki/wiki_files_$(date +%Y%m%d).tar.gz -C /var/www/html/w images/ extensions/ skins/ LocalSettings.php

This archive includes:

• images/ - all uploaded files
• extensions/ - installed extensions
• skins/ - installed and custom skins
• LocalSettings.php - the wiki's configuration file, including database credentials

If disk space is a concern and extensions and skins are installed from official sources that can be re-downloaded, the archive can be narrowed to just the images/ directory and LocalSettings.php.

Step 4: XML Content Dump (Optional Secondary Backup)

MediaWiki includes a built-in maintenance script that exports all page content and revision history into a portable XML format. This is not a substitute for the database dump - it does not include user accounts, permissions, or file metadata - but it is a valuable secondary safeguard and the standard format for sharing or migrating wiki content.

Generate a full XML dump of all current page revisions:

php /var/www/html/w/maintenance/run.php dumpBackup --current > /var/backups/mediawiki/wiki_content_$(date +%Y%m%d).xml

To include all historical revisions rather than just the current version of each page:

php /var/www/html/w/maintenance/run.php dumpBackup --full > /var/backups/mediawiki/wiki_full_$(date +%Y%m%d).xml

The --current flag produces a smaller file suitable for content archiving and migration. The --full flag produces a complete revision history export, which is larger but preserves the complete edit history.

Note on script syntax. MediaWiki 1.40 and later use php maintenance/run.php scriptName. MediaWiki 1.39 and earlier use php maintenance/scriptName.php. All examples in this guide use the current syntax for 1.40+.

Step 5: Automate Backups via Cron

A backup that must be run manually will be skipped. Automating the process via cron ensures backups happen reliably regardless of other priorities.

Open the crontab for the web server user:

sudo crontab -e -u www-data

Add a daily database backup at 02:00:

0 2 * * * mysqldump --user=wikiuser --default-character-set=binary --single-transaction wikidb | gzip > /var/backups/mediawiki/wiki_db_$(date +\%Y\%m\%d).sql.gz

Add a weekly file system backup at 03:00 on Sundays:

0 3 * * 0 tar -czf /var/backups/mediawiki/wiki_files_$(date +\%Y\%m\%d).tar.gz -C /var/www/html/w images/ extensions/ skins/ LocalSettings.php

Backup retention. Without a retention policy, backup files accumulate until they fill the disk. Add a daily cleanup that removes database backups older than 30 days:

30 2 * * * find /var/backups/mediawiki -name "wiki_db_*.sql.gz" -mtime +30 -delete

Off-site storage. Backups stored on the same server as the wiki are lost if the server fails. Transfer completed backups to a separate location - an object storage service, an off-site server, or a remote backup service - as the final step in the backup process.

Restoring the Database

The restore procedure should be tested before it is needed. A backup that has never been tested is a backup of unknown reliability.

Step 1: Create a fresh database if restoring to a new server, or confirm the existing database is empty. Log into MariaDB:

sudo mysql -u root -p

Create the target database:

CREATE DATABASE wikidb CHARACTER SET utf8mb4;

Exit the MariaDB shell:

EXIT;

Step 2: Import the database dump.

For an uncompressed dump:

mysql --user=wikiuser -p wikidb < /var/backups/mediawiki/wiki_backup_20250101.sql

For a gzip-compressed dump:

gunzip < /var/backups/mediawiki/wiki_backup_20250101.sql.gz | mysql --user=wikiuser -p wikidb

Step 3: Restore the file system. Extract the file archive to the MediaWiki root:

tar -xzf /var/backups/mediawiki/wiki_files_20250101.tar.gz -C /var/www/html/w

Confirm ownership is correct after extraction:

sudo chown -R www-data:www-data /var/www/html/w/images

Step 4: Run the database update script to confirm the schema matches the installed MediaWiki version:

php /var/www/html/w/maintenance/run.php update

Step 5: Rebuild the recent changes table after a restore, since the recentchanges table is time-bounded and may appear empty:

php /var/www/html/w/maintenance/run.php rebuildrecentchanges

Verify the wiki loads correctly, confirm a content page renders, and check Special:RecentChanges before removing the read-only setting if it was left in place during the restore.

Key Maintenance Scripts

MediaWiki ships with approximately 200 maintenance scripts covering database health, content integrity, search indexes, and administrative tasks. The following are the most relevant for routine database maintenance.

Essential MediaWiki Maintenance Scripts

Script	Purpose	When to Run
update	Applies database schema changes after a MediaWiki core upgrade. Must be run after every upgrade before the wiki is used.	After every MediaWiki version upgrade
refreshLinks	Rebuilds the internal link tables: pagelinks, categorylinks, imagelinks, and templatelinks. Run when categories appear empty, "What links here?" is inaccurate, or after a database restore.	After restoring from backup; when link tables appear inconsistent
rebuildrecentchanges	Rebuilds the recent changes table from the revision and logging tables. Run when Special:RecentChanges appears empty or inaccurate.	After restoring from backup; after importing an XML dump
rebuildall	Equivalent to running rebuildtextindex, rebuildrecentchanges, and refreshLinks in sequence. Marks all previously patrolled edits as unpatrolled.	Full rebuild after a major restoration or migration
dumpBackup	Exports page content and revision history as a portable XML file.	As part of the backup routine; before major migrations
importDump	Imports an XML content dump into the wiki.	When migrating content from another wiki or restoring from an XML backup
runJobs	Manually processes the background job queue.	When the queue is backlogged; as part of cron scheduling
showJobs	Displays the number of jobs currently in the queue.	During troubleshooting; after template edits affecting many pages

Running the refreshLinks script on a large wiki can take several hours. On very large wikis - hundreds of thousands of pages - it may take days. The official documentation recommends running it in chunks using the --e (end ID) parameter to avoid memory exhaustion on long runs. Run the script first to check it completes without error on a small page range before committing to a full run.

Running Maintenance Scripts

All maintenance scripts on MediaWiki 1.40 and later are invoked through the unified run.php runner. The scripts should be run as the web server user (www-data on Ubuntu/Debian) to ensure correct file system permissions, particularly for scripts that touch uploaded files.

Run the link refresh script:

sudo -u www-data php /var/www/html/w/maintenance/run.php refreshLinks

Run the recent changes rebuild:

sudo -u www-data php /var/www/html/w/maintenance/run.php rebuildrecentchanges

Check the job queue:

sudo -u www-data php /var/www/html/w/maintenance/run.php showJobs

Run the database schema update:

sudo -u www-data php /var/www/html/w/maintenance/run.php update

Recommended Maintenance Schedule

Suggested Database Maintenance Schedule

Frequency	Task
Daily	Database dump via mysqldump; transfer completed backup off-site
Weekly	File system backup of images/, extensions/, skins/, and LocalSettings.php
Monthly	Test restore from backup to a staging environment to confirm recoverability
Monthly	Review job queue via showJobs; process any significant backlog
Per upgrade	Run update script after every MediaWiki core version upgrade
As needed	Run refreshLinks when category pages or link tables appear inconsistent
As needed	Run rebuildrecentchanges when Special:RecentChanges appears empty or inaccurate

Best Practices

Always use --default-character-set=binary with mysqldump. This is specifically recommended in MediaWiki's own restore documentation to prevent silent character encoding conversion that can corrupt non-ASCII page content during the dump and import cycle. Never rely solely on an XML content dump as the primary backup - it does not contain user accounts, file metadata, or permission settings, and restoring a wiki from an XML dump alone is significantly more complex than restoring from a full database dump. Test the restore procedure before it is needed: a backup whose restore procedure has never been verified is a backup of unknown reliability. Store backups off-site - backups that live only on the same server as the wiki provide no protection against server failure or data centre incidents. Run the update script every time MediaWiki core is upgraded, without exception - skipping it leaves the database schema out of sync with the code, which causes errors that are avoidable.

Common Mistakes

The single most common database maintenance mistake is having no automated backup at all - most wiki administrators intend to set one up but defer it until after a data loss event has already occurred. The second is backing up the database but not the images/ directory, then discovering during a restore that uploaded files are unrecoverable even though the page content survived. Using mysqldump without --default-character-set=binary on a wiki with non-Latin content is a well-documented source of character corruption that only becomes apparent after a restore, not during the backup itself. Skipping the update maintenance script after a MediaWiki upgrade silently leaves the database schema inconsistent with the codebase, producing errors that are often misdiagnosed as extension conflicts or server problems. And running rebuildall on a wiki with a large volume of previously patrolled edits without noting that it marks all patrolled edits as unpatrolled - a documented side effect of the script - can create significant re-review work for wikis where patrolling is actively used.

Frequently Asked Questions

How often should I back up a MediaWiki database?

The appropriate frequency depends on how often the wiki is edited. For an actively edited wiki, daily automated backups via cron are appropriate. For a largely static reference wiki that sees few edits per week, weekly backups may be sufficient. The key question is: how much content are you willing to lose if the server fails right before the next scheduled backup?

Can I use phpMyAdmin for backups instead of mysqldump?

phpMyAdmin's export function produces the same type of SQL dump as mysqldump and is a valid option for occasional backups. For automated, scheduled backups it is not appropriate, since it requires a browser session and has PHP execution time limits that may cause it to time out on large databases.

Is an XML content dump a complete backup?

No. An XML content dump produced by dumpBackup contains page content and revision history but does not include user accounts, file metadata, namespace configuration, or permission settings. It is a valuable secondary safeguard and the standard format for content migration, but it is not a substitute for a full database dump.

How do I confirm a backup is valid before I need it in an emergency?

Restore the backup to a separate test environment - a staging server, a local virtual machine, or a temporary cloud instance - and confirm the wiki loads correctly, pages render, and user accounts are present. This is the only reliable way to verify that a backup is recoverable.

How do I restore a single deleted page rather than the whole database?

MediaWiki keeps deleted pages in the archive table rather than permanently removing them. A sysop can restore a deleted page via Special:Undelete without touching the database directly. The database restore procedure described in this guide is for recovering from a server-level failure, not for undoing individual page deletions.

The refreshLinks script ran out of memory on a large wiki. How do I handle this?

The official documentation recommends running refreshLinks in chunks using the --e (end page ID) and start ID parameters, processing a few thousand pages at a time rather than the entire wiki in a single run. Start with a small range to confirm the script runs successfully, then increase the range or script the full run in batches.

Conclusion

MediaWiki database maintenance comes down to three disciplines executed consistently: automated backups that cover both the database and the file system, a restore procedure that has been tested and confirmed to work, and a small set of maintenance scripts run at the right moments - after upgrades, after restores, and when specific tables show signs of inconsistency.

None of the individual steps are technically complex. The risk comes from deferring them, from backing up only part of what a recovery requires, and from assuming a backup is valid without ever testing the restore process. A wiki that holds institutional knowledge, company documentation, or years of collaborative content is worth the hour it takes to set up automated backups and verify they work.

For help setting up a backup and maintenance routine for an existing wiki, or as part of a new deployment, see SolidWiki's MediaWiki Development Services page.

See Also

• How to Install MediaWiki on Ubuntu Server
• MediaWiki Security Hardening Guide
• MediaWiki Performance Optimisation
• MediaWiki Hosting Guide: Choosing the Right Server for Your Wiki
• MediaWiki Namespaces Explained

External Links

• MediaWiki Manual: Backing Up a Wiki
• MediaWiki Manual: Restoring a Wiki from Backup
• MediaWiki Manual: Maintenance Scripts
• MediaWiki Manual: dumpBackup.php
• MediaWiki Manual: refreshLinks.php