Hier matin vers 8h le serveur de base de donnée s'est mis à se comporter de manière extrêmement lente. L'un des CPU était bloqué à 100% en waiting (top retourne 25% cpu waiting en permannence, et c'est un 4 coeurs), curieux, le redémarrage de mysql n'y change rien, je lance alors un reboot soft du système, mais après 20 minutes, le serveur n'a pas toujours pas booté (SSH off).
Le problème ne semblant pas du à un problème de notre logiciel, nous avons contacté le support, qui nous a informé que deux des disques durs du serveur de base de donnée du site sont tombés défaillants. Ceci ayant été détecté lors de la vérification du système de fichiers lancé en mode recovery qui retournait nombreuses erreurs d'après le technicien.
J'accède au serveur en mode recovery, puis je monte mes partitions.
D'abord "fdisk -l" retourne :
> Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x0007d44f
>
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 4096 20975616 20971521 10G fd Linux raid autodetect
/dev/sda2 20975617 1952468992 1931493376 921G fd Linux raid autodetect
/dev/sda3 1952468993 1953520064 1051072 513.2M 82 Linux swap / Solaris
>
Partition 3 does not start on physical sector boundary.
>
Partition 4 does not start on physical sector boundary.
>
>
Disk /dev/md2: 921 GiB, 988924542976 bytes, 1931493248 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Alignment offset: 3584 bytes
Disk /dev/md1: 10 GiB, 10737352704 bytes, 20971392 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Alors je monte les systèmes de fichiers dans /mnt2 que je créé pour l'occasion :
> mkdir /mnt2
mount /dev/md1 /mnt2/
mount /dev/md2 /mnt2/home/
Dans /mnt2 je retrouve bien un système de fichier qui m'appartient, mais qui s'apparente à une backup de 2013 !
J'effectue mon chroot:
> chroot /mnt2/
Je vais voir les fichiers qui m'interessent :
> cd /home/mysql/tarot/
ls
La je trouve seulement certaines tables de ma base de données, en fait je trouve les tables de la version 2013 de ma base de donnée. Pour vérifier, je lance mysql
>/etc/init.d/mysql start
mysql -uroot -p******** tarot
mysqldump -uroot -p****** tarot utilisateurs > Test.sql
Je retrouve bien dans Test.sql une vieille version de ma table utilisateurs datant de 2013, avec les dates de dernière présence des utilisateurs qui coincident, derniers comptes créés en 2013, structure de la table datant de 2013. C'est une backup de mon disque, mais ce ne sont pas les données actuelles, avant redémarage en mode rescue. Je n'ai jamais vu çà, cela me semble impossible et incohérent.
Pour en avoir le coeur net, je vais voir dans les logs :
>tail /var/log/httpd/ovh-access_log
Voici le résultat :
> localhost - - [28/Jul/2013:13:24:48 +0200] "GET /ovh-status?auto HTTP/1.1" 200 1186 "-" "collectd/3.9.2"
localhost - - [28/Jul/2013:13:24:58 +0200] "GET /ovh-status?auto HTTP/1.1" 200 1186 "-" "collectd/3.9.2"
localhost - - [28/Jul/2013:13:25:08 +0200] "GET /ovh-status?auto HTTP/1.1" 200 1186 "-" "collectd/3.9.2" […]
Ou encore :
> tail /var/log/messages
Me retroune
> Jul 28 13:26:01 ns3099496 cron[29944]: (root) CMD (/usr/local/rtm/bin/rtm 12 > /dev/null 2> /dev/null)
C'est une backup ?
Ou sont mes données ?
Je sais qu'un fichier, nommé forumsujets.frm devrait se trouver dans la dernière version de la base de donnée, j'effectue alors une recherche sur ce fichier :
> cd /
find -name "forumsujets.frm'
Aucun résultats, j'essaye alors locate :
> locate forumsujets
Le système me retourne :
> /home/mysql/tarot/forumsujets.frm
/home/mysql/tarot/forumsujets.MYD
/home/mysql/tarot/forumsujets.MYI
Incroyable !
Mais :
> ls /home/mysql/tarot/
Ne retourne pas de fichier forumsujets.xxx
Quelqu'un y voit-t-il une explication ?
Je n'ose pas redémarer le serveur sur son boot normal, de peur de faire empirer la situation.
Je ne voit que très peu de possibilités :
- il y a un Raid soft, peut être ce raid effectue des backups des données, ou duplications, deux copies étaient effectuées de mes données ? la défaillance a fait basculer l'utilisation d'une copie qui n'était plus maintenue à jour depuis 2013 ?
- le disque a été changé, un disque a été changé, …
- j'ai mal monté mes systèmes de fichiers
- je suis dans un méchant cauchemar depuis hier…
Bonjour,
Hypothèse fort probable
En 2013 un disque présente des problèmes et se de synchronise du raid.
En 2017 le 2me disque casse.
Le raid essaye de repartir. Le disque 2 est mort donc il se remonte sur le disque 1 (qui date de 2013 puisqu'il était défaillant depuis 2013 et donc sorti du raid à cette date là) .
Mais vous ne semblez pas être dans la bonne section du forum.
Si vous n'avez aucun backup externe ça semble mal parti..
Cela semble mal parti en effet.
Pensez-vous que des techniciens OVH pourraient facturer une intervention ?
Je tiens beaucoup à ces données, car les backups étaient faites sur le même système de fichier dans une autre base qui a donc connu le même sort.
Je ne trouve pas de section plus convenable pour ce sujet dans le forum, quelle section serait plus pertinente ?
Dédié mais ce n'est pas grave.
Non au mieux les techniciens récupèrent les dds en les changeant et vous les envoie (contre rachat du dd). Après libre à vous de contacter une société spécialisée dans la récupération des données.
Mais avant, que renvoie
smartctl -a /dev/sda
smartctl -a /dev/sdb
smartctl -a /dev/sda
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-4.4.23-mod-std-ipv6-64-rescue] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda 7200.14 (AF)
Device Model: ST1000DM003-9YN162
Serial Number: S1D23Y6K
LU WWN Device Id: 5 000c50 04b545541
Firmware Version: CC4H
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 7200 rpm
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: Sat Mar 4 08:43:06 2017 CET
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: (0x82) Offline data collection activity
was completed without error.
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: ( 584) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
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: ( 116) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x3085) SCT Status supported.
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 103 099 006 Pre-fail Always - 220546165
3 Spin_Up_Time 0x0003 097 097 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 14
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 224
7 Seek_Error_Rate 0x000f 089 060 030 Pre-fail Always - 828120307
9 Power_On_Hours 0x0032 055 055 000 Old_age Always - 39746
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 13
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 078 078 000 Old_age Always - 22
188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 0 0
189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0022 063 051 045 Old_age Always - 37 (Min/Max 25/49)
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 12
193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 26
194 Temperature_Celsius 0x0022 037 049 000 Old_age Always - 37 (0 23 0 0 0)
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 136
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 136
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 39744h+19m+34.373s
241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 1073486515116
242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 654004613546
SMART Error Log Version: 1
ATA Error Count: 21 (device log contains only the most recent five errors)
CR = Command Register [HEX]
FR = Features Register [HEX]
SC = Sector Count Register [HEX]
SN = Sector Number Register [HEX]
CL = Cylinder Low Register [HEX]
CH = Cylinder High Register [HEX]
DH = Device/Head Register [HEX]
DC = Device Command Register [HEX]
ER = Error register [HEX]
ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.
Error 21 occurred at disk power-on lifetime: 39731 hours (1655 days + 11 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 08 ff ff ff 4f 00 14d+13:12:18.051 READ FPDMA QUEUED
ef 10 02 00 00 00 a0 00 14d+13:12:18.051 SET FEATURES [Enable SATA feature]
27 00 00 00 00 00 e0 00 14d+13:12:18.051 READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
ec 00 00 00 00 00 a0 00 14d+13:12:18.050 IDENTIFY DEVICE
ef 03 46 00 00 00 a0 00 14d+13:12:18.050 SET FEATURES [Set transfer mode]
Error 20 occurred at disk power-on lifetime: 39731 hours (1655 days + 11 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 08 ff ff ff 4f 00 14d+13:12:15.173 READ FPDMA QUEUED
ea 00 00 00 00 00 a0 00 14d+13:11:58.308 FLUSH CACHE EXT
61 00 08 ff ff ff 4f 00 14d+13:11:58.307 WRITE FPDMA QUEUED
ea 00 00 00 00 00 a0 00 14d+13:11:58.307 FLUSH CACHE EXT
ea 00 00 00 00 00 a0 00 14d+13:11:58.091 FLUSH CACHE EXT
Error 19 occurred at disk power-on lifetime: 39731 hours (1655 days + 11 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 08 ff ff ff 4f 00 14d+13:11:08.047 READ FPDMA QUEUED
ef 10 02 00 00 00 a0 00 14d+13:11:08.046 SET FEATURES [Enable SATA feature]
27 00 00 00 00 00 e0 00 14d+13:11:08.046 READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
ec 00 00 00 00 00 a0 00 14d+13:11:08.046 IDENTIFY DEVICE
ef 03 46 00 00 00 a0 00 14d+13:11:08.046 SET FEATURES [Set transfer mode]
Error 18 occurred at disk power-on lifetime: 39731 hours (1655 days + 11 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 08 ff ff ff 4f 00 14d+13:11:05.103 READ FPDMA QUEUED
ea 00 00 00 00 00 a0 00 14d+13:11:03.031 FLUSH CACHE EXT
61 00 08 80 0f 40 41 00 14d+13:11:03.031 WRITE FPDMA QUEUED
ea 00 00 00 00 00 a0 00 14d+13:11:03.030 FLUSH CACHE EXT
ea 00 00 00 00 00 a0 00 14d+13:11:02.813 FLUSH CACHE EXT
Error 17 occurred at disk power-on lifetime: 39731 hours (1655 days + 11 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 08 ff ff ff 4f 00 14d+13:04:02.758 READ FPDMA QUEUED
ef 10 02 00 00 00 a0 00 14d+13:04:02.758 SET FEATURES [Enable SATA feature]
27 00 00 00 00 00 e0 00 14d+13:04:02.758 READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
ec 00 00 00 00 00 a0 00 14d+13:04:02.758 IDENTIFY DEVICE
ef 03 46 00 00 00 a0 00 14d+13:04:02.757 SET FEATURES [Set transfer mode]
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% 12 -
# 2 Short offline Completed without error 00% 6 -
# 3 Short offline Completed without error 00% 6 -
# 4 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.
smartctl -a /dev/sdb
`Smartctl open device: /dev/sdb failed: No such device `
root@rescue:~# parted -l
Model: ATA ST1000DM003-9YN1 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 2097kB 10.7GB 10.7GB primary ext3 boot, raid
2 10.7GB 1000GB 989GB primary ext3 raid
3 1000GB 1000GB 538MB primary linux-swap(v1)
Model: Linux Software RAID Array (md)
Disk /dev/md1: 10.7GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Disk Flags:
Number Start End Size File system Flags
1 0.00B 10.7GB 10.7GB ext3
Model: Linux Software RAID Array (md)
Disk /dev/md2: 989GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Disk Flags:
Number Start End Size File system Flags
1 0.00B 10.7GB 10.7GB ext3
Model: Linux Software RAID Array (md)
Disk /dev/md2: 989GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Disk Flags:
Number Start End Size File system Flags
1 0.00B 989GB 989GB ext3
Sdb est bien mort.. Tu peux toujours demander au technicien de vérifier que le câble SATA est bien branché mais c'est rarissime qu'il se débranche ou casse.
Tu peux demander au technicien de le sortir du serveur et de te l'envoyer (et donc de l'acheter) ..
C'est entre 100 et 150 euro puis il faudra le confier à une société spécialisée.
Pour sda il est mourrant..
En fait c'est à toi de vérifier régulièrement ton serveur et l'état des disques.
Je ne sais pas quel serveur tu as mais chez soyoustart ou ovh, tu as un espace disque FTP et tu peux faire dessus des backups externes.
Dans tous les cas, je te conseille de repartir sur un serveur neuf.
Normallement, on automatische ce genre de vérification :
smartctl -a /dev/sda
smartctl -a /dev/sdb
par Munin ou comparable, ou mdadm pour vérifier la cohérence de raid ou tout autre moyen.
Dès qu'un truc sort de l'ordinaire, tu fait envoyer un sms / mail / signal de détresse, ou cette grosse bouton rouge …
Puis on sauvegarde TOUT sauf de truc pas important … (et surtout pas sur le même serveur - un NAS chez toi fera l'affaire déjà).
Il est vrai que le RTM test aussi pas mal de choses, mais apparemment pas l'état d'un raid …