Bonjour à tous,
ATTENTION : Ce nourjal n'est pas un nourjal sur l'athlétimse.
Quelle est selon vous l’espérance de vie en bonne santé d'un disque dur ?
Ma recherche sur Google m'a conduit sur deux articles assez intéressants à ce sujet.
Il s'agit de deux études menées par Google d'un coté portant sur 100 000 disques et Backblaze - un service de sauvegarde en ligne - de l'autre portant sur 25 000 disques.
La réponse bête et méchante semblerait être : 6.
6 ans soit 52594,92 heures en prenant bien entendu en compte les années bissextiles, la vitesse du vent… et surtout le fait que le disque ait été conservé dans de bonnes conditions de température d'humidité et de lumière… enfin bref qu'il ait été choyé comme du bon vin.
Il apparaîtrait par exemple que les températures trop froides sont plus dangereuses que les températures trop chaudes. La température idéale pour une bonne conservation - et des données toujours fraiches - se situerait entre 36 °C et 47 °C. Ne paniquez pas si votre client SMART vous annonce des deltas plus importants car les pics ponctuels de températures ne seraient pas très dangereux. Tout cela se joue sur la durée.
Ce chiffre de 6 ans correspond au temps nécessaire avant que la moité des disques soient décédés.
Réciproquement cela signifie aussi qu'au bout de 6 ans, il y a une chance sur deux qu'il ait déjà rejoint le paradis des disques durs.
En prenant le problème légèrement différemment on peut arriver à un deuxième chiffre : 3 ans.
Il s'agit du temps avant que leur AFR - annualized failure rate ou taux annuel de défaillance - ne recommence a augmenter nettement. La première période où ce taux est plus important se situe dans les premières semaines ou mois suivant sa mise en route.
En pondérant les chiffres de l'AFR par leur année d'installation des disques, chez Google, ils se sont rendu compte que les disques installés il y a 2 et 3 ans avaient un AFR plus élevé que les disques durs plus anciens.
Ces deux chiffres ne veulent donc pas dire grand chose dans le monde réel car le modèle, l'usine ou encore la série du disque choisi sont finalement des critères bien plus déterminants que son age.
Il faut également mettre ces chiffres en rapport avec deux autres critères très importants : leur degré de sollicitation, certainement élevé en datacenter ainsi que le nombre d'arrêts / démarrages que le disque subit. Ce dernier est plus élevé sur un poste de travail ou si la mise en veille est mal configurée.
<MA VIE>
Je me suis posé toutes ces question par rapport aux disques durs car je commence a manquer d'espace sur un serveur. Cette machine, qui fonctionne depuis 2001 a déjà connu pas mal d'évolutions et il est temps de lui en offrir une nouvelle.
Je me suis alors posé la question : faut il garder ou non les 4 disques d'1To disposés en deux raid-1. La première grappe à 39007 heures de fonctionnement et la seconde 41879 pour respectivement 95 et 121 arrêts / démarrages. Aucune erreur signalée pour le moment.
Je n’évoque pas le raid-5 de la machine composé de disques de 250Go, dont un en IDE qui affiche joyeusement ses 72564 heures (soit plus de 8 ans 24h/24) de fonctionnement pour 267 arrêts / démarrages. Celui ci va être remplacé pour faire de la place à des disques plus récents.
De mémoire j'ai remplacé 4 disques en tout sur cette machine depuis 2001. Les 3 premiers étaient déjà des disques "recyclés" et 1 seul disque m'a lâché dans la configuration raid actuelle, en 2009, un 250Go du raid-5.
Vu la capacité des disques actuels un petit raid-5 avec 3 disques de 2To serait largement suffisant pour mes besoins. Je pense donc également sortir les disques en raid-1 de la machine et les recycler pour d'autres besoins… mais j'hésite encore.
</MA VIE>
Et vous comment gérez-vous votre maintenance préventive ?
Quels âges ont les disques de vos NAS / serveur small business ou perso ?
# 55400h
Posté par Olivier Serve (site web personnel) . Évalué à 2.
J'avais 4 disques dans mon Syno (4 Maxtor 250Go) que j'ai changés récemment (merci Papa Noël). Ils étaient à 55400h environ et semblent encore en bon état. Par contre, ils ont eu peu cycle arrêt/démarrage, or c'est souvent un moment critique.
[^] # Re: 55400h
Posté par freem . Évalué à 1.
J'ai récemment ( 2 ans p'tet ) dû jeter une pile entière de vieux disques: du 10Gb, 40Gb et 80Gb.
La raison? Ca prend de la place, même si ça m'a emmerdé de jeter du matos qui marche encore parfaitement. Donc les 6 ans… passés et pas qu'un peu. En fait, de tous les HD que j'ai eu, je n'ai pas eu qu'une seule mort clinique je crois. Et encore, je devrai plutôt appeler ça une mutilation, seul un bon nombre de secteurs étaient HS.
Un disque au final, ça meurt le plus souvent quand on à plus la place de le stocker ou que le système devient tellement gros qu'on a du mal a y faire entrer plus de 4 logiciels, pour moi.
Après, je n'ai pas de serveurs ni autres jouets ou ça chauffe très très fort sur le disque, je parle d'utilisation par un particulier, et même si je ne m'amuse pas à faire du téléchargement massif pour les faire saturer, je pense qu'ils écrivent assez souvent quand même. Surtout quand j'étais encore avec G++ pour la compilation… ( oui je sais, pas vendredi, mais mon expérience a été une utilisation dépassant les 1.5GiB de ram donc gros swap sur netbook avec 4 process, quand clang++ ne montait même pas a 800GiB sur la même machine. )
# C'est un journal sur le cyclimse ?
Posté par J Avd . Évalué à -2.
Ou pour faire une wiche lorraine ?
Un méchoui ?
"Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"
[^] # Re: C'est un journal sur le cyclimse ?
Posté par jigso . Évalué à 2.
On va manger des chips, t'entend ? des CHIPS !
# Interprétation des données
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 6.
Attention à bien interpréter les données suivantes :
Si je ne me trompe pas, cela signifie que l'espérance de vie à la naissance ou plutôt « à la mise en service » d'un disque dur est de six ans. Mais qu'un disque dur ayant passé la période critique des deux trois premières années a une espérance de vie supérieure. Un peu comme d'antan, quand l'espérance de vie à la naissance était de trente ans : les adultes vivaient en moyenne jusqu'à soixante ans, mais la mortalité monstrueuse des nourrissons ne laissait pas transparaître ce fait dans l'espérance de vie.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Interprétation des données
Posté par Chris K. . Évalué à 4.
Je n'ai peut être pas été assez clair ou tu m'a peut être lu un peu vite :). Même si le parallèle que tu fais avec la démographie est tout à fait juste.
Cette période critique ne dure pas 3 ans. Seulement quelques semaines voir mois puis L'AFR baisse et se stabilise assez vite. Il ré-augmente sensiblement au début de la 4e année d'existence du disque.
Avec la pondération sur l'année d'installation, pour faire ressortir les données selon les séries installées - ils en parlent dans le pdf je t'invite à le consulter - les taux sont effectivement plus importants sur séries installées certaines années et leur conclusion est que cela est directement en lien avec la qualité de ces séries.
[^] # Re: Interprétation des données
Posté par steph1978 . Évalué à 3.
De ce que je comprends, la période critique est de quelques semaines (nourrisson). La meilleur période est jusqu'à trois ans (adulte). Ensuite, si tu as eu une activité physique régulière et que tu as mangé cinq fruits et légumes frais par jour, tu peux avoir une fin de vie heureuse jusqu'à 6 ans.
# Il est toujours la lui?
Posté par Zenitram (site web personnel) . Évalué à 8. Dernière modification le 05 février 2014 à 08:38.
Tu tiens vraiment à tes donnés?
Why RAID 5 stops working in 2009
(tu aurais un peu plus de temps avec RAID 6 : Why RAID 6 stops working in 2019
RAID6 + 2 backups distants RAID6 pour toutes les données et RAID1 pour l'OS.
(après, les données sont importantes pour mon boulot, donc j'y met les moyens…)
[^] # Re: Il est toujours la lui?
Posté par Adrien . Évalué à 2.
pour info, comment tu fais tes sauvegardes ? tu sauvegardes la sauvegarde (par rsync) ou bien tu sauvegardes un coup sur l'un, un coup sur l'autre ?
[^] # Re: Il est toujours la lui?
Posté par Zenitram (site web personnel) . Évalué à 2.
Jamais facile de choisir sa politique de backup (fric vs risque de tout perdre)
On est parti sur ça : mon upload "sur site" étant limité et pas les sites distants, rsync site vers backup1 et rsync backup1 sur backup2, les 2 serveurs de backup étant sous ZFS configuré avec RAIDZ2+snapshots
[^] # Re: Il est toujours la lui?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
pourquoi prendre du raid6 et peu seulement du raid 1 ? Tu as besoin de beaucoup de place ?
"La première sécurité est la liberté"
[^] # Re: Il est toujours la lui?
Posté par Zenitram (site web personnel) . Évalué à 6. Dernière modification le 05 février 2014 à 10:24.
1/ un RAID1 ne survit pas à la mort simultanée de 2 disques (et lors du rebuild, tu risques de constater que tu as perdu quelques secteurs, voir mon lien sur RAID5 qui s'applique aussi sur 1 disque). Alors certes le RAID est sur plus de disques, mais un RAID6 sur 4 disques ne meurent jamais avec 2 disques qui meurent tandis qu'un RAID 0+1 te laisse une chance sur deux de mourir quand 2 disques meurent.
2/ le coût, RAID1 c'est 50% de "perte", RAID6 c'est par exemple 33% de "perte" (pour 6 disques) ou 28% de "perte" (pour 7 disques) et si t'es bourrin tu fais du RAID-Z3 sur 12 disques donc 25% de "perte" et 3 disques qui peuvent mourir mais j'en suis pas encore la, et oui j'ai besoin de beaucoup de place (avant, j'avais du RAID 1 sur 2 disques, lien exemple car cette machine n'existait pas à l'époque)
[^] # Re: Il est toujours la lui?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
un raid 1 avec 3 disques, cela n'est pas possible ? Vu le prix du To, c'est pas idiot.
"La première sécurité est la liberté"
[^] # Re: Il est toujours la lui?
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 05 février 2014 à 11:07.
A priori, un RAID-1 sur 3 disques est pas trop possible avec les cartes Hard (qui acceptent 2 RAID1 + 1 hot-Spare, mais ça reste du spare qui est juste automatisé) possible mais le RAID de Linux semble accepter cette config (à confirmer).
Maintenant, ça bouffe 67% du disque, faut aimer…
Faut payer :
- d'une les disques, et si tu veux genre 16 To, ça fait 6 disques à 150 € soit 1800€, pas cher vraiment? On n'a pas la même notion de prix ;-). 16 To en RAID6 ne coûte "que" 900€. Penser à la carte RAID différente (obligé de passer à la gamme avec 16 ports plutôt que 8 ports, ça chiffre en plus, rajouter au moins 200€ pour ta config)
- la location de la machine ou de la baie dans laquelle tu mets tes disques. Pour 16 To, c'est 6 disques en RAID6, et 12 disques en RAID1 3 disques, le prix de la location est doublée chez OVH (150€/mois -> 300€/mois, soit ~2000€/an de différence)
Le prix du To descend, mais les besoins montent vite aussi (perso, mes besoins montent plus vite que le To baisse, surtout avec l'arrivée des vidéos en 3840x2160 10-bit ou même du simple 1920p en qualité acceptable et pas un amas de pixels façon Youtube). Maintenant, si tu as besoin de juste 1 To, certes c'est con de faire du RAID6, met plutôt 3 disques en RAID1.
[^] # Re: Il est toujours la lui?
Posté par Nicolas Boulay (site web personnel) . Évalué à -1.
Je me disais bien qu'à part pour la vidéo, personne n'a un besoin de sauver plus de 1 To.
"La première sécurité est la liberté"
[^] # Re: Il est toujours la lui?
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 05 février 2014 à 11:19.
Même sans parler "pro" qui est mon plus gros besoin, il suffit de faire un peu de vidéo amateur (j'ai quasi 1 To de vidéos personnelles, alors que j'estime utiliser à peine ma caméra) avec une caméra digne de ce nom en 2014 (et donc ça tourne à 25 Mbps avec AVCHD, 1 To fait 100 heures seulement) ou simplement éviter de te coltiner ces supports vieillots que sont les blu-ray (1 To c'est une trentaine de films seulement), rajoute quelques photos à 5 Mo/photo (200 000 photos pour 1 to certes, mais c'est "en pus du reste pour remplir le To)… Bref ça arrive vite, y compris pour monsieur tout le monde.
Après, oui, évidement, si tu peux faire tout rentrer sur un disque de 1 To… Au début, je répondais à une personne qui parle de RAID5 (donc besoin sur plusieurs disques)
[^] # Re: Il est toujours la lui?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Je fais qq dizaines de Go de photos par an. Il est vrai que si la carte mémoire de mon apn est de 4 Go, celle de la camera est de 32Go. Cela se remplit vite.
Si le but est de sauver des Br, on se fout de perdre la copie, on peut toujours re-ripper ensuite. Vu que ces données ne changent pas, une copie sur un autre disque est plus fiable qu'un raid (alimentation foireuse, orage, OS qui déconne…).
Pour moi le raid permet d'avoir de la disponibilité quand un disque meure, mais cela n’empêche pas d'avoir des sauvegardes pour tous les autres cas de panne (genre l'alimentation qui envoie du 220V au lieu du 12).
"La première sécurité est la liberté"
[^] # Re: Il est toujours la lui?
Posté par Zenitram (site web personnel) . Évalué à 2.
C'est pour ça que j'ai plusieurs machines dans plusieurs endroits.
Et dit-donc, comment tu les fais en pratique tes autres sauvegardes?
Perso, ils partent à la poubelle, je priorise un petit appart avec peu de stockage à un grand appart plus cher pour stocker ce genre de conneries inutiles (pareil pour livres etc… Même si je bataille un peu avec madame pour les livres :) ), ça me permet de dépenser l'argent ailleurs. Les BR n'étaient qu'un exemple parmi d'autres (les vidéos perso ne sont pas ailleurs et c'est le plus important)
[^] # Re: Il est toujours la lui?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"Et dit-donc, comment tu les fais en pratique tes autres sauvegardes?"
Copie sur disque usb et copie sur un serveur loué. Mais à distance, l'upload limité est vraiment chiant.
"La première sécurité est la liberté"
[^] # Re: Il est toujours la lui?
Posté par Kioob (site web personnel) . Évalué à 2.
Je confirme qu'en software depuis Linux ça fonctionne. Je m'en sers régulièrement sur des petites partitions, histoire d'avoir l'amorçage (/boot/) sur tous les disques et ainsi avoir la paix en cas de crash d'un disque. Je dois même avoir du RAID1 sur 12 disques.
alf.life
[^] # Re: Il est toujours la lui?
Posté par rakoo (site web personnel) . Évalué à 1.
Justement c'est un des problèmes que j'ai avec les RAID : il font tous du striping, ce qui fait que tu n'as pas le droit de perdre plus d'un certain nombre de disques. Il y a d'autres systemes, comme unRaid (bon ok c'est un OS entier) ou Snapraid, qui ont un avantage énorme: si plus de disques que la limite tombent en panne, on peut quand même récupérer des données sur les autres disques (avec les RAID, t'es foutu).
[^] # Re: Il est toujours la lui?
Posté par ZeroHeure (site web personnel) . Évalué à 3.
Eh ??? ;-)
D'abord c'est faut pour le striping (Raid 1, Raid 4 et Raid 6 n'en font pas forcément - double parité), ensuite le principe même du Raid c'est la redondance / répartition sur plusieurs disques. Donc il y a forcément une limite au nombre de disques que tu ne peux pas perdre. En Raid 1 il faut qu'il t'en reste au moins un… :-) Et en Raid 10 avec le raid logiciel linux et les bonnes options c'est pareil. Si tu veux garder tes données avec zéro disques en marche, faut changer de religion…
Snapraid c'est plus un système de sauvegarde, pas un système de travail. Ensuite tu récupère seulement ce qui n'est pas sur les disques foutus, c'est à dire pas tout. Cela dit c'est pas mal sur une grosse bécane, c'est vrai.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Il est toujours la lui?
Posté par kursus_hc . Évalué à 1.
Je ne comprends pas cette phrase. Quelle est la probabilité pour que 2 disque meurent en même temps ?
[^] # Re: Il est toujours la lui?
Posté par Zenitram (site web personnel) . Évalué à 3.
Pour toi, ça n'arrive jamais?
Au contraire, en général quand l'un meure, il y a plus de chances que l'autre suivent (même contraintes sur le disque).
Ensuite, rien ne dit qu'il n'était pas mort avant (mais tu ne le savais pas), genre des secteurs défecteurs qui te pourrissent tes fichiers et tu a laissé ça tranquille, jusq'uà ce que tu fasses le rebuild (et le lien qu j'ai mis au débût va aussi t'expliquer pourquoi ça rrive souvent lors d'un rebuilt, une question de stats).
En théorie, si disons tu met 2 jours à te déplacer, changer le disque et lancer le rebuild, avec un taux de panne de disons 5% par an, tu as 0.05% de chances de tout perdre. en pratique, j'ai lu qu'on avait beaucoup beaucoup plus de risques lors de la solicitation du build, et que du coup suivant les gens les taux de réuissite d'un rebuild complet sur des gros disques (4 To) pas de classe entreprise (1 erreur sur 1014) était de plusieurs pourcents (et en RAID5 en apparté, certains disent que le risque est de 90% vu le nombre de disques, voir le lien). Alors ca reste pas beaucoup; sauf quand ça tombe sur tes données et pas celles du voisin.
Après, ce niveau de sécurité peut suffir pour toi, comme beaucoup ont simplement un seul disque sans RAID en disant "Quelle est la probabilité pour que 1 disque meurent en même temps? Ca va tranquille ça n'arrive pas tous les jours". Pour moi, ces données valent que je mette un peu plus d'argent pour avoir un risque plus proche de 0.
Je note qu'en entreprise, le RAID1 est utilisé pour les disques système (pour la disponibilité) et RAID6 ou Z3 pour les données (coût et gestion du risque). Je rappelle aussi que RAID1, c'est une perte de 50% de l'espace, donc le coût est énorme.
(Note : j'avais du RAID1 avant d'avoir besoin de plus de place, le coût allait).
[^] # Re: Il est toujours la lui?
Posté par kursus_hc . Évalué à 1. Dernière modification le 05 février 2014 à 18:18.
On parle bien de RAID 1 là ? Le "rebuild" est donc une simple copie (et le type se fait bien contredire dans les commentaires). Ton chiffre de 0.05% est quand même pas mal sorti du chapeau, il ne faudrait pas oublier des facteurs important comme la mise en service ou non du système pendant la période, et si ce n'est pas le cas je crois que la probabilité de tout perdre est plus faible que la probabilité de voir un incendie se déclarer chez toi (et de tout perdre quoi qu'il arrive).
Bref il y a toujours une probabilité de faire claquer deux disques en même temps, il faut quand même aller sacrément titiller les probabilités, genre à aller jouer au loto dans la foulée. C'est déjà arrivé à quelqu'un ici ?
[^] # Re: Il est toujours la lui?
Posté par Zenitram (site web personnel) . Évalué à 2.
5% annuel (source : lit les liens du journal) divisé par 100 (ok, j'ai pris 3 jours plutôt que deux pour aller sur place, remplacer le disque, faire le rebuild)
Oui, et tu ne te rends pas compte que justement le problème est… la lecture du disque entier? Je t'invite à lire les liens que j'ai mis… Ca parle de RAID5 mais le principe du risque est identique (des calculs? On s'en fout, c'est de l'éléctronique…)
C'est un bon exemple. J'ai déjà eu un incendie chez moi (enfin : le voisin) qui a bousillé les disques. Mais j'ai 2 sites du coup, ça n'exuse pas.
Donc vu le risque incendie, tu double le risque avec le RAID pour le plaisir?
Sinon, le risque incendie en datacenter est très faible, donc je ne crois pas que ce soit équivalent. Tu aurais parlé des inondations à New-york…
Tu fais ce que tu veux de tes données, de mon côté j'ai discuté avec des gars de datacenter + lu plein d'articles sur le sujet, et les disques en rebuild, ça pête, c'est tout. Mais tu es as sans doute plus d'expérience que les gars qui ont eu besoin de ZFS RAID Z3 (3 disques peuvent péter en même temps, pour toi ça ne devrait jamais arriver) et qui disent de pas mettre trop de disques pour pas trop risquer…
[^] # Re: Il est toujours la lui?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
"une probabilité de faire claquer deux disques en même temps, il faut quand même aller sacrément titiller les probabilités, genre à aller jouer au loto dans la foulée"
Tu pars du principe qu'il y une indépendance entre les 2 disques au niveau panne, comme 2 vrais variables aléatoires. C'est vrai uniquement avec des disques de marques différentes. Si il s'agit de la même marque, il s'agit sans doute du même lot et donc des disques physiquement identiques (vu le volume de production). En raid, ils sont sollicités de façon symétrique (sauf un spare). Donc la probabilité qu'un disque tombe en panne juste après un autre, est très élevé.
"La première sécurité est la liberté"
[^] # Re: Il est toujours la lui?
Posté par ZeroHeure (site web personnel) . Évalué à 3.
Même pas puisques ils sont dans le même boitier, sur le même controlleur, géré par le même logiciel, alimintés par le même transfo, chaînés sur le même cable (pour le scsi), souvent avec la même durée de vie (donc les mêmes incidents), …
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Il est toujours la lui?
Posté par kursus_hc . Évalué à 1. Dernière modification le 06 février 2014 à 16:39.
Je ne crois pas qu'il y ait deux disques strictement identiques en sortie de chaîne, supposés claquer à dans la même minute (sinon ça se vérifierait pour n'importe quelle manufacture). Et quand bien même, il suffirait d'utiliser UN disque seul pendant deux jours avant de monter le RAID pour se donner une marge suffisante de remplacement (et d'obtenir si j'en crois vos stats une très forte probabilité de ne pas les voir mourir en même temps).
[^] # Re: Il est toujours la lui?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
" (sinon ça se vérifierait pour n'importe quelle manufacture)."
C'est le cas. Quand il y a un problème sur un produit, tout le lot est incriminé.
"La première sécurité est la liberté"
[^] # Re: Il est toujours la lui?
Posté par kursus_hc . Évalué à 2. Dernière modification le 06 février 2014 à 19:13.
On ne parle pas de vices de fabrication mais d'usure normale.
[^] # Re: Il est toujours la lui?
Posté par Zenitram (site web personnel) . Évalué à 3.
Usure normale qui dépend… du lot.
[^] # Re: Il est toujours la lui?
Posté par Renault (site web personnel) . Évalué à 3.
Pas forcément.
Disons que statistiquement, si un produit d'un lot est défectueux, de nombreux autres du mêmes lots présenteront des défauts identiques ou similaires. Cela ne signifie pas que ça s'appliquera forcément à tous les produits (parfois, il n'y en aura qu'un seul…) et donc que la casse d'un produit à un instant t dans les mêmes conditions d'utilisation et du même lot n'entrainera pas forcément la mort de son clone d'à côté dans un temps proche.
[^] # Re: Il est toujours la lui?
Posté par kursus_hc . Évalué à 2.
Bah oui, Zenitram si tu as une étude sourcée qui démonte ta théorie du "deux produits voisins de chaîne ont plus de chances de cesser de fonctionner précisément au même moment" (sauf défaillance technique, je précise au cas où quelqu'un ne comprendrait toujours pas) n'hésite pas à la publier hein ! Mais tu n'en trouveras pas car c'est du pur pipeau.
[^] # Re: Il est toujours la lui?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"Mais tu n'en trouveras pas car c'est du pur pipeau. "
C'est pourtant logique que des produits de conception identiques, avec une usure identique tombe en panne presque au même moment.
"La première sécurité est la liberté"
[^] # Re: Il est toujours la lui?
Posté par kursus_hc . Évalué à -1.
Ce qui permet d'éliminer tout risque si on utilise UN disque seul pendant quelques jours avant de mettre en place le RAID1, non ?
[^] # Re: Il est toujours la lui?
Posté par briaeros007 . Évalué à 4.
lorsqu'on change ses ampoules (de voiture), il est conseillé de changer les deux en même temps. L'idée est qu'on a un mtbf qui est sensiblement équivalent, et que le mttr est identique que tu fasse une ampoule ou deux, donc inutile d'attendre d'être de nouveau en "failure".
Alors peut être est ce du pipeau ou pas, mais cela me semble logique que quelque chose d'identique utilisé de la même façon s'use de la même façon.
D'ailleurs, c'est sur cette base que se base toutes les procédures d'entretiens et de remplacement de pièces (avec des normes/coefficient de sécurité bien sur).
ps: mdr la "geekscote" (même si ce n'est pas une geekscote)
[^] # Re: Il est toujours la lui?
Posté par nono14 (site web personnel) . Évalué à 2.
+1, pour le changement des 2 ampoules.
La luminosité est différente en fonction de l'usure.
Système - Réseau - Sécurité Open Source
[^] # Re: Il est toujours la lui?
Posté par Buf (Mastodon) . Évalué à 4.
Il faut aussi tenir compte du fait que quand un disque lâche, le RAID passe en mode dégradé, ce qui peut considérablement augmenter la sollicitation sur les disques restants et donc la probabilité qu'un autre lâche peu de temps après.
[^] # Re: Il est toujours la lui?
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
Cela dépend à quoi tu rapportes ce coût. La perte d'espace lié au raid a un cout négligeable par rapport aux heures sysadmin passées à remonter des données à partir d'un environnement dégradé. Voir aux indemnités à payer au client en cas de perte.
Le niveau de raid dépend avant tout du besoin en IO rapporté au volume à stocker. Pour un SGDB par exemple le choix est déterminant, pour des backups aussi si tu veux pouvoir paralléliser un maximum. Par contre pour de l'échange de fichiers ou encore pour un applicatif résident en RAM, tu veux juste éviter les indisponibilités.
Le reste c'est de la manut. Une politique de stockage, ce n'est pas seulement le RAID. C'est avant tout le choix des disques qu'il faut avoir en stock sans pour autant les laisser dormir trop longtemps, stresser, surveiller, remplacer à la moindre erreur, diagnostiquer, effacer et remettre en stock ou détruire. C'est aussi le choix des contrôleurs, des alimentations, des backplanes et du soft (système de fichier, gestionnaire de volumes, soft raid …). Enfin c'est de la procédure. Être alerté, savoir quel disque est dans quel tiroir, avoir une procédure de remplacement et de reconstruction solide.
Si effectivement, tu as besoin de deux jours pour intervenir sur un problème de disque, le raid (quelque soit son niveau) ne peut rien pour toi. Ce qu'il te faut alors c'est des backups.
[^] # Re: Il est toujours la lui?
Posté par Zenitram (site web personnel) . Évalué à 2.
Mais c'est ce que je dis depuis le début (je parle de RAID1 pour le système, je parle que j'avais du RAID1 quand j'avais besoin de "peu" de place, par exemple. Ca peu être aussi un besoin d'IO bien sûr, évidement un SGBD c'est sur du RAID1 voir RAID0+1 et en SSD s'il vous plait)…
Ici, je parlais de stockage, car l'auteur parlait déjà de RAID5.
L'un ne remplace pas l'autre.
[^] # Re: Il est toujours la lui?
Posté par ManuxFr (site web personnel) . Évalué à 0.
La même que les 2 pilotes d'un avion :D
[^] # Re: Il est toujours la lui?
Posté par lolop (site web personnel) . Évalué à 3.
Y'a pas une règle comme quoi ils sont censés ne pas manger la même chose avant le vol, histoire qu'une intoxication alimentaire n’anéantisse pas le duo ?
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Il est toujours la lui?
Posté par claudex . Évalué à 10.
J'ai essayé, j'ai donné du poulet à un disque et du bœuf à l'autre. Et bien, aucun des deux n'a apprécié.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Il est toujours la lui?
Posté par Mikis . Évalué à 3.
Si c'est du cheval à chaque fois, c'est normal.
[^] # Re: Il est toujours la lui?
Posté par Zenitram (site web personnel) . Évalué à 1.
J'ai bien rit sur la comparaison, elle serait presque bonne si lors de l'intoxication alimentaire d'un pilote, on ne lui demandait pas à l'autre pilote de refaire 1 an de vol en moins de 24 heures (c'est ce qu'on demande lors d'un rebuild, et c'est ce qui augmente les risques), ni que le pilote de dise que sur la durée du vol, statistiquement par sa formation il a une chance sur 10 de faire une "petite" bétise mortelle (c'est les stats des disques pas chers, après si tu as des disques entreprises tu divises ce risque par 10, voir les specs).
Bref, bien vu la comparaison, mais manque un petit truc.
[^] # Re: Il est toujours la lui?
Posté par ZeroHeure (site web personnel) . Évalué à 4.
Euh… non camarade. Une reconstruction ne demande pas de refaire toutes les lectures / écritures… ;-)
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Il est toujours la lui?
Posté par lolop (site web personnel) . Évalué à 7.
Pour faire simple: la phase de reconstruction sollicite beaucoup les disques, et donc augmente fortement la probabilité d'une panne d'un deuxième disque.
J'ai quelques baies en RAID6 (9 disques données + 2 parité + 1 spare, 13.5To de stockage utile), et ça m'est arrivé d'avoir un deuxième disque qui lâche pendant la reconstruction - tu te précipites pour remettre de nouveaux disques à la place des deux qui ont lâché… et tu devient croyant le temps que la reconstruction se termine.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Il est toujours la lui?
Posté par Adrien . Évalué à 3.
idem ici, sur un nas d'une vingtaine de disque, j'en suis déjà à deux fois qu'un deuxième disque lâche pendant la reconstruction :(
[^] # Re: Il est toujours la lui?
Posté par Alex . Évalué à 2.
Pour l'anecdote, ça nous est arrivé lundi dernier
suite a une panne de clim, 2 disques d'un raid5 ont flanchés
[^] # Re: Il est toujours la lui?
Posté par Zenitram (site web personnel) . Évalué à 2.
Ca vous motive à passer en RAID6? ;-)
(bon, la où ça triche un peu, est que l'auteur du commentaire parle de RAID1, alors que les témoignages sont sur du RAID5/6, il faudrait un témoignage sur du RAID1, mais c'est sûr que c'est plus rare car il y moins de disques donc risques divisés en RAID1)
[^] # Re: Il est toujours la lui?
Posté par Alex . Évalué à 2.
Je ne suis pas admin
mais à priori la solution choisie serait d'utiliser des vms (ce n'était toujours pas le cas) avec réplication et un peu de haute dispo
Si un service plante, une autre machine physique le prendra en charge
[^] # Re: Il est toujours la lui?
Posté par Adrien . Évalué à 3.
Des choses comme CEPH sont aussi intéressantes dans un contexte de limitation de pertes de données pour de gros volumes : http://ceph.com
http://ceph.com/presentations/
[^] # Re: Il est toujours la lui?
Posté par Adrien . Évalué à 2.
OK merci pour les info. Effectivement, les sauvegardes c'est jamais simple, surtout quand il y a beaucoup de données.
[^] # Re: Il est toujours la lui?
Posté par Chris K. . Évalué à 1.
Oui je suis toujours là ! t'aurai-je manqué ? :D
En effet mieux vaut y mettre les moyens.
J'avais déjà lu quelques articles similaires sur les problèmes que posaient la reconstruction sur un raid 5 et le risque accru de défaillance a ce moment là. Je me demande même si ce n'est pas toi qui les avait postés quelque part ici.
Pour l'instant il ne s'agit que de 3 disques donc le raid 6 n'est pas envisageable. Mais j'ai vu qu'il était maintenant possible migrer d'un raid 5 à un raid 6 avec mdadm. Je tenterai le coup lors de l'extension.
Sinon ne considère pas le raid comme une sauvegarde faut pas déconner. En guise de sauvegarde je duplique mes données sur un disque externe avec rsync. Sans compter que les données vraiment importantes trainent sur plusieurs machines.
# Amazon Glacier
Posté par Emmanuel C . Évalué à 1.
À propos de sauvegarde et de supports de masse, que pensez-vous du service Amazon Glacier ?
Amazon Glacier (http://aws.amazon.com/fr/glacier/) est l'un des Amazon Web Services qui propose de la sauvegarde à un prix très bas (enfin, d’après annoncé) en échange d'une disponibilité des données sous 3-5 heures (au lieu d'une disponibilité immédiate pour S3). Bien évidemment, vos données sont chiffrées, et bien évidement, elles sont disponibles pour l'administration américaine. Cela dit, rien n’empêche de les chiffrer en amont.
Est-ce plus rentable, si on tiens réellement à ses données, de les mettre sur un disque dur "hors ligne" ou de les poser sur un service tel que décrit ci-dessus ?
[^] # Re: Amazon Glacier
Posté par Zenitram (site web personnel) . Évalué à 5.
Glacier ou OVH Archives ne permettent, si j'ai bien compris dans mes tests, que de "pousser" une fois et après récupérer tout ou rien, pas de rsync, pas de diff, de la programmation à faire… Je le vois comme de l'archivage, tu pousse uene fois et tu oublies, tu ne fais pas de MAJ dessus. Perso j'ai abandonné l'idée pour mon backup (je me vois mal pousser des Teraoctets tous jours, je me vois mal faire de l'incrémental seulement en faisant confiance à l'horodatage de la machine à backuper seulement etc) alors que le prix m'interesse, mais peut-être que j'ai mal compris le "concept".
[^] # Re: Amazon Glacier
Posté par gnx . Évalué à 4.
Quelques précautions à prendre :
- prévoir un doctorat en mathématique pour calculer le prix de sortie (récupération) des données.
- faire gaffe au nombre de requêtes émises : dans mon cas, heureusement que j'ai testé juste avant la fin d'un mois et que ça n'a pas pris des proportions monstrueuses, mais je me suis retrouvé avec un nombre de requêtes d'un ordre de grandeur 1000 fois supérieur à celui que je croyais (la faute à mes scripts, à moi qui n'ai pas compris le principe, ou autre raison, je ne sais pas et je n'ai pas cherché).
Sinon, dans le même genre (que je n'ai pas testé), il y a le Public Cloud Archives chez OVH, mais c'est en béta. Et les bétas chez OVH… si Tatave a marché dans une flaque la veille, tu peux voir les tarifs changer du tout au tout ou le service arrêté du jour au lendemain.
[^] # Re: Amazon Glacier
Posté par gnx . Évalué à 1.
[J'ajoute, puisque "éditer" m'a pété dans les mains]
Du coup, je pense que je vais m'orienter vers la location d'un bête serveur : ça coûtera plus cher (tant que le volume sera relativement faible, du moins) mais au moins le prix sera fixe et connu sans surprises (et en plus il n'y aura pas le côté pas très pratique de l'archivage hors-ligne).
[^] # Re: Amazon Glacier
Posté par kerokero . Évalué à 2.
C'est à l'étude en ce qui me concerne, d'autant plus que j'ai un NAS Synology et qu'il y a un package Glacier Backup officiel.
Sur le papier ça me parait être l'idéal, mais il est vrai que savoir combien ça coûte exactement reste un peu obscure, mais à priori c'est assez peu onéreux.
Là où ça coûte cher c'est lorsque tu récupères les données, donc pour moi c'est vraiment pour du Disaster Recovery, en cas d'incendie, de cambriolage, ou si la meute de chats du quartier décide d'investir la maison.
# Multi sauvegarde
Posté par Xavier Teyssier (site web personnel) . Évalué à 5.
Et vous comment gérez-vous votre maintenance préventive ?
En faisant plein de sauvegardes.
De toute façon, mes disque vont mourir. Demain ou dans 15 ans, mais ils vont mourir.
Donc toutes mes données sont sauvegardées sur une machine, archivées sur une seconde, et pour certaines, répliquées sur une troisième, hors de chez moi.
# Complément
Posté par ZeroHeure (site web personnel) . Évalué à 8.
Petit complémént utile sur les disques:
L'article de Google était sorti lors de la conférence Usenix 2007 en même temps qu'une autre étude sur les disques menées par des chercheurs de l'université Carnegie Mellon. Un journal promu en dépêche avaient rendu compte de tout ça. Les commentaires sont savoureux.
Si ma mémoire ne s'amuse, Google avait lancé une étude complémentaire dont les résultats devraient maintenant être connus. Quelqu'un sait-il?
Enfin, parce que je suis tombé dessus inopinément, voici un compte rendu en 2009 d'un article sur la Ram. Les commentaires regorgent de trolls et d'anecdotes croustillantes — dont celle-ci : la corruption de la Ram à entraîné celle du disque. Comme quoi…
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Arrêts / redémarrage également ?
Posté par khivapia . Évalué à 3.
Pour une utilisation desktop, ne sont-ce pas les arrêts et redémarrages qui usent le plus les disques durs ?
[^] # Re: Arrêts / redémarrage également ?
Posté par Yannick (site web personnel) . Évalué à 2.
C'est pas plutôt les packages/déparckage des têtes ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.