Backups, backups, backups
Written by Isaac
Did you know that a whole two characters can make the difference between removing your entire database when shutting down a service? docker compose down -v will remove the volumes associated with the compose project, even if you specify a specific service that doesn't use the volumes.
Take, for example, a frontend and backend, where the backend has a SQL database that relies on a volume to persist changes. Suppose for whatever reason the frontend also has a volume (possible a redis database?); suppose you want to remove the volume only for that frontend.
One (I) might (did) assume that specifying the frontend service in the compose down command would only remove the volumes associated with said service (i.e. composing down the frontend should only remove volumes that the frontend uses).
Apparently this was incorrect. Running docker compose down -v frontend removes all volumes declared in that compose file.
This can be absolutely catastrophic to people that aren't prepared; novices that aren't familiar with docker, volumes, or back ups.
Thankfully, however, I setup automatic daily backups (and-conveniently, this happened only two hours after the daily backup), meaning I was able to trivially restore these docker volumes within five minutes.
sudo restic -r /mnt/usb/backups/ restore latest -i "/var/lib/docker/volumes/*" --target foo
Having progressive, frequent, and reliable backups has so far saved me twice from my own fuckups. I once unintentionally removed a .gitignore, which wasn't source tracked for whatever reason; and now this. Thank god for restic.