Repères · Tous niveaux · Relecture documentaire : 2 octobre 2026. Les exemples sont génériques ; adapter les noms, versions et chemins avant toute modification.
Un SSD peut héberger les systèmes et les charges à forte latence sensible ; un pool de capacité peut recevoir des données volumineuses. Mais SAS désigne une interface, pas une garantie que le disque soit mécanique ou rapide. Choisir le placement à partir du type réel de supports, de leur redondance et des mesures.
Le stockage système de l’hôte, les disques VM, les volumes LXC, les ISO et les sauvegardes sont des objets différents. Une partition racine pleine peut bloquer l’administration même si un autre pool possède beaucoup d’espace. Inventorier chaque emplacement et sa politique de rétention.
ZFS combine organisation des disques, contrôle d’intégrité, snapshots et autres fonctions. Il doit voir les disques d’une manière compatible avec son fonctionnement ; éviter un RAID matériel interposé avec sa propre gestion de cache. La redondance peut permettre de survivre à certaines pannes, mais ne protège pas contre une suppression, un vol, une compromission ou toutes les défaillances simultanées.
Relever le disque exact, son propriétaire, sa taille réellement occupée, ses snapshots et ses sauvegardes. Pour un CT, vérifier tous les points de montage : déplacer le rootfs ne déplace pas automatiquement tous les volumes attachés. Les montages de chemins de l’hôte demandent une stratégie de sauvegarde explicite.
Utiliser les fonctions Proxmox adaptées au type de volume. Vérifier l’espace de destination avec une marge pour la copie, les snapshots et la croissance. Planifier l’arrêt si la méthode ou l’application l’exige. Après déplacement, comparer la configuration et réaliser un test applicatif avant d’envisager toute suppression de l’ancien volume.
Surveiller tendances et alertes avant le seuil critique. Une marge de 15 à 20 % peut servir d’objectif de gestion, à ajuster au pool et aux charges ; elle n’est pas une garantie universelle de performances. Les snapshots conservent des blocs modifiés : supprimer un fichier ne rend pas nécessairement tout son espace si un snapshot le référence encore.
Volume « unused » : détaché ne veut pas dire inutile. Rechercher configuration actuelle, anciens invités, snapshots et sauvegardes avant décision. Un pool dégradé doit faire l’objet d’un plan de protection des données et de remplacement, pas d’une simple suppression d’alerte.
| Type proposé dans Proxmox | À choisir pour | Points d’attention |
|---|---|---|
| Directory | ISO, modèles, fichiers de sauvegarde et images compatibles | Le chemin doit être sur le bon montage ; sinon la racine peut se remplir |
| LVM-thin | Volumes locaux d’invités, allocation progressive et snapshots | Surveiller données et métadonnées du thin pool |
| LVM classique | Volumes blocs selon architecture | Fonctions de snapshots dépendantes de la version ; ne pas appliquer les anciennes limites à toutes les versions 9.x |
| ZFS local | Volumes avec intégrité, snapshots et organisation ZFS | RAM, disposition des vdevs et visibilité directe des disques |
| NFS | Fichiers partagés par un NAS | Disponibilité du NAS, droits d’export, réseau et performances |
| SMB/CIFS | Partage compatible pour contenus pris en charge | Comptes, permissions et possibilités exactes du backend |
| PBS | Sauvegardes d’invités | Ce n’est pas un emplacement d’exécution de leurs disques actifs |
| Ceph RBD / CephFS | Stockage distribué conçu à l’échelle d’un cluster | Matériel, réseaux, quorum et capacité de reconstruction ; pas une recette pour deux petits hôtes |
| iSCSI | Accès bloc à une baie | Les LUN et couches de gestion demandent une conception cohérente |
La colonne « Content » disponible dépend du backend : Disk image pour VM, Container pour volumes CT, ISO image, Container template, Backup, Snippets ou autres fonctions prises en charge. Autoriser uniquement les contenus nécessaires. Un stockage ZFS de type zfspool n’est pas le même objet qu’un répertoire monté sur un dataset ZFS destiné aux ISO.
| Champ | Réponse à préparer | Piège |
|---|---|---|
| ID | Nom stable, court, fonctionnel | Renommer casse les références si mal géré |
| Directory / Pool / VG | Objet réellement existant et contrôlé | Un nom ne crée pas automatiquement le stockage physique |
| Nodes | Hôtes qui peuvent effectivement y accéder | Une définition globale peut viser un support seulement local |
| Content | Types utiles au besoin | Tout cocher mélange usages et politiques de rétention |
| Enable | Activer une fois prérequis vérifiés | L’inactivité peut venir d’un serveur absent, pas d’une case |
| Shared | Seulement si contenu réellement commun | Cocher ne partage pas un disque local |
| Thin provision | Selon backend et politique de capacité | La taille promise n’est pas l’espace physiquement disponible |
| Server / Export | Adresse et export précis pour NFS | Vérifier droits et disponibilité avant d’héberger un invité |
Un miroir conserve plusieurs copies et offre une capacité liée au plus petit membre. RAIDZ distribue données et parité ; le niveau définit combien de pannes de disques le vdev peut supporter. Le pool répartit les données entre ses vdevs : la perte d’un vdev de données peut compromettre tout le pool. Ajouter un disque seul à côté de vdevs redondants peut donc supprimer le niveau de protection attendu.
ashift concerne l’alignement des secteurs et doit correspondre au matériel ; ne pas le choisir après lecture d’un benchmark sans vérifier les disques. La compression légère est souvent utile, la déduplication n’est pas une option gratuite en ressources. SLOG sert aux écritures synchrones, L2ARC au cache de lecture : un SSD de cache ne répare pas automatiquement une architecture lente. Ne pas désactiver la synchronisation pour obtenir un beau résultat de test au prix de la durabilité.
Additionner occupation actuelle, croissance, espace des snapshots, migrations temporaires et réserve d’exploitation. Exemple fictif : 600 Go actifs + 150 Go de croissance + 100 Go de modifications retenues + 100 Go de copie temporaire = 950 Go avant marge ; un support « 1 To » ne convient pas nécessairement. Tenir compte des unités TB/TiB et de la redondance.
Des quotas de volumes supérieurs à la capacité du pool sont une promesse de croissance, pas un espace réservé, selon le backend. Surveiller le pool global et chaque système de fichiers invité. Un fichier supprimé peut rester retenu par un snapshot ; un disque virtuel peut ne restituer les blocs qu’avec une chaîne discard/TRIM compatible.
Identifier VMID, volume et fonction. Vérifier sauvegarde, état des deux stockages, espace et éventuelles limitations de snapshots. Sur une VM, sélectionner le disque dans Hardware puis l’action de déplacement ; sur un CT, traiter séparément rootfs et chaque point de montage géré. Choisir le stockage cible et les options compatibles. Ne supprimer la source qu’après fin de tâche et test applicatif ; ne pas réattacher les deux copies simultanément en écriture.
Pour des données applicatives, vérifier aussi permissions, montages, chemin dans l’application et inclusion dans la sauvegarde. Un bind mount est un chemin hôte, pas un volume automatiquement transporté par toutes les opérations Proxmox. Consulter le manuel CT.
pvesm status
df -h
df -i
zpool status
zfs list
lvs -a -o lv_name,vg_name,lv_size,data_percent,metadata_percent
Exécuter uniquement les outils du backend utilisé ; l’absence de ZFS n’est pas une panne si l’hôte utilise LVM. Un volume détaché demande une recherche de propriétaire et d’historique, jamais une suppression sur le seul mot « unused ». Consigner ce qui existe avant et après migration, puis effectuer une restauration de test indépendante.