I run Docker on Ubuntu while keeping large files such as photos on a redundant NAS through NFS. However, application data and databases, including the Immich database, currently live in Docker volumes on the server's single, non-redundant SSD. If that SSD fails, I could rebuild the containers from my version-controlled Compose files, but I would lose the data stored in those local volumes. Moving everything to NFS has caused permission errors. I'm looking for a reliable setup that keeps the server mostly focused on compute and makes recovery quick after hardware failure. Would it be better to move the workloads into Proxmox virtual machines, use a cluster, or simply improve my backup and storage strategy? I already use Borg with an off-site copy, but I also want to validate that restoration actually works. What approaches do others use for resilient Docker storage and disaster recovery?
4 Answers
Running Docker directly on Ubuntu is perfectly valid; Proxmox will not automatically make application data resilient. Its main advantages are isolation, easier VM management, and the ability to back up or move complete virtual machines. A practical design is to keep Docker on a small VM, store bulk data on the NAS, keep only what needs local SSD speed locally, and back up the VM or its application data separately. With Compose files in version control and a documented restore procedure, replacing the host becomes much easier.
A NAS-mounted Docker volume is a reasonable option for data that benefits from centralized storage. You can define the NFS mount directly in Compose with the local volume driver and options such as the NAS address, NFS version, export path, and read/write mode. Permission errors usually come from UID/GID mismatches, export permissions, root squashing, or security settings on the NAS, so make sure the container’s user IDs line up with the ownership expected by the NFS share. I would be more cautious about putting latency-sensitive databases on NFS unless you have tested the performance and locking behavior.
A simple recovery plan can be more valuable than a cluster for a small, stable home setup. Automate a scheduled stop of the containers, run Borg against the Docker data and configuration, restart the services, and retain an off-site copy. Then periodically restore to a spare computer or VM and confirm that the databases and applications actually start. If the whole host can be rebuilt from a minimal OS installation, Docker, Compose files, secrets, and a tested backup, a single-server setup can still have very good disaster recovery.
The most important distinction is that redundancy and backups solve different problems. RAID or redundant NAS storage helps keep services available when a disk fails, but it does not replace backups. Back up the Docker bind mounts and volumes, preferably with the affected containers stopped so databases are captured consistently. If you back up while everything is running, the result may only be crash-consistent unless the application supports a proper backup procedure.
I already use Borg and copy the backups to a separate off-site location. My next step is to stop the containers during the backup and restore everything to another Linux machine so I can verify the recovery process instead of assuming the backups are usable.