Proxmox VE : bases du stockage et des sauvegardes pour des machines virtuelles sûres - guide pratique

Introduction

Les choix de stockage et la discipline de sauvegarde dans Proxmox VE déterminent à quel point vous pouvez exécuter, modifier et récupérer des machines virtuelles en toute sécurité. Ce guide propose un chemin pratique pour :

Comprendre local-lvm, le stockage de type Directory et ZFS
Mapper les disques de VM vers les backends et choisir le bon emplacement
Utiliser efficacement les snapshots
Vérifier les sauvegardes et tester des restaurations avant toute modification sur des VMs de production
Exécuter un pilote mono-nœud sûr avant un déploiement plus large

Objectif : des changements prévisibles et une reprise fiable, sans surprises. Les mots-clés utiles comme Proxmox VE storage, ZFS Proxmox, Proxmox backups et VM disk troubleshooting apparaissent ici pour cadrer le sujet.

Vue d'ensemble du flux de travail

Suivez ces étapes, de l'inventaire au changement maîtrisé.

1) Inventorier le stockage actuel et sa santé

Identifiez ce que vous avez et si c'est sain.

Commandes :

État du stockage Proxmox

pvesm status

Lister les volumes par stockage

pvesm list local
pvesm list local-lvm

Détails LVM (fréquent pour local-lvm, souvent en LVM-Thin)

vgs
lvs -a -o+lv_size, lv_attr, lv_time, segtype, thin_count

Santé du pool ZFS (si vous utilisez ZFS)

zpool status
zpool list
zfs list -o name, used, avail, mountpoint

Capacité des systèmes de fichiers (Directory sur ext4/xfs)

df -hT

Checklist :

Relever l'espace libre, l'usage du thin pool et l'état des pools ZFS
Noter d'éventuelles erreurs de lecture/écriture ou de checksum (ZFS)
Confirmer que TRIM est activé lorsqu'approprié

2) Cartographier les VMs, leurs disques et snapshots

Comprenez où vit chaque disque et vos filets de sécurité.

Commandes :

Configuration de la VM et mapping des disques

qm config <vmid>

Repérez des lignes comme :

scsi0: local-lvm: vm-100-disk-0, size=40G
scsi1: zfspool: vm-100-disk-1, size=200G
sat : local: iso/ubuntu.iso, media=cdrom

Snapshots existants

qm listsnap <vmid>

3) Choisir le bon stockage pour chaque rôle

Chaque backend a des compromis. Commencez par une règle simple puis affinez.

local-lvm (LVM-Thin sur un périphérique bloc)
Avantages : allocation rapide, snapshots au niveau stockage, simplicité d'exploitation
Inconvénients : pas de fichiers lisibles « humainement » ; redimensionnement et migration différents du stockage fichier
Adapté à : disques de VM généraux sur nœud unique ou petits clusters

Directory (fichiers sur ext4/xfs)
Avantages : accès simple au niveau fichier ; sauvegardes aisées avec des outils classiques ; idéal pour ISOs, templates et cibles de sauvegarde
Inconvénients : snapshots dépendants du format d'image et non équivalents à ZFS ; I/O lourde peut impacter la surcharge du FS
Adapté à : ISOs, templates, backups, datastores PBS montés

ZFS (datasets et zvols)
Avantages : checksums, snapshots, clones, send/receive ; intégrité des données et réplication
Inconvénients : plus gourmand en RAM ; nécessite un réglage attentif du write cache et des paramètres de sync
Adapté à : VMs avec exigences d'intégrité élevées, workflows de snapshots et de réplication

Séparez les rôles autant que possible :

Disques runtime de VM sur local-lvm ou ZFS
ISOs et templates sur Directory
Sauvegardes sur Directory dédié ou dataset ZFS avec assez de capacité

4) Sauvegardes d'abord, puis changements

Les sauvegardes sont votre filet de sécurité. Créez, vérifiez et testez avant toute action risquée.

Sauvegarde à la demande (mode snapshot si supporté) :

vzdump <vmid> --mode snapshot --compress zstd --storage <backup-storage>

Sauvegardes planifiées (GUI) :
Datacenter -> Backup -> Add
Choisir le stockage, la planification et la rétention (prune)
Préférer le mode snapshot pour minimiser l'indisponibilité

Vérifier les sauvegardes en listant et en testant une restauration :

pvesm list <backup-storage> | grep vzdump
qmrestore /path/to/vzdump-qemu-<vmid>-*.vma.zst <new-vmid> --storage <target-storage> --unique 1

Réalisez la restauration test vers un ID de VM non production et un réseau isolé. Vérifiez que l'OS démarre et que l'application fonctionne. C'est la base d'un VM disk troubleshooting efficace en cas d'incident.

5) Déplacements et redimensionnements sûrs

Lors d'un move ou d'un resize, réduisez le risque avec snapshots et sauvegardes.

Créer un snapshot pré-changement :

qm snapshot <vmid> pre-change --description "before storage move"

Déplacer un disque vers un autre stockage (planifier une coupure sauf move en ligne validé) :

qm stop <vmid>
qm move_disk <vmid> scsi0 <target-storage>
qm start <vmid>

Vérification :

qm config <vmid>
pvesm list <target-storage> | grep vm-<vmid>

Redimensionner un disque en sécurité :

qm stop <vmid>
qm resize <vmid> scsi0 +20G
qm start <vmid>

Ensuite, agrandissez le système de fichiers à l'intérieur de l'OS invité.

Revenir en arrière si nécessaire :

qm stop <vmid>
qm rollback <vmid> pre-change
qm start <vmid>

6) Contrôles opérationnels et monitoring

Garde-fous de capacité : conservez au moins 20 % de libre sur LVM-Thin et sur les pools ZFS
Santé : surveillez zpool status, l'usage lvs et les journaux système pour toute erreur d'E/S
Succès des backups : examinez quotidiennement les logs des jobs et de prune
Fenêtres de changement : réalisez les opérations de stockage uniquement durant des fenêtres de maintenance

Plan pilote local

Démarrez petit et mesurable sur un seul nœud. Choisissez une VM non critique ou créez une VM de test.

Objectifs du pilote (exemple) :

Deux sauvegardes en mode snapshot réussies pour la VM de test
Une restauration test réussie vers un nouvel ID qui démarre et répond à un check basique (ex. : HTTP 200)
Un déplacement de disque entre deux stockages sans perte
Des temps collectés pour backup, restore et move

Étapes du pilote :

Préparer le stockage

Créer un Directory pour ISOs/backups, par exemple monté sur /mnt/backupdir

mkdir -p /mnt/backupdir
# montage via /etc/fstab si nécessaire, puis :

L'ajouter dans Datacenter -> Storage (type : Directory).

Optionnel : créer un petit pool ZFS (miroir de deux SSD) pour tests

zpool create zfspool mirror /dev/sdX /dev/sdY

L'ajouter dans Datacenter -> Storage (type : ZFS ou ZFS pool).

Établir la baseline de la VM

qm config <vmid>
pvesm status

Vérifiez 20 % de marge sur le stockage cible.

Snapshot et sauvegarde

qm snapshot <vmid> pilot-start --description "pilot baseline"
vzdump <vmid> --mode snapshot --compress zstd --storage backupdir

Restauration test

qmrestore /mnt/backupdir/dump/vzdump-qemu-<vmid>-*.vma.zst <vmid+100> --storage <test-storage> --unique 1

Démarrez la VM restaurée, isolez le réseau si besoin, et vérifiez un service basique.

Essai de déplacement de disque

qm stop <vmid>
qm move_disk <vmid> scsi0 <target-storage>
qm start <vmid>

Vérifiez le bon fonctionnement, puis nettoyez d'éventuels volumes orphelins côté source si non supprimés automatiquement.

Capturez :

Consigner et décider

Servez-vous-en pour fixer des RPO/RTO réalistes et planifier les fenêtres de production.

Les durées de sauvegarde, restauration et déplacement
L'impact CPU et disque durant les opérations
Toute erreur ou friction opérateur

Conclusion

Une pratique sûre de Proxmox VE storage commence par des rôles clairs pour chaque backend, des sauvegardes fiables et de petits pilotes mesurables. Gardez les disques runtime des VMs sur local-lvm ou ZFS, stockez ISOs et backups sur Directory ou dataset dédié, et validez les Proxmox backups par une restauration test avant tout changement.

Checklist pré-changement :

Sauvegarde récente réussie et testée
Snapshot de la VM créé et documenté
Au moins 20 % d'espace libre sur les stockages source et cible
Santé du stockage au vert (pvesm status, zpool status, lvs)
Fenêtre de maintenance et étapes de rollback confirmées
Plan de vérification post-changement défini (boot, services, logs)

Avec ces garde-fous, vous pouvez faire évoluer la topologie de stockage, déplacer/redimensionner des disques, et garder vos VMs de production en sécurité.