OVH Community, votre nouvel espace communautaire.

Raid 1 : données revenues des mois en arrière


Fraise
10/05/2016, 23h34
OK merci pour l'info !

Raid1_danger
10/05/2016, 22h38
En Raid software, ça a pris à peu près 80 minutes pour 1 Tera.

Fraise
10/05/2016, 22h23
ca a pris combien de temps en rescue ?

Raid1_danger
10/05/2016, 21h30
Pour ma part, je n'ai pas eu à tester en fonctionnement, j'ai tout fait en rescue...

fritz2cat
10/05/2016, 15h17
En principe tu peux laisser tourner.
Dans la pratique si ton serveur n'a pas des baies hot-swap, tu devras quand même éteindre pour remplacer le disque fautif.
Généralement tu as un contrôleur RAID hardware qui va de pair avec les baies hot-swap. La performance de ton serveur s'en ressent pendant le rebuild et la plupart des contrôleurs permettent d'indiquer s'il faut privilégier la perf du rebuild ou la perf du serveur.

En outre dans le cas d'un RAID software avec le système dessus tu dois t'assurer que ta config GRUB est en ordre pour que tu puisses booter sur l'un ou l'autre.
Je n'ai encore jamais eu à reconstruire un disque système.

Fraise
10/05/2016, 15h03
Au fait, en cas de reconstruction d'un raid, vous arrêtez les services du serveur ou bien vous laissez tourner ?

Nowwhat
09/05/2016, 17h33
A mettre en place quelque chose comme ceci : http://denisrosenkranz.com/tuto-mdad...raid-logiciel/

Raid1_danger
09/05/2016, 16h10
Finalement, j'ai pu resynchroniser les deux disques après le changement du 2ème disque (sans perdre les données)... mais je ne m'en suis jamais sorti avec le système, j'ai réinstallé.

Nowwhat
09/05/2016, 15h02
Citation Envoyé par starouille
......
!! le revenant !!

fritz2cat
09/05/2016, 12h42
Citation Envoyé par rookie67
Bonjour,
...
pas mal le spam caché dans la ponctuation.

rookie67
05/05/2016, 17h48
Bonjour,

Le problème avec les RAID 1 c'est que souvent ce sont deux disques identiques. Donc la probabilité de panne simultanées voire très peu éloigné dans le temps n'est pas négligeable. C'est vrai qu'il faut sauvegarder et surtout consulter ses logs régulièrement pour éviter ce genre de situation.

starouille
03/05/2016, 03h41
Citation Envoyé par Raid1_danger
Dans la continuité, je pose la question à tout hasard car je ne suis pas en terrain conquis... Voici la situation :

root@rescue:~# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
md1 : active raid1 sda1[2](S) sdb1[1]
10485696 blocks [2/1] [_U]

md2 : active raid1 sda2[0] sdb2[1]
965746624 blocks [2/2] [UU]

J'ai tenté de déclarer sdb1 comme défaillant par : mdadm --manage /dev/md1 --set-faulty /dev/sdb1 , ce qui m'a retourné un device or ressource busy (toujours en mode rescue pro) ... J'hésite à aller plus loin avec : mdadm --stop /dev/md1

Ma question revient à demander comment être sûr de savoir sur quel disque on boote (je dirais sdb qui est le 1 du RAID 1), et comment faire en sorte de changer le disque "maitre", si cela peut permettre de booter sur le disque sain, à savoir le nouveau sda
Le bios . C'est lui qui choisi le disque.

Ensuite c'est ton MD, tout dépend comment il est sync et l'état des disques. Tu peux très bien remplacer ton MD par /dev/sdX dans ta conf (fstab, grub etc..) pour booter directement dessus comme si tu n'avais pas de raid.

C'est de la bidouille mais c'est tout à fait possible.

Raid1_danger
30/04/2016, 00h31
Dans la continuité, je pose la question à tout hasard car je ne suis pas en terrain conquis... Voici la situation :

root@rescue:~# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
md1 : active raid1 sda1[2](S) sdb1[1]
10485696 blocks [2/1] [_U]

md2 : active raid1 sda2[0] sdb2[1]
965746624 blocks [2/2] [UU]

J'ai tenté de déclarer sdb1 comme défaillant par : mdadm --manage /dev/md1 --set-faulty /dev/sdb1 , ce qui m'a retourné un device or ressource busy (toujours en mode rescue pro) ... J'hésite à aller plus loin avec : mdadm --stop /dev/md1

Ma question revient à demander comment être sûr de savoir sur quel disque on boote (je dirais sdb qui est le 1 du RAID 1), et comment faire en sorte de changer le disque "maitre", si cela peut permettre de booter sur le disque sain, à savoir le nouveau sda

Raid1_danger
30/04/2016, 00h12
Merci à vous deux, c'est intéressant en effet... Et comme quoi ce smartctl a des options plus précises qu'il n'y parait.

fritz2cat
29/04/2016, 23h38
Pour être honnête avec toi, je monitore les paramètres 197 198 et 199 qui doivent être égaux à zéro, ainsi que la présence de la ligne "No Errors Logged" ; ceci chaque jour.
Tes deux disques passent donc sous mon radar.

Par contre pour détecter le bon état du RAID 1 à 2 disques, cette ligne montre le défaut:
cat /proc/mdstat |grep blocks|grep -v -q UU&& (action_a_prendre)

Je vais de ce pas surveiller le paramètre #5...

buddy
29/04/2016, 23h30
tu peux actier toutes les options de collectes automatiques des erreurs
smartctl -s on -o on -S on /dev/sda
smartctl -s on -o on -S on /dev/sdb


Le nombre de secteur réalloué (5- ) t'indique le nombre de secteurs morts.

Après power on hours, l'age de ton disque en heure de fonctionnement.

196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0
si ces 3 lignes montent c'est mauvais signe.

si tu n'as plus
SMART Error Log Version: 1
No Errors Logged

mais des erreurs c'est aussi mauvais signe



après tu peux aussi lancer des tests un peu plus poussé de tes disques avec (idem avec /dev/sda)
smartctl --test=short /dev/sdb (environ 1 à 5 minutes)
smartctl --test=long/dev/sdb (beaucoup plus long)

Raid1_danger
29/04/2016, 23h18
Voici les smartctl que j'avais obtenu (justement ça m'intéresse de mieux pouvoir les décrypter) :

root@rescue:/# smartctl -a -d ata /dev/sda
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.14.32-xxxx-std-ipv6-64-rescue] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Hitachi Deskstar 7K1000.D
Device Model: Hitachi HDS721010DLE630
Serial Number: MSK523Y20L759F
LU WWN Device Id: 5 000cca 37fc84999
Firmware Version: MS2OA610
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 7200 rpm
Form Factor: 3.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Tue Apr 26 15:54:54 2016 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status: (0x84) Offline data collection activity
was suspended by an interrupting command from host.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 7313) seconds.
Offline data collection
capabilities: (0x5b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 122) minutes.
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 098 098 016 Pre-fail Always - 262144
2 Throughput_Performance 0x0005 141 141 054 Pre-fail Offline - 74
3 Spin_Up_Time 0x0007 108 108 024 Pre-fail Always - 212 (Average 211)
4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 12
5 Reallocated_Sector_Ct 0x0033 095 095 005 Pre-fail Always - 264
7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0
8 Seek_Time_Performance 0x0005 118 118 020 Pre-fail Offline - 33
9 Power_On_Hours 0x0012 098 098 000 Old_age Always - 17661
10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 12
192 Power-Off_Retract_Count 0x0032 094 094 000 Old_age Always - 8029
193 Load_Cycle_Count 0x0012 094 094 000 Old_age Always - 8029
194 Temperature_Celsius 0x0002 142 142 000 Old_age Always - 42 (Min/Max 21/48)
196 Reallocated_Event_Count 0x0032 093 093 000 Old_age Always - 294
197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 9 -
# 2 Short offline Completed without error 00% 3 -
# 3 Short offline Completed without error 00% 2 -

SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.



root@rescue:/# smartctl -a -d ata /dev/sdb
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.14.32-xxxx-std-ipv6-64-rescue] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Hitachi Deskstar 7K1000.D
Device Model: Hitachi HDS721010DLE630
Serial Number: MSK523Y20ME1GF
LU WWN Device Id: 5 000cca 37fc8d407
Firmware Version: MS2OA610
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 7200 rpm
Form Factor: 3.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Tue Apr 26 15:55:45 2016 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status: (0x84) Offline data collection activity
was suspended by an interrupting command from host.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 7410) seconds.
Offline data collection
capabilities: (0x5b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 124) minutes.
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 100 100 016 Pre-fail Always - 1
2 Throughput_Performance 0x0005 140 140 054 Pre-fail Offline - 75
3 Spin_Up_Time 0x0007 100 100 024 Pre-fail Always - 211
4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 9
5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0
7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0
8 Seek_Time_Performance 0x0005 118 118 020 Pre-fail Offline - 33
9 Power_On_Hours 0x0012 096 096 000 Old_age Always - 29887
10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 9
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 21
193 Load_Cycle_Count 0x0012 100 100 000 Old_age Always - 21
194 Temperature_Celsius 0x0002 157 157 000 Old_age Always - 38 (Min/Max 21/47)
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 9 -
# 2 Short offline Completed without error 00% 3 -
# 3 Short offline Completed without error 00% 2 -

SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

buddy
29/04/2016, 22h41
pour savoir l'état des disques tu fais un
smartctl -a /dev/sda
et
smartctl -a /dev/sdb

si tu n'arrives pas à savoir poste les ici, on te le dira.

Raid1_danger
29/04/2016, 22h32
Bonjour,

Merci pour cette réponse TBC_Lyon. J'explique brièvement ce qu'ils s'est réellement passé :

1. Un cable SATA s'est montré défectueux, ce qui a rendu sdb invisible, donc sda (désynchronisé ) a pris le relai.
2. Le disque sda s'est montré défectueux... Une fois le cable changé, sdb est revenu mais ne bootait plus.
3. Sauvegarde des données les plus récentes, changement de sda puis resynchronisation presque complète: sda est "Spare" (S)
4. J'en conclus que sdb est également défectueux, le test des blocks le prouve sur sdb1 ... j'ai demandé le changement de sdb

J'en suis là... Il va sans doute falloir réparer le système sur sda1

Conclusion, la leçon est prise, une fois sorti d'affaire, je vais installer de quoi monitorer l'état de mes disques durs et l'état du RAID.


@buddy : oui, j'ai du passer par là il y a 4 ans (avant de passer en Raid 1), ce fut cher mais ça avait marché

buddy
29/04/2016, 22h06
Tu peux demander à OVH de te vendre le disque après son remplacement et le confier à une société spécialisée .. mais c'est cher ..

Raid1_danger
29/04/2016, 22h02
Merci pour la réponse.

Oui, je fais des sauvegardes régulières et distantes, mais il est important dans mon cas de récupérer les données très récentes...

C'est exact pour le monitoring, à vrai dire je pensais que les défaillances des disques durs étaient détectées par ovh avant que le serveur tombe vraiment en rade, mais ça ne semble pas être le cas (ce qui parait compréhensible à la réflexion), je mettrai donc des routines en place. ^^

Raid1_danger
29/04/2016, 21h57
Bonjour,

Merci pour la réponse... Alors voilà ce qu'il s'est réellement passé :

1. Un cable SATA s'est montré défectueux... et a rendu sdb invisible, en donnant la main a sda (désynchronisé).
2. Une fois le cable changé, sdb a repris la main... et sda s'est montré défectueux pendant les tests : changement de sda
3. Synchronisation presque complète de sdb sur le nouveau sda qui est "Spare" (S)... d'où nouveaux tests sur sdb : blocks défectueux et sdb1 ne boote plus.
4. Demande de changement de sdb (on en est là, et j'ai pu sauver mes données)

Bref, 3 défaillances hardware dont 2 (les disques) que j'aurais sans doute du monitorer ... je m'en tire sans casse pour le moment, mais la leçon est prise.

Je m'apprête à défaire sdb du RAID pour voir si md1 boote à partir de sda1 (sinon il faudra le réparer, je ne sais pas encore bien comment).

buddy
29/04/2016, 09h59
Citation Envoyé par Raid1_danger
moralité : le raid 1, soit on maitrise de long en large et on installe les mdadm et autres routines de monitoring, soit on évite...
Bonjour,

heu, la faute ne revient pas à mdadm ...
Mais en partie à toi.
1) tu dois faire des sauvegardes régulières et distantes (pas sur le serveur)
2) quand tu as un serveur, il faut le monitorer.
comme tu l'as toi même dit, le disque /sda1 est défaillant depuis un moment (arrêt de copie des données)
LE disque sda2 est tout simplement mort récemment...

Tu as donc failli à détecter la défaillance de sda1 (smartctl te l'indique) et tu as peut être failli dans tes sauvegardes...
Si sda1 était complètement mort depuis plusieurs mois, avec la panne de sda2 il y a quelques jours, tu n'aurais tout simplement plus rien ...


bref tout çà pour dire, que tu es bon pour contacter le support et remplacer les 2 disques dans ton serveur ...

TBC_Ly0n
29/04/2016, 09h47
Citation Envoyé par Raid1_danger
# fdisk -l

Disque /dev/sda: 1000.2 Go, 1000204886016 octets
255 t▒tes, 63 secteurs/piste, 121601 cylindres
Unit▒s = cylindres de 16065 * 512 = 8225280 octets

P▒riph▒rique Amorce D▒but Fin Blocs Id Syst▒me
/dev/sda1 * 1 1306 10485760+ fd Linux raid autodetect
/dev/sda2 1306 121536 965746688 fd Linux raid autodetect
/dev/sda3 121536 121601 525536 82 Linux swap / Solaris

Disque /dev/md2: 988.9 Go, 988924542976 octets
2 t▒tes, 4 secteurs/piste, 241436656 cylindres
Unit▒s = cylindres de 8 * 512 = 4096 octets

Disque /dev/md2 ne contient pas une table de partition valide

Disque /dev/md1: 10.7 Go, 10737352704 octets
2 t▒tes, 4 secteurs/piste, 2621424 cylindres
Unit▒s = cylindres de 8 * 512 = 4096 octets

Disque /dev/md1 ne contient pas une table de partition valide
Tu as perdu ton disque /dev/sdb. La désynchronisation date de la date à laquelle tu retrouves tes fichiers.
Depuis le disque n'est même plus visible au niveau physique.

Donc :
  • Si tu n'avais pas de sauvegardes, tu as perdu tes données
  • il faut reconfigurer mdadm pour t'envoyer un mail quand il détecte la désynchronisation des disques. Sur Debian, un dpkg-reconfigure le gère.

Raid1_danger
23/04/2016, 18h21
Bonjour à tous,

Après pas mal de recherches, je vous expose brièvement mon problème : J'ai un serveur dédié Kimsufi / Gentoo chez OVH depuis des années en Raid 1 et je m'aperçois hier que tout le serveur a fait un bond dans le passé....

J'ai d'abord cru à une procédure automatique d'ovh qui aurait ramené pour une raison ou l'autre un vieux backup suite à une défaillance quelconque... Mais mon idée actuelle, après un cat /prod/mdstat affichant [2/1] aux deux disques, est que le Raid a du se désynchroniser (et la copie automatique s'arrêter) à la date du retour en arrière, puis que le disque principal a du avoir une défaillance (plutôt logicielle que matérielle), ce qui aurait automatiquement entrainé une copie à partir de l'autre disque... et c'est bien le problème, c'est la vieille version du serveur qui a apparemment remplacé la bonne........... moralité : le raid 1, soit on maitrise de long en large et on installe les mdadm et autres routines de monitoring, soit on évite...

Mais je ne suis même pas tout à fait sûr de mon diagnostic et j'en suis à (très) vaguement voir si une récupération de fichiers effacés pourrait me sauver la mise pour récupérer les données les plus récentes.

Voilà ce que donne fdisk :

# fdisk -l

Disque /dev/sda: 1000.2 Go, 1000204886016 octets
255 t▒tes, 63 secteurs/piste, 121601 cylindres
Unit▒s = cylindres de 16065 * 512 = 8225280 octets

P▒riph▒rique Amorce D▒but Fin Blocs Id Syst▒me
/dev/sda1 * 1 1306 10485760+ fd Linux raid autodetect
/dev/sda2 1306 121536 965746688 fd Linux raid autodetect
/dev/sda3 121536 121601 525536 82 Linux swap / Solaris

Disque /dev/md2: 988.9 Go, 988924542976 octets
2 t▒tes, 4 secteurs/piste, 241436656 cylindres
Unit▒s = cylindres de 8 * 512 = 4096 octets

Disque /dev/md2 ne contient pas une table de partition valide

Disque /dev/md1: 10.7 Go, 10737352704 octets
2 t▒tes, 4 secteurs/piste, 2621424 cylindres
Unit▒s = cylindres de 8 * 512 = 4096 octets

Disque /dev/md1 ne contient pas une table de partition valide


J'ai essayé de monter les uns et les autres avec mount -t ext3 mais je ne trouve que les vieilles données.

Des idées ?