Proxmox / Backups / Docker

Get Your Docker App Configs Actually Backed Up

A common homelab pattern — running each app in its own container with its config folder bind-mounted from a NAS over NFS — works great right up until you check whether it's actually being backed up. It usually isn't. Here's why, and how to fix it without losing anything.

The invisible gap

Most VM/container backup tools (Proxmox Backup Server included) back up disk images — the virtual disk attached to a VM or container. A raw NFS bind-mount pointing at a folder on your NAS isn't a disk image at all; it's just a path the container happens to read and write through. Your backup tool has no idea it exists, so an app's entire configuration — quality profiles, credentials, indexer settings, months of tuning — can be completely unprotected while every other VM on the same host is faithfully backed up nightly. The setup looks complete (backups are running, green checkmarks everywhere) right up until you actually need to restore one specific app and discover its data was never in scope.

Check for this specifically — don't assume. A real case: five separate applications had been running this exact way for months, all confirmed "working" in every visible sense, with zero backup coverage for any of their config data the entire time. Nothing failed or errored; the gap was just 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

This provisions a real disk image on your NAS via your hypervisor's own storage layer — formatted normally, mounted like local storage inside the container — rather than a bare NFS path. The backup=1 flag is what actually 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 staged at a temporary mount path, so the original bind-mount stays fully intact the whole time — nothing about the old location changes yet.
Copy the data across, then diff the two locations to confirm they're identical before trusting the copy:
```
diff -rq /config /mnt/newconfig
```
Only once confirmed identical: detach the old bind-mount reference (harmless — it's just removing a config line, the original folder is untouched) and repoint the same new disk at the real config path.
Restart the app and 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 actual settings are there.

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

Expect at least one file per app to fail with a permission error mid-copy. Long-running apps often 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 specific user ID that doesn't match whatever identity your copy operation is running as. This isn't a sign anything is broken; it's just one or two files with different ownership than everything around them.

Fix: if a permission fix from inside the container doesn't stick (a very common NFS behavior — the client-side change appears to succeed but doesn't actually take effect on the NAS), make the permission change directly on the NAS itself instead, then re-run just that one file's copy. Always re-diff afterward to confirm a truly clean, complete match before moving on to the swap step — don't assume one fixed file means everything else copied cleanly too.

Verify before you trust it

Don't just check that the container starts — confirm the app is actually 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 (an existing setting, a historical record) through the app's own interface.

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 cleaning them up — the same caution worth applying to any storage migration, not just this one.