J’avais présenté il y a quelques temps l’offre kDrive d’Infomaniak dans ce post. Il se trouve que j’y ai introduit une erreur que je tiens à rectifier ici. Jusqu’à présent j’utilisais leur application maison kDrive dont il existe un appimage pour Linux pour synchroniser mes données. Elle se présente comme cela:
kDrive
Les dernières versions ont apporté des régressions qui m’ont causé un tas de problème de synchronisation, heureusement que j’entretiens 3 sauvegardes au total pour éviter la perte sèche de données. J’y ai passé des heures pour tout remettre en place et mes échanges avec la hotline ont été vain pour comprendre pourquoi ça dysfonctionnait. Lors de mon dernier échange avec la hotline, j’ai appris qu’il était possible de se connecter au kDrive via WebDAV et donc d’utiliser un outil comme rclone, ce que je ne pensais pas possible jusqu’à présent à tort.
Aussitôt dit, aussitôt fait, j’ai mis en place avec des scripts bash deux synchronisations avec rclone qui m’ont permis d’abandonner définitivement l’application kDrive dédiée:
une synchronisation asynchrone pour mes photos que je lance ponctuellement de mon PC où elles sont stockées physiquement ;
une synchronisation synchrone qui se lance automatiquement via cron toutes les semaines pour mes données de bureautique et les pages de mes sites.
J’utilisais jusqu’à présent et depuis 7 ans un serveur Dell PowerEdge T310 après avoir utilisé pendant 5 ans un PowerEdge 840. Dans un récent article j’indiquais que j’avais passé mes services réseau sur un mini PC Lenovo ThinkCenter M92p pour des considérations économiques mais que j’avais conservé mon serveur Dell pour le stockage des fichiers multimédia et que j’allumais que quand j’avais besoin d’y accéder.
Il se trouve que j’ai décidé d’abandonner le serveur Dell car ayant mis en place les redondances nécessaires pour mes fichiers multimédia, je ne voyais plus la nécessité de conserver une machine gourmande en énergie, bruyante et encombrante. D’autant que j’avais de temps à autre à reconstruire mon espace RAID5 qui devenait capricieux pour un gain du RAID5 de plus en plus discutable.
Voilà donc la nouvelle architecture que j’ai mise en place pour l’archivage longue durée des données froides, celles qui évoluent peu et prennent beaucoup de place et la sauvegarde des données chaudes, celles qui évoluent rapidement et qui prennent assez peu de place disque.
Architecture réseau local d’archivage et de sauvegarde
Les données chaudes sont essentiellement mes données de bureautique les fichiers systèmes et les mails. Les données froides sont les fichiers multimédia, comme les photos et les vidéos. J’ai réussi à me passer de mon serveur Dell en mettant en place les redondances nécessaires pour sauvegarder mes données froides.
Pour résumer les données chaudes présentes sur le mini serveur M92p nommé Ultra sont sauvegardées sur 4 supports différents à savoir :
kdrive d’infomaniak avec l’application kDrive qui se lance à chaque démarrage du PC Predator via un partage réseau d’Ultra (sauvegarde incrémentale)
un disque de 4To branché en USB directement sur Ultra (sauvegarde incrémentale) via un script basé sur borg
Les données froides se trouvent physiquement sur le PC Predator et sont sauvegardées sur:
un TerraMaster D5-300C de 5 disques en dispatchant sur plusieurs disques, sachant que je compte le booster avec les 4 disques de 4To que je vais récupérer du RAID5 de mon Dell, la sauvegarde est manuelle et se fait via Unison
kdrive d’infomaniak manuellement (via un navigateur) mais seulement pour les photos
Pour les données froides il existe dont trois supports de sauvegarde pour les photos et deux pour les vidéos, mais à terme je rajouterai un troisième disque dans le terramaster dédié à la sauvegarde des vidéos.
A partir de toutes ces considérations, j’estime que mon serveur Dell ne sert plus à rien et que je peux maintenant m’en débarrasser sans regret. J’ai considérablement allégé mon réseau local, par ailleurs en déportant la sauvegarde à distance j’ai amélioré sensiblement les risques de perte de données.
Maintenant pour mon serveur Dell, il me reste à voir qui voudra encore le récupérer pour qu’il ne finisse pas dans la benne à métaux.
Jusqu’à présent je me suis beaucoup focalisé sur les solutions de sauvegarde de mes données sans m’attarder sur leur archivage. Ce post résume un peu toutes mes cogitations sur la sauvegarde. Mais au fait quelle est la différence entre sauvegarde et archivage ? En deux mots la sauvegarde est une copie identique des données à un moment donné qui permet une restitution en cas de pertes des données d’origine. Alors que l’archivage est une copie des données avec une notion de gestion de version, c’est à dire qu’on dispose de plusieurs enregistrements effectués à des dates différentes. Cet article explique assez bien la nuance entre les deux.
J’ai donc mis assez simplement un archivage chiffré basé sur rclone sur Google Drive en mode synchronisation. Le script est assez simple et ressemble à ça
Les anciennes versions des fichiers seront sauvegardées avec le suffixe date et heure sous cette forme .2021-12-04–07:55:25. En cas de synchronisation et d’archivage on a ce message.
1
2
3
4
5
6
7
8
2021/12/04 16:35:09 INFO : mana/data/bureautique/Finance/les comptes.ods: Moved (server-side) to: mana/data/bureautique/Finance/les comptes.ods.2021-12-04--16:34:59
2021/12/04 16:35:35 INFO : mana/data/bureautique/Finance/les comptes.ods: Copied (new)
Il ne reste plus qu’à lancer le script de manière régulière avec cron pour mettre en place un archivage régulier. Vous trouverez plus de détails sur la configuration de rclone pour une synchronisation sur le cloud avec en exemple Google Drive avec chiffrement des données sur cette page de funix.org.
J’ai considérablement étoffé mon dispositif de sauvegarde de mes données. J’évoquais dans ce post un premier dispositif basé sur un script bash lui même basé sur rsync qui permettait une sauvegarde incrémentale. Malheureusement j’ai rencontré un crash disque « bas bruit » qui a entraîne une corruption des données et de la sauvegarde sans que je m’en rende compte immédiatement. Suite à cet incident j’avais amélioré mon dispositif de sauvegarde et des tests d’intégrité des disques qui est décrit dans cet autre post. J’avais fait part de mes déboires sur le site linuxfrdans ce journal. Les commentaires m’ont conduit à revoir complètement mon dispositif qui repose maintenant sur les outils borg, btrfs et unison.
Tout cela est présenté et détaillé sur cette page de funix.org. et à fait l’objet de cet autre journal sur linuxfr. Les commentaires m’ont poussé à aller encore plus loin en rendant mon dispositif de sauvegarde encore plus robuste. Je l’ai donc complété par :
– une solution de sauvegarde et de partage des données base sur un cloud payant kdrive d’infomaniak avec un dispositif de synchronisation automatique et des sauvegardes manuelles. Cette sauvegarde à distance vient compléter le dispositif local et permet de le rendre encore plus robuste à un sinistre qui détruirait à la fois le serveur et les sauvegardes locales. Un troisième journal sur linuxfr détaille ce point précis, je vous invite à découvrir les commentaires qui ont été faits sur ces trois journaux qui sont assez instructifs sur les éventuelles autres solutions de sauvegarde.
– une pure solution de sauvegarde avec des données stockées chiffrées en utilisant rclone et Google Drive. Ce dernier offre une solution gratuite jusqu’à 15Go, ce qui est généralement largement suffisant pour stocker des données sensibles (hors fichiers multimédia). Si on peut s’inquiéter de la protection des données et de l’utilisation que Google peut en faire, le problème ne se pose pas car elles sont envoyées chiffrées et stockées en l’état sur le drive. C’est donc bien de la pure sauvegarde plutôt que du partage de données. A noter que ce ne sera possible avec infomaniak qu’après souscription à l’offre supplémentaire Swiss Backup.
J’ai connu en début d’année des déboires suite à un crash disque inopiné comme je l’évoque dans ce post. En fait un problème disque bas bruit, non détecté, a conduit à la corruption de données, données qui ont été sauvegardées en écrasant la sauvegarde saine. J’ai été surpris par le crash disk qui est arrivé sans crier gare, et c’est seulement en remontant ma sauvegarde que je me suis rendu compte de sa corruption. Malgré des heures passées à tenter de récupérer les données manquantes avec photorec entre autres, j’ai perdu dans l’affaire pas mal de données essentiellement des fichiers multimédia patiemment emmagasinés depuis des années.
Suite à cet incident, j’avais revu de fond en comble ma stratégie de sauvegarde qu’on peut retrouver dans cet autre post. J’avais évoqué mes déboires et présenté fièrement cette nouvelle stratégie dans ce journal sur linuxfr. Bien m’en a pris, les commentaires qui m’ont été faits m’ont ouvert les yeux et j’ai revue de fond en comble ma stratégie de sauvegarde qui ressemble maintenant à quelque chose comme cela :
Depuis maintenant 20 ans la numérisation touche tous les domaines, dans le domaine privé, cela concerne des données de bureautique, les échanges par mail mais également tous les fichiers multimédia photo, vidéo et images. Récemment je me pensais à l’abri de la perte de données, je suis équipé depuis des années d’un serveur Dell PowerEdge avec RAID matériel acheté d’occasion sur Ebay (PowerEdge 840 puis T310) et je fais des sauvegardes régulières sur disque dur externe USB grâce à un script lancé automatiquement avec l’utilitaire cron. Les données les plus précieuses se retrouvent sur un autre disque externe que je stocke au boulot. Mon RAID était basé sur 4 disques Seagate ST2000DM01 de 2To chacun de 2015, alors certes le RAID n’est pas assimilable à de la sauvegarde, c’est juste un système de redondance qui dispatche les données sur plusieurs disques pour éviter de tout perdre quand un disque crashe, la tolérance au panne est donc censée être meilleure qu’avec un seul disque.
Il se trouve cependant que j’ai eu au printemps dernier une panne de mon RAID bas bruit, le RAID est passé en mode dégradé avec la perte d’un disque. Puis un second disque du RAID a commandé à défaillir, c’est là que j’ai commencé à m’en rendre compte car j’ai eu un certain nombre d’erreurs système qui remontaient. Dans ce post je relate cet incident. Il était temps de changer 2 disques de mon RAID qui avaient 5 ans, après avoir fonctionné quasiment 24h/24 7j/7 dans la période. Cette durée de vie me paraît correcte pour des disques bas de gamme. Je les ai remplacés par des Seagate IronWolf de 3To. Mon RAID 5 est donc maintenant constitué de 2 disques Seagate ST2000DM01 de 2015 et de 2 disques Seagate IronWolf de 3To ce qui donne une capacité utile de 5,5To. D’ailleurs il faut sans doute que je songe à changer les deux disques les plus anciens.
Après avoir réinstallé mon RAID avec les nouveaux disques j’ai redescendu la sauvegarde , c’est là que je me suis rendu compte qu’il manquait un paquet de fichiers. Sur le coup je n’ai pas compris car les sauvegardes avaient été régulières, j’ai reconstitué alors le fil du drame. Il y a eu un crash bas bruit sur le RAID qui a dégradé des données, la sauvegarde s’est faite normalement mais a supprimé les fichiers qui avaient disparu du RAID car corrompus. Mais quel crétin ! Je n’avais pas mis en place un test d’état de santé des disques et du RAID avant de lancer la sauvegarde. Du coup j’ai essayé de récupérer les fichiers supprimés de la sauvegarde avec Photorec, ça m’a pris beaucoup de temps (des mois !) car il y en avait pour des To, mais comme il y a eu plusieurs sauvegardes dans l’intervalle je n’ai récupéré au final que peu de choses. Dans l’histoire, j’ai perdu dans les 400 films et une centaine de vidéos perso
J’ai dû revoir de fond en comble ma pratique de la sauvegarde, mes données principales sont toujours stockées sur le RAID 5 et il existe toujours une sauvegarde journalière sur disque de USB externe. Mais j’ai rajouté des sauvegardes croisées avec d’autres PC que je lance manuellement avec unison au moins une fois par semaine et j’ai rajouté également des tests d’état de santé des disques, dès dégradation des disques les sauvegardes ne sont pas lancées, j’ai mis en place un système de mail automatique journalier qui m’informe de l’état des disques.
Pour mémoire, je dispose d’un serveur Dell PowerEdge T310 que j’ai acheté pour une poignée de figues sur ebay, d’occasion évidemment. Il me sert de serveur perso sur mon réseau local (serveur de fichiers via NFS et automontage sur les clients, de serveur de mail en réception et en émission, et de serveur d’authentification, entre autres), il me permet également d’envoyer et de recevoir des mails à partir de mon téléphone mobile où que je sois en fournissant un service de webmail à distance.
Il est installé dans le garage et tourne 7j/7 24h/24. Il est équipé d’une carte contrôleur RAID hard PERC 6/i et de 6 disques durs au total : 2 disques SATA en RAID 1 (installés d’origine à l’achat de la bête) pour le système et 4 disques SATA Seagata Barracuda en RAID 5 rajoutés en plus pour les données, c’est sans doute ce qui m’a coûté le plus cher pour monter cette configuration. A l’époque de mon achat (2015) j’avais installé la Mageia 5. Depuis par flemme et surtout car j’appréhendais le boulot vu la personnalisation poussée du serveur, j’avais repoussé aux calendes grecques sa mise à jour alors que Mageia 5 n’est plus maintenue depuis un certain temps. Et bien en fait, le serveur s’est rappelé à moi il y a quelques jours avec un disque SATA qui a lâché au bout de 5 ans de fonctionnement. C’est un modèle bas de gamme qui n’est pas prévu pour tourner 7j/7 24h/24. En farfouillant dans la configuration BIOS du contrôleur PERC 6/i, je découvre que j’ai un autre disque qui est à deux doigts de lâcher, je me retrouve avec un système virtuel RAID 5 fortement dégradé qui m’a généré une tonne d’erreurs de disques que j’ai dû traiter avec fsck. Au final j’ai laissé des plumes niveau données. Mais ouf ! Je suis bien content d’avoir programmé une sauvegarde incrémentale sur un autre disque externe (voir par là ). Tant qu’à faire à mettre les mains dans le cambouis, je me suis dit qu’il était temps de migrer vers Mageia 7.1, j’ai fait le choix de ne pas refaire une installation complète pour ne pas perdre toute ma configuration et gagner du temps. J’ai donc opéré une migration vers la 6 puis vers la 7.1 et là bluffé j’ai retrouvé tous mes petits et pourtant j’avais de quoi m’inquiéter avec tout ce qui tourne dessus en version packagée, compilée et fortement personnalisée. Je dois juste déplorer qu’il n’a pas repris le fichier de configuration de sendmail, mais à part ça rien à redire.
Me voilà donc avec un serveur up to date. Pour reconstruire le RAID, j’ai installé 2 disques Seagate de la gamme au dessus, des IronWolf qui sont donnés pour pouvoir tourner 7j/7 et 24h/24, en espérant tout de même qu’ils tiennent plus que 5 ans.