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:
- 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 thisf77c92...
. - 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.
- Doing
- 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)?
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):
(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)
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.