2 Reliable Backup Strategies for Your WordPress Blog

WordPress logo drowning in water.WordPress is a prime target for hackers due to its popularity as a content management system, across the web. A robust backup strategy is a must for every professional web publisher using WordPress as the underlying platform. This helps you recover quickly from an unwanted incident that may cost you time and money. There are several ways to back up a WordPress blog that directly affects your restoration strategy. If you're relying on a single backup option, probably you're making a big mistake. There should be at least two backup options so that if one of the options fails in an emergency, you always have a replacement to get back your website, online, as soon as possible. The methodologies discussed below should be first tried in a test environment before you start applying them on a production website. Once you gain confidence in these techniques, no matter the size of the website, you'll be able to keep it backed up, quite easily. So, let's get going and learn these two reliable WordPress backup solutions.

WordPress logo drowning in water. Before we start, I must emphasize two important points. Firstly, you must have SSH access to your web server and you must be familiar with Linux command line environment. And secondly, you should never ever try it directly on your live website unless you've tested it thoroughly on a demo website.

Tree Replication on Your Web Server

This is the simplest and the fastest way to backup your WordPress blog. This methodology must be used in conjunction with other options. Relying only on this option is not a wise move as all of your data is saved on the same web server where your blog is running.

Folders and briefcase. To implement this technique, create a separate folder out of your WordPress installation directory tree that is not publicly accessible. Let's assume, we name this backup directory as securebackup created at the following the path /var/www/. First simple step is to take a database backup to save all the MySQL tables to this directory.

Throughout this tutorial, I'm assuming, you're logged in with root privileges via SSH login.

So, first of all, switch to the newly created backup directory using the following command.

mkdir /var/www/securebackup && cd /var/www/securebackup
Now, use the following command to backup the WordPress database in the current directory. Let's assume that our WordPress MySQL database name is wp_mysite. Here's a generic command for the database backup.

mysqldump -u [username] -p[password] -h [host] [databaseName] > [DBbackup-name].sql
For demo purposes, let's assume, your MySQL account with administrative privileges is having the username as root and the password as secretpass. Now, the generic command will change as follows.

mysqldump -u root -psecretpass -h localhost wp_mysite > mysitebackup.sql
Note that there is no space between password and the -p switch.

The next important step is to copy the entire WordPress installation directory tree to the backup folder. This strategy has the following advantages.

The restoration process is extremely fast and there's no complexity involved to save your backup. You must copy the installation tree recursively so that it can be restored in the same way, without any hassle. Here's the command to copy and save your installation tree, recursively.

cp -r /var/www/html /var/www/securebackup
Here, we're assuming that the installation tree path is /var/www/html. The copy command given above uses the -r switch and instructs to copy the installation tree, recursively, to the target backup directory.

This way you'll have both the database as well as entire WordPress directory tree backed up on your web server. In case your blog is affected by a malware and the infection is limited to the blog's installation directory tree, you can restore your blog very quickly.

Start by dropping (deleting) the entire WordPress MySQL database and then import it directly from the backup. Here's how to do it. Use the following command to delete the database.

mysqladmin -u root -p drop wp_mysite
After firing this command, you'll be prompted for the MySQL password. Just before deleting the target database, the command will ask for confirmation. Simply, press y key to complete the process.

Now delete the infected WordPress directory tree using the following commands. First, switch to the directory where WordPress is installed.

cd /var/www/html
And now, use the recursive deletion command as shown below.

rm -rf *
At this point, both the infected WordPress directory tree and the MySQL database has been deleted. Now is the time to reinstate both the directory tree as well as the database to their original locations from the saved copies residing within the backup directory.

To copy the saved directory tree back to its original location in a recursive manner, use the following command.

cp -r /var/www/securebackup /var/www/html
You can note that it's just the opposite of the first copy command fired earlier. The last step involves restoration of the database. Here's the command to be used for the same.

mysql -u root -psecretpass wp_mysite < mysitebackup.sql
And, that's it! This backup and restoration process is simple and easy-to-use. Usually, this method can help you recover your blog within minutes unless the archive is extremely huge.

Caution: Never ever overwrite the infected directory tree as it may leave some extra infected files intact even after copying the backup tree.

The correct method is to first completely delete the entire infected tree (recursively of course) and then copy the backup tree back to its original location. This technique only works when the infection is limited to the installation tree and the web server itself has—no problem. It will not work if the server itself is down or it is experiencing system-wide infection.

Cross-Server Replication

This is yet another interesting backup strategy that's fast and reliable. This methodology requires two parties who mutually agree to provide their server space to back up each other's data. Both parties sync the data stored on the partner's remote server within their local backup directory.

This way, if one of the web servers fails, the data can be easily restored from the partner's remote web server. The challenge to implement this solution is to find a trusting partner who is ready to be a part of this solution.

Because both the parties are beneficiaries, a mutual agreement may not be a big problem if both the blogging buddies are on good terms with each other.

Web servers. So, let's get started and see how to implement this powerful backup solution. First, let's assume that both the parties have a zipped backup file in a separate backup directory on their web servers. The goal is to simply sync this zipped backup across both the servers, periodically.

In simple words, party A syncs and keeps a backup of party B on his own server and party B syncs and keeps a backup of party A on his own server. It's a win-win situation for both the ends.

If you don't know how to create a zipped archive for the entire installation tree, here's a simple command to do that. Make sure you're in the backup directory created specifically for storing these compressed archives.

zip -r archive_`date '+%Y-%m-%d'`.zip /var/www/html/*
This command will recursively compress your WordPress installation directory tree and will pack it in a dated archive. Now, we move on to the most important step of remotely syncing the compressed archive.

Remember, if you're looking to sync your data to the remote server, it's not you who will use the relevant command. It will be fired by your partner from his end to pull and sync your zipped archive on his web server and vice versa.

This essentially means that both the parties have to exchange their server login credentials to connect and fetch the archived data. Use the following rsync command to connect and sync your friend's archived data on your own web server.

rsync -e ssh -a —delete root@friendssite.com:/friends_site/backup_directory /your_site/backup_directory
While using this command, you have to supply the login credentials to complete the syncing activity. If you want to automate this process, you can use this excellent tutorial to implement automated cross-server backup syncing.

Restoring a backup simply requires firing of rsync command from the original server where backup needs to be pulled. If you have a trusted blogging peer, I highly recommend using this methodology to keep a secure backup of your blog to a remote location.

The same syncing activity can be performed for zipped database archive too.