Perfect Homelab [E10] : Cluster Proxmox HA - Migration PBS et préparation

Le problème de départ : pourquoi la HA ne fonctionnait pas

#

Mon cluster Proxmox MATRIX est composé de deux nœuds locaux :

• Morpheus — ASRock H670M-ITX, i3-13100, 64 Go RAM, 2x NVMe Crucial P5 Plus 1 To en ZFS mirror
• Neo — Intel NUC7i3BNH, i3-7100U, 32 Go RAM, 1x SSD SATA Crucial BX500 1 To en LVM

La Haute Disponibilité (HA) sous Proxmox repose sur un principe fondamental : le stockage doit être partagé entre les nœuds. Quand un nœud tombe, l’autre doit pouvoir accéder aux disques des VMs pour les redémarrer automatiquement.

Or avec du stockage local hétérogène (ZFS sur Morpheus, LVM sur Neo), impossible de faire de la réplication native Proxmox. La réplication ZFS de Proxmox exige ZFS des deux côtés.

Les options envisagées

#

La solution la plus propre et la plus rapide à mettre en place : migrer Neo vers ZFS pour utiliser la réplication ZFS native de Proxmox, sans dépendance tierce. Mais avant de toucher à Neo, il fallait résoudre un problème d’architecture plus fondamental.

Le problème architectural : Proxmox Backup Server (PBS) en bare metal sur Neo

#

En auditant l’infrastructure, j’ai identifié une mauvaise pratique que j’avais mise en place à mes débuts : Proxmox Backup Server tourne en bare metal sur Neo, sur le même OS que PVE.

Neo (bare metal)
├── Proxmox VE (PVE:8006)
├── Proxmox Backup Server (PBS:8007)  ← problème
│   └── /mnt/backups (429 Go, 132 Go utilisés)
├── LXC 230 - Smarthome (32 Go)
└── LXC 253 - Technitium DNS fallback (8 Go)

Les conséquences de cette architecture :

• Couplage fort : réinstaller PVE détruit PBS et son datastore
• PBS sauvegarde son propre hôte : fiabilité discutable
• Pas d’isolation : PBS et PVE partagent RAM, CPU, disque
• SPOF (Single Point Of Failure) : si Neo tombe, on perd simultanément un nœud PVE et la destination de backup

Architecture cible

#

PBS doit être indépendant de ce qu’il sauvegarde. La bonne pratique avec mon architecture : PBS dans un LXC dédié sur Morpheus, avec son datastore sur le pool ZFS NVMe.

Morpheus
└── LXC 107 - PBS (10.10.10.7)
    └── datastore → rpool/pbs-datastore (ZFS, 632 Go)

Neo (après migration ZFS)
├── LXC 230 - Smarthome (32 Go)
└── LXC 253 - Technitium DNS fallback

Étape 1 : Migration du LXC Smarthome

#

Avant de toucher à Neo, j’ai migré le LXC Smarthome (Home Assistant, MQTT, Zigbee2MQTT, Z-Wave JS) de Neo vers Morpheus avec PBS via le stockage S3 Scaleway/Garage comme point de transit — la migration directe entre les deux nœuds n’étant pas possible sans stockage partagé.

# Le SLZB-MR1U (coordinateur Zigbee/Matter/Z-Wave) est accessible
# via le réseau, pas en USB direct → migration transparente

Résultat : Home Assistant, ESPHome et surtout Zigbee2MQTT ont redémarré proprement sur Morpheus. ✅

Étape 2 : Création du dataset ZFS pour PBS

#

# Sur Morpheus
zfs create rpool/pbs-datastore
zfs list rpool/pbs-datastore

NAME                  USED  AVAIL  REFER  MOUNTPOINT
rpool/pbs-datastore    96K   632G    96K  /rpool/pbs-datastore

632 Go disponibles sur les NVMe en mirror. ✅

Étape 3 : Création du LXC PBS (ID 107)

#

Le LXC doit être privilégié (--unprivileged 0) — PBS a besoin d’accès aux vrais UIDs/GIDs pour gérer les backups correctement.

pct create 107 /mnt/iso/template/cache/debian-13-standard_13.1-2_amd64.tar.zst \
  --hostname pbs \
  --ostype debian \
  --arch amd64 \
  --cores 2 \
  --memory 2048 \
  --swap 2048 \
  --rootfs datastore-zfs:16 \
  --net0 name=eth0,bridge=vmbr0,firewall=1,gw=10.10.10.1,ip=10.10.10.7/24,type=veth \
  --features nesting=1 \
  --mp0 /rpool/pbs-datastore,mp=/mnt/datastore \
  --tags "prod;backup" \
  --unprivileged 0 \
  --password

Note réseau : pas de tag= VLAN sur net0 car le bridge vmbr0 est configuré avec bridge-vlan-default 10 — le VLAN 10 (10.10.10.0/24) est appliqué automatiquement par Proxmox pour tout LXC sans tag explicite.

Vérification de la config :

pct config 107

arch: amd64
cores: 2
features: nesting=1
hostname: pbs
memory: 2048
mp0: /rpool/pbs-datastore,mp=/mnt/datastore
net0: name=eth0,bridge=vmbr0,firewall=1,gw=10.10.10.1,ip=10.10.10.7/24,type=veth
ostype: debian
rootfs: datastore-zfs:subvol-107-disk-0,size=16G
swap: 2048
tags: prod;backup

Étape 4 : Bootstrap et installation de PBS

#

Bootstrap avec init-linux-machine

#

C’est un dépôt perso qui fournit deux modes de bootstrap pour une machine Linux fraîchement installée (RHEL/Rocky/Alma ou Debian/Ubuntu)

Allons-y :

pct start 107
pct exec 107 -- bash

# Dans le LXC
apt update && apt install -y git
git clone https://forgejo.allfabox.fr/allfab/init-linux-machine
cd init-linux-machine
chmod +x bash/init-machine.sh
./bash/init-machine.sh --create-user
# Mode interactif ici pour saisir l'utilisateur et son mot de passe
./bash/init-machine.sh --setup

Installation de PBS 4.2 (Debian Trixie)

#

Le LXC tourne sous Debian 13 Trixie — il faut le repo trixie de Proxmox :

echo "deb http://download.proxmox.com/debian/pbs trixie pbs-no-subscription" \
  > /etc/apt/sources.list.d/pbs-no-subscription.list

curl -fsSL https://enterprise.proxmox.com/debian/proxmox-release-trixie.gpg \
  -o /etc/apt/trusted.gpg.d/proxmox-release-trixie.gpg

apt update
apt install -y proxmox-backup-server

PBS 4.2.1 s’installe proprement. Les services démarrent :

● proxmox-backup.service       Active: active (running)
● proxmox-backup-proxy.service Active: active (running)

Création du datastore

#

proxmox-backup-manager datastore create Morpheus-datastore /mnt/datastore
proxmox-backup-manager datastore list

┌────────────────────┬────────────────┬─────────┐
│ name               │ path           │ comment │
╞════════════════════╪════════════════╪═════════╡
│ Morpheus-datastore │ /mnt/datastore │         │
└────────────────────┴────────────────┴─────────┘

Étape 5 : Déclaration dans Proxmox VE

#

# Récupérer le fingerprint PBS
pct exec 107 -- proxmox-backup-manager cert info | grep Fingerprint

# Déclarer le storage PBS dans PVE Morpheus
# Depuis le shell de Morpheus
pvesm add pbs morpheus-pbs \
  --server 10.10.10.7 \
  --datastore morpheus-datastore \
  --username root@pam \
  --password \
  --fingerprint <fingerprint> \
  --content backup

pvesm status | grep pbs

morpheus-pbs    pbs    active    662 Go    0% utilisé

✅

Étape 6 : Synchronisation PBS Neo → PBS Morpheus

#

L’objectif : mirorer le datastore PBS de Neo (132 Go de backups) vers Morpheus avant de réinstaller Neo en ZFS.

Créer le remote

#

# Récupérer le fingerprint PBS de Neo via SSH ou l'interface WebUI de Neo
# fingerprint-Neo
proxmox-backup-manager cert info | grep Fingerprint

# Depuis le LXC 107
proxmox-backup-manager remote create neo-pbs \
  --host 10.10.10.6 \
  --auth-id backup@pbs \
  --password <mot-de-passe-du-user-backup> \
  --fingerprint <fingerprint-Neo>

Créer le Sync Job

#

# Depuis le LXC 107
proxmox-backup-manager sync-job create neo-pbs-sync \
  --store morpheus-datastore \
  --remote Neo-pbs \
  --remote-store local-lvm-backup \
  --schedule daily \
  --remove-vanished false

Le Sync Job tire (pull) les backups depuis Neo vers Morpheus de façon incrémentale grâce à la déduplication PBS. La première synchronisation est en cours. ✅

État actuel de l’infrastructure

#

CLUSTER MATRIX
│
├── Morpheus (PVE — nœud principal)
│   ├── rpool ZFS mirror 2x NVMe (632 Go libres)
│   ├── LXC 107 - PBS 4.2.1 (10.10.10.7) ← NOUVEAU
│   │   └── datastore → rpool/pbs-datastore
│   ├── LXC 180 - Smarthome ← migré depuis Neo
│   └── [...autres LXC...]
│
└── Neo (PVE — nœud secondaire)
    ├── PBS bare metal (à supprimer)
    ├── LXC 253 - Technitium DNS fallback
    └── SSD SATA 1 To (LVM → ZFS à venir)

Ce qui reste à faire

#

C’est la première étape d’une série de modifications pour atteindre un cluster Proxmox HA complet. La suite dans les prochains articles :

1. Installer le QDevice sur le Raspberry Pi (en attente d’alimentation) pour résoudre le quorum à 2 nœuds
2. Réinstaller Neo en ZFS une fois le miroir PBS validé et le QDevice en place
3. Activer la réplication ZFS entre Morpheus et Neo
4. Activer le HA Manager sur les LXC critiques (Smarthome, PBS)

La règle d’or de cette migration : ne rien casser avant d’avoir un filet de sécurité. Le miroir PBS sur Morpheus est ce filet — il permet de réinstaller Neo sereinement.

Est-ce vraiment de la HA ? Nuances et honnêteté

#

Soyons clairs : aujourd’hui, non. À terme, oui — mais avec des nuances importantes à comprendre.

Ce qu’on a actuellement

#

Cluster MATRIX
├── Corosync ✅ (les 2 nœuds se voient)
├── Quorum ⚠️  (fragile sans QDevice)
├── Stockage partagé ❌ (ZFS ≠ LVM)
├── Réplication ZFS ❌ (neo pas encore en ZFS)
└── HA Manager ❌ (non activé)

C’est un cluster Proxmox basique — les nœuds se connaissent, peuvent migrer des VMs manuellement, mais sans aucune bascule automatique.

Ce que sera la HA au final

#

Une fois toutes les étapes complétées, le scénario de bascule automatique sera :

morpheus tombe à 3h du matin
         ↓ ~30 secondes
Corosync détecte la panne
QDevice (RPi) confirme le quorum → neo reste opérationnel
         ↓ ~2 minutes
HA Manager redémarre automatiquement sur neo :
    ├── LXC Smarthome (Home Assistant, MQTT, Zigbee2MQTT)
    ├── LXC PBS 107
    └── LXC DNS fallback (déjà sur neo)
         ↓
Domotique rétablie sans intervention manuelle 😴

Les garanties réelles

#

Ce que cette HA garantit :

• Bascule automatique sans intervention humaine
• RTO (temps de reprise) de 2-3 minutes pour les LXC critiques
• RPO (perte de données max) de ~15 minutes, configurable

Ce qu’elle ne garantit pas :

• Zéro interruption — il y aura toujours quelques minutes de coupure
• Protection contre une panne simultanée des deux nœuds
• Cohérence parfaite des données en cas de crash brutal non anticipé

Mais pour un homelab, c’est largement suffisant. Le rapport qualité / complexité / coût est imbattable, et ta maison survivra 2-3 minutes sans Home Assistant.