How To Restore WordPress Without A Backup
I will explain in this article how you can restore WordPress without a backup. When it comes to WordPress websites, there are a number of components that could possibly become corrupted:
- The WordPress core files
- The website theme
- The plug-ins used on your website
- Your database containing all your content
I explained in a previous article how to recover from many of these types of failures. Also I mentioned I had never experienced a situation where the WordPress core files had become corrupted. This is no longer true! This is good because if these things happen to me I can guide my customers regarding the recovery steps required.
I did not have backups (although I thought I did) and in this article I will explain how to recover your website if you find yourself in this situation. This article will not be a detailed step-by-step guide. I am assuming that you already know some basics. Therefore, I will not explain how to use an FTP client such as FileZilla or how to backup and restore databases using a tool such as phpMyAdmin.
First of all, do not panic! I know we said we were going to restore WordPress without a backup but we do need a starting point. The very first step you need to take is to create a backup of the currently broken website. I suggest performing a full backup using whatever fast backup tool is provided by your hosting company. Secondly, create a backup of the wp-content directory in your WordPress website and the MySQL database used by your website. These are the only two items we need for our procedure. Place these in a safe place and guard them with your life, this is basically your entire website at this point.
Details of my disaster
I wanted to quickly perform updates on seven websites on May 11, 2019. Most of these were not production websites but two of them were. One was my main business website you are viewing at this moment. I was using the second production website to store reference material for an ongoing project. All seven websites needed to be upgraded to a new version of WordPress. Because I was in a hurry I started all seven updates at the same time. Please learn from my mistake and never do this!
In the middle of these updates there was apparently some sort of glitch at GoDaddy and of the seven websites, six of them were corrupted. After a while some of them could at least be viewed but I could not access the WordPress dashboard to configure anything. My two production websites were completely dead in the water. I was seeing either a blank white web page or I was greeted with an internal server error.
Possible solution one
I first thought I could refer to this wonderful article I wrote that explained exactly how to recover from just this type of scenario. However, that article was on my broken website and as I needed to fix the website to access the article containing the steps to fix the website, this was not going to help.
Also, using the debug file to track down exactly what files were corrupted would not be a good idea in my opinion. I could have spent a great deal of time finding and replacing the corrupted files that were preventing my website from working. However, what else was corrupted that I would discover months or years later? At that point I might not remember this incident and what had happened to corrupt the files.
Possible solution two
Another possible solution was to use my weekly backup. I provided step-by-step instructions in this article to implement a free automated backup. I even tested this when I originally created it, using the backup to completely restore my website. However, now when I really needed it to save the day I discovered the backup was corrupted! (I am including a screenshot of the unfriendly error I received.)
The best solution
I mentioned in the article that I referenced above that to restore any WordPress website you only need two components, the database backup and the wp-content directory. Rather than attempting to troubleshoot this issue I decided to save these items from the broken website and then follow the procedure I will detail below. I knew this would work because everything went haywire when I was upgrading the WordPress core files. Therefore, that had to be the location of the corruption and everything else was perfect.
Some additional details
What exactly is located in the database and what is in the wp-content directory? I am glad you asked! These are the major components in the wp-content directory:
- All uploaded media (photos, movies, audio clips)
- Your plug-ins with their associated configuration files
- Finally, your themes with all their configuration files.
There are exceptions to this rule. I am including here an example of a theme storing configuration settings inside the database. Consequently it seems that configuration settings may be stored in either location.
Restoring from the backup of the broken website
First of all, is there any reason to start with an old copy of your website from a year ago and then restore on top of that? This would depend upon your exact situation and this scenario is somewhat outside the scope of this text. If you had manually installed complicated configuration updates in a file such as .htaccess it might be useful to start with a copy that included those settings. Another solution would be to backup the .htaccess file from your broken website and then restore it in the steps below.
Here are the detailed steps:
- After you make certain you have a backup, delete the old broken website as we do not know what is corrupted (if you wish you can use your hosting tools to move it to a different directory if you do not want to delete it yet).
- Install a brand new instance of WordPress using the latest version in the same directory as the old broken website (it is very important this is in the old directory).
- Also, you need to know the name of the new database (such as i712345_wp15).
- After the WordPress installation completed, rename the new wp_content directory to something else (you can also delete it but this can take a long time).
- Copy the wp_content directory into the new WordPress installation from your backup of the broken website.
- Delete all the tables in the database. Be certain to click yes when it asks if you are sure. Then restore on top of the now empty database using the backup of the broken database (these two databases will have different names).
In case this sounds a little confusing, let’s say that back when you saved the database from the old website it was i712345_wp7. The backup file might be named i712345_wp7.sql. Now after you installed the brand new website you discovered the database for that website is i712345_wp15. Therefore, after removing all the tables from the new website (which is required so the restore will not return errors), you would restore this i712345_wp15 database using the i712345_wp7.sql file.
Detailed steps (continued):
7. The restore will not change the database name and the user password is not stored there so everything should just work.
8. Re-apply security settings as required using a plugin such as iThemes.
By the way, I performed further research regarding the user name and password for the database. Each time a database is installed such as i712345_wp12, a corresponding user name is created that is called i712345_wp12 and that user is configured with full access to that database. The password is some enormously unfriendly combination of characters that is written to the wp-config.php file so WordPress can access the database. Therefore if you wish you could set all your databases to the same account and password (Rumpelstiltskin – OhCanHeSew) and update all the wp-config.php files accordingly. However, from a security point of view this would be a terrible idea!
Finally, this should get you back to exactly where you were when the sky fell. By the way, this could happen to anyone at any time. Since it is very important to update your website on a regular basis to guard against malware, this article stresses the true value of our prepaid maintenance package. On a weekly basis we will backup your website, apply all the updates, scan for malware, and test your website to verify that everything is working.
In this article explaining how to restore WordPress without a backup I assumed that you had the wp-content directory to use in the restore process. If all you have is the database backup, there is a complicated procedure that can restore your website and it is covered in the following article: How to restore from database backup only