Ce que nous faisons
Réparation matérielle Maintenance de serveurs Récupération de données Montée en puissance & upgradeIntervention & différenciateurs
Datacenter Lombardie Aruba Ponte San Pietro Au-delà du support constructeurProxmox VE : ZFS, LVM-thin, qcow2. Recovery sur les trois stacks de stockage.
Proxmox VE est la plateforme de virtualisation open source la plus répandue dans nos dossiers. Stockages typiques : ZFS (pools, datasets), LVM-thin (logical volumes thin-provisioned), qcow2 (fichiers image qemu). Le recovery couvre les trois couches et leurs imbrications.
Pool faulted, snapshots orphelins.
ZFS est un système de fichiers-RAID intégré doté d'excellentes capacités de self-healing. Lorsqu'un pool passe à l'état faulted, il est souvent récupérable via zpool import -fF en lecture seule, éventuellement avec un rewind vers un checkpoint antérieur. Dans les scénarios plus graves, il faut cloner les disques et reconstruire algébriquement les vdev manquants.
Thin pool corrupted, metadata exhaustion.
LVM-thin est efficace en espace (allocation on-demand) mais présente une faiblesse connue : si la metadata area est saturée ou corrompue, l'ensemble du thin pool devient inaccessible. Le recovery impose une manipulation des metadata du thin pool et une récupération du logical volume manager sur volume cloné.
Image qemu corrupted, snapshot chain.
qcow2 (QEMU Copy-On-Write) est le format standard des VM Proxmox lorsque le stockage n'est ni ZFS ni LVM. Header, tables L1/L2, snapshots internes multiples, backing file chain : autant d'éléments susceptibles de se corrompre et qui exigent un recovery dédié. Outils : qemu-img check, reconstruction des tables L1/L2 endommagées, extraction manuelle des données raw quand le qcow2 n'est pas récupérable en tant que tel.
Les questions qu'on nous pose le plus souvent.
Cluster Proxmox VE de 3 nœuds ou plus : comment se passe le recovery si l'un lâche ?
Si la réplication HA est active et correctement configurée, les VM critiques doivent basculer automatiquement. Le recovery du nœud défaillant est un chantier distinct : souvent une réparation matérielle du serveur, puis un rejoin du cluster. En cas de split-brain ou de perte de quorum, une intervention manuelle ordonnée sur l'outil de quorum (pmxcfs) est nécessaire.
Vaut-il mieux migrer vers ZFS ou rester sur LVM-thin ?
ZFS offre des avantages importants (compression, snapshots atomiques, checksums end-to-end, scrub) mais réclame davantage de RAM (ARC). Sur des systèmes disposant de 64 Go de RAM ou plus dédiés au stockage, ZFS est presque toujours le meilleur choix pour de nouveaux déploiements. Sur des systèmes plus modestes ou sous contraintes, LVM-thin reste pertinent.