Proxmox backup on an unprivileged LXC container with bind-mounted NAS datasets backs up the container’s rootfs and configuration, but it silently skips the bind-mounted data. The backup task completes with a green checkmark, and you won’t know the media files are missing until you need them.
What the backup actually contains
When you run a backup of an LXC container in Proxmox VE, the default mode is snapshot. The backup process creates a temporary snapshot of the container’s filesystem, then streams that snapshot to the backup storage. For an unprivileged container, the rootfs lives in a subvolume or directory on the host, typically under /var/lib/vz/images/<vmid>/ or a ZFS dataset. The snapshot captures everything inside that rootfs: the operating system, installed packages, configuration files in /etc, and any data written to the container’s writable layers.
The key phrase is “inside that rootfs.” A bind mount is not inside the rootfs. It’s a mount point that points to a directory on the host or a network share. When the snapshot is taken, the bind mount is not followed. The backup tool sees the mount point as an empty directory or as a directory with whatever was there before the bind mount was applied. The actual data on the TrueNAS dataset is not included.
This is documented behavior, but it’s easy to miss. The Proxmox wiki mentions that bind mounts are not included in backups unless you use stop mode and configure the backup to include additional mount points. Even then, the backup of a bind mount is not a simple file copy; it’s a separate archive that you have to restore manually.
Why it looks successful
The backup task itself doesn’t fail. It creates the snapshot, reads the rootfs, and writes the archive. The bind mount is simply ignored. The task log shows no errors, no warnings, nothing to indicate that a large chunk of your data was left behind. If you’re backing up a Plex or Jellyfin container, the media library might be hundreds of gigabytes, but the backup archive is only a few gigabytes. That’s the first clue that something is off.
I’ve seen this happen on my own setup. I have a few unprivileged LXC containers that bind-mount TrueNAS datasets for Plex and Jellyfin, as described in my earlier post on sharing TrueNAS datasets with unprivileged LXC containers. The containers themselves are small—just the media server software and its config. The media lives on the NAS. When I first set up backups, I assumed the whole thing was being protected. It wasn’t.
What PBS does and doesn’t do
Proxmox Backup Server (PBS) works the same way for LXC containers. It uses the same snapshot mechanism under the hood. PBS has some advantages—deduplication, incremental backups, encryption—but it still only sees the rootfs. If the bind mount is not part of the rootfs, PBS won’t back it up. There’s no setting in PBS to include arbitrary mount points from a container backup. You can back up the host directories separately if you install the PBS client on the host, but that’s a different workflow.
One thing PBS does well is verify the integrity of what it does back up. The verify job checks the chunks in the datastore, and you can set up garbage collection to remove unused chunks. But none of that helps if the data was never included in the first place. The verification will pass because the missing data isn’t part of the backup set.
How to actually back up the bind-mounted data
The straightforward fix is to back up the TrueNAS dataset separately. TrueNAS has its own backup tools—snapshots, replication, cloud sync. You can schedule snapshots on the TrueNAS side and replicate them to another TrueNAS system or to a cloud provider. That protects the media files independently of the Proxmox backup.
If you want everything in one place, you can run a backup job on the Proxmox host that mounts the TrueNAS share and copies the data to your backup storage. This could be a simple rsync job in cron, or you could use a tool like restic or borg to create versioned backups. The key is that this job runs on the host, not inside the container, and it targets the NAS data directly.
Another option is to use stop mode backups with --include mount points. In stop mode, the container is shut down before the backup, and the backup tool can include additional mount points that are listed in the container configuration. This is more disruptive because the container is offline during the backup, and the restore process is more manual. You have to extract the mount point archive separately and place it back on the NAS. For a media server that’s running 24/7, this isn’t practical.
What I’d recommend
For a homelab, the cleanest approach is to treat the container and the data as separate backup domains. Use Proxmox backup for the container rootfs—it’s small, changes infrequently, and the backup is quick. Use TrueNAS snapshots and replication for the media datasets. This way, each backup tool does what it’s good at, and you don’t have to fight the limitations of bind mounts.
If you’re using PBS, you can still back up the container rootfs to PBS and use a separate job for the NAS data. PBS doesn’t have a built-in way to back up arbitrary host directories, but you can install the proxmox-backup-client on the TrueNAS host or on the Proxmox host and use it to back up the dataset. The client supports file-level backups with deduplication, so it’s efficient for large media libraries. You’d set up a cron job that runs the client against the mounted dataset and stores the backup in the same PBS datastore. That gives you a single backup target with different backup types.
One thing to watch out for: if you’re using NFS for the bind mount, the backup job on the host might fail silently if the NFS share is unreachable. I wrote about that in NFS backup storage fails silently. The same principle applies here—make sure your backup job checks for mount availability before running, and log the output so you can see failures.
Restoring from a container backup
When you restore a container from a Proxmox backup, you get the rootfs back. The bind mount is not restored—it’s a configuration entry that points to a host directory or network share. After restore, you need to recreate the bind mount in the container configuration. The data on the NAS is untouched, so if you have a separate backup of that data, you’re fine. If you don’t, the restore gives you a working container with an empty mount point.
This is where the separation of concerns pays off. The container backup gets you back to a running state quickly. The NAS backup gets you your media back. You restore them independently, and you don’t have to worry about one giant archive that contains everything.
What about immutable backups?
If you’re using PBS with a datastore that has immutable set, the container backups are protected from ransomware deletion for the duration of the immutability window. But again, that only applies to what’s in the backup. The NAS data is not in the PBS backup unless you explicitly back it up with the client. If you want immutability for the media files, you need to set up a separate immutable backup job on the TrueNAS side or use a cloud provider with object lock. I covered some of the practical limits of immutability in immutable backup on Proxmox. The short version: it’s doable, but you have to plan for it.
Final thoughts
The takeaway is simple: a Proxmox backup of an LXC container with bind mounts is not a backup of everything the container can see. It’s a backup of the container’s own filesystem. The bind-mounted data lives outside that filesystem, and it’s your job to back it up separately. The backup task won’t warn you, and the restore won’t fail—it’ll just be missing data. Check your backup sizes. If your media container backup is suspiciously small, you know why.
If you’d rather pay for this
If you don’t want to manage separate backup jobs for containers and NAS data, a commercial backup solution might be worth it. Veeam Backup & Replication Community Edition is free for up to 10 workloads and can back up Proxmox VMs and containers, but it has the same limitation with bind mounts—it backs up the VM disk, not external mounts. For NAS data, you’d still need a separate file-level backup. Veeam’s paid versions add more features, but the pricing model is per-socket or per-instance, which gets expensive for a homelab.
Another option is a cloud backup service like Backblaze B2 with a tool like Restic or Duplicacy. You pay per TB stored per month, and at the time of writing, Backblaze B2 is around $6 per TB per month. That’s reasonable for a few terabytes of media, but it adds up if you have a large library. For a homelab, the free tools—TrueNAS snapshots, Proxmox backup, and a cron job with rsync—are usually enough. You just have to remember that the container backup and the data backup are two different things.
