5 votes

Peut ZFS send/receive m'aider à récupérer d'une perte partielle de pool après une mise à niveau vers Ubuntu 22?

J'ai un pool ZFS de longue date sous Ubuntu, qui a subi de nombreuses mises à niveau. Après la mise à niveau d'Ubuntu 20 à 22, les systèmes de fichiers chiffrés refusent de se monter, bien que le reste semble correct. zpool status -v signale une erreur permanente ZFS-8000-8A à la racine du système de fichiers chiffré. Je constate qu'il y a un gros saut dans la version du package zfsutils-linux, de 0.8.3 à 2.1.5.

Le pool peut encore être importé sur un système Ubuntu 20, et le système de fichiers chiffré peut toujours être monté là-bas. Tout semble correct. De plus, je suis capable de zfs send de Ubuntu 20 et zfs receive sur Ubuntu 22, avec un succès apparent.

Si je zfs send l'intégralité du pool (ou le faire en parties) de Ubuntu 20 (ZFS 0.8.3) à Ubuntu 22 (ZFS 2.1.5) et que l'opération réussit, aurais-je créé un pool exempt de problèmes de mise à niveau? Autrement dit, l'opération de réception construira-t-elle un pool entièrement à jour avec ZFS? Ou les problèmes de compatibilité pourraient-ils passer par le lien?

Je ne connais pas suffisamment le niveau auquel zfs send/receive opère pour être sûr de ne pas rencontrer de nouvelles corruptions sous Ubuntu 22.

Je suis prêt à re-chiffrer les systèmes de fichiers chiffrés si nécessaire, au lieu de les envoyer bruts. Tout se passerait en local. Dans ce cas, Ubuntu 20 s'exécute dans une machine virtuelle LXD avec les périphériques de disque attachés, et le canal send/receive ne traverse aucun réseau.

Veuillez noter que je suis conscient des conseils de jeter l'ensemble du pool et de le restaurer à partir d'une sauvegarde. J'essaie de récupérer sans avoir à recourir à cela, car il semble que je puisse lire le pool.

Tous les disques passent les longs tests SMART, et le nettoyage du pool sous Ubuntu 20 ne montre aucune erreur.

Je serais très content si l'on me disait (avec des citations) que l'erreur est limitée aux systèmes de fichiers chiffrés et que je peux les remplacer et continuer sans reconstruire l'ensemble du pool, mais je ne connais pas suffisamment les détails de ZFS pour en être sûr. Je serais intéressé par la manière de le découvrir.

1voto

shodanshok Points 42743

Tout d'abord, bien que la mise à niveau de 0.8.3 à 2.1.5 soit sûrement importante, elle ne devrait pas se terminer par un pool (partiellement) cassé. Je suggère donc d'ouvrir une issue GitHub (ou d'écrire à la liste de diffusion zfs-discuss).

Cela dit, envoyer le pool sans les options --raw ou --compress est certainement une bonne stratégie pour récupérer toutes les données : un zfs send complet est très similaire à parcourir logiquement l'ensemble du pool avec, par exemple, rsync (il y a des différences importantes dans la manipulation de la taille d'enregistrement mais elles ne sont pas significatives en ce qui concerne le chiffrement).

Si cela échoue, vous pouvez utiliser un simple rsync entre les deux pools/ensembles de données.

1voto

rptb1 Points 161

J'ai travaillé sur le problème et j'ai posté des détails sur la liste de diffusion zfs-discuss. Je posterai les informations ici au cas où cela aiderait d'autres personnes. Ma solution a impliqué un long temps d'arrêt du serveur. Il existe des correctifs disponibles dans le bug Ubuntu #1987190 qui peuvent mieux fonctionner si vous ne pouvez pas tolérer cela.

J'ai trouvé plusieurs problèmes ZFS sur GitHub liés à mes problèmes :

Le bug concerne les métadonnées des systèmes de fichiers créés avec un chiffrement native avec des versions ZFS plus anciennes.

J'ai réparé le pool comme ceci :

  1. Installé Ubuntu 22 sur un disque externe avec un pool ZFS frais et démarré le serveur sur ce disque.

  2. Exécuté Ubuntu 20 dans une VM sur ce système, et attaché les disques membres du pool du serveur à cette VM.

  3. Importé l'ancien pool dans la VM.

  4. Monté les systèmes de fichiers "endommagés" dans la VM.

  5. zfs send de l'ancien pool dans la VM à zfs receive dans le nouveau pool dans le système hôte. Cela corrige les métadonnées.

  6. Vérifié, revérifié, vérifié que toutes les données ont bien été transférées. (J'ai utilisé rsync -n --checksum sur des instantanés critiques dans .zfs/snapshot.)

  7. Tests SMART étendus et scrub complet sur l'ancien pool.

  8. Redémarré le serveur dans son Ubuntu 22. Aucun retour en arrière n'était nécessaire.

  9. Importé le pool ZFS frais depuis le disque externe.

  10. Détruit les systèmes de fichiers endommagés.

  11. zfs send depuis le pool frais vers l'ancien pool, recréant les systèmes de fichiers endommagés.

J'ai fait cela de cette manière car je me méfiais de l'intégrité de l'ancien pool et je ne voulais pas y toucher plus que nécessaire. En fait, je pense que j'aurais pu continuer à faire fonctionner le serveur sur l'ancien pool dans Ubuntu 22 et démarrer la VM Ubuntu 20 sur le serveur. Mais bien sûr, cela aurait échoué si le système d'exploitation lui-même était dans un système de fichiers endommagé.

J'espère que cela aidera toute autre personne ayant ce problème.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X