Contents
Preface
The idea came about because after changing the domain name of my image hosting service, I encountered a formatting issue when copying and pasting the SQL commands in the WordPress database. This caused the WordPress database in MariaDB to crash. Although I managed to restore it using a backup I had made beforehand through the "WPvivid backup plugin," the blog was down for about 30 minutes in the meantime. This was only because I was lucky enough to still be able to log into WordPress; if I hadn't, it would have taken even longer. I feel that regularly backing up the MariaDB database using mysqldump is necessary, so I'll put it on the agenda (because the source site is hosted on a Mac Mini, and I previously didn't want to run scripts on a Mac Mini).
After thinking about it for a while, I feel that the safest way is to set up a redundant WordPress site (which can be deployed in the same home data center, or on a cloud host, or in the home data center of other friends in the same city (or other place), and then use backup plug-ins (such as WPvivid backup plug-in) to regularly back up the WordPress and database data to the redundant site. When needed, the latest source site backup data can be immediately imported to provide services. Combined with the hot standby source site function of CDN, it can also achieve: disaster recovery in the same city (other place), and hybrid deployment of local and cloud disaster recovery functions.
Create and initialize the MariaDB database (optional)
WordPress requires a MariaDB database (MySQL is also an option, but MariaDB is always preferred when given a choice). Since I prefer deploying WordPress using `docker run` (deploying WordPress using `docker-compose` doesn't require creating a separate MariaDB database), I need to manually create and initialize the MariaDB database (if a pre-existing MariaDB database is available, you can initialize it directly). The recommended process for creating a new MariaDB database is as follows:
Create a new public-net bridge (optional)
docker network create public-net
Note:
This step is not required, but because the non-default bridge public-net needs to be referenced in both the mariadb container and the wordpress container so that wordpress can directly access mariadb using the container name, it needs to be created in advance (if there are other existing non-default bridges, you can also reuse them).
In fact, you can achieve the same purpose by using the –link parameter to directly link mariadb in WordPress. However, in order to facilitate management and operation and maintenance of more containers in the future (for example, creating different bridges to connect containers in different areas), try not to use the –link parameter. Because when there are more containers, linking everywhere may confuse yourself and make operation and maintenance inconvenient. Therefore, it is best to develop a good habit of using the –net parameter from the beginning.
Create a new mariadb database (optional)
If there is no mariadb database container in the environment or you do not want to reuse the existing one, you need to create a new one.
Create a directory on the host that needs to be mounted into the mariadb container
mkdir -p /docker/mariadb/db
Create mariadb container
The command to build the mariadb database in docker run format is as follows:
docker run --name=mariadb01 -d --restart=always --net=public-net \ -p 3306:3306 \ #Map the host's port 3306 to the container's port 3306 -v /docker/mariadb/db:/var/lib/mysql \ #Mount the previously created host directory to the specified directory inside the container -e MARIADB_ROOT_PASSWORD=123 \ #Specify the password corresponding to the database root user, which you can modify by yourself mariadb:10.11
Initialize the mariadb database
Please refer to my other article for details:Tips and tricks: Create a new empty database and grant permissions to corresponding usersIn the following text, it is assumed that the initialization database name, the corresponding username and password are all wordpress.
Deploy WordPress and initialize
Deploying WordPress using Docker Run
Create the directories on the host machine that need to be mounted into the WordPress container:
mkdir -p /docker/wordpress/html
The command to build wordpress in docker run format is as follows:
`docker run --name=wordpress -d --restart=always --net=public-net -p 8080:80 #` maps port 8080 on the host machine to port 80 in the container. Please choose the appropriate host port based on your environment. `-v /docker/wordpress/html:/var/www/html #` maps a directory created on the host machine to the specified path `wordpress` inside the container.
Note: Please delete the comment after #
Deploying WordPress using Docker Compose
For those who don't want to create and initialize a database separately, you can directly deploy WordPress using Docker Compose. Follow these steps:
Create the directories on the host machine that need to be mounted into the WordPress container:
mkdir -p /docker/wordpress
Create docker-compose.yml:
vim /docker/wordpress/docker-compose.yml
Then paste the following content into docker-compose.yml and save it:
version: '3.0' services: db: image: mariadb:10.11 restart: unless-stopped environment: MARIADB_ROOT_PASSWORD: 123 # Modify as needed MARIADB_DATABASE: wordpress MARIADB_USER: wordpress MARIADB_PASSWORD: wordpress # Modify as needed volumes: - './db:/var/lib/mysql' networks: - default app: image: wordpress:latest restart: unless-stopped ports: - 8080:80 # Modify as needed. Consistent with firewall open ports. environment: WORDPRESS_DB_HOST: db # If a named container is needed, use 'mariadb-wp' WORDPRESS_DB_NAME: wordpress WORDPRESS_DB_USER: wordpress WORDPRESS_DB_PASSWORD: wordpress # Modify volumes as needed: - './app:/var/www/html' depends_on: - db networks: - default redis: image: redis:alpine restart: unless-stopped volumes: - ./redis-data:/data networks: - default networks: default: name: public-net
Then activate the service:
cd /docker/wordpress docker-compose up -d
Initialize WordPress
usehttp://host IP:8080Log in, select Simplified Chinese as the language, and click Continue in the red box in the lower right corner:
Click "Start Now" in the red box in the image below to begin initialization:
Fill in the parameters as configured during database initialization, and finally click the "Submit" button to begin initializing the WordPress database.
If the previous configurations are like this, the following success interface appears:
Click "Run installer" in the red box in the lower right corner, and you will be prompted to fill in some key WordPress information, including site title, username, password, and administrator email. After filling in the information, click "Install" in the red box in the lower left corner.
At this point, the WordPress initialization is complete. Click "Login" in the red box in the lower left corner to enter WordPress and begin the actual configuration.
Note: If it is a completely new site, then you will enter the step of formally configuring WordPress. I will use an article to summarize some experience of getting started with WordPress, including plug-ins, theme configuration, etc. This article will not involve it. In fact, I am only half-baked in this area.
If you need to publish to the public Internet through a reverse proxy, you can refer to my other two articles:Docker series uses Docker to build its own reverse proxy based on NPMandLinux panel series configure reverse proxy and use non-443 port for publishing.
Install and enable the WPvivid backup plugin
As shown in the red box, click "Add New Plugin" in the red box in the "Plugins" interface:
Search in the search box on the upper right
WPvivid Backup PluginThen click "Install Now" in the red box:
Click "Enable" in the red box:
Enter the WPvivid configuration interface:
Finally, we get to the point. After that, you need to configure WPvivid on the source site and the main site respectively.
Install FTP server software on the target site (optional)
The main job of the WPvivid backup plugin on the source site is to back up the WordPress data and related library files in the database of the source site to local or remote storage. In this article, the best way is to back up directly to the directory of the WPvivid plugin on the target site via FTP, so that the target site can quickly import information directly. Of course, this is not necessary, and you can back up to any remote storage, such as:
Just using other remote storage requires two more steps: downloading the backup from the remote storage and uploading it to the WPvivid plug-in directory of the target site. These two steps don’t take much more time (just a little slow), so I said the content of this section is optional.
The way to install FTP software at the target site has a lot to do with the operating system environment of the target site. My target system is a Debian 12 virtual machine with the Baota Linux panel installed, so I will use my environment as an example to demonstrate the installation of FTP. For other environments, please study it by yourself. It's just about installing an FTP server.
Search for and install "Pure-Ftpd" in the "Software Store" of the BT Panel:
Then, in "FTP", click "Add FTP" to add the FTP user and home directory on the target site:
The key is that the root directory of the user in the red box points to:
The path is:
/docker/wordpress/html/wp-content
Why is the path above? In fact, you can see it in the configuration interface of WPvivid:
Because you can't directly use "/" to specify the root location when adding remote storage via FTP in WPvivid later, the root directory of the FTP user is pointed to /wp-content here, so that you can specify the root directory using /wpvividbackups when adding later.
After successfully adding the FTP user, please confirm whether the root path is correct:
To connect to the target site in FTP passive mode, the pure FTP configuration needs to be modified as follows:
PassivePortRange:
Define the port range that the source site ftp client can connect to when the ftp server is working in passive mode (please modify according to the actual situation), because it needs to be configured on the target site firewall (if enabled). What is more complicated here is that if the target site is set up on a cloud host, these ports need to be allowed in both the cloud host provider's security policy and the cloud host's own security policy. For example, if you are using a cloud host on Tencent Cloud, you first need to:
Then allow access to these ports through the ufw firewall on the cloud host Debian system itself.
ForcePassiveIP:
This is very important. If it is the same intranet environment, you need to specify the intranet IP address of the target site WordPress host; if it is a cloud host, you can directly use the public IP.
After configuration, you can use the FTP client in passive mode to access and confirm whether the FTP server on the target host can run normally.
Note:
The active and passive modes of ftp are actually quite interesting. Once you understand them, you can understand many network failures. I suggest you study them carefully if you are interested. Everyone's ftp environment may be different. If there is a problem, you may need to analyze the cause yourself. If it doesn't work, you can only use other methods.
In addition, if combined with the IP addresses provided by virtual LAN software such as TailScale, you can form a disaster recovery and hot standby solution with hosts in the same city, in different locations, or even anywhere in the world.
Source site WPvivid configuration
Adding Remote Storage
Fill in the information according to the target site FTP configuration information in the previous section:
The path is not the absolute path of the target site host, but the relative path to the root directory set by the ftp user. This is very important and it took me a long time to figure it out.
If the connection is successful, it will be displayed under the storage options below:
Schedule backup
Choose the backup frequency and backup content according to your actual needs in the plan tab, then select "Send files to remote storage", and then select "Save changes" in the red box in the lower left corner:
The default scheduled backup will upload the backup data of the source site to the target site and then delete the local backup. If you want to keep the backup generated by the scheduled task on the source site, you need to check the option in the red box under the Settings tab:
Note: This method has many limitations. Although it can be used, it is no longer recommended. The reasons and alternative methods are discussed in the last part.
If you want to configure it manually outside of the scheduled time, you can do so under the "Backup & Restore" tab:
You can back it up once here so that you can view it on the target site.
Target site WPvivid configuration
Actually, the target site doesn't need any configuration. Just click "Scan for uploaded backups or receive backups" (highlighted in red) under the Backup & Restore tab, and then select "Restore" from the backups that appear below. Since we backed up the source site once, clicking the "Scan for uploaded backups or receive backups" button (highlighted in red) should normally show the backup data from the source site.
Summarize
In fact, the key to this method is that the source site uploads the backup file directly to the backup directory of the target site's WPvivid plug-in through FTP. In this way, the target site only needs to scan to immediately see the configuration file of the source site and restore it immediately. Even if the wordpress of the source site cannot be opened at all, the access to wordpress can be restored in a very short time. However, even if it is not through FTP but other remote storage methods, there is only one more step of downloading and manually transferring to the target site. In fact, it does not take much longer, but the technical perception is not as good as this FTP method.
In addition, after the slave site is published through the reverse proxy, the hot backup source site can be pointed to this slave site on the CDN to achieve disaster recovery for the WordPress site. Of course, in this case, the slave site is best deployed on a cloud host or off-site. For example, I deploy it in my home data center, so that it will be over when there is a power outage.
After using it for a while, I have eliminated the use of FTP for remote backup. There are two reasons:
1. Only one remote node can be set
In addition to a hot backup WordPress site in the intranet, I now also have a mirror site on the Tencent Cloud server. There may be more in the future, and backing up one remote node is not enough.
2. Verification is required when restoring
When I use FTP to back up the configuration, I have to enter the FTP server information (IP, port number, username and password) when restoring it at the remote site, which is quite annoying.
So the idea is still the same, but I changed the implementation method. Instead of sending the regularly backed-up configuration directly to the remote slave site via FTP, I used Syncthing's multi-point folder synchronization method to implement it.
Change the settings for the main site WPvivid's regularly backed-up files from "Send files to remote storage" to "Save backups to local":
Then use syncthing to synchronize the regularly backed-up files in the WPvivid local directory directly to the same directory of the WPvivid plugin on other sites. This method is perfect. For detailed syncthing configuration methods, please refer to my other article:Docker series: A detailed tutorial on how to synchronize multiple folders using Docker based on syncthing.