Rescue and Repair: Recovering Databases from Corrupted XAMPP Instances
I have several WordPress website projects, each hosted on different XAMPP instances. One of these was on my laptop, which I decided to bring with me on vacation to Thailand. Since I wouldn’t need the websites during my trip, I moved all the folders of the XAMPP instance and my WordPress website projects to an external USB drive before leaving.
After returning from vacation, I attempted to resume work on my WordPress project, only to discover that key XAMPP files were missing. The xampp-control.exe, xampp-start.exe, and xampp-stop.exe files had all disappeared. Fortunately, the mysql folder was intact, along with all files in the /data subfolder.
With my database files still available, I needed to find a way to restore my website’s database.
The Way to Restore the Database
My plan was to:
- Install a fresh instance of XAMPP.
- Copy all files from the database folder /data/website-project/ of the old XAMPP instance to the same location in the new instance.
- Start XAMPP and check phpMyAdmin to see if my website’s database was accessible and working properly.
Abstacles on the way and the solutions
Initially, everything seemed to go smoothly. The database appeared in phpMyAdmin, and all tables were listed under the database node. However, when I clicked on a table, I encountered an error message: “#1932 – Table ‘databasename.wp_signups’ doesn’t exist in engine.” As you can see in the screenshot below:
With the help of ChatGPT, I learned that this error meant that while the table structure existed in phpMyAdmin, MySQL couldn’t access the actual table data. This was because InnoDB tables store their data inside ibdata1, rather than individual files.
Since I had only copied the database folder from mysql/data without also copying ibdata1, the InnoDB tables were inaccessible.
To fix this, I copied all necessary files and folders (marked with red lines in my screenshot) from my old XAMPP instance to their new location under mysql/data in my new XAMPP installation.
After copying the missing files, I encountered a new problem—MySQL refused to start. The error log displayed the following message:
“InnoDB: Downgrade after a crash is not supported. The redo log was created with MariaDB 10.4.32.”
This error indicated that the ib_logfile0 and ib_logfile1 files had been created by a newer version of MariaDB/MySQL than the one installed in my new XAMPP instance. Since InnoDB log files are not backward compatible, MySQL failed to start.
To fix this issue, I deleted the ib_logfile0 and ib_logfile1 files. These files store redo logs, which are not required to recover table data, so removing them was safe.
After deleting these files and restarting MySQL in XAMPP, everything worked perfectly! My website’s database was accessible and fully functional in phpMyAdmin.
Final Thoughts
This experience taught me the importance of backing up all necessary files—including ibdata1 and InnoDB log files—when migrating or restoring MySQL databases. Job done!
