pve-bindsnap

pve-bindsnap

Snapshot and clone Proxmox LXC containers that have bind-/device-mounts (mpN entries pointing at host paths). Proxmox greys snapshots out and refuses the clone; this overlay enables both again, delegating to Proxmox's genuine snapshot and clone code rather than forking it.

Release 1.1.0. It passes the unit tests and has been exercised on Proxmox VE 9.2 / 9.3 (pve-container 6.1.10) across the full install lifecycle and matrix: create / rollback / delete (including a data-level rollback), the BINDSNAP-FORCE-RUNNING, BINDSNAP-UNSUPPORTED and BINDSNAP-EXCLUDE paths, each both per-snapshot and as a standing CT-Notes directive, plus the known-bad hard block, and it runs in the author's own production cluster. pct clone of a bind-mount container is covered too (the binds are carried to the clone, BINDSNAP-EXCLUDE drops them), gated by its own checksum so an untested build falls back to stock. It hasn't been run against other pve-container versions yet, so on a build it doesn't recognise it refuses by default until you opt in. It's a small, commented overlay: read the source and the test plan before you deploy.

The risks are low: the wrapper loads the overlay eval-guarded (a bug in it just falls back to stock), the installer pre-flights and rolls back on failure, uninstall.sh restores stock cleanly, and containers without bind/device mounts are never touched. So please try it on other Proxmox / pve-container versions and report back on the issues page, whether it worked or not, with the version and combined checksum the overlay prints, so the tested set can grow and known-bad builds get flagged.

Why?

Add a bind mount to a container and Proxmox stops letting you snapshot it. The check it runs is "can every mountpoint be snapshotted?", and a bind mount (just a host path) can't, so the whole container loses its snapshot button. That happens even when the real rootfs sits on ZFS and would snapshot fine on its own.

The overlay hides the bind and device mounts from the snapshot code path, and only from that path. Your Proxmox-managed volumes are still snapshotted exactly as they would be normally; only the bind/device mounts are skipped, and their data on the host is left untouched.

What's in the container config	In the snapshot?	In a clone?	Notes
rootfs (the root disk)	Yes	Yes (copied)	Proxmox-managed volume; always kept
mpN: a storage volume	Yes, unless excluded	Yes (copied)	Managed volume (e.g. a data disk)
mpN: a bind mount (host path)	No (setting kept)	Carried, unless excluded	Only the mount setting is snapshotted/cloned and restored on rollback; the host data is never snapshotted, cloned, or rolled back
devN: a passthrough device	No (setting kept)	Carried	Only the mount setting is snapshotted/cloned and restored on rollback; the host device/data is never snapshotted, cloned, or rolled back

So a storage-backed data disk on mp1 is captured right alongside the rootfs, while a /mnt/... bind mount stays out of the snapshot, even if the path behind it happens to sit on ZFS. Everything else Proxmox does carries on unchanged, backups (vzdump) included.

A snapshot never drops a bind/device mount. Only the mount setting (the mpN/devN line in the config) is stored in the snapshot and restored on rollback -- the overlay just hides it from the volume-snapshot step so Proxmox doesn't try to snapshot a host path. The data behind the bind is never snapshotted, cloned, or rolled back: a rollback rewinds the managed volumes (rootfs and volume disks), but the host data behind a bind/device mount stays exactly as it is now, untouched. So the outcome for the mount is the same either way -- snapshot and rollback, or clone, both restore/carry the setting pointing at the live host path; only the managed volumes are ever copied or rewound, never the bind data.