Grâce à ZFS, la perte de données s’est limitée à seulement 10 minutes

 (mastodon.social)
3 points par GN⁺ 2023-08-24 | 1 commentaires | Partager sur WhatsApp
  • Un SSD vieux de 2 ans est soudainement tombé en panne, mais la réplication incrémentale ZFS a permis de ressusciter le système sur un nouveau disque, avec une perte réelle d’environ 10 minutes seulement
  • L’architecture prenait un snapshot toutes les 10 minutes de l’ensemble du système de fichiers pour l’envoyer vers un NAS, avec zrepl pour l’automatisation
  • Les snapshots enregistrent l’état du système à un instant donné, même en cours d’exécution, et ne transfèrent que les changements, ce qui permettait une réplication en arrière-plan sur un réseau domestique
  • Le processus de restauration a nécessité un zfs receive de 625GiB lancé toute la nuit, et il a aussi fallu restaurer la wrapper key de chiffrement, loin d’une récupération automatique
  • ZFS implique un coût d’adoption initial et une maintenance lourde, mais il a démontré un véritable effet de reprise après sinistre en restaurant jusqu’à l’état de travail au moment de la panne

Après la panne du SSD, il ne restait que 10 minutes de perte

  • Au moment d’ouvrir le portable pour envoyer un e-mail, l’écran était figé sur du noir, puis après redémarrage il est apparu que le SSD, vieux de 2 ans, était mort
  • Après restauration du système sur un nouveau disque, la machine a pu être réutilisée, et la perte totale de données s’est limitée à environ 10 minutes
  • Le portable restauré a redémarré là où il s’était arrêté, et même les onglets du navigateur ont ressuscité le travail inachevé de la veille au soir
  • Comme dans une publicité Chromebook d’il y a 12 ans, l’idée de reprendre son état précédent sur un nouvel appareil a réellement fonctionné dans cette panne

Une architecture plus proche de la réplication que de la sauvegarde

  • Au lieu de simplement sauvegarder le disque, l’auteur a choisi une approche de réplication de l’ensemble du système de fichiers
  • L’hiver dernier, un stockage réseau domestique a été mis en place pour les sauvegardes périodiques de plusieurs ordinateurs utilisés pour la création, et parmi les différentes options, la réplication incrémentale ZFS a été retenue
  • ZFS permet de créer efficacement des snapshots d’un instant précis, même sur un système en cours d’exécution
  • Ensuite, lors de l’envoi vers une autre machine, il n’est pas nécessaire de retransférer toutes les données : seules les données modifiées sont envoyées

Envoi vers le NAS toutes les 10 minutes avec zrepl

  • zrepl a été utilisé pour automatiser la création des snapshots et leur envoi vers le NAS
  • La configuration prenait un snapshot toutes les 10 minutes de l’ensemble du système de fichiers avant transmission
  • Grâce aux snapshots incrémentaux, il était possible de garder la réplique à jour même en l’exécutant en arrière-plan sur un réseau domestique
  • La dernière exécution a pris 14 secondes pour transférer environ 64MiB

La restauration a révélé une charge importante de travail manuel

  • La restauration du système a été un processus nécessitant de l’apprentissage, reposant en grande partie sur du travail manuel
  • L’opération zfs receive de 625GiB a dû tourner toute la nuit
  • Les snapshots étant chiffrés par l’ordinateur source, le NAS ne pouvait pas en lire le contenu
  • Pour pouvoir réellement utiliser la sauvegarde, il a aussi fallu restaurer la wrapper key de chiffrement
  • Jusqu’à la première confirmation qu’il était possible de déchiffrer les données, la restauration a été très angoissante

Coût d’adoption et remplacement matériel

  • La configuration initiale de ZFS imposait de remplacer l’ensemble du système de fichiers, ce qui entraînait un coût de départ élevé
  • La maintenance demande beaucoup de connaissances spécifiques et s’accompagne de procédures d’exploitation incluant des interventions manuelles
  • Malgré tout, avoir mis en place la réplication avant la première panne du SSD a été une chance, et ce cas a mis en évidence les avantages de ZFS
  • Le disque mort était à l’origine un WD_BLACK SN850 inclus dans une commande Framework
    • L’auteur avait déjà vu sur le forum Framework des cas inquiétants de ce disque mourant soudainement ou devenant non amorçable
  • Le même jour, un SSD SK Hynix P41 et un boîtier NVMe Sabrent ont été livrés depuis Amazon en environ 3 heures

À lire aussi

1 commentaires

 
GN⁺ 2023-08-24
Avis sur Hacker News

  • Comme il utilise ZFS, il était mieux préparé que d’autres utilisateurs de SSD WD ou SanDisk
    https://petapixel.com/2023/08/08/sandisk-portable-ssds-are-failing-so-frequently-we-can-no-longer-recommend-them/
    https://www.theverge.com/22291828/sandisk-extreme-pro-portable-my-passport-failure-continued
    https://news.ycombinator.com/item?id=37042587
    https://www.theverge.com/23837513/western-digital-sandisk-ssd-corrupted-deleted-questions
    https://news.ycombinator.com/item?id=37188736

  • Juste avant de quitter complètement le monde Linux, j’ai commencé à creuser un peu cet iceberg qu’est btrfs, et c’était assez intéressant
    Il semblait avoir beaucoup de potentiel sur plusieurs fonctionnalités, comme l’innovation côté sauvegardes ou la configuration des disques. btrfs n’est pas ZFS, mais il y a des recouvrements fonctionnels, et c’est aussi assez proche du « ZFS du pauvre ». De plus, ZFS a une situation un peu ambiguë côté licence, packaging et inclusion dans le noyau, donc sur certains systèmes d’exploitation btrfs se comporte de façon bien plus raisonnable
    Dans un Linux User Group, j’ai dit que j’avais dû débrancher le câble d’alimentation pour redémarrer un ordinateur ; je me suis fait sévèrement engueuler pour cette bêtise, et on m’a conseillé d’utiliser ZFS. Cela dit, si l’on considère que ce système était un Raspberry Pi, on peut changer d’avis sur lequel de ces deux choix était le plus judicieux

    • On dit que les Pi peuvent subir des corruptions de système de fichiers, mais à chaque installation d’image je lance un script qui monte tmpfs un peu partout et désactive la plupart des logs inutiles, donc je ne l’ai jamais constaté moi-même
      Tant qu’on ne maltraite pas la carte SD, ces machines tournent de façon très stable. ZFS a vraiment l’air génial, mais même si j’achète un NAS un jour, je ne pense pas vouloir payer pour du matériel capable de faire tourner ZFS, donc je finirai probablement avec du RAID et ext4
      J’ai continué à éviter btrfs parce que, tous les quelques mois, je voyais un billet du genre « BTRFS a détruit mes données », suivi d’un débat pour savoir si c’était vraiment la faute de btrfs. J’ai l’impression d’en voir moins aujourd’hui, donc il est peut-être temps d’y rejeter un œil
    • Par curiosité, qu’est-ce qui t’a poussé à quitter complètement le monde Linux ? Qu’est-ce que la « communauté » pourrait apprendre de cette expérience pour s’améliorer vis-à-vis des autres ?
    • La seule chose que je n’aime vraiment pas avec btrfs, c’est qu’il a tendance à provoquer de la fragmentation
      Surtout avec les images de VM creuses ; pour cet usage, je trouve que zvol est bien meilleur

  • Il y a quelques années, il y a eu la crise des condensateurs, et maintenant j’ai l’impression qu’on traverse une crise du stockage
    Le fait que tous les supports de stockage empirent devient absurde. WD gâche les HDD avec le SMR, et les fabricants disent que trois ans de fonctionnement pour les SSD et HDD, c’est déjà trop long — et ce n’est pas une blague. Rien que cette année, un SSD Kingston est mort ; bon, il avait environ 8 ans, passe encore, mais un HDD portable WD est aussi mort au bout d’environ 2 ans
    Aujourd’hui, Internet est rempli de problèmes de perte de données et de durée de vie. Il y a 20 ans, les HDD n’étaient pas non plus faits pour durer éternellement, mais j’ai le souvenir qu’ils tenaient au moins nettement plus longtemps que la durée de vie utile de l’ordinateur acheté avec

    • Les disques durs actuels ont eu bien plus de chance qu’il y a 20 ans
      Il y a 20 ans, c’était l’époque des tristement célèbres disques IBM Deathstar, dont le revêtement magnétique se détachait littéralement des plateaux. Il y avait aussi ces horribles disques Maxtor qui mouraient au bout d’un ou deux ans, et après le rachat de Maxtor par Seagate, les disques Seagate sont devenus peu fiables pendant un temps. En administrant un serveur avec environ 8 disques, il fallait en remplacer un à peu près chaque année
      À l’inverse, aujourd’hui j’aide à gérer un serveur ZFS avec plus de 20 disques, et leur durée de vie tourne autour de 4 à 5 ans. Et les ordinateurs de l’époque devenaient obsolètes bien plus vite. Aujourd’hui, un ordinateur de 6 ans peut encore être parfaitement utilisable, alors qu’à l’époque un ordinateur de 3 ans se faisait déjà nettement sentir
    • Pas d’inquiétude. Bientôt, les puces aussi commenceront à dysfonctionner après quelques années
      On se heurte aux limites de la mise à l’échelle, et la croissance exponentielle ralentit
    • Personnellement, je me souviens que par le passé, les HDD à moi et à des gens autour de moi tombaient parfois en panne
      Aujourd’hui, ça m’arrive très rarement avec les SSD. Même un vieux SSD Intel de la fin des années 2000, pourtant connu comme problématique, fonctionne encore très bien dans le même vieux MacBook que j’ai utilisé quelques années avant de le donner à ma mère. Je me demande dans quel état sont les données réelles
    • Tous les disques WD que j’ai achetés ces dix dernières années ont fonctionné comme prévu. Y compris ceux pour NAS achetés après l’introduction du SMR, parce que j’ai veillé à prendre des Plus ou des Pro, pas de simples Red
      J’ai aussi eu de la chance avec les SSD, mais sur desktop je garde encore le répertoire /home et mes grappes RAID sur de vieux disques rotatifs, donc je n’utilise que de petits SSD
      Il y a eu deux exceptions. J’avais retiré deux WD Red pré-SMR d’un vieux NAS pour les remplacer par des disques plus gros ; ils étaient en parfait état de marche, je les ai mis dans des sachets antistatiques et rangés dans un tiroir. Environ 2,5 ans plus tard, j’ai eu besoin d’un disque de secours, je les ai sortis pour les tester, et aucun des deux ne fonctionnait : l’un était complètement mort, l’autre était à peine détecté et illisible. Le premier n’apparaissait pas du tout quand je le branchais ; j’ai nettoyé tous les contacts, y compris les broches du PCB contrôleur, sans effet, donc j’ai fini par le jeter. Le second n’a pu être réutilisé qu’après un reformatage complet, mais même avec testdisk, il n’y avait aucun moyen de récupérer les anciennes données. Je n’avais jamais vécu ni prévu ce genre de chose, et honnêtement ça m’inquiète pas mal
    • Il y a environ 20 ans, il y avait aussi les HGST “Deathstar”, des disques tellement mauvais qu’ils ont donné lieu à une action collective
      Les disques sont toujours morts de façon aléatoire, et c’est aussi l’une des raisons pour lesquelles Sun a créé ZFS

  • Pour résumer très brièvement, le fil Mastodon pointe vers https://zrepl.github.io
    « zrepl est une solution intégrée et tout-en-un pour la réplication ZFS »

    • Quelqu’un sait-il en quoi zrepl et sanoid/syncoid diffèrent, à part le fait que zrepl est écrit en Go et que sanoid/syncoid sont des scripts Perl ?
    • On dirait qu’il faut communiquer avec un démon qui tourne sur le serveur de stockage
      Par exemple, ce serait super de pouvoir utiliser directement S3 comme stockage

  • Zrepl est l’une des grandes raisons pour lesquelles je peux vivre en nomade numérique l’esprit tranquille
    Un script lancé environ une fois par nuit ouvre un pool ZFS protégé par LUKS avec un en-tête séparé, puis copie tous les snapshots. Ce boîtier NVME reste toujours dans le « sac » qui ne me quitte jamais
    Grâce à cette configuration et à NixOS, je peux provisionner un nouveau portable identique en environ 10 minutes. Récemment, j’ai aussi ajouté une réplication hors site, donc même si je me faisais très violemment braquer, la probabilité de perte de données sérieuse serait presque nulle
    Zrepl est un logiciel vraiment excellent. Il est facile à prendre en main, mais suffisamment raffiné et puissant pour permettre de toucher à tous les réglages si nécessaire. Je n’en dirai jamais assez de bien

    • Ça semble bien plus sûr que la situation de la plupart des gens, pour qui un seul vol, incendie, dégât des eaux ou autre catastrophe suffit à tout perdre
    • Tu as déjà essayé sanoid/syncoid ? Qu’est-ce que Zrepl apporte en plus par rapport à eux ?
    • Ce serait bien que tu écrives un billet expliquant comment cette configuration fonctionne. Ça a l’air assez intéressant

  • Le fait de prendre un instantané toutes les 10 minutes du système de fichiers a-t-il pu contribuer à la mort du SSD ?

    • ZFS est particulier et, comme il utilise la copie à l’écriture, le coût de création des instantanés est faible
      Intuitivement, même avec des instantanés très fréquents, le volume d’écritures supplémentaires doit rester assez faible. Cela dit, ce serait bien d’avoir des mesures scientifiques
      Sur certains serveurs que j’administrais auparavant, je prenais avec ZFS des instantanés toutes les minutes, toutes les heures et tous les jours. Les instantanés à la minute étaient supprimés au bout de 60 minutes, et une tâche cron sur une autre machine sauvegardait les instantanés horaires et quotidiens. Les instantanés horaires étaient conservés environ 72 heures, et les instantanés quotidiens devaient être conservés indéfiniment. Les instantanés à la minute servaient à revenir en arrière en cas d’erreur manuelle pendant une migration SQL, et cela fonctionnait bien
      J’utilise encore ZFS sur des serveurs FreeBSD, mais mes projets actuels ont peu de trafic et les modifications de données importantes sont rares. Sur mes serveurs personnels, je prends donc à peu près un instantané manuel par semaine et je déclenche manuellement la sauvegarde depuis un autre serveur. Désormais, je ne prends aussi des instantanés que de la partie du système de fichiers contenant les bases PostgreSQL et les données applicatives. Les données du système d’exploitation ne me préoccupent plus vraiment. En cas de panne matérielle grave, je réinstalle l’OS, je garde une trace des paramètres importants, et quand le script de sauvegarde s’exécute, il copie ces valeurs plutôt que diverses autres bricoles
    • C’est peu probable
      Les instantanés écrivent peu, et les SSD comme ZFS fonctionnent tous deux en copie à l’écriture. Autrement dit, le coût des écritures après un instantané est le même qu’avant l’instantané
      Il manque toutefois du contexte. Ni les SSD ni ZFS n’aiment être pleins ou presque pleins. Si les données de travail faisaient environ 650 Go et que le disque faisait 1 To, les instantanés ont facilement pu faire passer l’occupation au-dessus de 90 %. Rien que cela a pu mettre ZFS dans une situation inconfortable
    • D’après ce que je comprends, prendre un instantané dans ZFS consiste à écrire un objet de métadonnées et quelques références de données
      En supposant 100 Go de données, une taille de bloc de 128K et des pointeurs 64 bits, les nouvelles données écrites pendant un instantané devraient être de l’ordre de 5 Mo. Si l’on fait cela 6 fois par heure, soit 52 560 fois par an, cela représente environ 256 Go par an. C’est probablement moins de 1 % de l’endurance en écriture d’un SSD. Je serais donc surpris que les instantanés toutes les 10 minutes soient une cause importante
      Je peux me tromper, et cette estimation vient d’une source d’aide pas très fiable. Les corrections sont les bienvenues. Cela dit, si mon estimation est supérieure à la réalité et qu’elle a malgré tout peu de chances d’affecter la durée de vie, la question elle-même n’a peut-être pas grand intérêt
    • C’est peu probable. Un instantané consiste en gros à marquer les blocs les plus récemment écrits et à empêcher les anciens blocs d’être modifiés
      ZFS étant en copie à l’écriture, les modifications de fichiers provoquent les mêmes écritures, simplement certaines anciennes données ne sont pas supprimées
    • D’après un commentaire sur un site orange quelconque[1], la taille minimale d’écriture des puces flash modernes pourrait être d’environ 100 Mo
      Dans ce cas, des écritures de 5 Mo toutes les 10 minutes deviendraient en réalité 600 Mo par heure, 4,8 To pour une journée de travail de 8 heures, 24 To pour une semaine de 40 heures, soit 3,43 DWPD en temps réel sur un disque de 1 To, et 2500 TBW sur 2 ans en temps réel[2]
      L’endurance officielle du SN850 est de 600 TBW, mais elle est évidemment probablement abaissée de manière conservatrice pour des raisons de garantie. Par coïncidence, 2500 To est aussi une valeur d’endurance courante pour beaucoup de SSD sur ce marché. Dans l’ensemble, cela ne semble pas totalement impossible
      S’il est encore en vie, je serais curieux de savoir ce que dit le contrôleur dans les données SMART. Sous Linux, apt install smartmontools; smartctl -s on /dev/sda; smartctl -A /dev/sda devrait afficher un tableau[4]. Sous Windows, il suffit d’installer CrystalDiskInfo[3]
      1: https://news.ycombinator.com/item?id=29165202
      2: DWPD: drive writes per day, TBW: Total Bytes Written - in terabytes
      3: https://crystalmark.info/en/software/crystaldiskinfo/
      4: « Pre-fail » signifie que la valeur est censée changer juste avant une panne, et « Old_age » signifie qu’il s’agit d’une valeur liée à l’âge ; cela ne veut pas dire « ceci est mauvais et va bientôt tomber en panne » ni « ce disque est vieux ». Pre-fail et Old_age sont toujours affichés pour toutes les entrées. Je pense que quelqu’un aurait dû les renommer depuis longtemps en « somewhat_boolean » et « life_remain »

  • En général, je fais des sauvegardes incrémentales Apple Time Machine vers un serveur Synology à disques rotatifs
    Quand je fais une opération risquée ou que je mets à niveau une machine, il m’arrive aussi de mettre en miroir le disque interne sur un SSD externe. Cette méthode fonctionne bien. Les restaurations Time Machine peuvent être assez lentes, mais comme l’essentiel de mes données importantes est dans Git et des dépôts hébergés, cela n’a pas été un gros problème. J’utilise parfois Time Machine quand je veux revenir à une version précédente d’un seul fichier
    J’ai aussi l’un des tristement célèbres[0] disques SanDisk, mais je ne l’utilise pour rien d’important. Il ne contient guère que une bibliothèque de jeux. Comme je suis utilisateur Mac, les jeux ne sont pas un élément majeur, et je ne vais pas pleurer s’ils disparaissent
    [0] https://arstechnica.com/gadgets/2023/08/sandisk-extreme-ssds-are-worthless-multiple-lawsuits-against-wd-say/

    • Moi aussi, j’utilise Time Machine. J’ai récupéré l’app https://tclementdev.com/timemachineeditor/ pour déclencher manuellement les sauvegardes TM chaque fois que la machine est inactive
      Ça semble fonctionner bien mieux que les sauvegardes automatiques d’Apple ou celles basées sur l’heure
    • J’ai abandonné Time Machine. Même avec atalk et autres sur Synology, ça a rarement fonctionné correctement plus d’un mois ou deux

  • Mes snapshots sont chiffrés sur l’ordinateur d’origine. Le fait que le NAS ne puisse pas les lire est plutôt cool
    Donc, pour utiliser la sauvegarde, il fallait aussi restaurer la wrapper key de chiffrement. Sans mentir, c’était assez angoissant jusqu’à la première confirmation que les données pouvaient être déchiffrées
    Avec une méthode de sauvegarde personnalisée, il ne faut pas partir du principe qu’elle fonctionne tant qu’on n’a pas vérifié qu’on peut effectivement restaurer les données périodiquement

    • C’est pareil pour les sauvegardes non personnalisées
    • Je me disais toujours qu’il faudrait, au cas où, conserver une copie du LUKS header sur un disque séparé

  • Le futur proche de Linux ici, c’est bcachefs
    https://bcachefs.org/

    • Qu’est-ce que bcachefs fait mieux que BTRFS ou ZFS ?
    • Pour un « futur proche », il est déjà en développement depuis 7 ans et n’a toujours pas été accepté en upstream
      Le travail d’intégration upstream est certes en cours
    • Il y a un court résumé de ce qui devrait nous enthousiasmer ? Des fonctionnalités sympa ?

  • « C’était assez angoissant jusqu’à la première confirmation que les données pouvaient être déchiffrées » donne l’impression que la procédure avait été moins testée et moins documentée qu’idéalement
    Ce n’est pas très rare sur un système domestique ou un poste personnel. Mais sur un serveur de production, on n’a pas envie d’improviser la procédure de restauration sur le moment

    • Exact. Je savais que j’avais tous les éléments nécessaires à la restauration, et j’avais même fait un test six mois auparavant, mais au début j’avais copié la mauvaise clé
      Quand le chargement a échoué, j’ai eu un bref moment de désespoir, mais j’ai vite compris mon erreur. Dans ces moments d’échec, toutes les failles du processus apparaissent avec une clarté aveuglante