# Lost all my work in a docker instance **URL:** \ **Category:** Ignition\ **Tags:** ignition80\ **Created:** [March 10, 2021, 3:12pm UTC](https://forum.inductiveautomation.com/t/lost-all-my-work-in-a-docker-instance/44314 "2021-03-10T15:12:18Z")\ **Posts on this page:** 1\ **Showing post:** 14
**Author:** ![kcollins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcollins/32/19646_2.png) [@kcollins](https://forum.inductiveautomation.com/u/kcollins)\ **Post date:** [June 1, 2021, 2:13pm UTC](https://forum.inductiveautomation.com/t/lost-all-my-work-in-a-docker-instance/44314/14 "2021-06-01T14:13:25Z")
The benefits of volumes discussed above are definitely clear. However, it is usually a good idea to have proper backup strategies in place for your development. The backup method I prefer for most scenarios is utilize a bind-mount into the container as a target for the scheduled gateway backups within Ignition. By providing a bind-mount of `-v /path/to/backups:/backups` combined with configuring scheduled backups (_Config-\>System-\>Gateway Settings_ in the Gateway webpage), you can easily have those backups piped back to your host system. If you need to backup the volume itself, usually you can just use another disposable container using the `--volumes-from` argument to enable tar’ing up the volume contents. It is a bit of an advanced exercise, and I’d only really recommend this technique if you need to move volumes from one system to another. Thankfully, Ignition has a great scheduled backup function built-in, and it helps guarantee write consistency that might be problematic with the volume export (if the container is still running). Hope this helps! Kevin C. --- _[View the full topic](https://forum.inductiveautomation.com/t/lost-all-my-work-in-a-docker-instance/44314)._