Data Backup
- Data Backup
This article details the procedures and configurations for data backup on our MediaWiki 1.40 server. Regular backups are crucial for disaster recovery, preventing data loss due to hardware failure, software bugs, or malicious attacks. This guide is intended for system administrators and those responsible for maintaining the integrity of the wiki.
Understanding Backup Requirements
Before diving into specific methods, it's important to understand *what* needs to be backed up. Our MediaWiki installation consists of several key components:
- Wiki Code: The core MediaWiki software files. Relatively static and updated infrequently.
- Wiki Data: This includes the wiki’s pages, revisions, user data, and configuration files stored in the `mw-config` directory. This is the most critical component.
- Uploaded Files: Images, documents, and other media files stored in the `images` directory.
- Database: The MySQL/MariaDB database containing all wiki content and metadata. This is the largest and most important part of the backup process.
Failing to back up any of these components can lead to significant data loss. We aim for a Recovery Point Objective (RPO) of 24 hours and a Recovery Time Objective (RTO) of 4 hours. This means we want to be able to recover data lost within the last 24 hours, and restore full functionality within 4 hours. See Disaster Recovery Plan for more details.
Backup Methods
We employ a multi-layered backup strategy to ensure data redundancy and reliability.
1. Full Backups: Complete copies of all data are created weekly. 2. Incremental Backups: Backups of only the changes made since the last full backup are performed daily. 3. Database Dumps: Regular database dumps are created for faster restoration of wiki content.
Database Backup Procedure
The database is the most crucial component and requires a dedicated backup process. We use `mysqldump` for this purpose.
Database Backup Script
The following script, located at `/opt/mediawiki/backup/db_backup.sh`, automates the database backup process:
```bash
- !/bin/bash
DATE=$(date +%Y-%m-%d_%H-%M-%S) DB_USER="wikiuser" DB_PASS="wikipassword" DB_NAME="wikidb" BACKUP_DIR="/opt/mediawiki/backup/db"
mysqldump -u $DB_USER -p$DB_PASS $DB_NAME > $BACKUP_DIR/wikidb_$DATE.sql gzip $BACKUP_DIR/wikidb_$DATE.sql ```
- Note:* Replace `"wikiuser"`, `"wikipassword"`, and `"wikidb"` with your actual database credentials. See Database Configuration for more information.
Database Backup Schedule
The script is executed daily at 02:00 using `cron`. The crontab entry is located at `/etc/crontab` or in the system user's crontab (using `crontab -e`).
File System Backup Procedure
We back up the wiki code, data, and uploaded files using `rsync`.
File System Backup Script
The following script, located at `/opt/mediawiki/backup/fs_backup.sh`, handles file system backups:
```bash
- !/bin/bash
DATE=$(date +%Y-%m-%d_%H-%M-%S) SOURCE_DIR="/var/www/mediawiki" BACKUP_DIR="/opt/mediawiki/backup/fs"
rsync -avz $SOURCE_DIR/ $BACKUP_DIR/mediawiki_$DATE/ ```
File System Backup Schedule
The script is executed weekly on Sunday at 03:00 using `cron`.
Backup Storage and Retention
Backups are stored on a dedicated network-attached storage (NAS) device with a total capacity of 4TB. The following retention policy is enforced:
| Backup Type | Retention Period |
|---|---|
| Full Backups | 4 Weeks |
| Incremental Backups | 1 Week |
| Database Dumps | 2 Weeks |
Old backups are automatically deleted using a separate script, `cleanup_backups.sh`, executed weekly. See Backup Cleanup Procedures for more details.
Restoration Procedure
Restoration involves restoring both the database and the file system.
Database Restoration
1. Stop the web server (e.g., Apache or Nginx) – see Web Server Configuration. 2. Restore the database from the latest dump: `mysql -u wikiuser -p wikidb < /opt/mediawiki/backup/db/wikidb_YYYY-MM-DD_HH-MM-SS.sql.gz` (unzip first if necessary). 3. Restart the web server.
File System Restoration
1. Stop the web server. 2. Restore the file system from the latest backup. Ensure proper permissions are set. 3. Restart the web server.
Testing Restorations
Restoration procedures are tested quarterly to ensure their effectiveness. Results are documented in Backup Test Results.
Technical Specifications
| Component | Specification |
|---|---|
| NAS Device | Synology DiskStation DS1821+ |
| NAS Capacity | 4TB (RAID 5) |
| Backup Software | rsync, mysqldump |
| Backup Server OS | Ubuntu Server 20.04 LTS |
| Script | Location | Purpose |
|---|---|---|
| db_backup.sh | /opt/mediawiki/backup/ | Daily Database Backup |
| fs_backup.sh | /opt/mediawiki/backup/ | Weekly File System Backup |
| cleanup_backups.sh | /opt/mediawiki/backup/ | Automated Backup Cleanup |
Security Considerations
Backups are encrypted both in transit and at rest. Access to the backup storage is restricted to authorized personnel only. Regular security audits are conducted to ensure the integrity of the backup system. See Security Policy for more information.
Related Pages
- Disaster Recovery Plan
- Database Configuration
- Web Server Configuration
- Backup Cleanup Procedures
- Backup Test Results
- Security Policy
- Cron Job Management
- MySQL/MariaDB Documentation
- Rsync Documentation
- NAS Device Configuration
- File Permissions
- Wiki Maintenance
- Troubleshooting Backups
- Database Optimization
- Server Monitoring
- MediaWiki Installation
Intel-Based Server Configurations
| Configuration | Specifications | Benchmark |
|---|---|---|
| Core i7-6700K/7700 Server | 64 GB DDR4, NVMe SSD 2 x 512 GB | CPU Benchmark: 8046 |
| Core i7-8700 Server | 64 GB DDR4, NVMe SSD 2x1 TB | CPU Benchmark: 13124 |
| Core i9-9900K Server | 128 GB DDR4, NVMe SSD 2 x 1 TB | CPU Benchmark: 49969 |
| Core i9-13900 Server (64GB) | 64 GB RAM, 2x2 TB NVMe SSD | |
| Core i9-13900 Server (128GB) | 128 GB RAM, 2x2 TB NVMe SSD | |
| Core i5-13500 Server (64GB) | 64 GB RAM, 2x500 GB NVMe SSD | |
| Core i5-13500 Server (128GB) | 128 GB RAM, 2x500 GB NVMe SSD | |
| Core i5-13500 Workstation | 64 GB DDR5 RAM, 2 NVMe SSD, NVIDIA RTX 4000 |
AMD-Based Server Configurations
| Configuration | Specifications | Benchmark |
|---|---|---|
| Ryzen 5 3600 Server | 64 GB RAM, 2x480 GB NVMe | CPU Benchmark: 17849 |
| Ryzen 7 7700 Server | 64 GB DDR5 RAM, 2x1 TB NVMe | CPU Benchmark: 35224 |
| Ryzen 9 5950X Server | 128 GB RAM, 2x4 TB NVMe | CPU Benchmark: 46045 |
| Ryzen 9 7950X Server | 128 GB DDR5 ECC, 2x2 TB NVMe | CPU Benchmark: 63561 |
| EPYC 7502P Server (128GB/1TB) | 128 GB RAM, 1 TB NVMe | CPU Benchmark: 48021 |
| EPYC 7502P Server (128GB/2TB) | 128 GB RAM, 2 TB NVMe | CPU Benchmark: 48021 |
| EPYC 7502P Server (128GB/4TB) | 128 GB RAM, 2x2 TB NVMe | CPU Benchmark: 48021 |
| EPYC 7502P Server (256GB/1TB) | 256 GB RAM, 1 TB NVMe | CPU Benchmark: 48021 |
| EPYC 7502P Server (256GB/4TB) | 256 GB RAM, 2x2 TB NVMe | CPU Benchmark: 48021 |
| EPYC 9454P Server | 256 GB RAM, 2x2 TB NVMe |
Order Your Dedicated Server
Configure and order your ideal server configuration
Need Assistance?
- Telegram: @powervps Servers at a discounted price
⚠️ *Note: All benchmark scores are approximate and may vary based on configuration. Server availability subject to stock.* ⚠️