Difference between revisions of "Backup and Restore"
Line 38: | Line 38: | ||
The process of restoring data after backing up can be found here: | The process of restoring data after backing up can be found here: | ||
==Restoring | ==Restoring Binary Files== | ||
The process of restoring images should refer to [[Restore.sh]]. | The process of restoring binary files, such as images, PDF, and other binary format data, should refer to [[Restore.sh]]. In PKC, we suggest that images or any other independent files to be stored in a separate file service. However, for MediaWiki related operations, the following instructions will work. | ||
For people who wants to do it manually, this is the command line information. It needs to be launched in the container that runs MediaWiki instance. | For people who wants to do it manually, this is the command line information. It needs to be launched in the container that runs MediaWiki instance. |
Revision as of 03:22, 23 June 2021
Introduction
To ensure this MediaWiki's content will not be lost, we created a set of script and put it in $wgResourceBase's extensions/BackupAndRestore directory.
The backup.sh script, convert all SQL database content into an XML file called: XLPLATEST.xml, and put all uploaded files into the images/UploadedFiles/ directory under the specified $wgResourceBase/ directory.
The restore.sh script, extract the content of XLPLATEST.xml, and reload all files of the images/UploadedFiles/ directory into the currently running MediaWiki.
Alternatively, the data set could be exported to a SQL file. Since that is running in a separate Docker service, the process will be discussed in a different page.
Importance
To enable proper data security, convenient backup and restore procedure would be the first layer.
This MediaWiki instance already stores all data under mountPoint/images and mountPoint/mariadb, these two directories store all the data relevant to MediaWiki, including its uploaded media files, and textual data stored in the MariaDB database.
Implementation
The default up.sh shell script is a way to allow users to kickoff the program. This process does the following tasks:
- Before shutting down existing instance of docker services, it first asks the existing instance to backup the data.
- Then, use docker-compose down --volumes to shut down all the docker services.
- If the mountPoint/ directory does not exist, yet, decompress InitialDataPackage.tar.gz to the mountPoint/ directory.
- When the mountPoint directory has the initial data content, start docker services, using docker-compose up -d
- The docker-compose program reads docker-compose.yml file to configure docker services.
- When the docker services start running, take the existing data in the directory, if images/UploadedFiles/ directory or XLPLATEST.xml are available, these data elements will be imported to the database.
Periodic Backup
It is necessary to regularly and automatically create backup data copies. The ideal way of doing such a task is to use cron job.
The following instructions are designed to configure the crontab for the Ubuntu container that runs MediaWiki.
A documented solution can be found here Backup_MW by Flominator.
Restore
The process of restoring data after backing up can be found here:
Restoring Binary Files
The process of restoring binary files, such as images, PDF, and other binary format data, should refer to Restore.sh. In PKC, we suggest that images or any other independent files to be stored in a separate file service. However, for MediaWiki related operations, the following instructions will work.
For people who wants to do it manually, this is the command line information. It needs to be launched in the container that runs MediaWiki instance.
# Load images from the UploadedFiles location. cd $ResourceBasePath php $ResourceBasePath/maintenance/importImages.php $ResourceBasePath/images/UploadedFiles/
Restoring SQL Data
The following instruction should be launched in the host (through docker exec or kubectl exec -it command) of the container that hosts the mariadb/mysql service.
mysql -u $DATABASE_USER -p $DATABASE_NAME < BACKUP_DATA.sql