$&#%*! If you live in Salem, Oregon you may have heard me over the cacophony of fireworks and mortars on New Year’s Eve. Around the time 2019 was ending, I deleted what I thought were corrupted archives of my website. In fact, I deleted my WordPress installation, which took my site with it. Seven years of photos and posts gone…like the puffs of smoke from the expended fireworks outside my window that night. Family history, memoirs and other valuable content deleted with the click of a button. Actually, two buttons. The second asking if I was sure I wanted to delete. WELL, I THOUGHT I WAS!
Before going further, it helps to understand a few basics about WordPress, the free content management system that powers more than 35% of the world’s websites. It makes building sites much easier for non-developers, though developers use and modify the open source code. Plugins are pieces of software added to a WordPress site giving it security, optimizations, visual effects, etc. Themes are templates.
Among the myriad folders and files in a WordPress installation, two are of utmost importance. First, the content folder, which holds the plugins and themes the site uses and all the images. Second, the SQL file, which resides elsewhere on the server and holds the site’s database information. This includes all written content, plugin data and other information that tells WordPress how to display the site.
Back to New Year’s Eve. In full panic mode, I opened my FTP client and connected to the server to look around and…yep. All the WordPress files were gone. Forever. While digging around, however, I discovered that my web host does automatic nightly backups. A flicker of hope! Inside the nightly backup folder was a copy of the content folder, but I also needed the SQL file, and that isn’t backed up because it hides in a more secure area of the server. Not secure enough apparently. Once I hit the delete button on WordPress it was irretrievable. Just great.
But, then another glimmer of hope! Inside the backed up content folder I found my plugins, including the one I use to manually back up my website. It was holding the backup files from a week prior of both my content folder and my SQL file. (It sounds like I’m going down a rabbit hole. Stay with me!) I immediately downloaded all the backups off the server onto my computer so they would not be overwritten the following night. Now, I had to put all the pieces back together.
This was where things became maddening. I had to do a fresh installation of WordPress. That was an easy click of a button. Done! Unfortunately, restoring everything had a broken easy button. After reinstalling the backup plugin, I tried many times to restore the files it had saved. The program simply refused to do so, thinking I was moving my website to a different server. That is a paid feature. No go. There was a note in the Frequently Asked Questions section of the plugin’s support website, mentioning if a database table prefix was different (huh?) this error could come up. Support for free plugins is not particularly robust and certainly not over a holiday. I filed a ticket and hoped to hear something before spring.
In the meantime, I moved forward with the messiness of a manual restoration, but the backed up files from the plugin were compressed in a proprietary file format. I had to grab the developer’s extraction tool so I could separate the content folder and the SQL file. Then, when overwriting the fresh WordPress content folder with my backup, I completely borked the website. I had to ask my web host for help because it was fundamentally broken. It turned out a couple files added from the backup were referencing files that did not exist, crashing the site, so the simple fix was deleting the offending files.
By this time, I figured out where I was supposed to put that SQL backup file — the one that hides in a special place. It required going into the back end of my website, adding a database and importing the SQL file into it. Everything was there that I lost, so I hoped to be nearly done with the project, but the restoration process dragged on like a root canal. I could get the site partially functioning, but not fully. Back to the beginning.
Mentally and emotionally I was a mess. There was a lot of self-loathing for making such a stupid mistake to begin with. Anxiety attacks greeted me every morning when I woke up. I wondered if I was going to have to open that SQL file and hunt through all the code for more than 130 posts I’d written and then copy and paste them back one at a time. There were also more than 300 photos and images and the thoughts of trying to put those back made me ill.
I reached out to developers who didn’t think they could help. I talked to friends who had some experience with WordPress, and they weren’t sure how to help but were fairly certain I had everything I needed. There were suggestions to start over. I began seeing the situation as having locked my keys in my car. I didn’t need a new car. I needed someone who could help me get back into the car!
I became too singularly focused on getting the website back and finally had to mentally let go, knowing I had done all I knew to do. By the fifth day of this ordeal, I found relief in that. I had hope and faith I’d get the help I needed and stopped spending all day and night in front of the computer trying different solutions.
By the start of the next week, the plugin developers responded to my request for help. Further research online helped me figure out a few things on my own. As it turned out, when I did my first installation of WordPress seven years ago I put it at http:///stormyweatherdesign.com. When I reinstalled it after my disaster I put it at http://www.stormyweatherdesign.com. I didn’t think there was a difference, and in practice there’s not, but the software thought it was a new website and thus a migration. Again, a paid feature and something I couldn’t do. Once I got that fixed, I was able to start the automated restoration. And…
…it didn’t work. $&#%*! You have GOT to be kidding me. The backup was large, and the server allows only a limited amount of time for the program to finish its work. Mine took too long because of the backup’s size. My web host was not open to allowing a temporary increase of the execution time, so I had to do everything manually, something that had not worked 100 attempts before.
This time I found better instructions on manual restoration and got the site up to about 90% put together. The missing 10% though included the administration page, which is needed to do any kind of changes going forward, and the site was still a bit wonky. After more research, I found a solution, and the site was back, a week to the exact hour I destroyed it.
Getting everything back and fully functioning was a miracle. It may not rate highly in great miracles of the world, but it was a big one to me. Not having a stroke or cardiac episode was probably a marvel too. Ha! I’m grateful for the support of many who were aware of the problems I was having and for those who offered advice, even if it was more about my personal health rather than actually restoring the website.
I learned a lot about WordPress and databases in a week. I’ll be a little more careful about what I’m deleting in the future, but I saved all the instructions for how to put things back together should this happen again. To be extra safe, I’m offloading my backups to a location other than the server. As the saying goes, “There are those who have lost data and those who will.” Best to increase the odds of recovery.
When I told my five-year-old that the website was back she said, “It didn’t even take you seven years.” She thought when I said I lost seven years of material that it would take seven years to get back. Ultimately, it took seven days. And that was enough.