Cela a commencé un samedi soir avec ma femme qui demandait pourquoi notre enregistreur vidéo numérique avait soudainement cessé de jouer une émission qu’elle regardait. Je lui ai dit que c'était probablement juste un petit problème, mais je jetterais un coup d'oeil. J'entre dans la salle familiale pour regarder et l'erreur indique essentiellement que le disque sous-jacent n'est plus disponible. Pas bon! C'était le début de mon histoire d'horreur de trois jours…
Un peu de fond
Mon DVR est en fait juste un logiciel spécialisé (SageTV pour ceux qui sont curieux) fonctionnant sur un PC. Le logiciel est très flexible et vous permet d’en séparer tous les aspects. J'ai une machine séparée pour le contrôle, la planification et l'enregistrement centralisés, des machines séparées pour la lecture et l'étoile de cette histoire, une machine séparée pour le stockage. Pour le stockage, j'utilise un serveur de fichiers Linux, en utilisant LVM (Logical Volume Manager) pour regrouper de nombreux lecteurs distincts et non identiques en un seul lecteur logique de grande taille (environ 6 To actuellement) visible par le système d'exploitation. Depuis la sauvegarde de plusieurs To de données n'est pas pratique, et puisque ces données sont «juste» des émissions télévisées, ma philosophie de sauvegarde pour cela a toujours été de ne pas m'en soucier. Jusqu'à récemment, cette philosophie n'avait pas été testée par un événement réel.
Tenter de récupérer les données
En voyant l'erreur sur le DVR, je commence immédiatement à regarder le serveur de stockage. Le système de fichiers est incroyablement lent et lent à répondre. Je demande donc à LVM l’état des disques physiques sous-jacents à son volume logique. Après un long délai, il se lève et indique qu'un lecteur de 750 Go est manquant. Uh-oh! Je redémarre le serveur et étonnamment, le lecteur revient. J'émets une commande pvmove pour migrer automatiquement toutes les données de ce lecteur, mais elles échouent à moins de 2%.
Face à un lecteur très peu coopératif quant à la lecture de ses données, mais qui apparaît au moins dans le BIOS, je me tourne vers mon outil de récupération de lecteur préféré, Spinrite. Bien que Spinrite démarre normalement à partir de supports amovibles, il y a des années, j’ai mis en place un démarrage réseau chez moi pour différents utilitaires afin que je n’aie plus à me soucier de garder trace de tout support. Normalement, je me connecte simplement à mon réseau, je sélectionne le démarrage à partir du réseau et je dispose de nombreux outils pour résoudre de nombreux problèmes. Le problème est que la machine qui fait tout ce travail magique est la même machine qui est actuellement en panne. Pas grave, dis-je, je vais démarrer à partir d'un CD Spinrite. Sauf qu'il y a quelques années, le lecteur optique de mon serveur de fichiers a abandonné le fantôme. À ce moment-là, j'ai décidé que je n'utilisais jamais de support optique dans cette machine, je n'avais donc pas besoin de le remplacer. Pas de souci, me suis-je dit, je vais simplement sortir le lecteur optique de mon ordinateur principal. J'éteins mon ordinateur principal et retire le lecteur optique. Ensuite, je cherche mon CD de démarrage Spinrite. Je ne le trouve pas! Nous avons emménagé dans une nouvelle maison il y a quelques mois, alors tout est un peu en désarroi. Je pense que je vais juste graver une nouvelle copie, mais je ne peux même pas trouver de support optique vierge! Sur le prochain plan, un lecteur flash bootable! Après quelques minutes sur Google pour rafraîchir ma mémoire, j'ai un lecteur flash Spinrite amorçable. Je démarre ma machine Linux à partir de cela et lance Spinrite. L'ordinateur se fige et semble se bloquer. Cherchant à éliminer les variables, je déplace le disque défectueux d’être inséré dans une carte d’extension PCI-e vers un ordinateur directement connecté à la carte mère. Maintenant, Spinrite se lance bien, mais il faut énormément de temps pour énumérer les disques qui y sont connectés. Je débranche systématiquement tous les autres lecteurs sauf le mauvais, mais il ne termine jamais l'énumération des lecteurs, peu importe le temps que j'attends. Sur le prochain plan! Je sors le disque de mon ordinateur Linux, le connecte à mon ordinateur principal et démarre à partir de mon tout nouveau lecteur flash Spinrite. Spinrite se lance et voit immédiatement le lecteur, et je lui dis de commencer à récupérer les données, convaincu que je progresse enfin. Je reviens le vérifier après peut-être 10 minutes et il y a une erreur à l'écran et il semble que le lecteur a de nouveau disparu. Frustré, j'essaie quelques fois de plus et dis à Spinrite de commencer à différentes parties du lecteur, mais d'obtenir le même résultat à chaque fois. Il semble que cela ne va pas m'aider après tout.
Dans un élan d'espoir irrationnel, j'ai remis le lecteur dans ma machine Linux et je l'ai mis sous tension. À mon grand étonnement, le lecteur apparaît et LVM active tout. Pour tenter plus de chance, j’émets une autre commande pvmove pour essayer de déplacer à nouveau les données du lecteur. Au début, je vois des messages d'erreur indiquant que je ne peux pas lire le disque, mais étonnamment, le pvmove continue de progresser, se rapprochant de plus en plus de 100%. Un mélange de confusion, de soulagement et d’excitation me submerge. Vais-je m'éloigner de cet homme indemne? Malheureusement, la dernière chose que LVM fait sous les couvertures pour terminer proprement un pvmove est d'écrire un journal mis à jour sur tous les lecteurs sous son contrôle. Cela échoue bien sûr lorsqu’il essaie d’écrire sur le mauvais disque, ce qui annule l’ensemble du processus. Défaite arraché à la gueule de la victoire une fois de plus! Je me replonge dans Google et découvre qu'il est possible de contrôler la quantité de données que la commande pvmove déplace au lieu de déplacer TOUTES les données d'un coup. J'expérimente cela et réussis à déplacer une infime partie de mes données à la fois. Je deviens gourmand et le lecteur disparaît plusieurs fois, mais revient toujours après un cycle d'alimentation de l'ordinateur. Théorisant que peut-être seulement certaines parties du disque sont mauvaises, je commence à sauter au lieu de travailler sur le début du disque. Après quelques itérations de cela, j'ai tout sauf 40 Go sur 750 Go transférés en toute sécurité hors du lecteur. Pour les 40 Go restants, il n’a pas bougé, peu importe ce que j’ai essayé. C'était maintenant dimanche soir et j'étais épuisé, alors j'ai décidé de me coucher et de m'attaquer davantage à ce problème le lendemain.
Le lendemain, après un peu de sommeil et la première moitié de ma journée de travail, je décide de mordre la balle parce que je ne me soucie pas des 40 derniers Go d'émissions de télévision enregistrées et décide de retirer le lecteur de ma configuration LVM. . Je l'ai déjà fait plusieurs fois auparavant, donc ça se passe assez bien. Suivant sur la liste de nettoyage est la réparation du trou au milieu du système de fichiers. Je pense qu'avec seulement 40 Go au lieu de 750 Go, ça ne peut pas être trop grave, non? Faux! Après la réparation, il me restait 900 Go d’espace libre supplémentaire par rapport à avant le début de l’épreuve, ce qui me piquait un peu. Oh bien, je me dis, c'était juste la télé de toute façon. Mon DVR est enfin opérationnel après trois jours d'arrêt, et je peux enfin arrêter de penser à cela à chaque cycle cérébral disponible.
Leçons apprises
Alors qu'est-ce que j'ai appris de tout ça? J'aurais dû faire un meilleur travail de ce qui comptait vraiment. Cela s'est passé il y a quelques semaines et à ce moment-là, aucun contenu télévisé qui avait disparu n'a été oublié. Cependant, je regrette de m'être évité, mais surtout avec ma famille, de pouvoir utiliser la télévision pendant trois jours et de m'être mis en crise pendant ces trois jours. Si j'avais renoncé à récupérer mes données au début, la fonction aurait été restaurée en environ une heure, et non trois jours. Je sais trop bien que la plupart du temps, nos données sont précieuses, mais ce n’était pas le cas.
Deuxièmement, si vos données sont vraiment précieuses et qu’elles le sont à 99%, vous devez les protéger! Sauvegardez vos données, il n'y a pas d'excuses. Pour des données irremplaçables, telles que des milliers de photos de mon fils que j'ai sur mon ordinateur, je veille à les sauvegarder à au moins trois emplacements, dont l'un est un fournisseur de sauvegarde sur le cloud. En ce qui concerne le stockage DVR, je ne pense toujours pas qu’il soit pratique de le sauvegarder sur le cloud, mais avec le prix des lecteurs, je n’ai aucune excuse pour ne pas le faire protéger par le RAID, et c’est justement ce que je souhaite. va faire. Lorsque j'ai installé mon cluster de stockage pour la première fois il y a quelques années, je pense qu'il m'a fallu 10 disques ou plus pour accéder à un pool de plusieurs To. Je viens de vérifier les prix et vous pouvez acheter un disque de 3 To maintenant pour moins de 100 dollars. Je n'ai simplement aucune excuse pour laisser mes données non protégées, et si une perte de données comme celle-ci m'arrive à nouveau, c'est vraiment de ma faute.
