A Sane Proxmox Storage Plan: TrueNAS, LXC, NFS, and Backups Without Overlap

Proxmox storage gets dangerous at exactly the moment it gets interesting: you add a TrueNAS VM for your pool, bind some datasets into LXC containers over NFS, and point Proxmox Backup Server at "the NAS." Now four layers all have an opinion about the same physical disks, and the failure modes — a backup job that deadlocks against the VM serving its own target, a pool that won't import because two systems claimed it — are nasty precisely because they only show up under load. The fix is a storage plan, decided before you create the pool.

Decide who owns the disks — exactly one thing

The cardinal rule: one system owns each physical disk, full stop. The usual mistake is letting Proxmox's ZFS and a TrueNAS VM both think they manage the same drives.

• If TrueNAS owns the pool, pass the HBA/controller through to the TrueNAS VM (PCIe passthrough), so Proxmox never touches those disks. TrueNAS sees real hardware; Proxmox sees none of it.
• If Proxmox owns the pool, build ZFS on Proxmox and don't also virtualize TrueNAS on the same disks. Run TrueNAS only if it has its own dedicated controller and drives.

Half-passthrough (handing TrueNAS virtual disks backed by a Proxmox ZFS pool) is the configuration that bites — you get ZFS-on-ZFS, double caching, and confusing performance. Avoid it.

Map the layers top to bottom

Write down the stack so the dependencies are visible:

1. Physical disks → owned by one system (TrueNAS-via-HBA, or Proxmox-ZFS).
2. Datasets/pools → named by purpose: vm-store, media, app-data, backups.
3. Sharing → NFS/SMB exported from the owner to consumers.
4. Consumers → VMs and LXC containers that mount the shares or use bind mounts.
5. Backups → Proxmox Backup Server with a target that is not served by a VM that PBS also backs up.

That last point prevents the classic deadlock: don't make PBS write its backups to an NFS share exported by the very TrueNAS VM that PBS is trying to back up. Give backups an independent target — a separate disk, a separate box, or off-site.

LXC bind mounts vs NFS

For containers on the same host as the storage, bind mounts are simpler and faster than looping back through NFS. Reserve NFS for cross-host access. Mixing both for the same data ("bind mount here, NFS there") leads to permission drift and uid/gid mismatches between the host and the container.

Backups are a separate failure domain

Treat backups as their own layer with its own rules:

• The backup target must survive the loss of the thing it backs up. Same pool ≠ a backup.
• Snapshots are not backups — a zfs destroy or pool failure takes the snapshots too.
• Rehearse a restore before you rely on it. A restore drill applies just as much to a TrueNAS dataset as to a Docker volume.

Plan checklist

• Exactly one system owns each physical disk (HBA passthrough if TrueNAS).
• No ZFS-on-ZFS; no half-virtualized pools.
• Datasets named by purpose, not by app-of-the-week.
• Bind mounts for same-host LXC; NFS only across hosts.
• PBS target independent of the VM/host it protects.
• A restore rehearsed at least once.

When you're sizing the host itself for all of this — and deciding whether some workloads belong on a cheap cloud VPS instead — a real benchmark, not the spec sheet, tells you what the hardware can actually carry. Decide the storage plan first; the rest of the Proxmox build gets much calmer once the disks have one clear owner.