Proxmox with Local M.2 Storage: The Best Storage & Backup Strategy (No Ceph Needed) – DETECTX

If you’re building a Proxmox cluster and only want to use local M.2 NVMe storage, you’re not alone. NVMe drives offer blazing-fast performance and low latency, but they also come with a challenge: no shared storage.

That means popular options like Ceph may not be ideal — and the good news is, you don’t need them.

In this post, I’ll walk you through the best storage setup for Proxmox clusters using only local disks, and how to back up or replicate your data to central storage efficiently.

✅ Best Storage for Local M.2-Only Proxmox Clusters

🔹 Use ZFS + Proxmox Replication

Proxmox supports native ZFS replication between nodes — and it works beautifully with NVMe SSDs. Here’s why it’s the best choice:

Benefits of ZFS Local + Replication:

No need for shared SAN or Ceph
Native support in Proxmox GUI
Efficient snapshot-based replication
Fast local performance (near bare-metal)
Built-in data integrity via checksums

How It Works:

Each node runs Proxmox with ZFS on its local M.2 drive (e.g., rpool).
VMs are stored locally and replicated to other nodes using scheduled snapshots.
If one node fails, you can boot the VM on the replica node.

Limitations:

No live migration (since disks aren’t shared)
No automatic HA (manual or scripted failover only)

Still, for most users — especially in small to medium Proxmox clusters — this setup offers the best of simplicity, speed, and resilience.

🔄 Can You Back Up ZFS to Central Storage? Yes — Here’s How

Even if all your data lives on local ZFS disks, you can still back up and replicate to central storage using these options:

🔸 1. Native ZFS Send/Receive to Backup Server or NAS

ZFS includes send and receive commands to efficiently replicate datasets or snapshots over SSH.

Example:

bashCopyEdit# Take a snapshot
zfs snapshot rpool/data/vm-100-disk-0@snapshot1

# Send it to your backup server over SSH
zfs send rpool/data/vm-100-disk-0@snapshot1 | ssh backupserver zfs receive backup-pool/vm-100

This method is:

Incremental
Fast
Deduplicated
End-to-end ZFS

You can automate it with tools like Sanoid and Syncoid, or use cron jobs.

Ideal Target: Any server running ZFS (TrueNAS, Ubuntu, Debian, etc.)

🔸 2. Use Proxmox Backup Server (PBS)

If you want a fully supported solution with a GUI, encryption, and deduplication — use Proxmox Backup Server (PBS).

It’s tightly integrated with Proxmox and designed to back up:

VMs
Containers
Snapshots

Steps:

Set up PBS on a spare server or NAS.
Add PBS as a storage backend in Proxmox.
Schedule VM backups via GUI or CLI.

It supports:

Incremental backups
Pruning
Compression
Encryption

🔸 3. Use rsync to a NAS or Remote Server

For less complex setups, you can use rsync to copy ZFS snapshots or raw VM files to a central backup location.

Pros:

Works with any type of storage (ext4, NTFS, ZFS, etc.)
No need for ZFS on the target

Cons:

No deduplication
Less efficient than ZFS send
Higher disk and network usage

🔸 4. Mount Central Storage as NFS or iSCSI

If you have a central storage server (like TrueNAS), you can expose it over:

NFS (for backup files, templates, etc.)
iSCSI (for block-level VM disks)

Then mount it in Proxmox and either:

Back up VMs to that storage
Use it as a remote ZFS replication target

🔚 Summary: Best Practice for Proxmox + Local M.2 Drives

Goal	Recommended Approach
Fast local VM performance	ZFS on M.2 drives
Cluster without Ceph	ZFS + Proxmox replication
Backup to central storage	ZFS send/receive or Proxmox Backup Server
Simple remote copy	rsync or mounted NFS share

Bottom line: You don’t need Ceph for small or medium clusters if you have fast local disks.
ZFS gives you reliability, replication, and flexibility — and it plays perfectly with Proxmox’s native tools.

Option 1: Add Shared Storage (for true Live Migration)

If you want true live migration (zero downtime), then one of your nodes must expose shared storage, such as:

🔹 1. Add NFS over ZFS from one node (or NAS)

Node A exports a ZFS dataset via NFS.
Mount it on Node B, C, etc.
Store VMs on that shared storage.

🔹 2. Use iSCSI + ZFS ZVOL (via TrueNAS or targetcli)

Use a central ZFS system (like TrueNAS) to export block devices over iSCSI.
Proxmox nodes mount iSCSI as shared storage.

🔹 3. Use GlusterFS or LVM over iSCSI

Set up GlusterFS for shared volumes across local drives (complex).
Or set up LVM over iSCSI (block-level access).

💡 These let all nodes access the same VM disk, enabling live migration without copying the disk.

❗ If You Can’t Use Shared Storage: Use “Semi-Live” Migration

You still have two options without shared storage:

✅ Option 2: Use Proxmox Replication + Manual Failover (Cold Migration)

Proxmox’s ZFS replication lets you:

Schedule snapshot replication (e.g., every 5–15 min).
Quickly start a VM on a different node if needed.

🟡 This is not live migration — but downtime can be very low (15–30 sec).

🔧 Steps:

Enable ZFS replication from Node A → Node B: bashCopyEditpvesh create /nodes/A/qemu/100/replication --target B --schedule "*/5"
Stop the VM on Node A.
Start it on Node B using the replicated copy: bashCopyEditqm start 100 --node B

✅ Option 3: Migrate with Disk Copy (One-time Live Migration)

Proxmox supports live migration with local disks, but it will:

Copy the entire disk over the network during migration
Cause high I/O and network usage
Take time (depending on disk size)

🔧 Enable Live Migration with Local Storage:

In Proxmox GUI:

Go to Datacenter > Options > Migration settings
Set:
- Migration type: Secure
- Migration network: your faster NIC (10GbE preferred)
- Enable live migration with local storage

Then run:

bashCopyEditqm migrate 100 target-node --online

🟠 Not recommended for large VMs or regular usage — but OK for occasional moves.

📌 Summary

Goal	Method	Downtime	Storage Required
✅ True Live Migration	Use NFS/iSCSI shared storage	~0 sec	Shared
🟡 Semi-Live Failover	ZFS Replication + Manual Start	15–30s	ZFS Local
🟠 Disk Copy Live Migration	Live Migrate with Local Storage	Minutes	Local

🔧 Best Hybrid Approach (If You Want Live Migration Occasionally)

Use local ZFS + replication for 95% of the time.
Enable local-disk live migration for occasional needs.
Or expose one node’s ZFS as NFS, mount it on others, and store critical VMs there.