WordPress sites have been hacked and hijacked. Having the ability to recover from such an event can be critical. The recreation of content by other means may not be possible. This is why establishing a disaster recovery policy is important. More importantly, the policy must be put into practice.
In this document, I’ll cover the creation of a disaster recover policy and the steps involved in following through with the policy.
Creating a backup
This should be done as soon as possible. We’ll use this backup to restore to a sandbox system to validate that our policy is sound.
First is to make a backup of the file/folder structure. I copied mine with FTP. This file/folder data will be overwritten onto a sandbox instance of WordPress. Only one of the files in this backup will need to be modified in order for it to work in on our sandbox environment. That file is “wp-config.php” which contains pointers to the WordPress database. These are the specific lines in that file that must match the sandbox environment.
Next, make a backup of the database. I used an integrated backup utility my provider makes available through its control panel. The database is then ready to download with FTP. Once copied, delete it from the host.
Now that the database is copied locally, make another copy for modifications. These changes should not be made directly to the newly created backup database. Rather, you should create a copy of the database file for manipulation. This allows for additional recovery, in the event those changes cause the database to become corrupt.
Setup the Sandbox
Testing the process of recovery should never be done on a live system. For this purpose, a sandbox environment is used to validate the steps of data restoration.
I’m going with a VM that has the standard LAMP (Linux, Apache, MySQL, and PHP) setup. I won’t go through how to create VMs or install LAMP. That is beyond the scope of this paper. There is plenty of documentation and demonstrations on how to do that online.
Once the system is up and running, I’ll install MyPHPAdmin. I’ve found that this tool is much easier to use than fumbling through command line entry. Again, install steps are not covered here. Once it is up and running, you’ll need to create a database and the user / password that WordPress will use.
Login on the phpMyAdmin portal and click the “Databases” link in the ribbon above the main page. Type in the name of the database we’ll use for WordPress, in this example it will be “wordpress”, then click Create. You should see it listed in the left and below now.
Now we’ll create the user account that WordPress will use to connect with the database. Click the “Users” link in the ribbon above. Midway down the page you should see a link named “Add user”, click it. The Add user page should load. Fill in the fields for these items and set these options as follows:
User name: dbtest
Host: Local (localhost)
Password: dbpass (use something stronger if online, but this is a sandbox)
Database for user
Grant all priviledges on wildcard name – Check this box
Global priviledges – Check all
Resource limits – leave default
Now the user account and database are ready for WordPress to utilize. We are ready to start the WordPress install and configure it on our sandbox. The steps to install will not be covered. I’ll only cover the steps once it is installed.
Now that WordPress is installed, you’ll be prompted with a language preference when you first load the site. Choose your language and click Continue. Here you will see a notice about WordPress needing to connect to a database. This will be the database we create just a bit ago. Let’s go!
Enter in the information to connect to our WordPress database and click Submit. Then Run the install.
Since this site will be overwritten later on, it isn’t all that important what is entered in the Welcome page. Do make a note of it anyway, you may need it later. Use better login info if your sandbox is online, which is something highly discouraged.
Now our sandbox WordPress site should be ready to use.
One thing to look at before we move on is the “wp-config.php” file in the root of the WordPress site. Go ahead and open it up in a text editor. You should see these entries:
This is the config page we’ll edit next when we restore our live database and file structure onto our sandbox system.
Modifying and Restoring the live WordPress site in the Sandbox
Now comes the moment of truth. Before we restore the data, it must be modified to work in our sandbox environment. Make a copy of the live database backup. This way, we can revert back if something doesn’t go quite right.
Massage the data
Now, open the database copy in a text editor, I’m using Notepad++. Since my live system is hosted with SSL and my sandbox is not, I’ll need to do a search and replace for “https:/” and change it to “http:/”
Next, I do search and replace for the URL that my live site uses and replace it with my sandbox URL. That’s it, the database can be saved. Now we are ready to import it into our sandbox database on MySQL.
Import the data
From phpMyAdmin, go to the sandbox database then select Import from the ribbon bar. Select the database to import and uncheck the option to interrupt. Otherwise, the process could timeout.
It may take several minutes to complete. Keep the phpMyAdmin page open, it will tell you when it’s done.
Now the file and folder structure can be copied over the sandbox instance of WordPress. Before we begin, lets backup the sandbox “wp-config.php” file. We’ll use this later.
Once the sandbox WordPress directory has been overwritten with our live backup files and folder, we can modify the “wp-config.php” file to point to the sandbox database.
That should do it, save the “wp-config.php” file and reload the sandbox WordPress site. You should see something similar to your live WordPress site.
The theme, plugins, comments, posts, etc. should all be there. You may notice some formatting or main page content not quite in line with what’s live. Look around, 99% of it should be available.
Now, login on the wp-admin portal of the sandbox. You will need to use the login that is setup on your live system. This is because the database that was imported contains that information. This is why it’s important to safeguard the database backup files. Even though the password is hashed, it can be broken to reveal it in plaintext.
You have no excuses now! Do your backups and test your restore process before you need to!