Restoring data from a broken Business Central Docker Container

 By Steve Endow 

(This blog post is inspired by a forum question. Credit to Arvydas for the question and sharing the solution.)

What if I made the mistake of storing some "worthwhile" data in a Business Central Docker container over the course of several months?  Perhaps it was test data or data imports that I didn't think I would ever need--but then 3 months later I realized that the accumulated data was valuable.

In theory, no big deal.  If you realize that you want to keep the data from a working container, Stefan Maroń has a blog post with instructions on converting that Container into an Image using "docker commit".  Just create an image and you can make new containers from that image.  You could also backup the SQL databases from the Docker Container to the local file system.  

But, what if the Business Central Docker Container with your valuable data stops working due to a Windows Update?  And you only realize you need that data after the container stops working.  If the Container can't be started at all, how can you extract the Business Central data?

This solution appears to allow me to copy the SQL mdf and ldf files from the broken container to my local file system, then copy the mdf and ldf files to a new working container to effectively "restore" them.

This may not work for all situations where a BC container has issues, but should work if the container is intact, but just won't start up due to a Docker or Windows issue or error.  

Let me know if there are any issues or caveats with using this method to restore the data from a container.

In this example, I have a 'broken' container named "dev18", and a working container named "test18".  Both containers have the exact same version of Business Central. (I don't know how much latitude is possible with different BC versions.)

I first create a local directory called BCDockerBackups (or whatever your want to call it).  Within that directory I create a subdirectory with the name of my broken docker container, "dev18".

First make sure the problem container with your data is stopped.  (Change "dev18" in these examples to the name of your broken container.)

docker stop dev18

Then, run docker ps -a and copy the CONTAINER ID value for the problem (source) container AND the working (destination) container

docker ps -a

Next, use the "docker container cp" command to copy the SQL database files to your local file system.

docker container cp fd572657ff36:C:\databases D:\BCDockerBackups\dev18

You can use relative path references for your destination directory, but after encountering a few oddities, I personally recommend using absolute paths in these commands.

If you see a message "unexpected EOF", that indicates that the Docker Container is still running. Make sure the container is stopped before trying to copy files out of the container.

Next, make sure that your new working container, where the database files will be 'restored', is also stopped.  In this example, my destination container is named "test18".

docker stop test18

With the working destination container stopped, copy the database files from the local file system to the destination container.

docker container cp D:\BCDockerBackups\dev18\databases\. e8d69bfb5e78:C:\databases

(Note: Make sure to have the backslash and period at the end of your local path where the mdf and ldf files are located)

This should "restore" the database files into the working container.

Low Tech Database File Transfer

Now that the database files have been copied, restart your working container.

docker start test18

Finally, log into your working container and you should hopefully see the data from your broken container.

Steve Endow is a Microsoft MVP in Los Angeles.  He works with Dynamics 365 Business Central, Microsoft Power Automate, Power Apps, Azure, and .NET.

You can also find him on Twitter and YouTube