Storage support matrix
Last updated: October 2026
Read this first
Each backing below carries a validation status (validated end-to-end, a documented caveat, or in validation), so you can match Asternodis to your storage with confidence.
Every Validated status is earned on a live two-site deployment, not inferred from the code path. That rigor is
deliberate: CIFS/SMB, for one, needs cache=writeback because
Proxmox's default cache=none path can seed a replica that
reports success yet won't boot, exactly the kind of silent failure a DR product has to catch before
you do. Each backing is qualified on its own results, never assumed equivalent to another.
Virtual machines: source disk
A VM's disk is read through QEMU's own block layer over blockdev-backup,
so replication is storage-agnostic: every backing below travels the identical path. What differs is
failback: putting the workload back needs a writable rollback net on the home disk, and each
backing provides that differently.
| Backing | Replicate · fail over · DR test | In-place failback | Status |
|---|---|---|---|
| ZFS zvol block | Yes | Incremental reverse lane, always on | Validated Primary path. |
| LVM-thin block | Yes | Thin-snapshot rollback net (on by default) | Validated |
| Ceph / RBD block | Yes | Object-copy rollback net (on by default) | Validated |
| dir (qcow2 / raw) file | Yes | qcow2 overlay chain (on by default) | Validated VM and container. |
| NFS file | Yes | qcow2 overlay chain (on by default) | Validated VM and container. |
| CIFS / SMB file | Caveat | In validation | Caveat Replication, failover, DR test and recovery points validated. Requires cache=writeback (see below). |
| LVM thick (single-node, incl. iSCSI LUN) block | Yes | Incremental reverse lane (activates the home LV first) | Validated Proven on a live two-site iSCSI deployment: a guest run at the recovery site returns home shipping only the failover delta (seconds, not a whole-disk copy) and keeps its recovery points. A stopped guest's thick LV has no device node, so the lane activates it before it reads or writes; from there it is the same incremental reverse lane ZFS and LVM-thin use. |
| LVM thick (shared / clustered) block | In validation | Refused, by design | By design A volume group shared across the cluster (a SAN or FC/iSCSI LUN visible to every node) is the one shape still refused for in-place failback: a snapshot there rewrites volume-group metadata every node shares, which is only safe under Proxmox's own cluster storage lock. The preflight refuses before you fail over, not after. The only way home is then Abort failover, which returns the guest to its pre-failover disk at the primary and discards whatever it wrote at the recovery site. |
Containers (LXC): rootfs
Containers get full parity with VMs: replication, non-disruptive DR testing, failover and failback. Proxmox's own replication covers ZFS only.
| Backing | Transport | Status |
|---|---|---|
| ZFS (subvol) | zfs send / recv | Validated |
| dir · LVM-thin | rsync (block LVs snapshot-mounted read-only) | Validated |
| LVM (thick) | rsync (LV snapshot-mounted read-only) | In validation |
| NFS | rsync | Validated |
| CIFS / SMB | rsync | Validated |
| Ceph / RBD | rbd snap → protect → clone → krbd map clone → mount ro → rsync | Validated |
Recovery site: where the DR copy lands
| Recovery storage | Shadow form | Status |
|---|---|---|
| ZFS (zfspool) | Allocated zvol, served raw over qemu-nbd | Validated |
| LVM-thin | Thin LV, served raw over qemu-nbd | Validated |
| dir / NFS | qcow2 file | Validated |
| Ceph / RBD | rbd image, krbd-mapped, served raw over qemu-nbd | Validated |
| CIFS / SMB | qcow2 file | Caveat Replication validated; recovery points, DR test and failover in validation. The cache=writeback caveat below concerns a CIFS source disk, not a shadow. |
| CephFS | qcow2 file, via a dir storage over the mountpoint | Validated |
Restore in place: every backing above
The failback column answers "how does a guest running at the recovery site come home". A different question ("put this guest back to how it was on Tuesday, where it already runs") is answered by Restore in place, which rewrites the guest's own disks at the primary from a recovery point. No failover, no site change, no second operation afterwards to undo the first.
It is supported on every VM home backing on this page (ZFS, LVM-thin, Ceph/RBD, and directory, NFS and CIFS alike), because it writes the disk from a point rather than streaming deltas into it, so it needs none of the rollback machinery in-place failback does. Two limits worth knowing: it is VM guests only for now, not containers, and it needs the primary healthy and the guest at home, so a guest that is already failed over is told to use failback instead before anything is stopped.
CephFS: validated, via a directory storage over it
A storage of type cephfs cannot hold a DR copy: Proxmox's CephFS
plugin supports backup, iso,
snippets and vztmpl, not
images. That is a limit on the storage type, not on CephFS: point a
dir storage at the CephFS mountpoint and Asternodis treats it as any
other path-backed storage.
Set up that way, the full round trip has been run end to end for a VM: seed, recovery-point capture (verified against the qcow2's own internal snapshot), DR test booted and serving, failover, and failback home with a scoped verify. No qcow2 locking problems, no stalls.
Three things to know before you choose it. A dir storage is not
marked shared, so a multi-node recovery cluster will not treat one mountpoint as a single storage the way a
native CephFS storage would. Plan the node mapping deliberately. The DR copy is never booted from
CephFS: a DR test or failover converts it to a raw volume on block storage first, so CephFS is where the
replica and its points live at rest, not where the recovered guest runs. And it is a
VM option only: a container's replica arrives as ZFS
subvolumes, so containers need a ZFS pool whatever the rest of your storage looks like.
The one backing with a real caveat: CIFS / SMB
Proxmox creates CIFS-backed disks with cache=none. On that path a
live seed can complete, report success at every layer, and leave a replica that will not boot, which is
the worst failure mode a DR product can have, because nothing tells you. Set the disk to
cache=writeback and the lane is validated for replication, failover,
DR testing and recovery points. Failback from a CIFS home is still in validation.
Thick LVM and iSCSI used to be refused for in-place failback outright: no native snapshot, no rollback net. That is no longer true for a single-node thick volume group: the reverse lane activates the stopped guest's thick LV, then ships and verifies only the failover delta, so these backings now fail back in place and incrementally, proven on a live two-site iSCSI deployment. The one shape still refused is a thick volume group shared across the cluster (a SAN or FC/iSCSI LUN visible to every node): a snapshot there rewrites volume-group metadata every node shares, which is only safe under Proxmox's own cluster storage lock, so the preflight refuses before you fail over, not after. The only way home is then Abort failover, which returns the guest to its pre-failover disk at the primary, discarding whatever it wrote at the recovery site.
What "validated" means
A backing is marked validated when a guest on it has been replicated, DR-tested, failed over and recovered across two live Proxmox sites, and the recovered guest was confirmed by serving its own identity page, not merely by booting. A guest that boots is not necessarily your guest, at the point you expected, with the data you expected.
Coverage spans every validated backing above, VMs and containers alike, including UEFI with vTPM and Windows Server 2025.
Running a backing marked in validation, or one not listed? Tell us, and the free, full-featured trial lets you prove it in your own environment either way.