Vous avez installé Proxmox VE. L’interface web s’affiche. Vous pouvez créer une VM. Vous vous sentez puissant.
Puis un disque se remplit à 3 h du matin, des sauvegardes « réussies » ne se restaurent pas, et quelqu’un découvre que votre interface d’administration est accessible depuis le réseau des invités. C’est le moment où Proxmox cesse d’être un jouet de labo et devient une infrastructure. La bonne nouvelle : les 10 premiers correctifs sont pour la plupart ennuyeux, rapides et extrêmement efficaces.
Contexte historique rapide (parce que ça explique les aspérités)
- Les racines de Proxmox VE sont Debian. Cela signifie que vous bénéficiez de la stabilité et de la culture des paquets de Debian—mais aussi de l’attente que vous agissiez comme un administrateur système, pas comme un magicien.
- KVM est devenu « l’hyperviseur Linux » il y a plus d’une décennie. Proxmox profite de cette maturité. La plupart des bizarreries que vous voyez concernent le réseau/le stockage, pas KVM lui‑même.
- Les conteneurs LXC sont plus anciens que Docker. LXC est plus proche d’une « VM légère » : excellent pour les services, mais vous héritez des contraintes de partage du noyau.
- ZFS n’a pas été conçu pour « oups, j’ai rempli le pool ». C’est un système de fichiers transactionnel qui récompense la planification et punit le mensonge sur l’espace libre.
- Le thin provisioning précède la mode du cloud. La sur‑allocation a toujours été un tour de comptabilité avec une facture physique plus tard.
- Les systèmes de fichiers en cluster et le quorum sont des disciplines anciennes et capricieuses. Corosync n’est pas une magie nouvelle ; c’est la réalité des systèmes distribués avec de meilleurs outils.
- Le statut « sauvegarde réussie » est trompeur depuis l’époque des bandes. Une coche verte signifie « le job s’est exécuté », pas « les données sont récupérables ».
- « L’infrastructure comme animaux de compagnie » était normale autrefois. Proxmox est assez flexible pour vous laisser continuer ainsi. Ne le faites pas.
Une citation à garder collée à votre écran, paraphrasant une idée de John Allspaw : idée paraphrasée : la fiabilité vient de la conception pour l’échec et de l’apprentissage rapide, pas de la prétention d’éliminer l’échec.
1) Corriger les dépôts de paquets (et mettre à jour comme un pro)
Juste après l’installation, Proxmox pointe soit vers le dépôt enterprise (qui nécessite un abonnement), soit vers quelque chose que vous avez hérité d’un guide en lequel vous avez une confiance mitigée. Votre première tâche est de rendre les mises à jour prévisibles. La prévisibilité vaut mieux que l’héroïsme.
Tâche 1 : Voir quels dépôts vous utilisez réellement
cr0x@server:~$ grep -R --line-number -E 'pve|proxmox|ceph' /etc/apt/sources.list /etc/apt/sources.list.d/*.list
/etc/apt/sources.list.d/pve-enterprise.list:1:deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise
/etc/apt/sources.list.d/ceph.list:1:deb http://download.proxmox.com/debian/ceph-quincy bookworm no-subscription
Ce que signifie la sortie : Vous utilisez actuellement le dépôt enterprise pour PVE (abonnement requis) et no-subscription pour Ceph.
Décision : Si vous n’avez pas d’abonnement, désactivez pve-enterprise et utilisez le dépôt no-subscription. Si vous en avez un, conservez enterprise et supprimez no-subscription pour éviter des provenances mélangées.
Tâche 2 : Désactiver le dépôt enterprise (si vous n’avez pas d’abonnement)
cr0x@server:~$ sed -i 's/^deb /# deb /' /etc/apt/sources.list.d/pve-enterprise.list
cr0x@server:~$ cat /etc/apt/sources.list.d/pve-enterprise.list
# deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise
Ce que signifie la sortie : Il est commenté. APT n’essaiera plus d’interroger enterprise et n’affichera plus de 401.
Décision : Ajoutez le dépôt no-subscription afin d’obtenir les mises à jour de sécurité.
Tâche 3 : Ajouter le dépôt no-subscription (PVE)
cr0x@server:~$ echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" | tee /etc/apt/sources.list.d/pve-no-subscription.list
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription
cr0x@server:~$ apt-get update
Hit:1 http://download.proxmox.com/debian/pve bookworm InRelease
Hit:2 http://security.debian.org/debian-security bookworm-security InRelease
Reading package lists... Done
Ce que signifie la sortie : Les index ont été mis à jour avec succès. Plus de spam rouge « 401 Unauthorized ».
Décision : Mettez le système à jour maintenant, puis adoptez une routine (hebdomadaire suffit pour la plupart des petites structures ; quotidienne pour des environnements exposés).
Tâche 4 : Vérifier ce qui sera mis à niveau avant de l’exécuter
cr0x@server:~$ apt-get -s dist-upgrade | sed -n '1,25p'
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
The following packages will be upgraded:
pve-kernel-6.8.12-4-pve proxmox-ve pve-manager ...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Ce que signifie la sortie : Le mode simulation (-s) montre l’impact. Les mises à jour du noyau nécessitent des redémarrages. Les mises à jour de l’interface peuvent redémarrer des services.
Décision : Si c’est en production, planifiez une fenêtre de redémarrage. Si c’est votre premier nœud, redémarrez maintenant et familiarisez‑vous avec le cycle.
Règle d’opinion : Ne laissez pas les mises à jour d’hôte en mode « configure et oublie ». Proxmox est un plan de contrôle. Les plans de contrôle non patchés sont la source de nuits de week‑end.
2) Verrouiller les utilisateurs, les domaines et les permissions
Proxmox facilite l’exécution de tout en tant que root@pam. C’est aussi comme ça que vous vous retrouvez avec un mot de passe partagé sur un post‑it. Utilisez des comptes nommés et le principe du moindre privilège. Votre futur vous enverra une carte de remerciement.
Tâche 5 : Lister les utilisateurs et voir qui peut faire quoi
cr0x@server:~$ pveum user list
┌─────────────┬───────────┬───────────┬──────────────────────┐
│ userid │ enable │ expire │ firstname │
╞═════════════╪═══════════╪═══════════╪══════════════════════╡
│ root@pam │ 1 │ │ │
│ alice@pam │ 1 │ │ Alice │
└─────────────┴───────────┴───────────┴──────────────────────┘
cr0x@server:~$ pveum acl list | head
/:
user:root@pam role:Administrator
Ce que signifie la sortie : Seul root@pam est explicitement administrateur. C’est typique d’une installation fraîche.
Décision : Créez un administrateur nommé, puis restreignez l’usage de root au cas d’urgence.
Tâche 6 : Créer un administrateur nommé et exiger une MFA à la périphérie (ou au moins une authentification forte)
cr0x@server:~$ pveum user add sre-admin@pam --comment "Named admin account"
cr0x@server:~$ pveum passwd sre-admin@pam
Enter new password:
Retype new password:
cr0x@server:~$ pveum aclmod / -user sre-admin@pam -role Administrator
cr0x@server:~$ pveum acl list | head -n 10
/:
user:root@pam role:Administrator
user:sre-admin@pam role:Administrator
Ce que signifie la sortie : Vous avez maintenant un deuxième administrateur, ce qui vous permet d’arrêter d’utiliser root au quotidien.
Décision : Gardez root@pam pour les situations d’urgence et l’automatisation qui en a vraiment besoin, pas pour cliquer par habitude.
Mini‑histoire d’entreprise : incident causé par une mauvaise hypothèse
Dans une entreprise de taille moyenne, un nouvel administrateur virtualisation a supposé « l’UI Proxmox est sur le LAN de gestion, donc personne d’inconnu n’y a accès ». C’était vrai dans sa tête, pas dans les commutateurs.
Un prestataire branché sur un port libre s’est retrouvé dans le même VLAN que les hyperviseurs. Personne ne l’a remarqué parce que tout « marchait », et le diagramme réseau avait été mis à jour la dernière fois qu’on imprimait encore ces choses.
Ils n’ont pas été attaqués par un État‑nation. Ils ont été repérés par un scanner ennuyé qui a trouvé la page de connexion et a forcé un mot de passe root faible partagé. L’attaquant a créé une VM, l’a utilisée comme pivot, et le premier signe fut un pic de trafic sortant.
La correction n’était pas exotique : séparer le réseau de gestion, restreindre l’accès à l’UI, désactiver l’authentification par mot de passe SSH pour root, et arrêter le partage des identifiants. La leçon douloureuse : les hypothèses ne sont pas des contrôles.
3) Renforcer SSH et arrêter de se connecter en root
SSH est la clé maîtresse. Traitez‑la comme telle. Vous voulez : authentification par clé, pas de connexion root, et une piste d’audit compréhensible.
Tâche 7 : Vérifier les paramètres SSH actuels importants
cr0x@server:~$ sshd -T | egrep '^(permitrootlogin|passwordauthentication|pubkeyauthentication|kbdinteractiveauthentication) '
permitrootlogin yes
passwordauthentication yes
pubkeyauthentication yes
kbdinteractiveauthentication no
Ce que signifie la sortie : La connexion root et l’authentification par mot de passe sont autorisées. C’est pratique ; c’est aussi une invitation.
Décision : Désactivez la connexion root et l’authentification par mot de passe une fois que vos clés fonctionnent pour un utilisateur nommé.
Tâche 8 : Appliquer un drop‑in de durcissement basique
cr0x@server:~$ install -d -m 0755 /etc/ssh/sshd_config.d
cr0x@server:~$ cat > /etc/ssh/sshd_config.d/99-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
EOF
cr0x@server:~$ sshd -t && systemctl reload ssh
Ce que signifie la sortie : sshd -t valide la syntaxe. Le reload applique sans couper les sessions existantes.
Décision : Testez une nouvelle session SSH avant de fermer la vôtre. Se verrouiller hors du système est un rite de passage ; c’est aussi évitable.
Tâche 9 : Confirmer que vous pouvez toujours vous connecter (et que root ne peut pas)
cr0x@server:~$ ssh -o PreferredAuthentications=publickey sre-admin@192.0.2.10 'id'
uid=1001(sre-admin) gid=1001(sre-admin) groups=1001(sre-admin)
cr0x@server:~$ ssh -o PreferredAuthentications=password root@192.0.2.10 'true'
root@192.0.2.10: Permission denied (publickey).
Ce que signifie la sortie : L’administrateur nommé fonctionne avec des clés. Root est bloqué.
Décision : Conservez l’accès console (IPMI/iKVM/physique) comme chemin de secours. Ne comptez pas uniquement sur SSH comme seule porte d’entrée.
4) Activer le pare‑feu (la bonne façon)
Proxmox a un pare‑feu correct. Il n’est pas magique. Le mode de défaillance le plus courant est de l’activer partout sans comprendre l’ordre des règles et de se bloquer soi‑même.
Petite blague #1 : Les pare‑feu sont comme les ceintures : vous ne regrettez pas de les avoir mises que pendant les moments excitants.
Tâche 10 : Voir l’état actuel du pare‑feu et les règles
cr0x@server:~$ pve-firewall status
Status: disabled/running (cluster: disabled)
cr0x@server:~$ pve-firewall localnet
192.0.2.0/24
Ce que signifie la sortie : Le démon du pare‑feu tourne mais n’applique pas. localnet est ce que Proxmox considère comme « de confiance ». Si c’est erroné, vos règles seront erronées.
Décision : Définissez les sous‑réseaux de gestion comme localnet, puis activez le pare‑feu au niveau datacenter, puis au niveau nœud—avec précaution.
Tâche 11 : Valider l’IP de gestion et le sous‑réseau associé
cr0x@server:~$ ip -br addr show vmbr0
vmbr0 UP 192.0.2.10/24 fe80::5054:ff:fe12:3456/64
cr0x@server:~$ ip route show default
default via 192.0.2.1 dev vmbr0
Ce que signifie la sortie : Votre interface de gestion est sur vmbr0 avec 192.0.2.10/24. La route par défaut y est aussi.
Décision : Si les invités partagent ce réseau, arrêtez‑vous et reprenez la conception. La gestion ne doit pas être « juste un VLAN » que les VM peuvent rejoindre par curiosité.
Tâche 12 : Activer le pare‑feu et n’autoriser que l’essentiel vers l’hôte
cr0x@server:~$ pvesh set /cluster/firewall/options --enable 1
cr0x@server:~$ pvesh set /nodes/$(hostname)/firewall/options --enable 1
cr0x@server:~$ pvesh get /nodes/$(hostname)/firewall/options
┌────────────┬────────┐
│ key │ value │
╞════════════╪════════╡
│ enable │ 1 │
└────────────┴────────┘
Ce que signifie la sortie : Le pare‑feu est activé cluster‑wide et sur le nœud. Il reste à créer des règles explicites, sinon vous risquez de perdre l’accès selon les valeurs par défaut.
Décision : Ajoutez une règle d’autorisation pour la gestion (UI web et SSH) depuis localnet, puis un drop par défaut pour le reste.
Tâche 13 : Confirmer que les ports écoutent, puis qu’ils ne sont atteignables que depuis les bons endroits
cr0x@server:~$ ss -lntp | egrep '(:22|:8006)\s'
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1123,fd=3))
LISTEN 0 4096 0.0.0.0:8006 0.0.0.0:* users:(("pveproxy",pid=1876,fd=6))
Ce que signifie la sortie : SSH et le proxy web Proxmox sont liés sur toutes les adresses IPv4. C’est normal sur un nœud mono‑interface.
Décision : Si vous ne pouvez pas isoler par liaison, isolez par conception réseau et règles de pare‑feu. « Bound to 0.0.0.0 » est acceptable si votre pare‑feu et vos VLANs sont corrects.
5) Corriger le réseau de gestion et les bridges
La plupart des douleurs Proxmox sont en réalité des douleurs réseau Linux habillées. Les bridges sont puissants ; ils sont aussi honnêtes. Si votre réseau physique est négligé, Proxmox reproduira fidèlement cette négligence au débit linéaire.
Tâche 14 : Inspecter la configuration réelle du bridge utilisée par Proxmox
cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto enp3s0
iface enp3s0 inet manual
auto vmbr0
iface vmbr0 inet static
address 192.0.2.10/24
gateway 192.0.2.1
bridge-ports enp3s0
bridge-stp off
bridge-fd 0
Ce que signifie la sortie : Simple : une NIC, un bridge. Les invités attachés à vmbr0 sont sur le même L2 que votre interface de gestion.
Décision : Si ce n’est pas un labo, séparez le trafic de gestion et celui des invités avec des VLANs ou une seconde NIC. Au minimum : gestion sur un VLAN taggé accessible uniquement par l’équipe IT.
Tâche 15 : Vérifier la santé du lien et les problèmes de pilote (gains faciles)
cr0x@server:~$ ethtool enp3s0 | egrep 'Speed|Duplex|Link detected'
Speed: 1000Mb/s
Duplex: Full
Link detected: yes
Ce que signifie la sortie : Vous êtes en 1GbE. C’est correct pour un homelab ; c’est aussi la façon dont vous construisez accidentellement un problème de « stockage lent » qui est en fait un réseau lent.
Décision : Si vous prévoyez du stockage partagé ou des sauvegardes sur le réseau, le 10GbE n’est pas un luxe. C’est de la marge.
6) Temps, NTP et certificats : ennuyeux jusqu’à ce que ça vous brûle
Si l’heure est décalée, TLS se plaint, les clusters deviennent étranges et les logs deviennent de la fiction. Si les certificats sont en désordre, votre navigateur vous habitue à ignorer les avertissements—jusqu’au moment où il ne faut pas le faire.
Tâche 16 : Vérifier la synchronisation temporelle et le fuseau horaire
cr0x@server:~$ timedatectl
Local time: Sun 2025-12-28 11:02:15 UTC
Universal time: Sun 2025-12-28 11:02:15 UTC
RTC time: Sun 2025-12-28 11:02:16
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Ce que signifie la sortie : L’horloge est synchronisée. UTC est un bon choix par défaut pour les serveurs sauf raison impérieuse contraire.
Décision : Gardez les hôtes en UTC. Ajustez l’affichage dans votre outil de monitoring si les humains insistent.
Tâche 17 : Vérifier l’état des certificats (et éviter d’habituer aux mauvais comportements)
cr0x@server:~$ pvecm status 2>/dev/null | head -n 5
Cluster information
-------------------
Name: pve-cluster
Config Version: 1
Transport: knet
Ce que signifie la sortie : Si vous êtes déjà en cluster, la cohérence des certificats et des noms d’hôte compte encore plus. Même sur un nœud unique, gardez le nom d’hôte stable.
Décision : Ne réinstallez pas et ne renommez pas les nœuds à la légère. Proxmox est indulgent, mais les clusters s’en souviennent.
7) Choisir une disposition de stockage qui reflète la réalité
Les décisions de stockage sont là où les débutants se font discrètement ruiner. Proxmox vous permet de construire quelque chose qui a d’excellents benchmarks et qui échoue de façon catastrophique. Il faut décider : stockage local vs stockage partagé, ZFS vs LVM-thin, et où vont les sauvegardes.
Trois schémas raisonnables pour débutants
- Nœud unique, disques locaux : miroir ZFS pour les VM + disque/dataset séparé pour les sauvegardes (de préférence pas le même pool).
- Petit cluster sans stockage partagé : ZFS local sur chaque nœud + sauvegardes vers un Proxmox Backup Server dédié (PBS) + accepter que la migration à chaud nécessite du stockage partagé ou des stratégies de réplication.
- Cluster avec stockage partagé : Ceph (3+ nœuds minimum pour la sanité) ou un SAN/NAS dédié. Ce n’est pas un « débutant jour un » sauf si vous aimez les systèmes distribués à 2 h du matin.
Tâche 18 : Identifier vos disques et la pile de stockage actuelle
cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
NAME SIZE TYPE FSTYPE MOUNTPOINTS
sda 447.1G disk
├─sda1 1007K part
├─sda2 1G part vfat /boot/efi
└─sda3 446.1G part zfs_member
sdb 3.6T disk
└─sdb1 3.6T part
Ce que signifie la sortie : Votre pool OS/VM est sur ZFS (zfs_member). Vous avez un autre grand disque (sdb) actuellement inutilisé ou formaté ailleurs.
Décision : Utilisez sdb pour les sauvegardes, pas pour « espace VM supplémentaire ». Des sauvegardes qui concurrencent l’I/O des VM, c’est comme fabriquer de la latence.
Tâche 19 : Vérifier l’état du pool avant de lui faire confiance
cr0x@server:~$ zpool status
pool: rpool
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
sda3 ONLINE 0 0 0
errors: No known data errors
Ce que signifie la sortie : Le pool est en ligne sans erreurs. Aussi : c’est un disque unique. Ce n’est pas de la redondance ; c’est de l’espoir.
Décision : Si c’est important, reconstruisez en miroir. Un pool ZFS root sur un seul disque convient pour un labo, pas pour une VM de paie.
Fait intéressant : ZFS vérifie chaque bloc et peut s’auto‑réparer—mais seulement si vous lui donnez une seconde copie (miroir/RAIDZ). Sur un disque unique, il peut détecter la corruption puis hausser les épaules.
8) Bases ZFS : quoi régler, quoi laisser tranquille
Le tuning ZFS a une culture de hobbyistes. Une partie est légitime. Beaucoup est du cargo‑culting de posts de forum de 2016 sur des noyaux 2025. Votre travail est de garder les choses simples, mesurables et réversibles.
Les valeurs par défaut ZFS pour débutants à ne pas combattre
- Laissez ARC se gérer lui‑même sauf si vous avez un problème précis de pression mémoire.
- N’activez pas d’algorithmes de compression aléatoires parce que vous avez lu qu’ils sont « plus rapides ». Utilisez
lz4et passez à autre chose. - Ne définissez pas un
recordsizegéant sans comprendre votre charge de travail. Les VM sont des créatures d’I/O aléatoire.
Tâche 20 : Confirmer les propriétés clés du dataset ZFS pour le stockage de VM
cr0x@server:~$ zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 98G 300G 96K /rpool
rpool/ROOT 12G 300G 96K /rpool/ROOT
rpool/data 72G 300G 96K /rpool/data
rpool/data/vm-100-disk-0 40G 300G 40G -
cr0x@server:~$ zfs get -o name,property,value compression,atime,recordsize,volblocksize rpool/data
NAME PROPERTY VALUE
rpool/data compression lz4
rpool/data atime off
rpool/data recordsize 128K
rpool/data volblocksize -
Ce que signifie la sortie : lz4 et atime=off sont bons. recordsize sur un dataset compte pour les fichiers ; les ZVOLs utilisent volblocksize.
Décision : Pour les disques de VM, concentrez‑vous sur la taille de bloc ZVOL au moment de la création (souvent 16K est un bon compromis général pour des charges mixtes). Ne changez pas ces paramètres à la légère.
Tâche 21 : Vérifier l’espace libre du pool et le risque de fragmentation
cr0x@server:~$ zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH
rpool 446G 98G 348G - 12% 22% 1.00x ONLINE
Ce que signifie la sortie : 22% d’utilisation est correct. Les problèmes commencent quand vous traitez « FREE » comme dépensable jusqu’à zéro.
Décision : Gardez les pools ZFS sous ~80% d’utilisation pour des performances stables. Sous ~70% si vous voulez moins de surprises avec les snapshots et la churn.
Tâche 22 : Définir une politique explicite de réserve d’espace (optionnel mais intelligent)
cr0x@server:~$ zfs set refreservation=20G rpool/data
cr0x@server:~$ zfs get refreservation rpool/data
NAME PROPERTY VALUE SOURCE
rpool/data refreservation 20G local
Ce que signifie la sortie : Vous avez réservé 20G pour que le pool n’atteigne pas « 0 octet libre » aussi facilement lors de la croissance des snapshots.
Décision : Sur de petits pools, une réservation est une assurance bon marché. Sur de grands pools, vous préférerez peut‑être le monitoring + des quotas stricts.
Mini‑histoire d’entreprise : une optimisation qui a mal tourné
Une équipe voulait « économiser de l’espace » sur un cluster Proxmox. Ils ont activé la déduplication ZFS parce que ça ressemblait à de l’argent gratuit sur une diapositive. Ils ont aussi activé des tweaks de compression agressifs et gardé tout en thin‑provisioning parce que les chiffres étaient jolis.
Pendant une semaine, tout allait bien. Puis la charge a changé : plus de VMs bases de données, plus de churn, plus de snapshots. L’usage CPU des hôtes a grimpé. La latence est devenue instable. Le support l’a appelé « lenteur aléatoire », la catégorie la plus irritante.
Cause racine : la dédup ZFS consomme beaucoup de mémoire et punit quand elle est à court. Le DDT ne rentrait plus en RAM, donc les lectures/écritures ont forcé le pool à faire des I/O supplémentaires. Ils avaient optimisé pour la capacité et acheté par inadvertance un générateur de latence.
Le retour en arrière fut douloureux car les données étaient maintenant en état dédupliqué. Ils ont fini par migrer les disques VM vers un nouveau pool construit correctement : lz4, pas de dedup, espace libre ample et politique claire de rétention des snapshots. Les économies d’espace souhaitées existaient, mais le coût était opérationnel. La capacité est une métrique. La latence est une expérience utilisateur.
9) Sauvegardes qui se restaurent : PBS, calendriers, rétention, vérification
Proxmox facilite la planification des sauvegardes. Il facilite aussi l’illusion d’avoir des sauvegardes quand vous avez un dossier plein de fichiers que personne n’a jamais restaurés.
Faites‑le correctement :
- Sauvegardez sur un système séparé (idéalement PBS). Pas le même pool. Pas le même hôte.
- Utilisez une rétention sensée. Pas « garder pour toujours », pas « garder deux ».
- Vérifiez. Testez la restauration. Automatisez une restauration canari si possible.
Tâche 23 : Confirmer les jobs de sauvegarde existants (ou leur absence)
cr0x@server:~$ pvesh get /cluster/backup --output-format json-pretty
[]
Ce que signifie la sortie : Pas de sauvegardes planifiées. C’est le défaut et aussi le piège.
Décision : Créez un job aujourd’hui. Si vous « n’êtes pas prêt », vous n’êtes pas prêt à perdre des données.
Tâche 24 : Vérifier les cibles de stockage configurées (où les sauvegardes peuvent aller)
cr0x@server:~$ pvesm status
Name Type Status Total Used Available %
local dir active 98.00 GiB 12.30 GiB 85.70 GiB 12.55%
local-lvm lvmthin active 300.00 GiB 70.20 GiB 229.80 GiB 23.40%
Ce que signifie la sortie : Vous n’avez que du stockage local. Les sauvegardes ici valent mieux que rien, mais ne survivent pas si l’hôte meurt.
Décision : Ajoutez PBS ou au moins une cible NFS sur une machine différente. Préférez PBS pour la déduplication et les mécanismes de vérification conçus pour les sauvegardes virtualisées.
Tâche 25 : Valider que votre destination de sauvegarde ne se remplit pas immédiatement
cr0x@server:~$ df -h /var/lib/vz
Filesystem Size Used Avail Use% Mounted on
rpool/ROOT/pve-1 98G 13G 86G 13% /
Ce que signifie la sortie : Si vous sauvegardez sur local, vous consommez l’espace du système racine. C’est comme cela que vous briquez un nœud avec « No space left on device » pendant une fenêtre de sauvegarde.
Décision : Ne stockez pas les sauvegardes sur la partition racine à long terme. Ajoutez un stockage dédié pour les sauvegardes.
Tâche 26 : Lancer une sauvegarde manuelle et lire le résultat comme si ça comptait
cr0x@server:~$ vzdump 100 --storage local --mode snapshot --compress zstd --notes-template '{{guestname}} {{vmid}}'
INFO: starting new backup job: vzdump 100 --storage local --mode snapshot --compress zstd
INFO: Backup of VM 100 started at 2025-12-28 11:22:10
INFO: status = running
INFO: VM Name: app01
INFO: include disk 'scsi0' 'local-lvm:vm-100-disk-0' 50G
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating vzdump archive 'vzdump-qemu-100-2025_12_28-11_22_10.vma.zst'
INFO: Total bytes written: 9876543210 (9.1GiB, 220.0MiB/s)
INFO: backup ended at 2025-12-28 11:23:05
INFO: Backup job finished successfully
Ce que signifie la sortie : Le mode snapshot a réussi, la compression a été utilisée, le débit est indiqué. « Finished successfully » est nécessaire—mais pas suffisant pour la récupérabilité.
Décision : Testez immédiatement une restauration vers un nouvel ID de VM ou vers un emplacement de test. N’attendez pas l’incident.
Tâche 27 : Valider que le fichier de sauvegarde existe et a une taille raisonnable
cr0x@server:~$ ls -lh /var/lib/vz/dump | tail -n 3
-rw-r--r-- 1 root root 9.2G Dec 28 11:23 vzdump-qemu-100-2025_12_28-11_22_10.vma.zst
-rw-r--r-- 1 root root 637 Dec 28 11:23 vzdump-qemu-100-2025_12_28-11_22_10.log
Ce que signifie la sortie : Archive plus fichier log existent. Si votre « sauvegarde » fait quelques mégaoctets pour une grosse VM, vous avez probablement sauvegardé la mauvaise chose ou rencontré une erreur.
Décision : Lisez le log pour les avertissements et confirmez que les disques ont été inclus.
Tâche 28 : Tester la restauration (la partie que tout le monde évite)
cr0x@server:~$ qmrestore /var/lib/vz/dump/vzdump-qemu-100-2025_12_28-11_22_10.vma.zst 900 --storage local-lvm
restore vma archive: zstd -q -d -c /var/lib/vz/dump/vzdump-qemu-100-2025_12_28-11_22_10.vma.zst | vma extract -v -r /var/tmp/vzdumptmp1234 - /var/tmp/vzdumptmp1234
progress 1% (reading archive)
progress 55% (reading archive)
progress 100% (reading archive)
restore successful
Ce que signifie la sortie : Le pipeline de restauration s’est exécuté et a abouti. C’est votre signal réel.
Décision : Démarrez la VM restaurée dans un réseau isolé, vérifiez la santé de l’application, puis supprimez‑la. Répétez régulièrement.
Fait intéressant : L’expression « fenêtre de sauvegarde » vient d’une époque où il fallait arrêter tout le reste pour streamer vers une bande. Vos SSD n’ont pas reçu l’avis, mais vos utilisateurs ressentent encore la douleur si vous satuez l’I/O de stockage.
10) Logs, alertes et signaux de capacité
Un nœud Proxmox peut être « sain » jusqu’au moment où il ne l’est plus. Vous voulez des signaux précoces : utilisation disque, santé des pools, avertissements SMART, échecs de sauvegarde et redémarrages inattendus.
Tâche 29 : Vérifier le journal pour des erreurs importantes
cr0x@server:~$ journalctl -p warning -b --no-pager | tail -n 20
Dec 28 09:12:44 server kernel: nvme nvme0: I/O 123 QID 4 timeout, aborting
Dec 28 09:12:45 server kernel: ata1.00: failed command: READ DMA EXT
Dec 28 09:12:45 server kernel: blk_update_request: I/O error, dev sda, sector 1234567 op 0x0:(READ)
Ce que signifie la sortie : Ce n’est pas du « bruit ». Les timeouts et erreurs I/O sont des avertissements matériels ou de câblage, souvent des jours avant une panne.
Décision : Si vous voyez des erreurs I/O de stockage, arrêtez d’optimiser et commencez à remplacer. Lancez SMART, vérifiez les câbles/backplane et planifiez la migration.
Tâche 30 : Vérifier rapidement la santé SMART (si vous utilisez SATA/SAS)
cr0x@server:~$ smartctl -H /dev/sda
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.12-4-pve] (local build)
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Ce que signifie la sortie : « PASSED » n’est pas « comme neuf ». Cela signifie juste que le disque ne s’est pas encore déclaré mort.
Décision : Regardez les secteurs réalloués, les secteurs en attente et les logs d’erreurs, pas seulement le titre.
Tâche 31 : Vérifier l’utilisation des disques VM et le risque du thin‑provisioning
cr0x@server:~$ lvs -o lv_name,vg_name,lv_size,data_percent,metadata_percent,lv_attr
lv_name vg_name lv_size data_percent metadata_percent lv_attr
data pve 300.00g 78.12 4.55 twi-aotz--
Ce que signifie la sortie : Votre thin pool est rempli à 78%. Les thin pools échouent mal quand ils atteignent 100% : les VM peuvent devenir en lecture seule ou planter selon la charge.
Décision : Ajoutez de l’espace ou réduisez les allocations avant 90%. Surveillez aussi l’utilisation des métadonnées ; une métadonnée pleine est un désastre particulier.
Petite blague #2 : Un thin pool à 99% est le stockage de Schrödinger : il est à la fois OK et en feu jusqu’à ce que vous écriviez un bloc de plus.
Mini‑histoire d’entreprise : pratique ennuyeuse mais correcte qui a sauvé la mise
Une organisation financière utilisait Proxmox pour des applis internes. Rien de glamour : quelques bases de données, services de fichiers et des VMs que tout le monde prétendait « temporaires » depuis trois ans.
Leur lead SRE insistait sur une routine fastidieuse : mises à jour hebdomadaires des hôtes, sauvegardes nocturnes vers PBS, et un test de restauration mensuel d’une VM choisie aléatoirement dans un réseau isolé. Personne n’aimait ça. C’était de la paperasse avec des étapes supplémentaires.
Un trimestre de clôture, un contrôleur de stockage a commencé à retourner des erreurs intermittentes. Le pool ZFS est resté en ligne, puis a commencé à montrer des erreurs de checksum. Les performances ont plongé. Le responsable incident a pris la seule décision sensée : arrêter d’être astucieux, basculer en restaurant les VMs critiques sur un nœud de secours avec stockage propre.
La restauration a fonctionné parce qu’elle avait été testée. Les identifiants étaient documentés. Le datastore PBS avait été vérifié. L’équipe n’a pas dû apprendre la procédure de restauration pendant que l’entreprise regardait.
Après, personne n’a vanté d’héroïsme. C’était le but. Le travail de fiabilité le plus précieux est celui qui paraît ennuyeux dans un rapport d’état.
Playbook de diagnostic rapide : quoi vérifier en premier/deuxième/troisième
Quand Proxmox « semble lent », les gens blâment l’hyperviseur. En général, c’est l’une des trois choses : latence de stockage, mauvaise conception réseau ou pression mémoire. Voici comment trouver le goulot vite, sans deviner.
Premier : l’hôte est‑il en détresse maintenant ?
cr0x@server:~$ uptime
11:41:02 up 3 days, 2:17, 2 users, load average: 8.21, 7.95, 7.10
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 64Gi 56Gi 1.2Gi 1.1Gi 6.8Gi 4.0Gi
Swap: 8.0Gi 6.5Gi 1.5Gi
Comment interpréter : Une charge élevée avec peu de mémoire disponible et un swap important suggère une pression mémoire. La charge seule est ambiguë ; le swap ne l’est pas.
Décision : Si le swap est actif et croissant, réduisez la surallocation mémoire, ajoutez de la RAM ou déplacez des charges. Vérifiez aussi le ballooning et les caches hôtes.
Deuxième : la latence de stockage est‑elle le vrai coupable ?
cr0x@server:~$ iostat -x 1 3
avg-cpu: %user %nice %system %iowait %steal %idle
12.00 0.00 6.00 25.00 0.00 57.00
Device r/s w/s rkB/s wkB/s await svctm %util
sda 5.0 120.0 80.0 9000.0 35.20 2.10 98.00
Comment interpréter : %iowait est élevé et %util disque proche de 100% avec un await élevé. C’est une saturation de stockage classique.
Décision : Trouvez la VM la plus bavarde, réduisez la concurrence des sauvegardes/réplications, déplacez les disques chauds vers un stockage plus rapide ou ajoutez des plateaux/SSDs. Ne « tunez » pas d’abord des options noyau.
Troisième : est‑ce vraiment le réseau (surtout avec NFS/Ceph/PBS) ?
cr0x@server:~$ ip -s link show enp3s0 | sed -n '1,8p'
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 3c:ec:ef:12:34:56 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped missed mcast
9876543210 6543210 0 120 0 12345
TX: bytes packets errors dropped carrier collsns
8765432109 5432109 0 250 0 0 0
Comment interpréter : Des paquets dropés (RX/TX) ne sont pas normaux sur des réseaux propres. Ils indiquent congestion, problèmes de pilote ou MTU/queues incohérentes.
Décision : Corrigez le réseau avant d’accuser Ceph/NFS. Puis validez la cohérence MTU de bout en bout si vous utilisez des jumbo frames.
Bonus : trouver rapidement la VM voisine bruyante
cr0x@server:~$ pvesh get /nodes/$(hostname)/qemu --output-format json-pretty | head -n 20
[
{
"cpu": 0.85,
"mem": 4294967296,
"name": "app01",
"pid": 4321,
"status": "running",
"vmid": 100
},
{
"cpu": 3.72,
"mem": 17179869184,
"name": "db01",
"pid": 9876,
"status": "running",
"vmid": 110
}
]
Comment interpréter : Vue rapide des VMs avec utilisation CPU. Pas parfaite, mais bonne pour le triage.
Décision : Si une VM monopolise le CPU, vérifiez aussi son I/O disque et sa mémoire. « CPU élevé » peut être un symptôme de blocages de stockage provoquant des boucles actives.
Erreurs courantes : symptôme → cause racine → correction
1) Symptom : les sauvegardes sont « réussies » mais la restauration échoue
Cause racine : Sauvegardes stockées sur le même hôte/pool, archive corrompue, config VM manquante ou procédure de restauration jamais testée.
Correction : Sauvegardez sur PBS ou un stockage externe, faites un test de restauration mensuel et conservez les logs. Utilisez la vérification sur PBS et traitez les échecs comme des incidents de production.
2) Symptom : gels aléatoires de VM pendant la fenêtre de sauvegarde
Cause racine : Saturation du stockage (surtout sur HDD), trop de jobs de sauvegarde concurrents ou thin pool proche de la full provoquant une pression métadonnée.
Correction : Réduisez la concurrence, étalez les horaires, définissez des limites I/O pour le trafic de sauvegarde, déplacez les sauvegardes hors du pool primaire et gardez de la marge libre.
3) Symptom : l’interface web Proxmox est accessible depuis des endroits où elle ne devrait pas l’être
Cause racine : Réseaux de gestion et invités partagent le même bridge/VLAN ; pare‑feu désactivé ou mal configuré ; binding par défaut « 0.0.0.0 » exposé sur un LAN plus large.
Correction : Séparez le VLAN de gestion, appliquez des règles de pare‑feu, restreignez côté commutateur (ACL), et arrêtez de considérer le « réseau interne » comme de confiance.
4) Symptom : le cluster devient étrange après un reboot (nœuds en désaccord, GUI affiche des erreurs)
Cause racine : Dérive temporelle, incohérences DNS ou attentes de quorum cassées (cluster à deux nœuds sans mécanisme de départage).
Correction : Corrigez NTP, utilisez des noms d’hôtes stables et du DNS forward/reverse cohérent, concevez le quorum correctement (nombre impair de votants ou un qdevice).
5) Symptom : le pool ZFS est « ONLINE » mais les performances sont terribles
Cause racine : Pool trop plein, churn de snapshots élevé, disques lents ou inadéquation de la charge (bases de données sur RAIDZ HDD avec charges d’écritures sync élevées).
Correction : Gardez le pool sous ~80%, révisez la rétention des snapshots, utilisez des miroirs pour les charges IOPS intensives, ajoutez un SLOG seulement si vous comprenez les écritures sync, et mesurez la latence avec iostat.
6) Symptom : les VM deviennent subitement en lecture seule ou plantent ; les logs hôtes montrent des erreurs de thin pool
Cause racine : Le thin pool LVM a atteint 100% d’utilisation des données ou des métadonnées.
Correction : Étendez immédiatement le thin pool, libérez de l’espace et empêchez la récurrence avec du monitoring et une provision prudente.
Listes de contrôle / plan étape par étape
Jour 0 (première heure après l’installation)
- Dépôts : choisir enterprise vs no-subscription ; exécuter
apt-get updateet simuler les mises à niveau. - Administrateur nommé : créer
sre-admin@pam, accorder le rôle admin, cesser d’utiliserroot@pamau quotidien. - Durcissement SSH : ajouter un drop‑in pour désactiver root + mots de passe ; recharger SSH et tester les connexions.
- Vérification réseau : inspecter
/etc/network/interfaces. Si la gestion partage le bridge invités, corriger maintenant, pas « plus tard ». - Mise en scène du pare‑feu : confirmer
localnet, activer le pare‑feu avec précaution, s’assurer d’accéder à 8006 et 22 depuis la gestion. - Synchronisation temporelle : confirmer que
timedatectlmontre « System clock synchronized: yes ».
Jour 1 (avant d’y mettre quelque chose d’important)
- Décision stockage : choisir intentionnellement miroir ZFS ou LVM-thin. Éviter le « production » sur disque unique.
- Santé du pool : vérifier
zpool statusetzpool list; définir des attentes de marge. - Cible de sauvegarde : ajouter PBS ou stockage externe. Ne pas accepter « sauvegardes sur le nœud » comme état final.
- Première sauvegarde + test de restauration : exécuter
vzdumpetqmrestorepour prouver la récupérabilité.
Semaine 1 (rendre durable)
- Signaux de monitoring : décider des alertes nécessaires : remplissage disque, erreurs ZFS, avertissements SMART, échecs de sauvegarde.
- Cadence de patch : choisir une fenêtre ; documenter les attentes de redémarrage pour les mises à jour noyau.
- Politique d’accès : qui a l’accès console, qui a admin, qui a des permissions au niveau VM ; supprimer les identifiants partagés.
- Runbook : écrire les étapes de restauration et l’emplacement des sauvegardes. Sous stress, vous n’allez pas tout vous rappeler.
FAQ
1) Dois‑je utiliser ZFS ou LVM‑thin pour le stockage de VM ?
Si vous voulez des fonctionnalités d’intégrité (checksums, snapshots prévisibles, outils de réplication faciles), choisissez ZFS. Si vous voulez la simplicité et que vous comprenez le monitoring des thin pools, LVM‑thin convient. Les débutants s’en sortent généralement mieux avec des miroirs ZFS que des thin pools qu’ils oublient de surveiller.
2) Puis‑je stocker les sauvegardes sur le même hôte Proxmox ?
Vous pouvez, mais ne l’appelez pas « sauvegarde » pour tout ce que vous ne pouvez pas perdre. La panne de l’hôte, le ransomware sur l’hôte ou une corruption du pool de stockage emportent vos VMs et leurs sauvegardes ensemble. Utilisez un système séparé.
3) Est‑il acceptable d’exploiter un Proxmox mono‑nœud en production ?
Oui, si vous acceptez le risque et mettez en place de bonnes sauvegardes. Beaucoup de petites entreprises le font. Mais soyez honnête : un nœud unique implique des indisponibilités pendant les mises à jour et zéro redondance matérielle sauf si votre stockage est en miroir et que vous avez des pièces de rechange.
4) Pourquoi tout le monde dit « gardez ZFS sous 80% » ?
Les performances et le comportement de l’allocateur ZFS se détériorent à mesure que l’espace libre diminue, surtout avec des snapshots et des charges fragmentées comme les images VM. Vous pouvez le faire tourner plus plein, mais vous échangez une latence stable contre des droits de vantardise de capacité.
5) Ai‑je besoin de Ceph ?
Non, pas pour « j’ai deux nœuds et de bonnes vibes ». Ceph brille quand vous avez suffisamment de nœuds, de réseau et de maturité opérationnelle pour gérer du stockage distribué. Si vous voulez juste du stockage partagé pour un petit cluster, évaluez d’abord des options plus simples.
6) Quelle est la façon la plus simple et sûre d’exposer l’UI web Proxmox ?
Ne l’exposez pas directement sur Internet. Placez‑la sur un réseau de gestion, accédez‑y via VPN ou bastion, et appliquez la MFA là où vous terminez l’accès distant. Si vous devez absolument la publier, traitez‑la comme tout autre plan d’administration et restreignez fortement l’accès.
7) Pourquoi ma sauvegarde VM a‑t‑elle mis une éternité alors que mes disques sont rapides ?
Les sauvegardes forment une pipeline : lecture des disques VM, compression et écriture vers la destination. Le CPU peut être le goulot (compression), le réseau peut être le goulot (PBS/NFS), ou le stockage peut être saturé par des jobs concurrents. Utilisez iostat, ss/ip -s link et les métriques CPU pendant la fenêtre de sauvegarde.
8) Comment savoir si le thin provisioning est sûr ?
C’est sûr quand vous le surveillez et que vous pouvez l’agrandir avant qu’il soit plein. Si vous n’avez pas d’alerte et que vous faites régulièrement tourner des pools au‑dessus de 85–90%, ce n’est pas du thin provisioning—c’est du jeu avec des étapes supplémentaires.
9) Dois‑je changer les ports par défaut (SSH/8006) ?
Changer de port n’est pas de la sécurité ; c’est une réduction mineure du bruit de fond. Les vrais contrôles sont l’isolation réseau, les règles de pare‑feu, une authentification forte et le patching. Si changer de port aide votre modèle de menace, faites‑le—mais ne le confondez pas avec une protection réelle.
Étapes pratiques suivantes
Proxmox est suffisamment accueillant pour vous faire démarrer vite, et assez franc pour exposer chaque mauvaise habitude que vous apportez. Corrigez les bases maintenant : dépôts, comptes, SSH, pare‑feu, séparation réseau, synchronisation temporelle, disposition du stockage, marge ZFS, sauvegardes réelles et signaux réels.
Puis faites la chose qui sépare « je gère un labo » de « je gère la production » : planifiez un test de restauration sur votre calendrier et traitez une sauvegarde ratée comme un incident réel. Vos VMs sont des charges de travail. Votre nœud Proxmox est la plateforme. Gardez la plateforme ennuyeuse, patchée et prévisible.