muesli/docker-backup

Using docker-backup to migrate docker storage-engine

andrewleech opened this issue · 1 comments

Hi, thanks for your work on this project - the lack of built in backup/restore in docker is a strange oversight of the system!

I've got a general purpose linux home server which runs a bunch of network services, many of which run in docker (like home assistant). These have grown over time, many of which I didn't really document how I started the containers etc.

When updating the server recently I hit a need to migrate the docker configuration from aufs to overlay2 which basically amounts to a new installation - there's no provided mechanism to migrate between the two!

With this background, I thought your tool would be perfect to allow my to backup the existing docker system, then switch the storage engine and restore.

I did run into a few things that didn't just work for me, so I decided to learn go and see if I could add the extra features myself. It's gone quite well for me and I've now successfully migrated my docker to overlay2.

I'm going to raise a bunch of pull requests for the changes I made to support this. Don't feel any pressure to merge if they don't make sense to you or for normal use cases - I've raised this issue to simply provide some background to my changes.

  • #19 restore: only pull image if it doesn't already exist
  • #21 Recreate container with same name as original
  • #22 Backup and restore all HostConfig settings
  • #23 backup: If container image name doesn't specify the tag, find the correct/used one.
  • #24 restore: Add --replace option to automatically overwrite existing container of the same name
  • #25 backup: add option --exclude to skip matching file paths from bind mounts
  • #26 Backup & Restore files - copy volumes and included bind files to folder, restore files from same folder.

All of these can be seen together in https://github.com/andrewleech/docker-backup/tree/working

Edit: I found last night that a couple of my restored services still weren't working.
One of them failed because the resulted volume files had the wrong user (rsync options needed)
The other one was a set of containers with a common custom network between them. The network had been created, but the original containers had a hostname/alias that was used to access them on the network. I figured out how to manually remove them from the network them re-add them with the original aliases and they started working. I'll try to figure out how to do that programmatically and add that here too

Thank you @andrewleech! I'm going to review them one by one now, but I already greatly appreciate your efforts. If there's anything I can help with, never hesitate to ask!