[coug]

Bonjour,

pour les erreurs j'ai ça :
SMART Error Log Version: 1
ATA Error Count: 38 (device log contains only the most recent five errors), avec les 5 dernières qui se suivent.

Les sites et services web c'est pas un soucis à remonter. Le problème ce sont les mails, car entre le poids et remonter l'antispam j'en ai pour un bon moment.

Aucune idée pour savoir quels sont les fichiers corrompus ?

Sylvian

[nowwhat]

...
J'avais mis le retour du smartctl mais avec la modération ça prend 3 plombe.
En gros voici quelques lignes (les plus pertinentes) :
Raw_Read_Error_Rate 0x000b 095 095 016 Pre-fail Always - 393224
Reallocated_Sector_Ct 0x0033 087 087 005 Pre-fail Always - 368
Reallocated_Event_Count 0x0032 085 085 000 Old_age Always - 452
Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 136

Sinon si vous avez une solution pour savoir quels sont les fichiers qui sont sur les block défectueux, je suis preneur, car apparemment j'en 1 sur la première partition et 4 sur la seconde , donc c'est pas la lune non plus.

Ce liste est moins impiortant.
J'ai : SMART Error Log Version: 1
No Errors Logged
Or, chez toi, t'as probablement PAS "No Errors Logged" mais une liste des erreurs.
T'as déjà 368 secteurs plus que mort sur ton disque .... c'est la fin pour très bientôt.
452 ont été déplace.

SI tu arrive à trouver QUELLES fichier sont impactés .... ne le supprime pas - renomme-les et copie le au même endroit avec le nom original.
Suivant le type de fichier (par exemple : un fichier data de MySQL) : coupe d'abord le service MySQL avant de renommer / copier.

Je te conseille d’abandonner d’essayer à tout prix de garder ton serveur UP.
Copie sauvegarde final : puis fait toi remplacer ton sda (mort aussi).
Le up des tes sites (hébergement) + bases des donénes + paramétrage serveur web : dans un petit heure ça peut être fait (tout le clique DNS inclus).
Après : paramétrage mails et restaure mails etc etc.

[coug]

Bon je remet mes réponses car là c'est vraiment long....

Es-tu en rescue ou en fonctionnement normal pendant que tu tentes de reconstruire le raid?

Non, mais les adresses des blocs en erreur sont les mêmes

Le pense que la tache est rude et qu'il veut essayer de passer outre en récupérant le max de données sur son sdb MAIS je me trompe peut-être

C'est ça : si je peux récupérer le système sur le sdb sans avoir à tout réinstaller ce serait bien.


J'avais mis le retour du smartctl mais avec la modération ça prend 3 plombe. En gros voici quelques lignes (les plus pertinentes) :
Raw_Read_Error_Rate 0x000b 095 095 016 Pre-fail Always - 393224
Reallocated_Sector_Ct 0x0033 087 087 005 Pre-fail Always - 368
Reallocated_Event_Count 0x0032 085 085 000 Old_age Always - 452
Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 136

Sinon si vous avez une solution pour savoir quels sont les fichiers qui sont sur les block défectueux, je suis preneur, car apparemment j'en 1 sur la première partition et 4 sur la seconde , donc c'est pas la lune non plus.

Sylvian

[coug]

Un modo doit valider ma réponse. Elle devrait arriver rapidement j'espère.

Sylvian

[coug]

Bonjour,

Bonsoir @nowwhat,

Le pense que la tache est rude et qu'il veut essayer de passer outre en récupérant le max de données sur son sdb MAIS je me trompe peut-être

Cdlt
Bruno

C'est exactement ça + reconstruire le raid à partir du sdb. J'ai pas envie de tout réinstaller.

Es-tu en rescue ou en fonctionnement normal pendant que tu tentes de reconstruire le raid?

Je suis en fonctionnement normal, mais les erreurs viennent des mêmes blocks.
Apparemment en lecture le block n'est pa réaloué, mais en écriture il doit l'être. Vous avez une astuce pour savoir quel fichier est sur un block défectueux?

Pour info le smartctl a donné ça:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   095   095   016    Pre-fail  Always       -       393224
  2 Throughput_Performance  0x0005   100   100   054    Pre-fail  Offline      -       231
  3 Spin_Up_Time            0x0007   128   128   024    Pre-fail  Always       -       180 (Average 178)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       33
  5 Reallocated_Sector_Ct   0x0033   087   087   005    Pre-fail  Always       -       368
  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   097   097   000    Old_age   Always       -       26341
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       33
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       996
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       996
194 Temperature_Celsius     0x0002   222   222   000    Old_age   Always       -       27 (Min/Max 11/44)
196 Reallocated_Event_Count 0x0032   085   085   000    Old_age   Always       -       452
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       136
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       8
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

Sylvian

[Daixiwen]

Es-tu en rescue ou en fonctionnement normal pendant que tu tentes de reconstruire le raid? C'est mieux de le faire en rescue, puisque le disque sda sera moins sollicité par le système et répondra peut-être mieux.
Si tu as des erreurs de lectures toujours au même endroit à chaque fois que tu lances la reconstruction c'est mort par contre, ça veut dire que le disque sda est aussi fichu.

[sloomy]

Bonsoir @nowwhat,

Le pense que la tache est rude et qu'il veut essayer de passer outre en récupérant le max de données sur son sdb MAIS je me trompe peut-être

Cdlt
Bruno

[nowwhat]

Et que dit : smartctl -a /dev/sda

Il doit le savoir déjà

Normalement ™,on exécute ce commande par cron (ou par Munin, ou à la main) au moins une fois par jour, et dès qu'il délivre autre chose comme zéro à la sortie (donc : méga alerte !!) t'aura un gentil mail qui te dit : "arrête tout, annule tout, disque sdx mourant".

Il est clair qu'ici le sda est mauvais aussi. C'est le KO. C'est le début de la fin.

Concentre toi sur une sauvegarde des tes données, de ton paramétrage, de ta liste des paquetés installées etc - et fait changer le disque sda aussi.
Après, lance un réinstall à partir de ton Manager, puis installe tes apps et services et colle une par une leur paramétrage en place.
En suite : bases des données, hébergement webs, etc.
Et t'es réup.

Mais AVANT de tout installer, va "jouer" avec ton Raid1

[sloomy]

Bonjour,

Et que dit : smartctl -a /dev/sda

Cdlt
Bruno

[coug]

Mes logs donnent ça :

 Add. Sense: Unrecovered read error - auto reallocate failed
Feb  1 09:00:30 ks3294594 md/raid1:md1: sda: unrecoverable I/O read error for block 13641472
Feb  1 09:00:30 ks3294594 md: md1: recovery interrupted.

j'en 1 sur le /dev/md1 et 4 sur le /dev/md2

Sylvian

[sloomy]

Bonjour,

Et tes logs donnent quoi comme information ?

Cdlt
Bruno

[coug]

Bonjour,

Merci pour toute ton aide, mais j'ai déjà fait tout ça sauf que les commandes

mdadm --manage /dev/md1 --add /dev/sdb1
mdadm --manage /dev/md2 --add /dev/sdb2

ne terminent pas la reconstruction à cause d'erreurs de lecture sur le sda, et met les partitions du sdb en spare et non en active, d'où mon problème.

Je n'ai pas utilisé Grub. J''ai fait ça (comme indiqué dans le guide OVH) pour créer les partitions :

 sfdisk -d /dev/sdb | sfdisk --force /dev/sda

Par contre, créer un nouveau raid 1 sur le sdb en mode dégradé (manquera un disque et j'aurais en plus /dev/md0 et /dev/md3) puis copier les données avec dd du sda au sdb, et booter sur le sdb pour reconstruire le raid sur le sda c'est jouable ou pas ?

Le hic c'est le boot sur le sdb. Je pense pas que ce soit aussi simple.

Sylvian

[nowwhat]

Le lien cité au dessus va t'aider.
Le but d'un raid1 est justement que en cas de panne grave (un des deux disques mort, donc changé, donc totalement vide) que tu synchronise les données sur ce nouveau disque. C'est l'idée d'un Raid 1 : ton serveur continue de travailler, il n'y que un petit shut-down pendant la phase de changer un disque. physiquement.

L'exemple (lien) parle bien de "Simuler une panne de disque".

Pour moi :
J'ai un "md2 et md3".

root@ns311465:~# cat /proc/mdstat
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4]
md2 : active raid1 sda2[0] sdb2[1]
      51198912 blocks [2/2] [UU]

md3 : active raid1 sda3[0] sdb3[1]
      1901786048 blocks [2/2] [UU]

unused devices: 

Je passe 'sdb(2/3)' /en fail:

mdadm --manage /dev/md2 --fail /dev/sdb2
mdadm --manage /dev/md3 --fail /dev/sdb3

Dès cet instant, mon serveur tourne sur "un patte" : uniquement sur sda.

Je retire sdb définiivement :

mdadm --manage /dev/md2 --remove /dev/sdb2
mdadm --manage /dev/md3 --remove /dev/sdb3

Je demande OVH de changer mon 'sdb'.

Après, préparation d'un NOUVEAU disque sdb:

sfdisk -d /dev/sda | sfdisk /dev/sdb

qui va copier la tables des partions de /sda vers /sdb.


Source : https://www.howtoforge.com/replacing..._a_raid1_array
(attention : lire les commentaires concernant le "grub-install /dev/sdb" (si tu utilise grub) pour que le bootloader soit aussi active sur /dev//sdb)

Un

fdisk -l

confirme que les deux disques sda et sdb on la même partions.
puis, on remet le raid1 en marche::

mdadm --manage /dev/md2 --add /dev/sdb2
mdadm --manage /dev/md3 --add /dev/sdb3

PS : Pas besoin de ré-installer ton OS ==> encore plus de down time.

[coug]

Bonjour,

oui j'ai les backup heureusement: toutes les nuits !
Mais bon si on me donne une idée pour reconstruire sans réinstall je suis preneur !

Sylvian

[sloomy]

Bonjour,

J'ai pas dis cela mais si ton disque mirroir montre des signes de faiblesses, il est plus prudent et urgent d'avoir un backup en cas d'impossibilité de reconstruire un RAID sain.

Cordialement,
Bruno

[coug]

Bonjour,

Merci pour le tuto pour avoir les mails d'alerte : c'est ce qui m'a manqué...

Donc impossible de récupérer mes données sur un disque sain d'aprés vous sans réinstaller ?

Sylvian

[nowwhat]

Bonsoir,

Le jour que mon serveur a été livré, j'ai joué avec http://denisrosenkranz.com/tuto-mdad...raid-logiciel/
Histoire d'enlever un disque du raid1 - le zapper, puis effectuer les commandes nécessaires pour réintroduire le 'nouveau' disque.
Je n'ai pas voulu apprendre de faire ça avec avec des disques avec mes données dessus

[sloomy]

Bonjour,

Oula ! backup, backup, backup et ca sent la réinstallation

Cdlt
Bruno

[coug]

Bonjour à tous,

J'ai un soucis avec mon raid1 : un des 2 disques a laché complétement et est sortie de la grappe. De là, j'ai contacté le support. Suite aux tests en rescue mode, il s'avère que le sdb est mort et que le sda est fatigué (le raid tourne dessus actuellement en mode dégradé).

Je fais donc intervenir le support pour changer le sdb mort. Ce qu'ils font.
Je suis le guide pour reconstruire le raid après changement du disque et je recrée les partitions sur le nouveau sdb. Jusque là pas de problème.

Là où ça se complique c'est que le sda est fatigué et lors de reconstruction des 2 partitions du raid (/dev/md1 et /dev/md2) j'ai des read error qui font planter la reconstruction et les partitions du sdb se retrouvent en spare au lieu de active.

J'ai un peu chercher mais apparemment avec les read error il m'est impossible de récupérer mon raid originel.
J'ai trouvé un post sur un autre forum anglais qui pourrait me sauver la mise :
1. Supprimer le sdb du raid actuel en virant les partitions en spare
2. Créer un second raid1 vide sur le sdb avec deux partitions (/dev/md0 et /dev/md3).
3. "Create a new filesystem on the second RAID". là je n'ai pas traduit car je ne sais pas ce qu'il veut dire
4. Copier les fichiers du raid du sda sur le raid du sdb.
5. "Switch to the new filesystem." même remarque que pour le point 3
6. Deconstruire le RAID 1 du sda.
7. Ajouter le sda dans le raid du sdb (/dev/md0 et /dev/md3).
(La reconstruction va lire depuis le deuxième disque et écrire sur le premier disque. Lorsque le bloc défectueux sera écrit, il devrait être à nouveau lisible..)
8. Attendre la reconstruction.
9. Voir si tout est bon.

La reconstruction n'est pas obligatoire, puisque je doit faire changer le sda par le support, mais je dois récupérer mes données (pas envie de paramétrer le serveur de A à Z).

Donc d'aprés vous est-ce faisable ?
Que représentent les points 3 et 5 ?

Merci.

Sylvian