Warning: I Lost Database Data on 29 Sites — Here's What Happened and How to Protect Yourself

Workflow
1

What Happened

I’ve been using Local by Flywheel for a long time with 29+ WordPress sites, all stored on a separate drive (F:\Webserver\Source). One day I opened Local and every single site failed to start with the same error:

Uh-oh! Unable to start site.
Error: Command failed: mysqladmin.exe --host=::1 ping
mysqladmin: connect to server at '::1' failed
error: 'Can't connect to MySQL server on '::1' (10061)'

No Windows updates. No new software installed. No disk cleanup tools run. It just stopped working overnight.

Root Cause #1: Duplicate Ports in sites.json (MySQL Crash)

After digging into the log file at:

C:\Users\<username>\AppData\Roaming\Local\local-lightning.log

I found this critical error:

mysqld got exception 0x80000003
InnoDB: trx_undo_mem_init() assertion failed

Tracing back further, I found that one site (code-wp.com) had all services assigned to the same port (10774) in sites.json:

json

"mailpit":  { "WEB": [10774], "SMTP": [10774] },
"mysql":    { "MYSQL": [10774] },
"php":      { "cgi": [10774] },
"nginx":    { "HTTP": [10101] }

This appears to have happened when Local crashed or was force-closed during site creation. The corrupted config caused MySQL to crash on startup — taking down ALL other sites with it, not just the affected one.

Fix: Manually edit sites.json and assign unique ports to each service for the broken site.

Root Cause #2: Database Stored in AppData — Easy to Lose

This is the bigger concern I want to warn everyone about.

Local stores your live MySQL/MariaDB database in:

C:\Users\<username>\AppData\Roaming\Local\run\<random-id>\

Each site gets a randomly named folder (e.g., 7ZNeuG4WA, dS7Q-owea). Out of my 29 sites, only 7 had folders in the run directory. The rest were simply gone — likely cleaned up at some point either by Local itself or another process.

The app\sql\local.sql files in your site’s source folder? Those are just the default WordPress install SQL, not your actual current data. Don’t rely on them as backups.

This means:

  • Your WordPress files (themes, plugins, uploads) are safe if stored on a separate drive

  • Your database — posts, orders, settings, users — can be silently lost

What Local Does NOT Do by Default

  • :cross_mark: No automatic database backup on shutdown

  • :cross_mark: No warning when run folder is missing for a site

  • :cross_mark: No alert when ports conflict in sites.json

  • :cross_mark: Database stored in AppData, a location commonly targeted by cleanup tools

How to Protect Yourself

1. Export your sites regularly Use Local’s built-in export: click ... next to the site name → Export. This creates a proper .zip with both files and database. Store it on a separate drive.

2. Install UpdraftPlus or All-in-One WP Migration on every important site Set up automatic backups to Google Drive or a local folder outside AppData. This is the most reliable safety net.

3. Exclude Local’s data folder from any cleanup tools If you use CCleaner, IObit, or similar tools, whitelist:

C:\Users\<username>\AppData\Roaming\Local\

4. Manually backup the run folder periodically Just copy the entire folder to a safe location:

C:\Users\<username>\AppData\Roaming\Local\run\

5. Check your sites.json after any crash If Local crashes or freezes during site creation, open sites.json and verify each site has unique ports for all services.

Feature Requests for the Local Team

If anyone from Local is reading this, here are some suggestions that could prevent data loss for other users:

  1. Auto-backup database on site stop — export a .sql file to the site’s app/sql/ folder every time a site is stopped cleanly

  2. Detect and warn about port conflicts in sites.json before attempting to start

  3. Move database storage out of AppData\Roaming to a more stable location, or at least allow users to configure where DB data is stored

  4. Show a warning when a site’s run folder is missing on startup

My Setup (for context)

  • OS: Windows 11 Pro

  • Local version: 10.0.0+6907

  • Sites: 29 sites across MySQL 8.0.16, MySQL 8.0.35, MariaDB 10.4.x

  • Source files stored on: F:\Webserver\Source\

Hope this helps someone avoid the same situation. Always keep external backups — don’t trust any local dev tool to protect your data by itself.

2

Thank you for sharing all of this @vithanhlam! We’ll take a look at all of these details.

Would you also be able to share your full Local Log with us? There are some different ways to access and share Local Logs. For us to be able to troubleshoot thoroughly, please click the Download Local Logs button from the Support tab in Local (question mark on the left-hand side of the app, then scroll down a little). This will generate a zip archive containing the Local log and other diagnostic information for our investigation.

To piggyback on your advice of taking frequent backups, we agree! That’s why we made backups a native Local feature, so they are now easier than ever to create and manage right from the Local app and save to external Cloud providers. So for anyone reading along, check them out in Local v10.0.

3

It doesn’t do this for you? Haven’t really tested the file yet, but every time I stop a site, a local.sql file in my %site%/app/sql folder is written, and from the time it takes, it certainly feels like it’s a backup of the current SQL state.

3 Likes
4

@vithanhlam I’m also on Windows 11 Pro, Local Version 10.0.0+6907, MySQL 8.0.35, with 35 sites currently. The app updates the app/sql/local.sql files when sites are stopped. I do not use Local’s Cloud Backups, but I do have everything backed up using BackBlaze – something like this at the system level is essential, and not just for Local. I’d prefer to rely on something at that level, rather than WP backup plugins.

As for “cleanup tools” targeting AppData, there’s certainly a lesson in that – don’t run cleanup tools without knowing what they’re cleaning up. It wouldn’t matter what directory you had the site data in, if your cleanup tool is misconfigured, you run the risk of losing files. Have you identified the app or tool that actually removed the directories and files from your filesystem?

Sure, there are things that Local can probably do better when unexpected things happen. I’ve run into a couple of them over the years, and each has been addressed after being reported. Some situations are just very difficult to identify what happened to cause files to be lost or corrupted, and usually require a user willing to spend the time to track them down because the Local developers don’t have access to your system.

2 Likes