Yesterday when I tried to update WordPress to the most recent version of 4.2.1, I got a bit of a scare when I was greeted with a screen saying “Your WordPress database is already up-to-date” and I was unable to access my WordPress administration dashboard which kept redirecting back to the homepage. Since this wasn’t the first time I was dealing with a corrupted installation, I tried all the usual tactics. I disabled all WordPress plug-ins via FTP, cleared the cache at the server level, and disabled my WordPress theme. But none of these worked. I was simply unable to reach my website backend while the front-end continued to function perfectly.
Anyone who’s been in the situation will know how terrifying it can be – few things are more stressful than a broken installation on a live site. And even though the instructions before you install the WordPress update specify that you should take a backup of your database each time, how many of us really do all of that? So having failed to restore my site using the regular techniques, I had to press the nuclear option and restore a backup.
Now as we’ve seen before, there are many ways to go about this. You can restore a configured backup from cPanel or rely on WordPress plug-ins. However, I use SiteGround as my web host and they automatically take regular backups of my site on my behalf. So I decided to do a full restore of my entire WordPress folder using the most recent automatic backup. Here’s how I managed it:
Restoring an Automatic Backup
When you log into cPanel on SiteGround, go to the “Backups Manager” section and click the “Restore Backup” icon as shown below:
The great thing about this technique is that it is enabled by default and you don’t have to set it up beforehand. This means that even if you’re a scatterbrain, you have some degree of protection. In the resulting screen, you can see a list of all the backups of your site that are available for restoration. In the screenshot below, I can verify that I have at least one full backup for each day – and sometimes two.
Now depending on whether or not we want to restore the files or the database, click the corresponding icon on the top right-hand corner for the backup that you’re interested in restoring. This will open up a hierarchy of files or tables depending on what you clicked. In my case, the entire WordPress installation is located inside my “blog” folder. So I navigate down to it and place a checkmark on the left-hand side. This causes the “Restore Selected” button to become visible on top as shown here:
You can selectively restore folders or files to any degree of detail. The user interface is self-explanatory and very simple. Once you click the restore button, you’ll get a pop-up asking you for a confirmation and warting you that this will overwrite all existing files.
Once you accept the confirmation, there’s no going back. The restore process will start and you can monitor its progress via the UI. You can see the total number of files that need to be restored as well as the storage space in MBs. Before starting, it will calculate an estimate of how long the process will take:
And finally when all the files have been copied over, you’ll get a notification of a successful restore.
p style=”text-align: center;”>
At this point, I was able to go back and check that my blog was working fine and it had been reverted to the previous version of WordPress. I was finally able to resolve the database issue by first disabling all my plug-ins and THEN upgrading WordPress. With the daily file and database backups taken by SiteGround, I need to rely far less on manual solutions such as plug-ins and configured cPanel backups.