6

Let's say, I delete a PostgreSQL docker container which had its data only here: 

$ docker inspect postgres1
...
"Source": "/var/lib/docker/volumes/4948af..../_data"
"Destination": "/var/lib/postgresql/data"

$ docker rm postgres1

If there was no other container referencing the volume, I cannot reconnect to this volume with --volumes-from any more, even though the files are still on disk somewhere in: /var/lib/docker/volumes/...

This presents me with two problems:

  1. What is the best way to locate the data, if I do not know the volume UUID of the directory?
    • Doing ls /var/lib/docker/volumes/ presents me with a hundred dirs like this f77c92....
    • Using find . -name "*postgres*" I still get dozens of results like this ...10e0dc/_data/postgresql.conf, with no clear way to identify the right one.
  2. Once I find the correct data in the directory, how do I reconnect a newly created postgres container to this data in /var/lib/docker/volumes/4948af.../_data

I have a daily full system rsync backup. How could this help in recovery (short of restoring the whole system)?

ChrisW
  • 880
  • 10
  • 16

1 Answers1

5

That is exactly why, when creating a data container, I always register its path in a file. (see my script updateDataContainerPath)

Usage (to be used just after creating a data container):

docker inspect ${gitolite_repos_cont} > /dev/null 2>&1 || docker create --name="${gitolite_repos_cont}" gitolite.repos /bin/true

# source the script, to make the updatePath() function available
. ../updateDataContainerPath

# save the path in a file
updatePath ${gitolite_repos_cont} "$HOME/b2d/gitolite" ${grepos}

(here ${grepos} is the file where you register or save the path of the volume of the data container)

That script will, if there was already a path saved for that data container, remove the empty data container folder, and move the old one to the new one (and update the new path)

sudo rm -Rf "${grpath}"
sudo mv "${fgrpath}" "${grpath}"

That would help answering your question 2, and avoid entirely your question 1.

That way, I can rm any container (including a data container, without the -v option of course), and I know the next time I recreate that same data container, I will find back my data.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • This is a good approach, as it provides a backup of the path to the data. An automated solution to this would be nice, so that registring the path could not be forgotten. When trying your script, it would only save the path of the first volume of a multi-volume data-container. -- I could import the data from the saved path to a new container, but how would I actually _re-connect_ to the path when I re-create a container? – ChrisW Oct 24 '15 at 16:41
  • @ChrisW yes, my script only care about the first volume for now. The re-connect is the last part of my answer, done at https://github.com/VonC/b2d/blob/bb0a9afb4195da083e77157d54cb626d1b9eaa1d/updateDataContainerPath#L35-L38 – VonC Oct 24 '15 at 16:44
  • Right, I see, how that would work! I'll give that a try with some test containers. Thanks for explaining. – ChrisW Oct 24 '15 at 17:00