Restoring WordPress from Backup

I’ve been an infrastructure and systems engineer and admin for more than 15 years, so the foremost question in my mind when considering using a decentralized web hosting service like Akash is this: when the **&$# hits the fan (and it will), how do I get all my hard worked development and deployment back quickly and easily?

So my first task after successfully launching a WordPress deployment on Akash was to install the Updraft plugin. Updraft creates backups of a WordPress installation and can restore the backup from within a new WordPress installation–no root access needed.

I ran the backup, made a bunch of customizations, and ran the backup again–with the backups being stored in my Google drive account. There are multiple other main-market storage integrations as well, and you can also download the files to your computer.

Then I screwed up my site on purpose. Just because I like pushing the envelope of what is possible, I decided I wanted to change the URL of the WordPress site. It looks like a simple enough operation within WordPress; you type the things, and press “Save Changes” and… voila! I earned myself a 403: forbidden error. The problem is that while WordPress’ database now knows to answer to the new URL, the Apache configuration that presents WordPress to the world didn’t get the memo.

I knew it wouldn’t help, but just to see what would happen, I tried to update my Akash deployment with the new URL as well, and sure enough, it didn’t do anything. This is because the URL submitted in the manifest during deployment is only referenced when creating the WordPress-backed Apache instance, and that setting isn’t something that can be updated on the fly.

OK, so I was prepared for this: I closed my previous deployment, opened a new one with my new URL and went through the WordPress initialization process. Then I installed Updraft, located my backup and selected to restore everything. And… voila! I was redirected back to the old URL which now gave me a 404: file not found error. The problem was the database that was restored was the copy of the one that had the old URL in it, so again I was stuck. Apache knew about the change but not WordPress this time.

After a bit of mucking around with copies of the backup files (never mess with the originals, kids!), I figured out that the database backup wasn’t actually a mysql-encoded file: it was a text file containing insert commands to all the entries in the mysql database. Once I knew that, I spun up my sed command expertise (mostly typing ‘how to use sed‘ in duckduckgo), replaced all references to the old URL with the new URL, and after another quick re-deployment of blank wordpress, the restoration worked…mostly. For some reason the theme was missing and so were my pictures.

Long story short, don’t plan on changing the URL, and keep copies of all your stuff in case something goes wrong with your backup. And test your backup before you have to use it, to be sure you know what to do and how to do it when the **&$# hits the fan (and it will hit the fan)!

Share

Add a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.