MediaWiki Backup & Restore — XML Dumps, Database Backups, and File Backups

In this tutorial, you will learn about MediaWiki Backup & Restore. We cover key concepts, practical examples, and best practices to help you master this topic.

Backup and restore in MediaWiki requires protecting three components — the database (content and settings), the files (images and uploads), and the code (MediaWiki core and extensions) — using XML dumps, SQL dumps, and file archives, the same strategy Wikipedia uses for data preservation.

What You'll Learn

• Backing up the MediaWiki database
• Creating XML dumps of page content
• Backing up file uploads and images
• Creating automated backup scripts
• Restoring from backups
• Testing backup integrity

Why It Matters

Data loss is not a matter of if but when. A server crash, a corrupted database, a malicious attack, or a human error can wipe out months of work. Backups are your safety net. A proper backup strategy ensures that no matter what happens, you can restore your wiki to a working state. Without backups, you are one hardware failure away from losing everything.

Real-World Use

A DodaTech wiki server suffers a hard drive failure. The last backup was 6 hours ago. The administrator installs a new server, restores the database from the SQL dump, copies the image files from the file backup, and the wiki is fully operational within 2 hours. Only 6 hours of edits are lost — saved by the automated nightly backup.

Learning Path

flowchart LR
  A["35: Database Maintenance"] --> B["36: Logging & Monitoring"]
  B --> C["37: Backup & Restore"]
  C:::current
  D["38: Performance Tuning"]
  E["39: Upgrading MediaWiki"]
  F["40: Security"]

  C --> D --> E --> F

  classDef current fill#38bdf8,color#0f172a,stroke-width:2px

What to Back Up

A complete MediaWiki backup consists of three parts:

1. Database: Page content, user accounts, settings, logs
2. Files: Uploaded images, logos, configuration files
3. Code: MediaWiki core, extensions, skins, LocalSettings.php

Method 1: XML Dump

XML dumps export page content and revision history in a portable format. They can be imported into any MediaWiki installation.

Creating an XML Dump

cd /opt/lampp/htdocs/mediawiki

# Full dump (all pages, all revisions)
php maintenance/dumpBackup.php --full > backup/wiki-$(date +%Y%m%d)-full.xml

# Current revisions only (smaller)
php maintenance/dumpBackup.php --current > backup/wiki-$(date +%Y%m%d)-current.xml

# Specific namespace
php maintenance/dumpBackup.php --namespace=0 > backup/wiki-$(date +%Y%m%d)-main.xml

Advantages of XML Dumps

• Portable: Can be imported into any MediaWiki instance
• Selective: Can back up specific pages or namespaces
• Human-readable: XML format is inspectable with a text editor
• Version-independent: Works across MediaWiki versions

Limitations

• Does not include images or uploaded files
• Does not include user passwords
• Does not include wiki configuration
• Large dumps can take significant processing time

Method 2: Database (SQL) Dump

The SQL dump backs up the entire database including all tables.

Using mysqldump

# Full database backup
mysqldump --user=wiki_user --password=secure_password \
    --add-drop-database \
    --databases dodatech_wiki \
    > backup/wiki-$(date +%Y%m%d).sql

# Compress to save space
gzip backup/wiki-$(date +%Y%m%d).sql

Selective Table Backup

# Exclude large, less-critical tables
mysqldump --user=wiki_user --password=secure_password \
    --ignore-table=dodatech_wiki.logging \
    --ignore-table=dodatech_wiki.archive \
    dodatech_wiki \
    > backup/wiki-$(date +%Y%m%d)-core.sql

Backup Options

# Compression on the fly
mysqldump --user=wiki_user --password=secure_password \
    dodatech_wiki | gzip > backup/wiki-$(date +%Y%m%d).sql.gz

# Include stored procedures and events
mysqldump --routines --events --triggers \
    dodatech_wiki > backup/wiki-$(date +%Y%m%d)-full.sql

Advantages of SQL Dumps

• Complete: Includes ALL data, not just page content
• Fast: Single command backs up everything
• Restorable: Can restore with a single command
• Consistent: Uses database Transaction for snapshot consistency

Method 3: File Backup

Back up the images/ directory and configuration files.

Backing Up Images

# Full image backup
tar -czf backup/images-$(date +%Y%m%d).tar.gz \
    /opt/lampp/htdocs/mediawiki/images/

# Exclude thumbnails (can be regenerated)
tar -czf backup/images-$(date +%Y%m%d).tar.gz \
    --exclude='images/thumb' \
    /opt/lampp/htdocs/mediawiki/images/

Backing Up Configuration

# Back up LocalSettings.php and other config files
tar -czf backup/config-$(date +%Y%m%d).tar.gz \
    /opt/lampp/htdocs/mediawiki/LocalSettings.php \
    /opt/lampp/htdocs/mediawiki/config/

Automated Backup Script

Create a comprehensive backup script:

#!/bin/bash
# /usr/local/bin/backup-wiki.sh

BACKUP_DIR="/backup/wiki"
MW_DIR="/opt/lampp/htdocs/mediawiki"
DB_NAME="dodatech_wiki"
DB_USER="wiki_user"
DB_PASS="secure_password"
DATE=$(date +%Y%m%d_%H%M%S)

# Create backup directory
mkdir -p $BACKUP_DIR

echo "=== Wiki Backup: $DATE ==="

# 1. Database backup
echo "Backing up database..."
mysqldump --user=$DB_USER --password=$DB_PASS \
    --databases $DB_NAME \
    | gzip > $BACKUP_DIR/database_$DATE.sql.gz

# 2. Image backup
echo "Backing up images..."
tar -czf $BACKUP_DIR/images_$DATE.tar.gz \
    $MW_DIR/images/

# 3. XML dump (portable format)
echo "Creating XML dump..."
cd $MW_DIR
php maintenance/dumpBackup.php --full \
    | gzip > $BACKUP_DIR/pages_$DATE.xml.gz

# 4. Configuration backup
echo "Backing up configuration..."
tar -czf $BACKUP_DIR/config_$DATE.tar.gz \
    $MW_DIR/LocalSettings.php \
    $MW_DIR/composer.json

# 5. Clean up old backups (keep 30 days)
echo "Cleaning old backups..."
find $BACKUP_DIR -name "*.gz" -mtime +30 -delete

echo "=== Backup Complete ==="
echo "Backup size: $(du -sh $BACKUP_DIR | cut -f1)"

Schedule the Backup

# Nightly at 2 AM
0 2 * * * /usr/local/bin/backup-wiki.sh

# Weekly full backup on Sunday at 3 AM
0 3 * * 0 /usr/local/bin/backup-wiki.sh --full

Restoring from Backup

Restoring the Database

# Restore SQL dump
mysql --user=wiki_user --password=secure_password \
    dodatech_wiki < backup/wiki-20260601.sql

# Restore compressed dump
gunzip -c backup/wiki-20260601.sql.gz \
    | mysql --user=wiki_user --password=secure_password \
    dodatech_wiki

Restoring from XML Dump

cd /opt/lampp/htdocs/mediawiki
php maintenance/importDump.php < backup/wiki-20260601.xml

Restoring Images

tar -xzf backup/images-20260601.tar.gz -C /

Full Restore Procedure

#!/bin/bash
# Full restore script (run on a fresh MediaWiki installation)

# 1. Import database
gunzip -c database_20260601.sql.gz \
    | mysql --user=wiki_user --password=secure_password dodatech_wiki

# 2. Restore images
tar -xzf images_20260601.tar.gz -C /

# 3. Import XML dump (additional pages, if needed)
cd /opt/lampp/htdocs/mediawiki
php maintenance/importDump.php < pages_20260601.xml.gz

# 4. Run update.php
php maintenance/update.php

# 5. Rebuild caches
php maintenance/rebuildall.php

echo "Restore complete!"

Backup Strategies

The 3-2-1 Rule

• 3 copies of your data
• 2 different storage media
• 1 copy offsite

Retention Policy

Daily backups: Keep 7 days
Weekly backups: Keep 4 weeks
Monthly backups: Keep 12 months
Yearly backups: Keep permanently

Testing Backups

A backup that cannot be restored is worthless. Test regularly:

1. Restore the backup to a test environment
2. Verify page count matches
3. Check a sample of pages for correct content
4. Verify images display
5. Test user login

What You Learned

• Three types of backup: XML dump, SQL dump, file backup
• XML dumps are portable but exclude images and configuration
• SQL dumps are complete with all data
• File backups protect images, config, and code
• Automated scripts ensure regular backups
• The 3-2-1 rule: 3 copies, 2 media, 1 offsite
• Regular testing is essential for backup reliability

In the next lesson, you'll learn about performance tuning.

Common Mistakes

Practice Questions

1. What three components make up a complete MediaWiki backup?
2. What is the difference between an XML dump and a SQL dump?
3. How does the 3-2-1 backup rule apply to wiki backups?
4. Challenge: Build a complete backup and recovery system. Create a backup script that backs up the database, images, XML content, and configuration. Test each backup type individually. Restore the database backup to a test database and verify the page count. Create a restore procedure document with step-by-step instructions. Set up a cron job for nightly automated backups. Implement a 30-day retention policy. Test a full restore in a test environment (separate server or directory). Document what was restored and verify sample pages.

FAQ

Mini Project

Goal: Implement a complete backup and disaster recovery plan.

1. Create a backup directory structure with dated subdirectories
2. Run each backup method individually:
   • SQL dump with compression
   • XML dump (full and current)
   • Image archive
   • Configuration archive
3. Verify each backup file (check size, gzip integrity)
4. Create an automated backup script with all four backup types
5. Add a retention policy (keep 7 daily, 4 weekly, 3 monthly)
6. Schedule the backup script as a nightly cron job
7. Create a restore procedure with step-by-step instructions
8. Test a full restore in a test environment
9. Document the backup strategy in a "Backup Policy" wiki page

What's Next

Backups protect your data. Now let's optimize your wiki for speed and responsiveness.

Continue to Lesson 38: Performance Tuning — learn about Caching (FileCache, Redis), JobQueue, and profiling.