I run Docker on Ubuntu with a NAS storing large files such as photos over NFS. However, application data and databases, including my photo-management database, currently live on a single non-redundant SSD in the server. If that SSD fails, I could rebuild the containers from my Git-managed Compose files, but I would lose the persistent volumes stored locally.
I would like the server to be mostly compute and make recovery after hardware failure as quick and painless as possible. I have tried moving more volumes to the NAS over NFS but ran into permission errors. Would it be better to keep container data on local storage and rely on backups, mount NFS volumes properly, or use something like Proxmox and virtual machines? I am also open to a multi-server setup if that is genuinely useful.
What storage, backup, and recovery practices do you use for a resilient self-hosted Docker environment?
3 Answers
The main distinction is that redundancy and backups solve different problems. RAID or redundant NAS storage helps keep a service running, but it does not protect against accidental deletion, corruption, or a bad change. Keep proper backups of the persistent application data, ideally with multiple copies and one off site.
For databases and other stateful services, stop the relevant containers before backing up so the copy is consistent. A live backup may only be crash-consistent unless the application supports a proper dump or snapshot. Borg is a good choice, and the important next step is regularly restoring it somewhere else to prove that the backup actually works.
Proxmox is optional rather than a requirement. Running Docker directly on Ubuntu is perfectly reasonable and usually has less complexity. A virtual machine can make it easier to move or restore the Docker host, and it provides stronger isolation, but it does not automatically protect your data.
A practical setup is to keep Compose files and configuration in Git, store bulky media on the redundant NAS, keep databases on fast local storage if needed, and back up all persistent volumes to the NAS and then off site. You can also back up the whole Docker VM if you use virtualization. A scheduled job that stops the containers, runs Borg, and starts them again is a straightforward approach, as long as you periodically perform a full recovery test.
You can mount an NFS share directly as a Docker Compose volume instead of relying on a separate host mount. For example, a Compose volume can use the local driver with NFS options such as the NAS address, NFS version, read/write mode, and the exported path. Make sure the NFS export permissions, UID/GID mapping, and Docker container user all agree; permission errors are usually caused by those mismatches rather than Docker itself.
That said, I would be selective about what goes over NFS. Large media files are usually fine there, while databases may perform better on local SSD storage. The local database does not necessarily need redundant live storage if it is covered by frequent, tested backups.
I already use Borg with a secondary off-site copy. I am planning to test restoring to another Linux machine and will probably stop the containers during the backup, then start them again afterward.