Perfect Homelab [E10] : PBS en LXC dédié — fondations pour le cluster HA

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.

graph TB
    subgraph NeoHost["Neo — bare metal ⚠️"]
        PVE["Proxmox VE
port 8006"]
        PBS["Proxmox Backup Server
port 8007"]
        Backups[("/mnt/backups
429 Go — 132 Go utilisés")]
        LXC230["LXC 230 — Smarthome
32 Go"]
        LXC253["LXC 253 — Technitium DNS
8 Go"]
    end

    PVE --- PBS
    PBS --> Backups
    PVE --> LXC230
    PVE --> LXC253

    
    style PVE fill:#fef3c7,stroke:#b45309,stroke-width:2px,color:#000
    style PBS fill:#fecaca,stroke:#991b1b,stroke-width:3px,color:#000
    style Backups fill:#fef3c7,stroke:#b45309,stroke-width:2px,color:#000
    style LXC230 fill:#e2e8f0,stroke:#475569,stroke-width:2px,color:#000
    style LXC253 fill:#e2e8f0,stroke:#475569,stroke-width:2px,color:#000

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.

graph TB
    subgraph MorpheusHost["Morpheus"]
        LXC107["LXC 107 — PBS
10.10.10.7"]
        PBSStore[("rpool/datastore
ZFS — 632 Go")]
    end
    subgraph NeoHost["Neo — après migration ZFS"]
        LXC230n["LXC 230 — Smarthome
32 Go"]
        LXC253n["LXC 253 — Technitium DNS"]
    end

    LXC107 --> PBSStore

    style MorpheusHost fill:#dbeafe,stroke:#1e40af,stroke-width:2px,color:#000
    style NeoHost fill:#dbeafe,stroke:#1e40af,stroke-width:2px,color:#000
    style LXC107 fill:#dcfce7,stroke:#166534,stroke-width:2px,color:#000
    style PBSStore fill:#dcfce7,stroke:#166534,stroke-width:2px,color:#000
    style LXC230n fill:#e2e8f0,stroke:#475569,stroke-width:2px,color:#000
    style LXC253n fill:#e2e8f0,stroke:#475569,stroke-width:2px,color:#000

Étape 1 : Migration du LXC Smarthome

#

Avant de toucher à Neo, j’ai migré le LXC Smarthome (Home Assistant, MQTT, Zigbee2MQTT, ESPHome) 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) est accessible
# via le réseau, pas en USB direct → migration transparente

sequenceDiagram
    participant Neo as Neo — LXC 230
    participant S3 as Scaleway S3 / Garage
    participant Morpheus as Morpheus — LXC 130

    Note over Neo: Home Assistant, MQTT
Zigbee2MQTT
    Neo->>S3: Backup PBS via transit S3
    Note over S3: Point de transit temporaire
    S3->>Morpheus: Restore sur Morpheus
    Note over Morpheus: HA, ESPHome, Zigbee2MQTT
redémarrent proprement ✅
    Note over Neo: LXC 230 arrêté et supprimé

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, on crée un dataset ZFS nommé backups

# Sur Morpheus
zfs create rpool/backups
zfs list rpool/backups

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

632 Go disponibles sur les NVMe en mirroir. ✅

É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/backups,mp=/mnt/datastore \
  --tags "prod;backup" \
  --unprivileged 0 \
  --password

Ce qui est important à remarquer ici est le montage du dossier /rpool/backups (dataset ZFS que l’on vient de créer) vers le dossier /mnt/datastore dans le conteneur LXC

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/backups,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 (Bash ou Ansible) 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 backups /mnt/datastore
proxmox-backup-manager datastore list

É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 backups \
  --server 10.10.10.7 \
  --datastore backups \
  --username root@pam \
  --password \
  --fingerprint <fingerprint> \
  --content backup

pvesm status | grep backups

backups    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
# Sur 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 backups \
  --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. ✅

graph LR
    PBSNeo["PBS Neo — bare metal
10.10.10.6:8007
132 Go de backups"]
    LXC107PBS["LXC 107 — PBS Morpheus
10.10.10.7:8007"]
    DatastoreM[("backups (/rpool/backups)
ZFS — 632 Go")]

    PBSNeo -->|"pull incrémental
déduplication PBS"| LXC107PBS
    LXC107PBS --> DatastoreM

    style PBSNeo fill:#fee2e2,stroke:#991b1b,stroke-width:2px,color:#000
    style LXC107PBS fill:#dcfce7,stroke:#166534,stroke-width:2px,color:#000
    style DatastoreM fill:#dcfce7,stroke:#166534,stroke-width:2px,color:#000

État actuel de l’infrastructure

#

graph TB
    subgraph MorpheusG["Morpheus — nœud principal"]
        MorpheusNode["Morpheus
ZFS mirror 2x NVMe
632 Go libres"]
        LXC107cur["LXC 107 — PBS 4.2.1
10.10.10.7 ← NOUVEAU"]
        LXC130["LXC 130 — Smarthome
← migré depuis Neo"]
        PBSDataCur[("rpool/backups")]
    end
    subgraph NeoG["Neo — nœud secondaire"]
        NeoNode["Neo
SSD SATA 1 To — LVM
→ ZFS à venir"]
        PBSBareCur["PBS bare metal
← à supprimer"]
        LXC253dns["LXC 253
Technitium DNS fallback"]
    end

    LXC107cur --> PBSDataCur

    style MorpheusNode fill:#dbeafe,stroke:#1e40af,stroke-width:2px,color:#000
    style NeoNode fill:#fef3c7,stroke:#b45309,stroke-width:2px,color:#000
    style LXC107cur fill:#dcfce7,stroke:#166534,stroke-width:2px,color:#000
    style LXC130 fill:#dcfce7,stroke:#166534,stroke-width:2px,color:#000
    style PBSDataCur fill:#dcfce7,stroke:#166534,stroke-width:2px,color:#000
    style PBSBareCur fill:#fee2e2,stroke:#991b1b,stroke-width:2px,color:#000
    style LXC253dns fill:#e2e8f0,stroke:#475569,stroke-width:2px,color:#000

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 épisodes :

• E11 — Mettre en place le QDevice et migrer Technitium DNS sur Raspberry Pi : les filets de sécurité avant de toucher à Neo
• E12 — Réinstaller Neo en ZFS, activer la réplication ZFS et le HA Manager

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

#

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 :

flowchart TD
    A["Morpheus tombe — 3h du matin"]
    B["Corosync détecte la panne
~30 secondes"]
    C["QDevice confirme le quorum
Neo reste opérationnel"]
    D["HA Manager bascule sur Neo
~2 minutes"]
    E["LXC 130 — Smarthome
Home Assistant / MQTT / Zigbee2MQTT"]
    F["LXC 107 — PBS"]
    G["LXC 253 — DNS fallback
déjà sur Neo"]
    H["Domotique rétablie
sans intervention manuelle 😴"]

    A --> B
    B --> C
    C --> D
    D --> E
    D --> F
    D --> G
    E --> H
    F --> H
    G --> H

    style A fill:#fee2e2,stroke:#991b1b,stroke-width:2px,color:#000
    style B fill:#fef3c7,stroke:#b45309,stroke-width:2px,color:#000
    style C fill:#dbeafe,stroke:#1e40af,stroke-width:2px,color:#000
    style D fill:#dbeafe,stroke:#1e40af,stroke-width:2px,color:#000
    style E fill:#dcfce7,stroke:#166534,stroke-width:2px,color:#000
    style F fill:#dcfce7,stroke:#166534,stroke-width:2px,color:#000
    style G fill:#dcfce7,stroke:#166534,stroke-width:2px,color:#000
    style H fill:#dcfce7,stroke:#166534,stroke-width:2px,color:#000

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.