In a dramatic turn of events, one of our servers was recently decommissioned without warning. It all happened too fast. Before we’ve even said our goodbyes, we’d been assigned a new server, with the old server’s disk temporarily attached to it as a saving grace.
Now this was a development server. So despite my dramatisation of the situation, it wasn’t that critical. It didn’t have any client data, nor did it have any production code. But it did have a bunch of sites with unique configurations and dummy data that allowed us to quickly test new ideas for our product.
So I wasn’t entirely happy with abandoning ship and starting fresh. There had to be a way to restore the valuable sites from the old server!
Let’s 🚀
The Challenge
Restoring the files was a breeze. We had used CWP so creating a new CWP user with the same domain and moving the files into the user’s public_html directory was all it took.
Restoring the DB was tricky though. We didn’t have the luxury of using mysqldump
before the old server was nuked. So all we had was a copy of /var/lib/mysql
which we grabbed during the grace period.
Operation Phoenix
I knew I could boot up a MariaDB container with my old /var/lib/mysql
as a volume map. But I couldn’t fully imagine how I should proceed from there. So out came the checklist:
- Identify the DB version
- Create a container of the same version
without mariadb running on startup
- Boot up mariadb in safe mode
I forgot the root password (sudoers woe)
- Reset the root password
- Dump them all
I got ChatGPT to churn out a bash script to dump all my DBs in one go as timestamped SQL files.
So still in the container, I did a vi dump-all.sh && chmod u+x dump-all.sh
with the following going into the file:
Then I just had to run the script like so:
mkdir /var/lib/mysql/dumps && ./dump-all.sh
- Secure the salvage
- Verify that the operation was a success
And my site works!
Now I can go back to ignoring backup best practices /s