Proxmox / Backups / Docker

Back Up Docker Config Volumes That Live on an NFS Bind Mount

Run each app in its own container with its config folder bind-mounted from a NAS over NFS. It is a common homelab pattern, and it works great right up until you check whether any of it is being backed up. It usually is not. Here is why, and how to fix it without losing anything.

The invisible gap

Most VM and container backup tools back up disk images, Proxmox Backup Server included. The virtual disk attached to a VM or container. A raw NFS bind-mount pointing at a folder on your NAS is not a disk image. It is a path the container reads and writes through. Your backup tool has no idea it exists. So an app's entire configuration sits unprotected while every other VM on the same host is faithfully backed up nightly. Quality profiles, credentials, indexer settings, months of tuning. The setup looks complete. Backups running, green checkmarks everywhere. Then you need to restore one specific app and find its data was never in scope.

BE WARNED: check for this specifically. Do not assume. A real case. Five separate applications had run this exact way for months, all confirmed "working" in every visible sense, with zero backup coverage for any of their config data the whole time. Nothing failed or errored. The gap was never checked, because everything looked fine day to day.

The fix: move it onto a real, backed-up disk

The reliable pattern is a Proxmox-managed virtual disk living on your NAS-backed storage pool, instead of a raw bind-mount:

pct set <ctid> -mp3 <nas-storage-pool>:10,mp=/mnt/newconfig,backup=1

That provisions a real disk image on your NAS through your hypervisor's own storage layer. Formatted normally, mounted like local storage inside the container, instead of a bare NFS path. The backup=1 flag is what brings it into your backup job's scope.

Migrate without downtime risk

Stop the app's container process first, for a clean, consistent snapshot. Especially important for anything with a live database file.
Provision the new disk at a temporary mount path, so the original bind-mount stays intact the whole time. Nothing about the old location changes yet.
Copy the data across. Then diff the two locations to confirm they are identical, before you trust the copy:
```
diff -rq /config /mnt/newconfig
```
Only once they match, detach the old bind-mount reference and repoint the same new disk at the real config path. Detaching is harmless. It removes a config line, and the original folder is untouched.
Restart the app. Verify it comes back with its real existing data, not a fresh install. Check the logs for a clean boot and confirm through the app's own UI that your settings are there.

The gotcha you'll almost certainly hit: files the copy can't read

BE WARNED: expect at least one file per app to fail with a permission error mid-copy. Long-running apps generate a handful of files with tighter permissions than the rest of their config directory. An encryption key. A rotated log file. Usually owned by a user ID that does not match whatever identity your copy is running as. Nothing is broken. It is one or two files with different ownership than everything around them.

Fix: if a permission fix from inside the container does not stick, make the change directly on the NAS instead, then re-run that one file's copy. Not sticking is very common NFS behavior. The client-side change appears to succeed and never takes effect on the NAS. Always re-diff afterward to confirm a clean, complete match before the swap step. One fixed file is no proof everything else copied cleanly.

Verify before you trust it

Do not just check that the container starts. Confirm the app is running with its real data:

Check the app's own startup logs for a clean boot with no new-install indicators.
Hit the app's web UI and confirm a real response, not just "something is listening".
Spot-check a piece of data you know should be there through the app's own interface. An existing setting, a historical record.

Once every app is confirmed working on its new storage, leave the old bind-mounted copies in place for a few days as a rollback safety net before you clean them up. That caution applies to any storage migration, not just this one.