6. Choisir et surveiller ses stockages

Tous les backends du chapitre sont maintenant connus. Cette dernière section les compare pour aider à choisir. Puis elle montre comment ZFS vérifie l'intégrité de ses disques, pour qu'un disque ne se dégrade pas sans bruit.

6.1 Comparatif des backends de stockage

Type	Snapshots	Migration à chaud sans copie des disques	Multi-nœuds	Usage recommandé
local-lvm (LVM-thin)	✅	❌	❌	VMs single-node, dev
ZFS (local)	✅	❌	❌	Single-node, intégrité des données
NFS	✅ (disques qcow2)	✅	✅	ISOs, templates, backups
iSCSI + LVM	❌	✅	✅ (avec lock)	Migration, SAN existant
Ceph RBD	✅	✅	✅	Production cluster HA

La colonne « migration » se lit précisément. Une VM sur stockage local peut aussi migrer à chaud. Mais Proxmox copie alors ses disques d'un nœud à l'autre pendant la migration, ce qui prend du temps et du réseau.

Sur un stockage partagé, seule la mémoire voyage. Les snapshots sur NFS viennent du format qcow2, qui les porte lui-même.

Ce tableau explique pourquoi Ceph est la solution privilégiée dans les clusters Proxmox en production : c'est le seul backend qui combine snapshots, migration en ligne et partage natif multi-nœuds.

Retenez cependant que ce choix n'est pas binaire : un même nœud Proxmox combine souvent plusieurs backends. local-lvm pour les VMs de test rapides à recréer ; du NFS pour les ISOs et les sauvegardes centralisées ; Ceph pour les VMs de production qui exigent la haute disponibilité. Le bon réflexe consiste à choisir le backend en fonction du besoin de chaque VM plutôt que d'imposer un backend unique à l'ensemble du cluster.

6.2 ZFS — vérification périodique de l'intégrité

ZFS détecte et corrige les erreurs grâce aux sommes de contrôle de chaque bloc, à condition de tout relire de temps en temps : c'est le scrub.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Lancer un scrub complet sur le pool ; la commande rend la main aussitôt
zpool scrub datapool

# Une fois terminé : le bilan du scrub et des erreurs
zpool status datapool   # à lire : scan, errors

Résultat attendu (les lignes qui comptent) :

  scan: scrub repaired 0B in 00:00:01 with 0 errors on Tue Oct  6 19:48:05 2026
errors: No known data errors

repaired 0B with 0 errors est le résultat souhaité : ZFS a relu chaque bloc et n'a rien trouvé à corriger. Un repaired non nul signifie que la redondance a réparé une corruption silencieuse ; des erreurs répétées sur le même disque annoncent sa fin.

Un scrub sollicite fortement les disques et ralentit les VM. Debian le planifie déjà la nuit, une fois par mois, le deuxième dimanche (/etc/cron.d/zfsutils-linux) : inutile d'en ajouter un.

À retenir : chaque stockage a ses forces : seul Ceph réunit snapshots, migration à chaud sans copie et partage natif. Côté surveillance : le scrub ZFS relit et vérifie chaque bloc ; Debian le planifie déjà chaque mois.