title: Serveur défaillant
date: 2016-09-30
tags: blog, linux
url: serveur-defaillant
slug: serveur-defaillant
 Photo par [Magnus Hagdorn](https://www.flickr.com/photos/hagdorned/15021103291/in/lbum-72157646804892131/), sous [licence CC BY SA](https://creativecommons.org/licenses/by-sa/2.0/fr/)
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](https://f-droid.org/posts/k-9-mail/)) 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](https://f-droid.org/repository/browse/?fdfilter=connectbot&fdid=org.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 :
* Serveur dédié défaillant : [Ayaka (雪広 あやか)](https://duckduckgo.com/?q=ayaka+yukihiro)
* Serveur dédié fonctionnel : [Aeka (柾木 阿重霞 樹雷)](https://duckduckgo.com/?q=masaki+aeka+jurai)
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](https://roundcube.net/), et le
thème [Melanie2](https://github.com/messagerie-melanie2/Roundcube-Skin-Melanie2-Larry-Mobile)
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](http://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.
.