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:
ls /var/lib/docker/volumes/
presents me with a hundred dirs like this f77c92...
. find . -name "*postgres*"
I still get dozens of results like this ...10e0dc/_data/postgresql.conf, with no clear way to identify the right one./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)?
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.