How I Declustered My Proxmox Setup Without Data Loss

In my previous article, I walked through building a Proxmox cluster using two main nodes (a Dell Optiplex and a MeLE Fanless N100) and a Raspberry Pi 4 as a QDevice. After putting the system through rigorous High Availability (HA) stress tests, it performed beautifully.

However, a true test of reliability isn’t just about how a system stays up — it’s about how gracefully it can be taken apart. I decided to “decluster” my setup to see if my data would remain intact when reverted to standalone nodes. Luckily, the process worked perfectly, and my data remained untouched.

If you want the deep dive, you can check the official documentation below. Otherwise, here is exactly how I handled the decluster procedure for my specific hardware.

[embed]Proxmox VE Administration Guide The installer will guide you through the setup, allowing you to partition the local disk(s), apply basic system…pve.proxmox.com

Phase 1: Removing The QDevice

Since I was using a Raspberry Pi 4 as a lightweight voter (QDevice), I had to remove it first. If the main nodes lose that third “vote” unexpectedly, they might panic and reboot to protect data integrity.

On my main node (Optiplex and Mele):

pvecm qdevice remove

On the Raspberry Pi 4: Clean up the services and purge the packages so the Pi stops trying to communicate with a cluster that no longer exists:

sudo systemctl stop corosync-qnetd
sudo apt purge -y corosync-qnetd corosync-qdevices
sudo rm -rf /etc/corosync/qnetd /etc/corosync/qdevice

Phase 2: High Availability (HA) Lockdown

This is the most sensitive step. If HA is still active, Proxmox will try to “save” VMs by migrating them to nodes that are being disconnected, which often leads to a loop of fencing reboots.

I ran this on BOTH nodes:

# Stop and disable the HA managers
systemctl stop pve-ha-lrm pve-ha-crm
systemctl disable pve-ha-lrm pve-ha-crm

# Clear the HA configuration files
echo "" > /etc/pve/ha/resources.cfg
echo "" > /etc/pve/ha/groups.cfg

Phase 3: The Core Decluster

Now, I needed to tell each node it was an individual again. This involves stopping the cluster filesystem (pmxcfs) and forcing it into local mode. I performed these steps on one node at a time:

Stop Cluster Services & Force Local Mode:

systemctl stop pve-cluster corosync
pmxcfs -l

Wipe Cluster Networking:

rm /etc/pve/corosync.conf
rm -rf /etc/corosync/*

Restart the Filesystem:

killall pmxcfs
systemctl start pve-cluster

Phase 4: Cleaning the “Ghost” Folders

After the split, the Proxmox GUI will still show an “Offline” ghost of the former partner node. To clean this up, you must manually delete the remote node’s configuration folder.

⚠️ CRITICAL WARNING: Never try to run rm -rf /etc/pve/nodes by itself. That will delete the VM configurations for the node you are currently using!

On my MeLE N100 (to remove the Optiplex entry):

rm -rf /etc/pve/nodes/pve-optiplex

On my Dell Optiplex (to remove the MeLE entry):

rm -rf /etc/pve/nodes/pve-n100

Phase 5: Final Housekeeping

In my previous setup, I used the MeLE node as a Proxmox Backup Server (PBS) and shared a network store with the Dell Optiplex. To ensure both nodes worked perfectly as standalone units, I finished with two steps:

• Storage Settings: Navigate to Datacenter > Storage. Uncheck the “Shared” box for any local disks (ZFS, LVM). If Proxmox thinks a local disk is shared, it may fail to start VMs while searching for a non-existent network mount.
• SSH Handshaking: Clear the old cluster keys to avoid “Host Key Verification” errors when SSHing between nodes later:

truncate -s 0 /etc/pve/priv/known_hosts

The Result

My main Proxmox server is now a clean, standalone node with all data intact. The MelE PBS node and the Pi 4 are also running independently without issues.

Summary: Building a home lab is about more than just uptime; it’s about understanding the mechanics of your environment. This “Safe Divorce” procedure allowed me to reorganize my hardware without a single byte of data loss.