Chibi-nah::blog

Des geekeries, de la MAO, de tout et de rien…

Archives

Serveur défaillant

Photo d'un disque dur ouvert. Photo par Magnus Hagdorn, sous licence CC BY SA

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   107   099   006    Pre-fail  Always       -       205095556
  3 Spin_Up_Time            0x0003   100   100   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       87
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   069   060   030    Pre-fail  Always       -       167761870739
  9 Power_On_Hours          0x0032   050   050   000    Old_age   Always       -       44067
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       88
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   084   084   000    Old_age   Always       -       16
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -       4295032833
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   065   050   045    Old_age   Always       -       35 (Min/Max 34/35)
194 Temperature_Celsius     0x0022   035   050   000    Old_age   Always       -       35 (0 16 0 0 0)
195 Hardware_ECC_Recovered  0x001a   023   013   000    Old_age   Always       -       205095556
197 Current_Pending_Sector  0x0012   099   099   000    Old_age   Always       -       42
198 Offline_Uncorrectable   0x0010   099   099   000    Old_age   Offline      -       42
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       44213 (132 145 0)
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       3639020994
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       2452794878

La quasi-totalité des sites que j'héberge sous les sous-domaines en chibi- nah.fr/net et en nah.re sont inaccessibles. Les données sont en cours de récupération/transfert (actuellement 42 Go transférés) vers un autre disque/serveur. La remise en ligne des sites sera fait progressivement ce week-end.

Les sites des copains, ayant déjà migré sur un autre serveur, ne sont pas impactés.

~~Plus de détails prochainement.~~

Édit : La plupart des sites et bases de données sont restaurés, je peux donner des détails.

Jeudi soir

Je lis mes flux rss, consulte mes emails, comme d'habitude. Tous les sites fonctionnent.

Vendredi matin

Vers 10h30, je me rends compte que mon client mail (K-9 Mail sur Android) ne se synchronise plus (échec de connexion) avec le serveur. Pensant à un souci de connexion 3G/HSPA, j'ignore le problème.

À 11h, toujours pas de connexion, je décide de jeter un œil sur mon webmail (j'attendais un email), et là, c'est le drame. Le webmail répond, mais ne se charge pas entièrement. Je reprend mon téléphone, et force la synchronisation. Toujours rien. Je ne me laisse pas démonter pour autant, et lance connectbot. La saisie de ma passphrase plus tard, je tente de me connecter via ssh. Échec de connexion. Mon autre serveur, lui, est joignable avec la même clef, ce n'est pas un problème de connexion. Je tente de me connecter depuis un autre PC, et là, j'ai la main.

Le shell bash m'accueille sans problème. Je tape naïvement htop, et là

Erreur d'entrée/sortie

Ooook ?

Je tente de me connecter en root (via su)

Erreur d'entrée/sortie

Je tape une commande au hasard (comme df -h)

Erreur d'entrée/sortie

Bon… Les commandes ne répondent pas

Je tente dmesg

ayaka kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ayaka kernel: ata1.00: BMDMA stat 0x64
ayaka kernel: ata1.00: failed command: READ DMA EXT
ayaka kernel: ata1.00: cmd 25/00:00:e1:3a:f7/00:01:62:00:00/e0 tag 0 dma 131072 in
ayaka kernel:         res 51/40:00:dd:3b:f7/40:00:62:00:00/00 Emask 0x9 (media error)
ayaka kernel: ata1.00: status: { DRDY ERR }
ayaka kernel: ata1.00: error: { UNC }
ayaka kernel: ata1.00: configured for UDMA/133
ayaka kernel: sd 0:0:0:0: [sda] Unhandled sense code
ayaka kernel: sd 0:0:0:0: [sda]
ayaka kernel: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
ayaka kernel: sd 0:0:0:0: [sda]
ayaka kernel: Sense Key : Medium Error [current] [descriptor]
ayaka kernel: Descriptor sense data with sense descriptors (in hex):
ayaka kernel:        72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
ayaka kernel:        62 f7 3b dd
ayaka kernel: sd 0:0:0:0: [sda]
ayaka kernel: Add. Sense: Unrecovered read error - auto reallocate failed
ayaka kernel: sd 0:0:0:0: [sda] CDB:
ayaka kernel: Read(10): 28 00 62 f7 3a e1 00 01 00 00
ayaka kernel: end_request: I/O error, dev sda, sector 1660369885
ayaka kernel: ata1: EH complete
ayaka kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ayaka kernel: ata1.00: BMDMA stat 0x64
ayaka kernel: ata1.00: failed command: READ DMA EXT
ayaka kernel: ata1.00: cmd 25/00:08:d9:3b:f7/00:00:62:00:00/e0 tag 0 dma 4096 in
ayaka kernel:         res 51/40:00:dd:3b:f7/40:00:62:00:00/00 Emask 0x9 (media error)
ayaka kernel: ata1.00: status: { DRDY ERR }
ayaka kernel: ata1.00: error: { UNC }
ayaka kernel: ata1.00: configured for UDMA/133
ayaka kernel: sd 0:0:0:0: [sda] Unhandled sense code
ayaka kernel: sd 0:0:0:0: [sda]
ayaka kernel: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
ayaka kernel: sd 0:0:0:0: [sda]
ayaka kernel: Sense Key : Medium Error [current] [descriptor]
ayaka kernel: Descriptor sense data with sense descriptors (in hex):
ayaka kernel:        72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
ayaka kernel:        62 f7 3b dd
ayaka kernel: sd 0:0:0:0: [sda]
ayaka kernel: Add. Sense: Unrecovered read error - auto reallocate failed
ayaka kernel: sd 0:0:0:0: [sda] CDB:
ayaka kernel: Read(10): 28 00 62 f7 3b d9 00 00 08 00
ayaka kernel: end_request: I/O error, dev sda, sector 1660369885
ayaka kernel: ata1: EH complete

Et ce, en boucle.

Là,petitgros moment de panique : le disque dur est en train de lâcher.

Petit aparté

Dans un mail, à la question « Ma question est la suivante : vous qui passez du temps à administrer une infra perso, quels sont ces services un peu chiants pour lesquels vous savez que vous réagissez rapidement s'ils tombent ? », j'avais répondu :

Bonsoir,

Pour moi, c'est le serveur de mails qui est ultra-prioritaire (et même
critique), parce que ma famille l'utilise également. Si jamais ce
service tombe, je lâche tout pour pouvoir intervenir le plus vite
possible pour le rétablir (les adresses sont utilisées par exemple pour
tout ce qui est administratif (impôts et autres)).

Le serveur web est plutôt critique (plusieurs domaines hébergés), tout
comme le DNS, mais ça attendra le soir (ou le week-end au pire des cas).

Pour le reste (jabber, mumble…) c'est peu prioritaire.

Alex - nah

Fin de l'aparté.

Récapitulons, on est vendredi 30 septembre, il est quasiment midi. Je pose un après-midi de congé, et je rentre.

Premier truc à faire : manger. Je réfléchis mal si j'ai le ventre vide.

Second truc à faire, se connecter au manager OVH, pour redémarrer le serveur, et le démarrer via NetBoot, sur une image rescue64.

Le temps que ça redémarre, j'ai largement le temps de me préparer un café.

Quelque minutes plus tard, le serveur pingue à nouveau. Bien entendu, l'email contenant les informations de connexion est envoyé sur le serveur de mails… qui vient de démarrer en rescue >.< mais bon, heureusement que l'une de mes clefs publiques est rattachée sur mon compte, le robot l'a bien ajouté dans la liste des clefs autorisées.

Je monte les partitions, et tente d'y accéder. À priori, le disque est encore lisible.

Je génère alors une paire de clefs ssh que je copie sur mon autre serveur dédié (j'ai de la place dessus, le débit et la bande passante ne sont pas des soucis), et je lance la longue tâche de transfert (over sshfs) de copie des fichiers.

La priorité est : tenter de sauver le maximum de fichiers. que ça soit les sites hébergés, les bases de données et (si possible) le contenu de /etc.

La copie prend une bonne partie de l'après-midi.

Il est 19h20. Les copies sont terminées, à priori, tous les fichiers ont pu être sauvegardés. Je mange un morceau, puis je m'attaque à la longue tâche qui m'attend : l'installation des services de base sur Aeka.

Notes :

Apache2 est déjà installé, avecMySQLMariaDB, je n'ai donc pas à les réinstaller.

Commençons par les plus urgents : le DNS et le serveur d'emails.

L'installation des deux services ainsi que la configuration s'est déroulé quasiment sans anicroche, je commence à recevoir les emails de la journée (dont celui attendu). Cependant, un domaine résiste. Il est 22h30, je décide d'arrêter, je dois me lever tôt samedi matin (genre, vers 5h, pour prendre le train).

Samedi matin

J'allume mon pc portable, et je reprend la configuration du domaine récalcitrant. Modifications des SOA, de la glue record, systématiquement, je me prends un timeout sur la commande DIG. Les autres domaines fonctionnant sur le même serveur, eux, répondent instantanément. Je constate alors avoir perdu trop de temps et décide d'utiliser les DNS d'OVH pour ce domaine.

Je jette un œil rapidement sur twitter, et je vois qu'une question à propos de la configurations des DNS m'est posée (Ha ? Comme par hasard). J'y réponds, précise quelques éléments, ajoute quelques pistes (comme d'hab), et j'attends que le domaine soit à nouveau joignable pour continuer la restauration des services.

Le domaine récalcitrant est finalement joignable, et les emails arrivent aussi dessus.

C'est tout pour le samedi. L'essentiel est de nouveau fonctionnel, je peux alors profiter du week-end.

Lundi soir

Je m'attelle à la tâche suivante : Restaurer les sites hébergés.

Pour ça, ce fut relativement rapide, vu que j'ai une copie de la config d'Ayaka.

J'en profite pour faire un peu de ménage sur mes sites personnels, notamment les trucs expérimentaux ou en beta.

Les sites sont restaurés, c'est bon, mais certains demandent une base de données MySQL. Je regarde le dossier des dumps SQL, et là, c'est le drame.

Des fichiers sont manquants, incomplets, corrompus ou illisibles (remplis de 0x00). Cela me prendra du temps pour tenter de récupérer les données (jusqu'à mardi soir en fait).

Je récupère les bases de données, crée une VM sur mon pc portable avec EXACTEMENT la même config que le serveur, la même version de MySQL, et je tente de monter les bases.

Les BDD sont lisibles, je me dépêche de faire des dumps. Un contrôle rapide effectué, je charge les dumps dans MariaDB, sur Aeka. Les bases sont restaurées, les comptes dédiés aussi.

J'en profite pour mettre à jour Roundcube, et le thème Melanie2

Je regarde les sites restaurés, et je me rends compte que certains sites ne sont pas compatibles php7. C'est notamment le cas de Cheveretto, de Piwigo, et d'OpenArdilla.

Cheveretto, dans la version que j'utilise, correspond à mon usage attendu (juste une solution simple pour partager des images, sans créer de galerie), mais je me demande si je ne vais pas le remplacer par une instance de lut.im.

Piwigo, je le mettrai à jour quand j'aurai le temps.

Par contre, OpenArdilla n'a jamais dépassé le stade de la version 0.1, le site n'existe plus et il n'y a aucune activité sur sourceforge depuis des années. Ça m'embête un peu, parce que je n'ai pas trouvé d'agrégateur de flux RSS similaire, ultra-minimaliste (pas de gestion de lu/non lu par exemple) avec la même disposition (n'afficher que les 10 derniers titres, par site, sans regroupement). J'ai bien un leed qui tourne, mais c'est pas pareil.

La prochaine tâche qui m'attend, c'est donc de tenter de porter OpenArdilla en PHP7. Bon courage.

Pour les autres sites, pas de problème majeur, idem pour les autres services.

Conclusion

Cela m'aura pris quelques jours pour tout récupérer et (quasiment) tout restaurer.

L'ironie du sort, c'est que j'avais planifié la migration Ayaka -> Aeka, et que j'ai commencé par les sites des copains. La migration, telle que prévue aurait du être progressive, avec un arrêt prévu d'Ayaka pour décembre. Finalement, ça aura été fait dans l'urgence.