(je repèche le post via le waibe : mon doigt a glissé. Désolé si le formattage est aléatoire)
Jean-Yves F. Barbier wrote: > pour plusieurs raisons (d'ailleurs expliquées dans le texte): Ce n'était pas une question, mais une affirmation. Ceci dit, merci pour les autres pour le résumé attendu :) > reste que, quelque soit le système RAID utilisé, cela ne protège pas > contre des sectors failures (j'ai eu le PB aussi bien en 5 qu'en 10). > Donc, il *faut* régulièrement sauvegarder les arrays, puis les > reformater d'une manière sûre (mke2fs -c -c), de façon à éviter un > kickout de HD parce qu'un secteur aurait un PB (et ça peut être > TTTlong, surtout avec des HDz 500GB) Je plussoie. D'autant que badblocks devrait toujours être utilisé avec un front-end (mke2fs -c -c, comme tu le dis). >> J'ajouterai même: pourquoi ne pas plutôt envisager une solution >> *LVM par-dessus des mirroirs RAID1*, _beaucoup_ plus souple ? > par ce que ça rajoute une couche (logicielle) au RAID, et donc une > proba de panne plus élevée (j'ai aussi eu le PB: perte de toutes les > données à cause de LVM au-dessus de RAID). > Comme d'hab, les meilleures solutions sont toujours les plus simples > (d'autant que la courbe des probas de pannes a plutôt une tendance > de type exponentielle que linéaire au fur et à mesure qu'on ajoute des > couches au bouzin) Le propos était de remplacer la couche RAID0 par le LVM : il y a plus de complexité logicielle, mais ajouter / remplacer de l'espace disque, par exemple lors d'une vérification de disque (=> snapshot, déplacement, casser le raid1, vérifier les disques, tout remonter dans l'ordre) devient alors très (enfin, assez) aisé. Quant à la perte de données citée plus haut, t'es tu interrogé réellement sur le défaut d'architecture, ou as-tu arrêté l'analyse à la première cause apparente ? > LA sécurité restant de toute façon dans une sauvegarde à bande digne > de ce nom (LTO ou AIT); c'est d'ailleurs le système de plus en plus > utilisé maintenant: une bandothèque, avec un frontal en HDz (voire > même, un SSD en frontal des HDz). Et finalement (à un niveau pro, > oeuf-corse:), cela n'est pas si cher, ni si lent (~30 sec pour > charger la bonne bande, et la même chose pour retrouver les données > avec un LTO). Ca dépend du fait qu'on utilise ou pas une cochonnerie comme ArcServe :) Ceci dit, le RAID, c'est pour la continuité de service, pas pour la sécurité des données, donc les bandes [OUI], avec la rotation nécessaire. À remplacer par un DD externe si l'usage n'est pas professionnel. > Pour le coût, cela met les 800GB (natifs! pas compressés) à ~€45HT; > et c'est capable de résister aux pires traitements et/ou de partir > dans un sac à dos pour éviter la perte en cas d'incendie ;-) Ça, c'est le prix de la LTO, pas selui de l'ensemble... > SI les fabricants arrivent à péréniser la fiabilité des SSD, tout cela > ne sera plus qu'un mauvais souvenir à courte échéance. Mais c'est pas > gagné d'avance :( Encore une fois, cela ne remplacera pas les sauvegardes (suppression accidentelle de fichiers, incendie du site...). -- === The BOFH Excuse Server === Your excuse is: That's a great computer you have there; have you considered how it would work as a BSD machine? -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
