Cyber recovery vs disaster recovery: why replication alone leaves Proxmox clusters exposed

Cyber recovery and disaster recovery solve two different failure modes in infrastructure. Disaster recovery restores uptime after hardware crashes, power outages, or site loss, assuming the underlying data is clean and valid. Cyber recovery assumes an attacker has compromised administrative credentials, disabled system logs, and deliberately corrupted live replicas.

Most homelabs and small clusters rely on continuous replication to keep recovery time low. That design works during a power failure, but it accelerates data loss during an attack.

Why disaster recovery tools fail during an attack

Disaster recovery systems prioritize speed and low recovery point objectives. In a Proxmox cluster, storage replication sends ZFS snapshots to a secondary node every few minutes. High availability daemons monitor node heartbeats to restart failed virtual machines immediately.

When ransomware enters a virtual machine, those same automated mechanisms work against the operator. Encrypted files write to disk, generate dirty blocks, and replicate to secondary storage before monitoring alerts trigger. By the time an administrator detects the compromise, both the primary volume and the replicated failover target hold encrypted data.

If an intruder obtains administrative credentials to the Proxmox VE management interface, disaster recovery tools provide no resistance. An attacker can destroy replication tasks, delete local storage pools, and purge cluster configurations in seconds.

The four requirements of cyber recovery

A viable cyber recovery design introduces friction on purpose. While disaster recovery minimizes human intervention, cyber recovery relies on air gaps and access controls.

First, backups must use pull-based transfers. The backup repository contacts the production hypervisor to retrieve data, rather than allowing the hypervisor to write directly to the backup target. If a Proxmox host is compromised, the host holds no credentials to alter or delete existing snapshots on the backup server.

Second, the storage must enforce immutability. On Proxmox Backup Server, setting datastore tokens to append-only mode prevents client nodes from pruning older snapshots. Even if an attacker issues a purge command from the hypervisor, the backup server rejects the deletion until the configured retention window expires.

Third, the recovery environment requires network isolation. Testing backups or restoring a suspicious guest must occur on an isolated network bridge with no route to production networks. If a restored machine still hosts an active command-and-control beacon, the isolation prevents lateral movement.

Fourth, verification must test actual guest operation. Checking chunk hashes proves that the backup storage is readable, but it does not prove the guest can boot without malware active. Automated boot tests help verify operating system integrity before an emergency forces a restore.

Building an isolated tier on Proxmox

Homelab and small business environments can implement cyber recovery without purchasing proprietary enterprise platforms.

A practical implementation uses a dedicated Proxmox Backup Server instance running on distinct physical hardware, separated from the cluster API network. The backup server operates an isolated datastore and pulls snapshots over a restricted management subnet.

For offsite resilience, a secondary PBS instance located off-premises pulls datastore sync jobs from the primary backup server. The offsite node exposes only its SSH or PBS port to the primary node, preventing bidirectional administrative access.

To protect critical configuration data, administrators should regularly export cluster configuration archives and offline encryption keys to removable media stored in a physical safe. If the entire cluster configuration is erased, the offline keys allow the administrator to rebuild nodes and attach directly to the backup datastore.

The operational trade-off

Disaster recovery measures success in minutes of downtime. Cyber recovery measures success in data survival and forensic integrity.

An isolated backup architecture takes longer to configure, requires dedicated storage capacity, and increases the time required to perform large-scale restores over bandwidth-constrained links. In exchange, it ensures that an administrative compromise on a hypervisor does not destroy the organization's last copy of its data.