Hey @csilverman – I’m a little confused – the latest versions of Local don’t use Docker.
Older versions of Local made use of docker to host the sites, however, starting with the 5.x line, we no longer use docker and instead run the server processes directly on the host machine.
You mention having a mirror of the sites, can you expand on that a little?
Basically, there are roughly two ways to try and salvage a site. The first way is the safer route, and what you should try first while the second route is a little risky and might not work.
1. Locate and restore the sql dump file in the Local Sites folder
This is basically what Nick mentioned. When a Local site is stopped, the DB is exported to a folder at a location like this:
/Users/[username]/Local Sites/[sitename]/app/sql/local.sql
If you have a mirror of the drive, then I would try to restore the Local Sites folder. For the sites that have a local.sql file, you can zip up the files and sql dump using the help doc link from Nick:
2. Maybe use the raw DB files
While the ~/Local Sites folder is the safer place to go for restoring a site, Local stores the raw MySQL database files in the run folder of Local’s user config folder. This is located at:
/Users/[username]/Library/Application Support/Local/run
Each site’s raw files are contained in a folder with the site’s id. Within each of those folders is a mysql/data folder:
If you do have that run folder (and hopefully the raw DB files aren’t corrupted), then the rough process for restoring the sites would look like this:
For each site you want to restore…
- Create a new, plain WP site.
- Copy any files to this new site (ie, wp-content, uploads/media/plugins/etc)
- Stop the site and quit Local. very important! We need the mysql daemon to not be running!
- You should see a new folder within the
~/Library/Application Support/Local/run folder with a site id for the site.
- Replace that site’s
mysql/data folder with the mysql/data folder from the backup you have.
- Start Local and start the site and verify things are working
There are lots of things that could go wrong, so be careful and go slow!
For example, one thing I could imagine as being a problem is if the table prefix is different from the default wp_ prefix. You might need to update the wp-config.php file for the site with whatever prefix is used with the DB files.
Anyway, hope that helps give you some options for proceeding. Let us know if you get things working or have any pointers that might help the next person.
