Preface

I had this idea because I changed the domain name of my image storage last time. Later, when I was batch modifying the image storage addresses in the WordPress database, there was a format problem when copying and pasting the sql command, which caused the WordPress database in mariadb to crash. Although I later restored it by logging into WordPress and using the "WPvivid backup plug-in" to make a backup in advance, the blog was down for about 30 minutes in the middle... This was when I was lucky enough to log in to WordPress. If I was unlucky and couldn't log in to WordPress, it would take longer. I feel that it is necessary to use mysqldump to back up the mariadb database regularly, so I'll put it on the schedule (because the source site is set up on a macmini, and I didn't want to run scripts on a macmini before).

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

WordPress needs to use the mariadb database (mysql is also OK, but mariadb is always preferred when there is a choice). Because I use docker run to deploy, I need to manually create the mariadb database and initialize it (if there is an existing mariadb, just initialize it directly). The process of creating a new mariadb database is recommended 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

Create a directory on the host that needs to be mounted in the wordpress container

mkdir -p /docker/wordpress/html

Deploy WordPress

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 the host port 8080 to the container's port 80. Please select the host port according to the actual environment. -v /docker/wordpress/html:/var/www/html \ # maps the directory created on the host to the specified path wordpress in the container

Note: Please delete the comment after #

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 below to start initialization:

Fill in the parameters configured when initializing the database, and finally click the "Submit" button to start initializing the WordPress library:

If the previous configurations are like this, the following success interface appears:

Click "Run Installer" in the red box in the lower right corner to enter some key information of WordPress, including site title, username and password, and administrator email address. After filling in, click "Install" in the red box in the lower left corner:

At this point, the wordpress initialization work is finally completed. Click "Login" in the red box in the lower left corner to enter wordpress and start the formal 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 Plug-in" in the red box on the "Plug-in" interface:

Search in the search box on the upper rightWPvivid Backup Plugin, then 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 and install "Pure-Ftpd" in the "Software Store" of the Baota panel:

Then click "Add FTP" in "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 cannot directly use "/" to specify the root location when adding remote storage to WPvivid via FTP later, the root directory of the FTP user is pointed to /wp-content here, so that it is convenient to specify the root directory using /wpvividbackups when adding it 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

Select the backup frequency and backup content in the plan tab according to your actual needs, 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 manually configure 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

In fact, the target site does not need to do any configuration. You only need to click "Scan uploaded backups or receive backups" in the red box under the Backup & Restore tab, and then select and click Restore in the backup that appears below. Because we backed up once on the source site above, click the "Scan uploaded backups or receive backups" button in the red box below. Normally, you should be able to see the backup data of the source site above:

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 files that are regularly backed up by the main site WPvivid from "Send files to remote storage" to "Save backups locally":

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.