J'ai déjà dû raconter quelque part sur ce blog que je
suis obsédé par la préservation de
l'information. En particulier, l'idée de perdre des données
informatiques est quelque chose contre quoi je veux me garder le plus
sérieusement possible. Ça m'est déjà arrivé par le passé, à une
époque où les disques durs coûtaient strictement plus qu'une bouchée
de pain, et j'ai perdu des fichiers qui m'étaient
précieux[#]. Pour mes données
les plus précieuses, j'ai un système de sauvegarde où (1) les données
sont répliquées par RAID entre plusieurs disques
(cf. ci-dessous), (2) elles sont en plus répliquées chaque jour
par rsync
entre deux ordinateurs distants de 20km (et le point précédent
s'applique sur chacun de ces ordinateurs), (3) sur l'un de ces
ordinateurs, une copie est faite chaque nuit de tous les fichiers qui
ont changé, histoire de pouvoir extraire de vieilles versions si je me
rends compte que j'ai fait des changements malencontreux (ceci, en
plus du fait que beaucoup de données sont de toute façon sous contrôle
de git ; et le premier
point s'applique aussi à ces copies), et (4) une fois par an au moins,
je fais aussi une copie sur médias optiques, que j'archive. Avec tout
ça, je me sens raisonnablement en sécurité.
Le problème, c'est qu'à côté de ces données de grande importante
(très grossièrement, tous les fichiers que je crée moi-même), il y en
a d'autres, qui ne méritent pas des précautions aussi importantes, ou
surtout, qui ne les permettent pas parce que le volume de
données est trop important, mais qu'il m'embêterait quand même assez
sérieusement de perdre : des tas de choses que j'ai téléchargées sur
Internet (ou dont l'effet de rayons cosmiques aléatoires frappant mon
disque dur a causé l'apparition), ou encore des choses calculées par
des ordinateurs au prix d'heures de calculs que je n'ai pas envie de
refaire. Il me faut donc plusieurs niveaux intermédiaires entre les
données les plus importantes et les moins importantes (voire, celles
qui sont nettoyées automatiquement, comme le contenu
de /tmp).
Et un autre facteur qu'il ne faut pas perdre de vue, c'est le temps passé à restaurer les données en cas de problème : parfois les données elles-mêmes n'ont pas vraiment de valeur (comme pour les partitions système : il s'agit d'exécutables Linux qui de toute façon sont disponibles publiquement), mais le temps passé à les récupérer ou à les remettre en place peut justifier qu'on utilise tel ou tel mécanisme de sauvegarde.
J'en viens
à RAID :
pour ceux qui ne connaissent pas, cet acronym
signifie Redundant Array of Inexpensive Disks
.
L'idée est de partager des données entre plusieurs disques durs de
façon soit à augmenter la capacité ou la vitesse, soit à diminuer les
risques de pertes de données, soit les deux. En gros, vous
avez N disques (ou partitions de même taille sur des
disques différents), vous choisissez un niveau de
redondance k qui vous protège contre la panne simultanée
de k disques, et RAID vous présente
l'ensemble comme si vous aviez un seul disque de la capacité totale
de N−k disques, et qui peut résister à une
défaillance de k disques. En clair, il existe les
principaux niveaux suivants :
- RAID0, qui ne crée aucune redondance (k=0) : vos données sont réparties entre les N disques et il n'y a aucune protection contre les défaillances, bien au contraire, si un disque quelconque a un problème, toutes les données sont perdues. Ceci n'est donc utile que pour des données temporaires, ou très peu précieuses. L'avantage, c'est qu'on gagne en capacité et en vitesse de transfert (la capacité totale, comme la vitesse de transfert, est en gros celle de N disques).
- RAID1, qui est l'extrême inverse : la redondance est totale (k=N−1) : tous les disques contiennent une copie complète des données, ils sont miroirs les uns des autres. Même si tous les disques sauf un tombent en panne, les données sont sauves, puisque n'importe lequel permet de tout reconstituer.
- RAID5, qui est intermédiaire entre 0 et 1 (non, les numéros n'ont aucune logique, je suppose que c'est juste l'ordre d'introduction) : on a une redondance de k=1 disque. Autrement dit, RAID5 vous protège contre la panne d'un disque mais si deux disques tombent simultanément en panne, vos données sont perdues. En contrepartie, si vous avez N disques, vous avez la capacité de N−1 disques (et également un gain en vitesse, sur lequel je n'approfondis pas). Bien sûr, RAID5 n'a de sens que pour N≥3 disques (si on n'a que deux disques, soit on fait de la redondance et c'est du RAID1, soit on n'en fait pas et c'est du RAID0).
- RAID6, qui est aussi intermédiaire entre 0 et 1, mais plus proche du 1 que ne l'est le 5 : cette fois, on a une redondance de k=2 disques. Autrement dit, RAID5 vous protège contre la panne simultanée de deux disques (mais pas trois). En contrepartie, si vous avez N disques, vous avez la capacité de N−2 disques (et également un gain en vitesse, sur lequel je n'approfondis pas). Et RAID6 n'a de sens que pour N≥4 disques.
Lorsqu'on a 4 disques, toutes les possibilités sont représentées là : 0 disque de redondance pour RAID0, 1 pour RAID5, 2 pour RAID6 et 3 pour RAID1. (Je ne parle pas des autres niveaux de RAID, qui, à mon avis, ne sont pas très intéressants — par exemple le RAID10 est du RAID0 au-dessus de RAID1, qui entre 4 disques offre quelque part entre 1 et 2 disques de redondance vu qu'il peut subir la mort de 2 disques à condition que les 2 disques ne soient pas dans le même sous-tableau RAID1.)
En général, on ne choisit pas RAID1 entre un grand nombre de disques, ou, si on le fait, c'est pour des raisons différentes de la seule redondance (par exemple pour le fait que n'importe quel disque peut être lu pour trouver les données, ce qui peut être pratique lors du processus de démarrage). Certains peuvent se dire que RAID6, qui protège contre la panne simultanée de deux disques, est déjà un excès de précautions (quand un disque tombe en panne, on va le changer immédiatement, et il est peu vraisemblable qu'un autre disque tombe en panne pile à ce moment), mais c'est oublier que les pannes ne sont pas des événements indépendants : le même problème (un choc électrique ou mécanique, par exemple) peut causer la mort de plusieurs disques[#2], d'une part, et plus subtilement, l'utilisation du RAID lui-même peut causer la mort d'un disque (lorsqu'on remplace un disque dans un tableau RAID, il se produit une grande activité sur tout le tableau, qui peut accélérer la mort d'un disque) ; sans compter que si on a deux disques issus de la même série, ils peuvent avoir le même défaut de fabrication[#3]. Donc, deux disques de redondance, ce n'est pas forcément un luxe inutile.
Le RAID a aussi quelque chose de très agréable,
c'est qu'il est complètement transparent. Si un disque fait
une faute de lecture isolée, la couche RAID détecte
la faute, lit les données à partir des autres disques, réécrit le
secteur défectueux, ce qui cause sa réallocation par le firmware du
disque (donc en pratique « la corrige »), et on ne voit qu'un léger
délai. Si un disque meurt complètement, la
couche RAID finit par se lasser, chasse le disque
du tableau (qui devient alors dégradé
), et tout continue à
fonctionner, et quand vous achetez un nouveau disque pour le remplacer
et que vous l'ajoutez au tableau, les données sont automatiquement
copiées vers lui pour que le tableau cesse d'être dégradé. Pas besoin
de s'embêter à retrouver où on a mis des copies de sauvegarde ou quoi
que ce soit.
En contrepartie, RAID n'attrape pas tous les problèmes pour lesquels on fait des sauvegardes. Par exemple, si on efface un fichier malencontreusement, la couche RAID réplique l'effacement sur tous les disques, et ne vous protège pas du tout. Il existe des choses plus sophistiquées, comme des snapshots par copy-on-write (disponibles par exemple, sous Linux, dans BTRFS), mais cela, à son tour, ne vous protège pas contre des bugs du filesystem. Bref, il faut décider quelle assurance on veut, et contre quoi.
On a aussi parfois le choix entre le RAID logiciel ou matériel (c'est-à-dire que certaines cartes mères ou chipsets SATA sont capables de gérer le RAID de façon transparente et de ne présenter au système d'exploitation que l'apparence d'un seul disque). Mon choix est parfaitement clair, et c'est celui du RAID logiciel (celui de Linux : je ne suppose que Windows et Mac OS ont des choses semblables), qui est peut-être légèrement plus coûteux en ressources, mais qui m'offre beaucoup plus de finesse dans la gestion des choses, par exemple celle de convertir de RAID5 vers RAID6 (ou de lancer une vérification) sans passer des heures dans un outil du BIOS, et aussi la garantie que mes données sont stockées sur les disques dans un format connu et documenté, donc qu'elles ne vont pas devenir inaccessibles si ma carte mère meurt.
Comme je l'ai évoqué, il est possible de faire des conversions
entre niveaux de RAID, ou entre nombres de disques.
Ces conversions (de nouveau, sous Linux et en
utilisant mdadm, je ne sais rien des
autres OS) se font à chaud : le système
continue de fonctionner normalement alors qu'on est en train de
convertir, disons, un RAID5 entre 3 disques vers
un RAID6 entre 4 disques (ce qui garde la même
capacité, et ajoute un disque de redondance, mais nécessite de
réorganiser toutes les données du tableau) ; les choses sont même
prévues pour qu'on puisse interrompre l'opération et la reprendre plus
tard (par contre, dans ce cas, le tableau cesse d'être disponible au
moment où on interrompt). Enfin, ça c'est la théorie, parce que sur
le noyau que j'utilise (un
Linux 3.1.0-rc6[#4]), même si
la conversion en elle-même se passe très bien, on ne peut pas dire que
ça ne gêne pas le fonctionnement normal du système : j'ai des
processus qui restent bloqués indéfiniment (et c'est probablement un
bug, pas juste une attente disque devenue plus lente à cause de la
conversion, parce que ça a l'air de toucher les processus un peu
aléatoirement, et même quand on convertit des
tableaux RAID absolument pas utiles au système ni
utilisés par les processus qui bloquent). Enfin, ça reste utilisable,
la preuve c'est que j'ai pu écrire tout ça sur la machine en
question.
Moi je faisais du RAID5 entre 3 disques jusqu'à récemment, et comme j'ai vu qu'il y en a un qui commençait à montrer des faiblesses[#5] (ce qui, s'agissant de RAID5 veut dire qu'il faut le changer immédiatement), je me suis dit, plutôt que bêtement le remplacer, pourquoi ne pas ajouter un nouveau disque et faire du RAID6 sur 4 disques, et je virerai le disque qui faiblit quand il sera vraiment mort, pas au premier signe de faiblesse. En plus, ça me permet d'ajuster plus finement le niveau de RAID entre différentes partitions : il y en a pour lesquelles je reste à RAID5, mais sur 4 disques, pour gagner un peu de place, parce que ce sont des données vraiment peu importantes (un miroir Debian).
Et à part ça… c'est long… Mais qu'est-ce que c'est long ! La conversion du RAID5 sur N disques en RAID6 sur N+1 disques passe par un disque dur supplémentaire (il y a donc 5 disques impliqués dans l'affaire en ce qui me concerne, les détails sont là), vers lequel chacune des données du tableau doit être écrite, puis relue (ça va méchamment l'user, soit dit en passant — heureusement je m'en fous). Et ça se fait au rythme de 5.5Mo/s en moyenne. Et pour convertir 1To, au rythme de 5.5Mo/s, il faut… 50 heures. Voilà pourquoi, depuis maintenant une journée complète et sans doute pour encore aussi longtemps, j'ai 5 disques durs qui moulinent, qui moulinent, qui moulinent.
[#] En particulier, j'ai perdu des petits textes humoristiques que mon papa écrivait à mon sujet (c'est-à-dire, pour se foutre de moi), et qui s'appelaient The Adventures of Altcee : ça me fait de la peine, parce que j'aimerais bien les relire. Il semble qu'il en existe peut-être encore un exemplaire, mais il est sur une disquette 5″¼ et c'est devenu impossible de retrouver un lecteur 5″¼ de nos jours (ou en tout cas un lecteur 5″¼ dont on soit raisonnablement certain qu'il marche et qu'il ne risque pas d'endommager cette disquette si ce n'est pas déjà le cas !). [Ajout : elles ont maintenant été récupérées.]
[#2] J'ai un copain qui peut témoigner du risque lié au fait d'attacher les disques durs dans son boîtier avec des élastiques pour amortir les vibrations.
[#3] Raison pour laquelle j'essaie de faire des tableaux RAID entre disques de fabricants différents. Là, j'ai un Samsung, un Hitachi (le petit nouveau), un Seagate et un Western Digital.
[#4] Je n'aime pas utiliser des noyaux expérimentaux comme ça, mais en l'occurrence je n'avais pas le choix parce que j'étais coincé entre un bug USB des 2.6.38.x et un bug obscur dans le cache de routage dans les 3.0 qui cassait vraiment sérieusement ma config réseau, et pour lequel on ma donné un patch qui ne s'applique qu'au 3.1.
[#5] Dénonçons le coupable : c'est le Seagate. C'est un disque de 1To, et il en est à ~300 secteurs réalloués. Ceci dit, Western Digital mérite aussi un blâme dans l'histoire, pour des histoires expliquées ici par eux-mêmes (et dont l'explication technique détaillée est : ce sont des bouffons).