Petite surprise du jour, je me suis retrouvé avec un disque manquant sur mon RAID5 (message suivant sur cockpit :
Danger alert:Le RAID Array est dans un état dégradé):
Petite vérification :
sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 1,8T 0 disk
└─sda1 8:1 0 1,8T 0 part
└─md127 9:127 0 3,6T 0 raid5
├─vg_data-lv_home 253:3 0 100G 0 lvm
│ └─luks-xx-xx-xx-xx-xx 253:10 0 100G 0 crypt /home
├─vg_data-lv_www 253:4 0 1,2T 0 lvm
│ └─luks-xx-xx-xx-xx-xx 253:9 0 1,2T 0 crypt /var/www/html
├─vg_data-lv_virtual02 253:5 0 600G 0 lvm
│ └─luks-xx-xx-48e6-xx-xx 253:8 0 600G 0 crypt /virtu02
└─vg_data-lv_virtual01 253:6 0 600G 0 lvm
└─luks-xx-xx-xx-xx-xx 253:7 0 600G 0 crypt /virtu01
sdb 8:16 0 1,8T 0 disk
└─md127 9:127 0 3,6T 0 raid5
├─vg_data-lv_home 253:3 0 100G 0 lvm
│ └─luks-xx-xx-xx-xx-xx 253:10 0 100G 0 crypt /home
├─vg_data-lv_www 253:4 0 1,2T 0 lvm
│ └─luks-xx-xx-xx-xx-xx 253:9 0 1,2T 0 crypt /var/www/html
├─vg_data-lv_virtual02 253:5 0 600G 0 lvm
│ └─luks-xx-xx-xx-xx-xx 253:8 0 600G 0 crypt /virtu02
└─vg_data-lv_virtual01 253:6 0 600G 0 lvm
└─luks-xx-xx-xx-xx-xx 253:7 0 600G 0 crypt /virtu01
sdc 8:32 0 1,8T 0 disk
sdd 8:48 0 232,9G 0 disk
├─sdd1 8:49 0 600M 0 part /boot/efi
├─sdd2 8:50 0 1G 0 part /boot
└─sdd3 8:51 0 231,3G 0 part
├─fedora_xxxxx0-root 253:0 0 50G 0 lvm /
├─fedora_xxxxx0-swap 253:1 0 10G 0 lvm [SWAP]
└─fedora_hxxxxxxx0-var 253:2 0 60G 0 lvm /var
zram0 252:0 0 8G 0 disk [SWAP]
En effet j'ai bien le /dev/sdc qui n'est plus attaché au RAID 5.
Vérification du disque (smartcl est dans le paquet
smartmontools) :
sudo smartctl -s on -a /dev/sdc
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.6-200.fc35.x86_64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Blue
Device Model: WDC WD20EZRZ-00Z5HB0
Serial Number: WD-xxxxxxxxxxxxx
LU WWN Device Id: 5 0014ee 265ab9a3d
Firmware Version: 80.00A80
User Capacity: 2000398934016 bytes [2,00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5400 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2 (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Mon Dec 6 08:44:25 2021 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF ENABLE/DISABLE COMMANDS SECTION ===
SMART Enabled.
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x85) Offline data collection activity
was aborted by an interrupting command from host.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 249) Self-test routine in progress...
90% of test remaining.
Total time to complete Offline
data collection: (25980) 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: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 263) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x7035) SCT Status 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 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 178 176 021 Pre-fail Always - 4083
4 Start_Stop_Count 0x0032 099 099 000 Old_age Always - 1581
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 067 067 000 Old_age Always - 24701
10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 89
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 38
193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 2912256
194 Temperature_Celsius 0x0022 112 097 000 Old_age Always - 35
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 12
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
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.
Le disque semble dans un état plus que correct. (bon après j'utilise pas des composants prévus pour cela et de très haute qualité...)
Comme j'ai fait un recâblage de mon serveur, je pense que le problème est venu de là (je l'avais refait suite à la disparition de ce disque dans le bios justement).
Du coup après quelques recherche, il m'a suffit juste de le rattaché au RAID :
sudo mdadm /dev/md127 --add /dev/sdc
Et hop plus que quelques heures (même pas 1h chez moi 🙂 ) de resynchro à attendre et le RAID 5 est de nouveau actif 🙂 :
sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 1,8T 0 disk
└─sda1 8:1 0 1,8T 0 part
└─md127 9:127 0 3,6T 0 raid5
├─vg_data-lv_home 253:3 0 100G 0 lvm
│ └─luks-xx-xx-xx-xx-xx 253:10 0 100G 0 crypt /home
├─vg_data-lv_www 253:4 0 1,2T 0 lvm
│ └─luks-xxx-xx-xx-xx-xx 253:9 0 1,2T 0 crypt /var/www/html
├─vg_data-lv_virtual02 253:5 0 600G 0 lvm
│ └─luks-xx-xx-xx-xx-xx 253:8 0 600G 0 crypt /virtu02
└─vg_data-lv_virtual01 253:6 0 600G 0 lvm
└─luks-xx-xx-xx-xxx-xx 253:7 0 600G 0 crypt /virtu01
sdb 8:16 0 1,8T 0 disk
└─md127 9:127 0 3,6T 0 raid5
├─vg_data-lv_home 253:3 0 100G 0 lvm
│ └─luks-xx-xx-xx-xx-xx 253:10 0 100G 0 crypt /home
├─vg_data-lv_www 253:4 0 1,2T 0 lvm
│ └─luks-xx-xx-xx-xx-xx 253:9 0 1,2T 0 crypt /var/www/html
├─vg_data-lv_virtual02 253:5 0 600G 0 lvm
│ └─luks-xx-xx-xx-acf6-xx 253:8 0 600G 0 crypt /virtu02
└─vg_data-lv_virtual01 253:6 0 600G 0 lvm
└─luks-xx-xx-xx-xx-xx 253:7 0 600G 0 crypt /virtu01
sdc 8:32 0 1,8T 0 disk
└─md127 9:127 0 3,6T 0 raid5
├─vg_data-lv_home 253:3 0 100G 0 lvm
│ └─luks-xx-xx-xx-xx-xx 253:10 0 100G 0 crypt /home
├─vg_data-lv_www 253:4 0 1,2T 0 lvm
│ └─luks-xx-xx-xx-xx-xx 253:9 0 1,2T 0 crypt /var/www/html
├─vg_data-lv_virtual02 253:5 0 600G 0 lvm
│ └─luks-xx-xx-xx-xx-xx 253:8 0 600G 0 crypt /virtu02
└─vg_data-lv_virtual01 253:6 0 600G 0 lvm
└─luks-xx-xx-xx-xx-xx 253:7 0 600G 0 crypt /virtu01
sdd 8:48 0 232,9G 0 disk
├─sdd1 8:49 0 600M 0 part /boot/efi
├─sdd2 8:50 0 1G 0 part /boot
└─sdd3 8:51 0 231,3G 0 part
├─fedora_xxxxxx0-root 253:0 0 50G 0 lvm /
├─fedora_xxxxxxx-swap 253:1 0 10G 0 lvm [SWAP]
└─fedora_xxxxxxx0-var 253:2 0 60G 0 lvm /var
zram0
J'ai tout de même rajouté une synchro différentiel avec mon unité de stockage dédié aux sauvegarde tous les jours, en plus de la synchro complète toutes les semaines.
Dans ce genre de cas, disparition et/ou problèmes de transfert/performance de vos disques SATA/SAS, n'hésitez pas à reprendre votre câblage, voir changer de nappes SATA/SAS 😉 . Surtout que pour ces dernières la qualité n'est pas souvent là...
Dmesg confirme que c'est rentré ans l'ordre 🙂 .
[déc. 6 08:33] md: recovery of RAID array md127
[déc. 6 08:52] md: md127: recovery done.