Proxmox ZFS « cannot import pool » : causes, vérifications et options de récupération

Ce que signifie réellement « cannot import pool » dans Proxmox

Proxmox ne fait rien de mystique ici. C’est un hôte basé sur Debian avec les outils ZFS. Si le pool ne s’importe pas,
Proxmox ne peut pas monter les datasets, ne peut pas présenter les ZVOLs, et votre définition de stockage dans l’interface devient une étiquette inerte.

Le processus d’import consiste pour ZFS à lire les labels des vdevs, reconstruire l’état du pool à partir du groupe de transactions (TXG) le plus récent,
et s’assurer qu’il peut ouvrir le pool en toute sécurité avec l’identité et les chemins de périphériques du système courant.
Quand cela échoue, c’est presque toujours dans l’une des cinq catégories suivantes :

• Problèmes de visibilité des périphériques : les disques ne sont pas présents (ou instables), chemins by-id incorrects, bizarreries HBA/firmware, conflits multipath.
• Contrôles de sécurité des métadonnées : multihost/hostid incompatible, imports obsolètes, le pool pense être actif ailleurs.
• Corruption ou écritures incomplètes : arrêts brutaux, mauvais blocs, périphérique en défaillance rendant labels/uberblocks illisibles.
• Incompatibilité de fonctionnalités/propriétés : userspace ancien vs flags de pool, clés de chiffrement non chargées, options non supportées.
• Séquençage de démarrage/import Proxmox : initramfs, ordre du service zfs-import, dérive du cachefile, conditions de course au démarrage.

L’objectif est d’identifier dans quel groupe vous vous trouvez à l’aide de preuves, puis de choisir la méthode d’import la moins dangereuse qui vous ramène en service.
Commencez par des imports en lecture seule, évitez « force » sauf si vous pouvez expliquer à un autre ingénieur pourquoi c’est sûr, et ne « tentez pas tout » sur la seule copie de vos données.

Playbook de diagnostic rapide (premières/deuxièmes/troisièmes vérifications)

0. Stabiliser : arrêter l’hémorragie

• Si c’est un stockage partagé ou potentiellement visible par plusieurs hôtes (baie SAS, LUNs iSCSI, FC), assurez-vous qu’un seul hôte y a accès. Débranchez des câbles ou désactivez les cibles si nécessaire.
• Gelez l’automatisation : arrêtez les cron, jobs de sauvegarde et tout ce qui pourrait continuer à sonder les périphériques.
• Si vous suspectez des disques défaillants, évitez les boucles de redémarrage. Chaque démarrage est un nouveau lancer de dés.

1. Première vérification : les vdevs sont-ils réellement présents et stables ?

La plupart des tickets « cannot import » ne signifient pas « ZFS est cassé ». Ils signifient « le chemin du disque a changé », « le HBA fait des caprices », ou « multipath ment ».
Confirmez la visibilité des périphériques et confirmez qu’il s’agit bien des mêmes disques que vous croyez.

• Exécutez zpool import et lisez le message d’erreur exact.
• Vérifiez ls -l /dev/disk/by-id pour les WWN attendus.
• Consultez dmesg -T pour les resets, timeouts, « I/O error », « offline device ».

2. Deuxième vérification : ZFS refuse‑t‑il par sécurité (hostid/multihost/état stale) ?

Si ZFS pense que le pool est actif sur un autre système, il refusera ou demandera une override explicite. C’est souhaitable ; cela évite le split‑brain.
Recherchez « pool may be in use from another system » et vérifiez le hostid.

3. Troisième vérification : pouvez‑vous importer en lecture seule et inspecter ?

Si le pool est visible, tentez un import en lecture seule. C’est le mode « safe » de ZFS.
Si l’import en lecture seule échoue, vous êtes probablement confronté à des périphériques manquants, une corruption sévère, des fonctionnalités non supportées ou des problèmes de clé de chiffrement.

Si vous ne faites rien d’autre : collectez les sorties de zpool import -D, zdb -l sur chaque périphérique, et journalctl -u zfs-import-cache -u zfs-import-scan.
Ces trois éléments vous indiquent généralement la direction à suivre.

Faits & contexte intéressants (pourquoi ZFS se comporte ainsi)

1. Les pools ZFS sont auto-descriptifs : la configuration vit sur chaque label de vdev, pas dans un fichier de configuration fragile unique.
2. L’import est un processus de consensus : ZFS choisit le TXG cohérent le plus récent parmi les périphériques ; ce n’est pas juste « monter et espérer ».
3. Hostid existe pour prévenir le split brain : ZFS peut enregistrer le dernier hôte ayant importé et bloquer les imports dangereux lorsque multihost=on.
4. Les feature flags ont remplacé les numéros de version : les pools modernes annoncent des fonctionnalités ; des outils plus anciens peuvent refuser l’import s’ils ne les comprennent pas.
5. ZFS préfère des ID de périphériques stables : /dev/sdX est une opinion, pas un fait. /dev/disk/by-id est le choix mature.
6. Le « cachefile » est une optimisation : il accélère les imports, mais des cachefiles obsolètes peuvent induire en erreur les imports au démarrage après des changements matériels.
7. OpenZFS a divergé de Solaris ZFS : Proxmox utilise OpenZFS sur Linux, avec son intégration de démarrage et ses subtilités de services.
8. Les scrubs ne sont pas des sauvegardes : les scrubs détectent et réparent la corruption silencieuse (quand la redondance existe), mais ils ne protègent pas contre un « rm -rf » ou la perte de clés de chiffrement.

Causes racines : les suspects habituels, avec symptômes

1) Disques manquants, renommés ou qui décrochent de façon intermittente

Symptômes : cannot import 'pool': no such pool available, ou one or more devices is currently unavailable.
Dans Proxmox, cela suit souvent un redémarrage, un échange de HBA, une mise à jour du firmware, un déplacement de baies, ou un « on a nettoyé les câbles ».

Réalité : les labels ZFS sont sur les disques, mais Linux peut ne pas les présenter de façon cohérente, ou udev a changé les noms,
ou multipath crée des nœuds en double. Le pool peut être importable avec -d /dev/disk/by-id ou après correction de la découverte des périphériques.

2) Le pool semble « en cours d’utilisation » sur un autre système (hostid / multihost / import stale)

Symptômes : pool may be in use from another system. Ceci est courant après avoir cloné des disques de démarrage, restauré des images Proxmox,
ou importé un pool qui a été utilisé en dernier sur un autre nœud.

Réalité : ZFS tente d’éviter une situation où deux machines écrivent sur le même pool en même temps. Si vous êtes absolument sûr qu’un seul hôte a accès,
vous pouvez importer avec -f. Si vous n’en êtes pas sûr, arrêtez-vous et prouvez‑le.

3) Clé de chiffrement non disponible (chiffrement natif ZFS)

Symptômes : l’import réussit mais les datasets ne se montent pas, ou l’import échoue avec des erreurs liées aux clés.
Proxmox peut afficher le stockage comme présent mais inutilisable.

Réalité : le pool peut s’importer, mais les datasets restent verrouillés tant que les clés ne sont pas chargées. Parfois les gens confondent cela avec « le pool ne s’importe pas »
parce que leurs VM ne démarrent pas. C’est une panne différente, donc une correction différente.

4) Feature flags non supportés ou incompatibilité de version

Symptômes : l’import refuse avec des messages concernant des fonctionnalités non supportées, ou « pool uses the following feature(s) not supported by this system. »

Réalité : vous avez mis à jour le pool sur une version plus récente d’OpenZFS, puis tenté d’importer sur un nœud Proxmox ou mode rescue plus ancien.
La solution est généralement de démarrer un environnement moderne avec un OpenZFS compatible, pas de « rétrograder le pool » (impossible).

5) Dommages aux métadonnées / périphérique en défaillance / labels illisibles

Symptômes : erreurs I/O pendant l’import, cannot open sur des vdevs spécifiques, bad label, tentatives répétées, ou le pool apparaît dans zpool import mais échoue à l’import réel.

Réalité : un ou plusieurs périphériques ne peuvent pas lire des métadonnées critiques. La redondance aide. Sans redondance, vous êtes en mode récupération : essayez la lecture seule, l’import avec périphériques manquants,
et préparez‑vous à copier les données rapidement.

6) Courses d’import au démarrage et cachefiles obsolètes

Symptômes : le pool s’importe manuellement mais pas au démarrage ; le stockage Proxmox est « manquant » après reboot jusqu’à ce que vous exécutiez zpool import.

Réalité : les services d’import ZFS se sont exécutés avant que les périphériques soient prêts, ou le cachefile pointe vers d’anciens chemins. Le pool est sain ; la séquence de démarrage ne l’est pas.

Tâches pratiques : commandes, sorties, décisions (12+)

Voici les tâches que j’exécute réellement en incident. Chaque tâche inclut : la commande, un extrait de sortie réaliste, ce que cela signifie, et la décision que vous prenez.
Exécutez-les en root (ou avec sudo) sur le nœud Proxmox ou en shell de secours avec les outils ZFS installés.

Tâche 1 : Voir ce que ZFS pense pouvoir importer

cr0x@server:~$ zpool import
   pool: rpool
     id: 1234567890123456789
  state: ONLINE
 status: The pool was last accessed by another system.
 action: The pool can be imported using its name or numeric identifier and the '-f' flag.
 config:

        rpool       ONLINE
          sda3      ONLINE

Ce que cela signifie : ZFS voit le pool et ses vdev(s). Le blocage est « last accessed by another system ».

Décision : Avant d’utiliser -f, prouvez que seul cet hôte peut écrire sur ces disques (surtout si c’est du stockage partagé). Si ce sont des disques locaux mono‑hôte, procédez à un import forcé.

Tâche 2 : Obtenir des diagnostics d’import verbeux, y compris pools détruits (-D)

cr0x@server:~$ zpool import -D -d /dev/disk/by-id
pool: tank
  id: 9876543210987654321
state: UNAVAIL
status: One or more devices are missing from the system.
action: The pool cannot be imported. Attach the missing devices and try again.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-3C
config:

        tank                         UNAVAIL  missing device
          raidz1-0                   UNAVAIL
            wwn-0x5000cca2abcd0001   ONLINE
            wwn-0x5000cca2abcd0002   ONLINE
            wwn-0x5000cca2abcd0003   UNAVAIL

Ce que cela signifie : ZFS a une attente claire concernant le membre manquant. Ce n’est pas un problème de nommage ; il est absent/illisible.

Décision : Recherchez ce périphérique au niveau matériel. S’il est vraiment parti et que vous avez de la redondance, vous pouvez importer en dégradé. Si vous n’avez pas de redondance, priorisez l’imagerie/la copie de ce que vous pouvez.

Tâche 3 : Confirmer que le noyau voit des erreurs de stockage

cr0x@server:~$ dmesg -T | egrep -i "zfs|sd |sas|nvme|ata|reset|timed out|I/O error" | tail -n 12
[Thu Dec 26 10:12:09 2025] sd 2:0:3:0: timing out command, waited 180s
[Thu Dec 26 10:12:09 2025] sd 2:0:3:0: [sdd] tag#24 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
[Thu Dec 26 10:12:10 2025] blk_update_request: I/O error, dev sdd, sector 2048 op 0x0:(READ)
[Thu Dec 26 10:12:12 2025] ata4: hard resetting link
[Thu Dec 26 10:12:18 2025] sd 2:0:3:0: [sdd] Synchronizing SCSI cache

Ce que cela signifie : Ce n’est pas ZFS qui dramatise. L’OS ne peut pas lire de façon fiable à partir d’un périphérique.

Décision : Arrêtez d’essayer des flags d’import au hasard. Stabilisez le chemin matériel (remplacez le disque/câble/port HBA) ou attendez‑vous à une récupération partielle au mieux.

Tâche 4 : Vérifier que vous utilisez des identifiants de périphériques stables

cr0x@server:~$ ls -l /dev/disk/by-id | egrep "wwn|nvme|ata" | head
lrwxrwxrwx 1 root root  9 Dec 26 10:10 wwn-0x5000cca2abcd0001 -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 26 10:10 wwn-0x5000cca2abcd0002 -> ../../sdc
lrwxrwxrwx 1 root root  9 Dec 26 10:10 wwn-0x5000cca2abcd0003 -> ../../sdd
lrwxrwxrwx 1 root root 13 Dec 26 10:10 nvme-SAMSUNG_MZVL21T0HCLR-00000_S6Z7... -> ../../nvme0n1

Ce que cela signifie : Vous avez des symlinks basés sur WWN ; c’est ce que ZFS souhaite pour des imports cohérents.

Décision : Lors d’un import manuel, pointez ZFS vers /dev/disk/by-id avec zpool import -d. Si votre pool a été créé avec /dev/sdX, planifiez une remédiation (export/import ou mise à jour de configuration) une fois stable.

Tâche 5 : Identifier quels disques contiennent réellement des labels ZFS

cr0x@server:~$ for d in /dev/disk/by-id/wwn-*; do echo "== $d =="; zdb -l $d 2>/dev/null | egrep "name:|pool_guid|vdev_guid|state:"; done | head -n 20
== /dev/disk/by-id/wwn-0x5000cca2abcd0001 ==
    name: 'tank'
    state: 0
    pool_guid: 9876543210987654321
== /dev/disk/by-id/wwn-0x5000cca2abcd0002 ==
    name: 'tank'
    state: 0
    pool_guid: 9876543210987654321
== /dev/disk/by-id/wwn-0x5000cca2abcd0003 ==
    name: 'tank'
    state: 1
    pool_guid: 9876543210987654321

Ce que cela signifie : Ces périphériques appartiennent vraiment au pool, et l’un semble malade ou incomplet (state: 1 varie selon le contexte).

Décision : Si ZFS voit des labels sur les périphériques attendus, le problème est probablement d’accessibilité/vérifications de sécurité, pas « mauvais disques ». Si un disque n’a pas de label, vous regardez peut‑être le mauvais LUN ou le mauvais emplacement de baie.

Tâche 6 : Vérifier hostid et la propriété multihost pour expliquer « in use »

cr0x@server:~$ hostid
7f01000a
cr0x@server:~$ zpool get multihost tank
NAME  PROPERTY  VALUE     SOURCE
tank  multihost  on        local

Ce que cela signifie : multihost=on rend ZFS plus strict concernant l’accès concurrent. Un hostid changé (images OS clonées) peut déclencher ces avertissements.

Décision : Si ce pool est vraiment un stockage local mono‑hôte, envisagez de définir multihost=off plus tard. Pour l’instant, confirmez l’exclusivité et importez avec -f uniquement si vous pouvez le défendre.

Tâche 7 : Tenter un import en lecture seule (mode inspection sûr)

cr0x@server:~$ zpool import -o readonly=on -N -d /dev/disk/by-id tank
cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
        the pool to continue functioning in a degraded state.
config:

        NAME                         STATE     READ WRITE CKSUM
        tank                         DEGRADED     0     0     0
          raidz1-0                   DEGRADED     0     0     0
            wwn-0x5000cca2abcd0001   ONLINE       0     0     0
            wwn-0x5000cca2abcd0002   ONLINE       0     0     0
            wwn-0x5000cca2abcd0003   UNAVAIL      0     0     0  cannot open

Ce que cela signifie : Le pool peut être ouvert sans monter les datasets (-N) et sans écritures (readonly=on).

Décision : C’est un feu vert pour continuer prudemment : montez les datasets en lecture seule et copiez les données critiques, ou remplacez le disque manquant puis laissez resilverer.

Tâche 8 : Importer en acceptant un log manquant (si vous aviez un SLOG séparé)

cr0x@server:~$ zpool import -m -d /dev/disk/by-id tank
cannot import 'tank': one or more devices is currently unavailable
cr0x@server:~$ zpool import -m -o readonly=on -d /dev/disk/by-id tank
cr0x@server:~$ zpool status tank | egrep -i "logs|missing|unavail"
logs
  wwn-0x5000cca2beef0009   UNAVAIL  cannot open

Ce que cela signifie : Le périphérique manquant est un vdev de log. ZFS peut souvent s’importer sans lui avec -m si les vdevs principaux sont intacts.

Décision : Importez sans le log, acceptez une dégradation des performances, et planifiez la suppression/le remplacement du vdev de log correctement une fois stable.

Tâche 9 : Inspecter les services d’import ZFS et les échecs au démarrage

cr0x@server:~$ systemctl status zfs-import-cache zfs-import-scan --no-pager
● zfs-import-cache.service - Import ZFS pools by cache file
     Loaded: loaded (/lib/systemd/system/zfs-import-cache.service; enabled)
     Active: failed (Result: exit-code) since Thu 2025-12-26 10:01:21 UTC; 3min ago
   Process: 812 ExecStart=/sbin/zpool import -c /etc/zfs/zpool.cache -aN (code=exited, status=1/FAILURE)

● zfs-import-scan.service - Import ZFS pools by device scanning
     Loaded: loaded (/lib/systemd/system/zfs-import-scan.service; enabled)
     Active: inactive (dead)

Ce que cela signifie : L’import par cache a échoué, et l’import par scan n’a pas démarré (ou n’est pas activé). Classique « le pool s’importe manuellement, pas au démarrage ».

Décision : Corrigez le cachefile ou activez l’import par scan. Investiguer aussi pourquoi les périphériques n’étaient pas prêts quand le cache import a tourné.

Tâche 10 : Lire le journal pour des indices d’import ZFS (généralement franc)

cr0x@server:~$ journalctl -u zfs-import-cache -u zfs-import-scan -b --no-pager | tail -n 40
Dec 26 10:01:20 server zpool[812]: cannot import 'tank': one or more devices is currently unavailable
Dec 26 10:01:20 server zpool[812]: Destroy and re-create the pool from a backup source.
Dec 26 10:01:20 server systemd[1]: zfs-import-cache.service: Main process exited, code=exited, status=1/FAILURE
Dec 26 10:01:21 server systemd[1]: zfs-import-cache.service: Failed with result 'exit-code'.

Ce que cela signifie : L’import a échoué pour la même raison qu’en manuel. Ce n’est pas de la « dramaturgie systemd » ; c’est la disponibilité des périphériques.

Décision : Retournez à l’énumération des périphériques et aux erreurs matérielles. Si l’import fonctionne manuellement après un délai, vous avez probablement un problème de timing au démarrage.

Tâche 11 : Vérifier les conflits multipath (fréquent avec SAN/iSCSI/FC)

cr0x@server:~$ multipath -ll | head -n 25
mpatha (3600508b400105e210000900000490000) dm-2 IBM,2145
size=2.0T features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 3:0:0:1 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 4:0:0:1 sdc 8:32 active ready running

Ce que cela signifie : Le même LUN est visible via plusieurs chemins et agrégé correctement en /dev/dm-2 comme mpatha.

Décision : Assurez-vous que ZFS utilise le périphérique multipath de façon cohérente (dm-id) et que vous n’importez pas accidentellement en utilisant les chemins bruts /dev/sdb//dev/sdc. La visibilité en double peut causer de la corruption si mal gérée.

Tâche 12 : Vérifier la compatibilité des fonctionnalités du pool (surtout en environnement rescue)

cr0x@server:~$ zpool import -o readonly=on -N tank
cannot import 'tank': unsupported feature(s)
This pool uses the following feature(s) not supported by this system:
        org.openzfs:encryption
        org.openzfs:project_quota

Ce que cela signifie : Votre userspace/noyau ZFS actuel ne comprend pas le pool. C’est courant en bootant un live ISO plus ancien.

Décision : Démarrez une version Proxmox (ou un environnement rescue) avec un OpenZFS moderne qui supporte ces fonctionnalités. N’essayez pas de « réparer » depuis un environnement incompatible.

Tâche 13 : Charger les clés de chiffrement et monter les datasets (cas « pool importé mais rien ne marche »)

cr0x@server:~$ zpool import -N -d /dev/disk/by-id tank
cr0x@server:~$ zfs get -r -o name,property,value keystatus tank | head
NAME          PROPERTY   VALUE
tank/secure   keystatus  unavailable
tank/vmdata   keystatus  available
cr0x@server:~$ zfs load-key -r tank/secure
Enter passphrase for 'tank/secure':
cr0x@server:~$ zfs mount -a
cr0x@server:~$ zfs get -r -o name,mounted,mountpoint mounted tank/secure | head -n 3
NAME         MOUNTED  MOUNTPOINT
tank/secure  yes      /tank/secure

Ce que cela signifie : L’import du pool est correct. Votre problème était des datasets verrouillés.

Décision : Corrigez la gestion des clés (prompt au démarrage vs fichiers de clés vs KMS externe). Ne poursuivez pas une chasse aux « échecs d’import » fantômes dans l’interface.

Tâche 14 : Confirmer que le pool n’est pas déjà importé (oui, ça arrive)

cr0x@server:~$ zpool list
NAME   SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank  5.45T  3.12T  2.33T        -         -    18%    57%  1.00x  ONLINE  -
cr0x@server:~$ pvesm status | head
Name             Type     Status           Total            Used       Available        %
local             dir     active       102399872        4823424        972...          4%

Ce que cela signifie : Le pool est déjà importé et sain. La plainte peut être un problème de montage de dataset, un décalage de configuration de stockage, ou une définition Proxmox pointant ailleurs.

Décision : Passez de « import » à « pourquoi Proxmox ne l’utilise pas » : vérifiez les mountpoints des datasets, /etc/pve/storage.cfg, et les permissions.

Tâche 15 : Tenter un import forcé (seulement après avoir prouvé l’exclusivité)

cr0x@server:~$ zpool import -f -d /dev/disk/by-id rpool
cr0x@server:~$ zpool status rpool
  pool: rpool
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          sda3      ONLINE       0     0     0

Ce que cela signifie : L’avertissement « in use » a été levé par l’import forcé.

Décision : Si ce pool est un jour visible par un autre hôte, corrigez le modèle de fencing/ownership sous‑jacent. L’import forcé est un outil, pas un mode de vie.

Options de récupération classées par risque

Tier 0 : Ne pas empirer

• Évitez zpool clear en réflexe. Cela efface des erreurs ; ça ne corrige pas la cause.
• Évitez d’écrire sur un pool que vous n’avez pas validé. Importez en lecture seule d’abord si vous avez un doute.
• Évitez zpool labelclear sauf si vous détruisez volontairement des labels (et que vous êtes sûr d’être sur les bons disques).
• Évitez « essayer des flags au hasard jusqu’à ce que ça marche ». C’est la façon de transformer un pool récupérable en artefact d’analyse forensique.

Tier 1 : Imports sûrs et inspections

• Import en lecture seule : zpool import -o readonly=on -N ... vous permet d’inspecter sans modifier l’état sur disque.
• Import sans montage : -N empêche les mounts de datasets pour que vous puissiez corriger mountpoints ou clés délibérément.
• Répertoire de périphériques explicite : -d /dev/disk/by-id évite la roulette des noms de périphériques.

Tier 2 : Overrides contrôlés pour scénarios connus

• Import forcé (-f) : seulement quand vous avez prouvé que le pool n’est importé nulle part ailleurs et que vous contrôlez tous les chemins.
• Log manquant (-m) : si un SLOG dédié est disparu. Importez, puis retirez/remplacez le log proprement.
• Import avec root alternatif (-R /mnt) : montez les datasets sous un root temporaire pour copier sans perturber les mountpoints normaux.

Tier 3 : Imports dégradés et évacuation des données

• Importer dégradé quand la redondance existe et qu’un périphérique est manquant. Importez en lecture seule si vous doutez de la santé des disques restants.
• Copier rapidement les disques VM et configurations critiques. Si un disque est en train de lâcher, le resilvering ajoute du stress ; la copie peut être plus rapide ; choisissez la voie qui extrait les données le plus vite.

Tier 4 : Derniers recours

• Récupération extrême avec outils de débogage ZFS (zdb en modes avancés) peut parfois récupérer des informations, mais à ce stade traitez le pool comme instable et priorisez l’extraction des données.
• Récupération professionnelle pour des données irremplaçables sans redondance. Si vous pensez « peut‑être on continue d’essayer », vous êtes probablement sur le point d’effacer la dernière métadonnée lisible.

Une idée paraphrasée de Werner Vogels : « Everything fails all the time. » ZFS est conçu pour cela. Vos pratiques opérationnelles devraient l’être également.

Blague #1 : ZFS ne « perd » pas vos disques ; il vous force simplement à apprendre enfin quel câble va où.

Erreurs courantes : symptôme → cause → correction

1) « Aucun pool disponible à l’import » après avoir déplacé des disques

Symptôme : zpool import ne montre rien.

Cause : Vous scannez le mauvais espace de noms de périphériques (par ex. derrière multipath), ou le HBA ne présente pas les disques, ou vous avez démarré un noyau sans le driver.

Correction : Vérifiez les disques avec lsblk, contrôlez dmesg pour l’attachement des drivers, scannez avec zpool import -d /dev/disk/by-id, et résolvez multipath pour obtenir un ensemble canonique de périphériques.

2) « Pool may be in use from another system » et des gens utilisent -f aveuglément

Symptôme : L’import demande -f.

Cause : Un accès partagé est possible (SAN, JBOD partagé, double chemin accidentel). Ou hostid a changé suite à un clonage.

Correction : Prouvez l’exclusivité (physiquement ou via contrôle d’accès côté cible). Ensuite utilisez zpool import -f. Si hostid est instable, corrigez /etc/hostid et évitez de cloner des images OS sans régénérer cet identifiant.

3) Le pool s’importe, mais le stockage Proxmox semble toujours mort

Symptôme : zpool list montre le pool en ligne, pourtant l’interface affiche le stockage « inactif » ou les VM ne démarrent pas.

Cause : Datasets non montés, mountpoints changés, clés de chiffrement non chargées, ou /etc/pve/storage.cfg pointe vers un dataset qui n’existe plus.

Correction : zfs mount -a, vérifiez zfs get mountpoint,mounted, chargez les clés et validez /etc/pve/storage.cfg par rapport aux datasets/ZVOL réels.

4) L’import échoue seulement au démarrage, mais l’import manuel fonctionne

Symptôme : Après un reboot, le pool est manquant jusqu’à ce que vous exécutiez une commande.

Cause : La découverte des périphériques est tardive (initialisation HBA, login iSCSI, multipath), et l’import par cache s’exécute trop tôt ou pointe vers des chemins obsolètes.

Correction : Activez l’import par scan, corrigez l’ordre iSCSI/multipath, régénérez /etc/zfs/zpool.cache en export/import propre pendant une fenêtre de maintenance, et assurez les dépendances de services.

5) « Unsupported feature(s) » en mode rescue

Symptôme : Le pool est visible mais refuse l’import avec une liste de fonctionnalités.

Cause : L’environnement rescue utilise un OpenZFS plus ancien que celui requis par le pool.

Correction : Utilisez un kernel/userspace Proxmox moderne compatible avec le jeu de fonctionnalités du pool. N’« upgradez » pas le pool sur un hôte sans plan pour les environnements de récupération.

6) Tentative d’import dégradé sur un pool non redondant

Symptôme : Pool mono‑disque dont le disque unique est manquant, ou miroir avec une face manquante et corruption silencieuse.

Cause : Pas de redondance ou les deux côtés impactés ; ZFS ne peut pas conjurer des blocs hors de la physique.

Correction : Récupération au niveau matériel (ramener le périphérique), puis évacuation immédiate des données. Si c’est vraiment perdu, restaurez depuis la sauvegarde. Si pas de sauvegarde, la correction est « apprendre et budgéter ».

Checklists / plan étape par étape

Checklist A : Triage « le pool ne s’importe pas » en 15 minutes

1. Confirmer l’exclusivité : assurez‑vous qu’aucun autre hôte ne voit les disques/LUNs.
2. Exécuter zpool import et capturez le message exact.
3. Vérifier la présence des périphériques : lsblk -o NAME,SIZE,MODEL,SERIAL et ls -l /dev/disk/by-id.
4. Scanner les erreurs noyau : dmesg -T | tail et rechercher timeouts/resets.
5. Tenter un import lecture seule sans montage : zpool import -o readonly=on -N -d /dev/disk/by-id POOL.
6. Si import réussi : vérifiez zpool status et décidez « resilver vs copie des données d’abord ».
7. Si échec : contrôlez les feature flags, périphériques manquants, et signaux hostid/multihost.

Checklist B : Workflow de récupération quand un vdev est manquant mais la redondance existe

1. Importer en lecture seule d’abord pour valider que les périphériques restants sont stables.
2. Collecter zpool status -v et compteurs d’erreurs ; si ils augmentent à l’arrêt, le matériel est encore malade.
3. Remplacer/restaurer le chemin du disque manquant (changer le disque, reseat, corriger multipath).
4. Importer en lecture/écriture et lancer le resilver quand vous êtes confiant que le bus est stable.
5. Surveiller la progression du resilver et les logs système pour resets/timeouts.
6. Après le resilver, lancer un scrub.

Checklist C : Échecs d’import au démarrage

1. Confirmer que l’import manuel fonctionne de façon répétée.
2. Vérifier systemctl status zfs-import-cache zfs-import-scan.
3. Vérifier l’ordre iSCSI/multipath (si utilisé) : les périphériques doivent exister avant que l’import ZFS s’exécute.
4. Régénérer le cachefile en export/import propre pendant une fenêtre de maintenance.
5. Redémarrer une fois. Si ça marche, redémarrez encore. Ne déclarez pas la victoire après un seul reboot.

Blague #2 : « Ça a marché après un redémarrage » n’est pas une correction ; c’est un retournement de situation.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : L’incident causé par une fausse hypothèse

Une entreprise de taille moyenne exploitait Proxmox sur deux nœuds avec une baie SAS partagée. Quelqu’un l’avait étiquetée « comme un SAN mais moins cher », indice clair que ça deviendrait cher plus tard.
Ils avaient mis ZFS au‑dessus de la baie partagée parce que « ça marchait bien en test ».

Un après‑midi, un nœud a redémarré après une mise à jour du kernel. Le pool ne s’est pas auto‑importé, et l’ingénieur en astreinte a fait ce que fait tout humain impatient :
il a exécuté zpool import -f parce que l’outil le proposait. Le pool est monté. Les VM ont démarré. Tout le monde a poussé un soupir.

L’autre nœud, qui avait encore un accès physique à la baie, était aussi configuré pour importer le même pool pour une expérimentation antérieure.
Il ne l’avait pas importé à ce moment, mais il exécutait du monitoring et des règles udev qui touchaient parfois les périphériques.
Quelques heures plus tard, une tâche programmée a déclenché une tentative d’import là‑bas aussi, et elle a utilisé -f parce que le runbook le recommandait.

Ils ont eu un scénario classique de split‑brain écritures. ZFS a fait de son mieux, mais aucun système de fichiers ne peut concilier deux écrivains sur les mêmes blocs sans coordination.
La corruption n’a pas été immédiate ; elle s’est manifestée par des erreurs « aléatoires » sur les disques VM et un démantèlement lent de la confiance.

La correction n’a pas été brillante. Ce fut de la gouvernance : fencing, suppression de la visibilité partagée, et arrêter le mythe que ZFS est un système de fichiers cluster. Ce n’est pas le cas.
Ils ont reconstruit le pool à partir des sauvegardes. Le vrai changement a été politique : « prouver l’exclusivité » est devenu une étape non négociable.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre équipe exploitait Proxmox avec ZFS sur des LUNs iSCSI. Ça peut fonctionner, mais c’est un pacte avec le diable : il faut gérer multipath constamment et éviter le churn des périphériques.
Ils voulaient des imports plus rapides et des boots accélérés, ils ont donc ajusté : ont fixé les imports sur un cachefile, désactivé l’import par scan, et réduit les délais de démarrage.

Ça a tenu jusqu’à ce qu’un basculement de contrôleur SAN rende les chemins des LUN visibles quelques secondes plus tard que d’habitude au démarrage.
L’import-cache ZFS a tourné tôt, n’a pas vu les périphériques attendus et a échoué. Comme l’import par scan était désactivé, rien n’a retenté.
Proxmox démarrait sans stockage. Le cluster considérait le nœud vivant mais sans ressources, combo amusant.

L’astreinte a fait un import manuel et tout est reparti. C’est le piège : les corrections manuelles vous font croire que le système est fiable.
Mais cela arrivait à chaque cold boot quand le SAN décidait d’être dramatique.

La correction finale fut ennuyeuse : réactiver l’import par scan en fallback, ajouter des dépendances pour que iSCSI login et multipath se stabilisent avant l’import ZFS,
et régénérer le cachefile après avoir confirmé des noms by-id stables. Le démarrage a gagné quelques secondes ; l’uptime a perdu de l’excitation.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Une entreprise dans la finance utilisait Proxmox avec des disques de boot miroir et un pool ZFS séparé pour le stockage VM. Rien d’exotique : HBAs en mode IT, disques avec WWN,
datasets nommés de façon sensée, et des rapports de scrub mensuels envoyés à une boîte mail que personne ne lisait — jusqu’au jour où ils l’ont lus.

Un matin après un incident électrique, un nœud a refusé d’importer le pool VM. L’erreur indiquait « one or more devices is currently unavailable. »
Plutôt que de paniquer, ils ont suivi leur checklist : confirmer l’inventaire des périphériques, vérifier dmesg, tenter un import en lecture seule.
Le pool s’est importé en dégradé ; un disque était vraiment mort.

Le détail clé : parce qu’ils faisaient des scrubs régulièrement, ils savaient déjà que les disques restants étaient propres la semaine précédente.
Cela a changé le calcul décisionnel. Ils ont importé en lecture/écriture, remplacé le disque défaillant, laissé resilverer, puis lancé un scrub.
Le downtime des VM a été mesuré dans une fenêtre de maintenance, pas dans un changement de carrière.

Le post-mortem fut presque ennuyeux. « Disque mort ; redondance a joué ; historique de scrub confirmé ; remplacement effectué. »
C’est l’histoire que vous voulez en exploitation : rien n’a explosé.

FAQ

1) Dois‑je toujours utiliser zpool import -f si ZFS le suggère ?

Non. N’utilisez -f que lorsque vous avez prouvé que le pool n’est importé nulle part ailleurs et qu’aucun autre hôte ne peut écrire sur ces périphériques.
Sur du stockage partagé, l’import forcé est la façon d’acheter de la corruption en urgence.

2) Que signifie généralement « no pools available to import » sur Proxmox ?

ZFS n’a pas trouvé de labels. C’est typiquement des drivers manquants, des périphériques absents, le mauvais espace de noms (multipath vs brut),
ou vous ne regardez pas les disques que vous croyez voir.

3) Si je peux importer en lecture seule, est‑ce que mon pool est garanti sain ?

C’est un bon indicateur que les métadonnées clés sont lisibles et cohérentes, mais cela ne garantit pas la stabilité future.
Le matériel peut se dégrader sous charge. Utilisez l’import en lecture seule pour inspecter, puis décidez de resilver ou d’évacuer les données en premier.

4) Pourquoi Proxmox échoue‑t‑il parfois à importer au démarrage mais fonctionne manuellement ?

Séquençage du démarrage. Les périphériques apparaissent tard (init HBA, login iSCSI, stabilisation multipath), tandis que les services d’import ZFS tournent tôt.
Corrigez l’ordre et les mécanismes de repli ; ne comptez pas sur « quelqu’un qui exécute la commande ».

5) Puis‑je « rétrograder » un pool ZFS pour l’importer sur un Proxmox plus ancien ?

Non. Si le pool utilise des feature flags non supportés par l’environnement plus ancien, vous avez besoin d’un environnement plus récent pour l’importer.
Planifiez les mises à niveau avec les outils de récupération en tête.

6) Pool importé mais datasets non montés. Est‑ce un échec d’import ?

Généralement non. C’est un problème de montage/clé/mountpoint. Vérifiez zfs mount, zfs get mounted,mountpoint, et le keystatus.
Le stockage Proxmox peut sembler « down » alors qu’il est en réalité « verrouillé » ou « non monté ».

7) Est‑il sûr d’importer un pool avec des périphériques manquants ?

Si la redondance existe et que ZFS indique qu’il y a suffisamment de répliques, cela peut être sûr, surtout en lecture seule au début.
Si la redondance n’existe pas, « périphérique manquant » signifie souvent « données manquantes ».

8) Effacer les erreurs avec zpool clear aide‑t‑il les problèmes d’import ?

Rarement. Cela efface des compteurs d’erreurs et peut réactiver un périphérique après des fautes transitoires, mais cela ne résout pas les timeouts, câblage,
disques défaillants, duplication multipath, ou fonctionnalités non supportées.

9) Quelle est la meilleure stratégie de chemins de périphériques pour les pools ZFS sous Proxmox ?

Utilisez systématiquement /dev/disk/by-id (WWN ou numéro de série NVMe). Évitez /dev/sdX.
Si vous utilisez SAN/multipath, assurez‑vous que ZFS utilise un ensemble canonique de périphériques (typiquement dm-id) et jamais à la fois les nœuds bruts et multipath.

10) Quand est‑il approprié d’utiliser zpool import -m ?

Lorsque un périphérique de log séparé (SLOG) est manquant et empêche l’import. Cela permet l’import sans ce log.
Vous devrez ensuite retirer/remplacer proprement le vdev de log pour éviter des avertissements répétés et des comportements étranges.

Conclusion : prochaines étapes à réaliser aujourd’hui

« Cannot import pool » n’est pas un problème unique. C’est une famille de symptômes. Le chemin le plus rapide est un triage discipliné :
vérifiez les périphériques, lisez la plainte exacte de ZFS, importez en lecture seule quand vous n’êtes pas sûr, et n’escaladez vers le forcé/dégradé qu’avec un argument de sécurité clair.

Prochaines étapes pratiques qui réduisent la douleur future :

• Standardisez l’usage de /dev/disk/by-id pour tous les pools et documentez le mappage WWN → emplacement physique.
• Rendez « prouver l’exclusivité » obligatoire avant -f sur tout stockage pouvant être partagé.
• Testez la récupération sur un environnement moderne capable d’importer le jeu de fonctionnalités de votre pool (surtout chiffrement).
• Activez et surveillez les scrubs, et traitez les rapports de scrub comme des signaux opérationnels, pas du bruit de fond.
• Corrigez l’ordre de démarrage si vous dépendez d’iSCSI/multipath ; les imports manuels ne sont pas un SLO.

Quand vous êtes en incident : collectez d’abord des preuves, puis agissez. ZFS vous dira généralement ce qui ne va pas. Il suffit d’écouter plus longtemps que votre adrénaline ne le voudrait.