Vous êtes sur la page 1sur 1

Contenu | Rechercher | Menus

Recherche rapide.... Forum ok

Identifiant Mot de passe connexion / inscription

Communauté francophone d'utilisateurs d'Ubuntu

Accueil Annonce

Documentation DVD, clés USB et t-shirts Ubuntu-fr disponibles sur la boutique En Vente Libre

Forum Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.
Navigation
- Règles À propos de l'équipe du forum.

Liens de recherche
- Messages récents Accueil » Forum » Sécurité » Problème RAID1 après reinstall Ubuntu
- Discussions sans réponse Pages : 1

Planet OdEa Le 10/05/2020, à 17:15 #1

Bonjour,
je m'arrache les cheveux depuis quelques heures suite à la reinstallation d'Ubuntu.
J'ai installé l'OS sur un SSD (sda) et j'avais avant 2 HDD en RAID1 (sdb et sdc) avec mdadm.

Pour l'installation de l'OS j'ai lu et exécuté le mode opératoire suivant :


1 - débrancher les HDD
2 - lancer le live CD et installer Ubuntu
3 - reboot
4 - installer mdadm
5 - reboot

Je suis arrivé à la situation suivante :

$ sudo fdisk -l
Disque /dev/sda : 37,28 GiB, 40020664320 octets, 78165360 secteurs
Disk model: INTEL SSDSA2M040
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x000c383d

Périphérique Amorçage Début Fin Secteurs Taille Id Type


/dev/sda1 * 2048 1050623 1048576 512M b W95 FAT32
/dev/sda2 1052670 78163967 77111298 36,8G 5 Étendue
/dev/sda5 74866688 78163967 3297280 1,6G 82 partition d'échange Linux / Solaris
/dev/sda6 1052672 74866687 73814016 35,2G 83 Linux

Les entrées de la table de partitions ne sont pas dans l'ordre du disque.

Disque /dev/sdb : 1,84 TiB, 2000398934016 octets, 3907029168 secteurs


Disk model: WDC WD20EARS-00M
Unités : secteur de 1 × 512 = 512 octets

$ cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md127 : active (auto-read-only) raid1 sdb1[1]
1953511865 blocks super 1.2 [2/1] [_U]

unused devices: <none>

$ sudo mdadm -D /dev/md127


/dev/md127:
Version : 1.2
Creation Time : Sat Nov 6 22:16:42 2010
Raid Level : raid1
Array Size : 1953511865 (1863.01 GiB 2000.40 GB)
Used Dev Size : 1953511865 (1863.01 GiB 2000.40 GB)
Raid Devices : 2
Total Devices : 1
Persistence : Superblock is persistent

Update Time : Sun May 10 16:33:41 2020


State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 0
Spare Devices : 0

Consistency Policy : resync

Name : :RAID1

Donc j'ai l'impression d'avoir automatiquement un RAID (/dev/md127), mais qu'un des 2 disques, sdc1 n'est pas attaché.
J'ai essayé ceci

$ sudo mdadm --assemble --scan


mdadm: Found some drive for an array that is already active: /dev/md/:RAID1
mdadm: giving up.

ca n'a pas vraiment aidé.

Est-ce que j'ai loupé quelque chose ?


Merci pour votre aide !

Dernière modification par OdEa (Le 10/05/2020, à 17:16)

bruno Le 11/05/2020, à 07:54 #2

Bonjour,

Cela me semble étrange d'avoir à la fois des disques avec une partition de type Linux Raid et un RAID partitionné (3 partitions) dans le retour de fdisk.
Comment était configuré le RAID avant la réinstallation ?
Il faut éclaircir ce point avant toute manipulation sur le RAID.

Peux-tu donner les retours de :

blkid

cat /etc/mdadm/mdadm.conf

mdadm --detail --scan --verbose

Pour l'instant un des volumes n'est pas intégré (removed) au RAID.

Dernière modification par bruno (Le 11/05/2020, à 07:56)

Le mensonge et la crédulité s'accouplent et engendrent l'opinion.

OdEa Le 11/05/2020, à 09:52 #3

Bonjour bruno et merci pour ta réponse rapide.


J'ai le sentiment que côté partitions tout est OK :
3 partitions sur les 2 disques de 2To, ce sont mes disques de données (Musiques, Vidéos et Data, j'avais partitionné à l'époque, pas sur que ce soit si
nécessaire que ca finalement...).

J'ai essayé d'avancer avec des commandes pas trop risquées, et j'ai réussi à changer md127 en md0 en faisant ceci :
Arrêter le raid md127 :

sudo mdadm --stop /dev/md127

Retrouver le raid md0 : je l'ai retrouvé mais toujours sans sdc1 :

sudo mdadm --assemble --scan

Puis j'ai ajouté sdc1, et via proc/mdstat j'ai vu la synchro des disques :

sudo mdadm --add /dev/md0 /dev/sdc1

Ce matin voici ce que j'ai, et qui pourrait expliquer des choses :

cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdc1[2](F) sdb1[1]
1953511865 blocks super 1.2 [2/1] [_U]

unused devices: <none>

sudo mdadm -D /dev/md0


/dev/md0:
Version : 1.2
Creation Time : Sat Nov 6 22:16:42 2010
Raid Level : raid1
Array Size : 1953511865 (1863.01 GiB 2000.40 GB)
Used Dev Size : 1953511865 (1863.01 GiB 2000.40 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Mon May 11 09:33:02 2020


State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 1
Spare Devices : 0

Consistency Policy : resync

Name : :RAID1

J'ai le disque 2 en faulty !


Je vais chercher un peu de mon côté pour scanner le disque et relancer un ajout dans le raid, mais si tu as une idée je suis preneur.

Voici les résultats des commandes que tu m'as demandé de taper :

blkid
/dev/sda6: UUID="aba7f69d-4cc0-4145-aa9e-ea9b6055561a" TYPE="ext4" PARTUUID="000c383d-06"

sda c'est le disque ssd principal avec l'OS.

sudo mdadm --detail --scan --verbose


ARRAY /dev/md0 level=raid1 num-devices=2 metadata=1.2 name=:RAID1 UUID=c4705cc8:0d2d0cca:c1a35fe5:12acc704
devices=/dev/sdb1,/dev/sdc1

mdadm.conf est vide. Si j'ai bien compris je peux ajouter un disque à la grappe raid et m'occuper de ce fichier de conf après.

OdEa Le 11/05/2020, à 10:08 #4

J'ai ca dans kern.log :

May 11 02:02:25 Planck kernel: [11857.909693] sd 4:0:0:0: [sdc] tag#2 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRI
May 11 02:02:25 Planck kernel: [11857.909699] sd 4:0:0:0: [sdc] tag#2 CDB: Write(10) 2a 00 89 7f 02 cf 00 05 00 00
May 11 02:02:25 Planck kernel: [11857.909703] blk_update_request: I/O error, dev sdc, sector 2306802383 op 0x1:(WRITE) flag
May 11 02:02:25 Planck kernel: [11857.909790] sd 4:0:0:0: [sdc] tag#3 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRI
May 11 02:02:25 Planck kernel: [11857.909794] sd 4:0:0:0: [sdc] tag#3 CDB: Write(10) 2a 00 89 7e fd cf 00 05 00 00
May 11 02:02:25 Planck kernel: [11857.909799] blk_update_request: I/O error, dev sdc, sector 2306801103 op 0x1:(WRITE) flag
May 11 02:02:25 Planck kernel: [11857.909830] sd 4:0:0:0: [sdc] tag#4 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRI
May 11 02:02:25 Planck kernel: [11857.909835] sd 4:0:0:0: [sdc] tag#4 CDB: Write(10) 2a 00 89 7e f8 4f 00 05 80 00
May 11 02:02:25 Planck kernel: [11857.909840] blk_update_request: I/O error, dev sdc, sector 2306799695 op 0x1:(WRITE) flag
May 11 02:02:25 Planck kernel: [11857.909842] sd 4:0:0:0: [sdc] tag#12 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DR
May 11 02:02:25 Planck kernel: [11857.909847] sd 4:0:0:0: [sdc] tag#12 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 0
May 11 02:02:25 Planck kernel: [11857.909854] blk_update_request: I/O error, dev sdc, sector 71 op 0x1:(WRITE) flags 0x800
May 11 02:02:25 Planck kernel: [11857.909858] md: super_written gets error=10
May 11 02:02:25 Planck kernel: [11857.909862] md/raid1:md0: Disk failure on sdc1, disabling device.
May 11 02:02:25 Planck kernel: [11857.909862] md/raid1:md0: Operation continuing on 1 devices.
May 11 02:02:25 Planck kernel: [11857.909905] sd 4:0:0:0: [sdc] tag#13 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DR
May 11 02:02:25 Planck kernel: [11857.909909] sd 4:0:0:0: [sdc] tag#13 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 0
May 11 02:02:25 Planck kernel: [11857.909914] blk_update_request: I/O error, dev sdc, sector 327 op 0x1:(WRITE) flags 0x800
May 11 02:02:25 Planck kernel: [11857.909916] md: super_written gets error=10
May 11 02:02:26 Planck kernel: [11859.047464] md: md0: recovery interrupted.
M 11 02 04 55 Pl k k l [12008 278663] d 4 0 0 0 [ d ] t #14 FAILED R lt h tb t DID BAD TARGET d i b t DR

bruno Le 11/05/2020, à 10:17 #5

Que ce soit md0 ou md127 n'a pour l'instant pas d'importance.


Bon le dernier retour confirme que le disque correspondant à sdc est probablement HS.
Il faut donner un retour complet de smartctl sur ce disque :

sudo smartctl -a /dev/sdc

Le mensonge et la crédulité s'accouplent et engendrent l'opinion.

OdEa Le 11/05/2020, à 10:50 #6

J'ai redémarré le PC, mais avant, j'ai un peu touché le cable SATA d'un des disques. Il avait l'air d'être très très très légèrement incliné d'un côté (1/4 de
milimètre ! vraiment rien).
Voici le résultat de smartctl :

sudo smartctl -a /dev/sdc


smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-29-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===


Model Family: Western Digital Caviar Green (AF)
Device Model: WDC WD20EARS-00MVWB0
Serial Number: WD-WMAZA1237407
LU WWN Device Id: 5 0014ee 655d19e65
Firmware Version: 51.0AB51
User Capacity: 2000398934016 bytes [2,00 TB]
Sector Size: 512 bytes logical/physical
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS (minor revision not indicated)
SATA Version is: SATA 2.6, 3.0 Gb/s
Local Time is: Mon May 11 10:43:32 2020 CEST
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

j'arrive maintenant à faire le smartctl, avant le reboot je n'y arrivais pas, a priori tout a l'air OK, si ca se trouve c'était à cause du cable ! EDIT : quoiqu'il y a
eu quand même quelques erreurs...
Que mon conseilles-tu de faire ?
est-ce que ma procédure d'arret du raid et d'ajout de sdc1 à md0 te parait correcte ?

Dernière modification par OdEa (Le 11/05/2020, à 11:03)

bruno Le 11/05/2020, à 11:14 #7

Bon il y a des erreurs sur le disque, cela me semble être des erreurs graves mais je ne suis pas spécialiste des résultats de smartctl.

Pour la procédure en #3 j'aurais fait :

sudo mdadm --stop /dev/md127

mdadm -A /dev/md0 /dev/sdb1 /dev/sdc1

Si tu arrives à reconstruire proprement le RAID sur /dev/md0, n'oublie pas de lancer :

sudo update-initramfs -u

pour éviter de te retrouver à nouveau avec /dev/md127

Le mensonge et la crédulité s'accouplent et engendrent l'opinion.

OdEa Le 11/05/2020, à 18:43 #8

Ca a l'air d'avoir fonctionné !, malgré ces messages dans syslog pendant la reconstruction :

May 11 17:40:03 Planck smartd[796]: Device: /dev/sdc [SAT], FAILED SMART self-check. BACK UP DATA NOW!
May 11 17:40:03 Planck smartd[796]: Device: /dev/sdc [SAT], 185 Currently unreadable (pending) sectors (changed -6)
May 11 17:40:03 Planck smartd[796]: Device: /dev/sdc [SAT], Failed SMART usage Attribute: 5 Reallocated_Sector_Ct.
May 11 17:40:03 Planck smartd[796]: Device: /dev/sdc [SAT], SMART Prefailure Attribute: 5 Reallocated_Sector_Ct changed from

Voici ce que j'ai après la reconstruction du raid :

$ cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdc1[2] sdb1[1]
1953511865 blocks super 1.2 [2/2] [UU]

unused devices: <none>

$ sudo mdadm -D /dev/md0


/dev/md0:
Version : 1.2
Creation Time : Sat Nov 6 22:16:42 2010
Raid Level : raid1
Array Size : 1953511865 (1863.01 GiB 2000.40 GB)
Used Dev Size : 1953511865 (1863.01 GiB 2000.40 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Mon May 11 18:29:28 2020


State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Consistency Policy : resync

Name : :RAID1

j'ai fait le sudo update-initramfs -u


Mais avant de redémarrer je me pose la question du fichier /etc/mdadm/mdadm.conf
Je ne pense pas qu'il soit correct.
Si j'ai bien compris je dois lancer la commande suivante pour retrouver mon raid au reboot :

sudo mdadm -Es >> /etc/mdadm/mdadm.conf

Voici ce que donne mdadm -Es :

ARRAY /dev/md/RAID1 metadata=1.2 UUID=c4705cc8:0d2d0cca:c1a35fe5:12acc704 name=:RAID1

Est-ce que je peux changer cette ligne par ceci ? :

ARRAY /dev/md0 metadata=1.2 UUID=c4705cc8:0d2d0cca:c1a35fe5:12acc704 name=raid1

ou tout simplement comme c'était avant de resintaller le system:

ARRAY /dev/md0 devices=/dev/sdc1,/dev/sdb1

Encore merci pour ton aide Bruno ! je pense voir le bout du tunnel.

bruno Le 11/05/2020, à 21:16 #9

Pour générer le fichier mdadm.conf :

mdadm --detail --scan --verbose >> /etc/mdadm/mdadm.conf

Mais attention les erreurs dans le syslog indique des secteurs ré-alloués. Le disque a donc bien des secteurs défectueux. Il faudrait au minimum faire un tes
approfondi avec smartctl et peut-être envisager de changer le disque.
J'espère que tu as bien une sauvegarde de tes données.

Le mensonge et la crédulité s'accouplent et engendrent l'opinion.

OdEa Le 11/05/2020, à 21:41 #10

Je commence en effet à me demander si le disque n'est pas mort :

May 11 18:10:03 Planck smartd[796]: Device: /dev/sdc [SAT], FAILED SMART self-check. BACK UP DATA NOW!
May 11 18:10:03 Planck smartd[796]: Device: /dev/sdc [SAT], 177 Currently unreadable (pending) sectors (changed -8)
May 11 18:10:03 Planck smartd[796]: Device: /dev/sdc [SAT], Failed SMART usage Attribute: 5 Reallocated_Sector_Ct.
May 11 18:40:03 Planck smartd[796]: Device: /dev/sdc [SAT], FAILED SMART self-check. BACK UP DATA NOW!
May 11 18:40:03 Planck smartd[796]: Device: /dev/sdc [SAT], 167 Currently unreadable (pending) sectors (changed -10)
May 11 18:40:03 Planck smartd[796]: Device: /dev/sdc [SAT], Failed SMART usage Attribute: 5 Reallocated_Sector_Ct.
May 11 18:40:03 Planck smartd[796]: Device: /dev/sdc [SAT], SMART Prefailure Attribute: 5 Reallocated_Sector_Ct changed fro
May 11 18:40:03 Planck smartd[796]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 114
May 11 19:07:22 Planck kernel: [30511.068256] sd 4:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support
May 11 19:10:02 Planck smartd[796]: Device: /dev/sdc [SAT], FAILED SMART self-check. BACK UP DATA NOW!
May 11 19:10:02 Planck smartd[796]: Device: /dev/sdc [SAT], 176 Currently unreadable (pending) sectors (changed +9)
May 11 19:10:02 Planck smartd[796]: Device: /dev/sdc [SAT], Failed SMART usage Attribute: 5 Reallocated_Sector_Ct.
May 11 19:10:02 Planck smartd[796]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 117
May 11 19:30:25 Planck kernel: [31894.604634] sd 4:0:0:0: [sdc] Synchronizing SCSI cache
May 11 19:30:25 Planck kernel: [31894.604698] sd 4:0:0:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARG
May 11 19:30:25 Planck kernel: [31894.604700] sd 4:0:0:0: [sdc] Stopping disk
May 11 19:30:25 Planck kernel: [31894.604710] sd 4:0:0:0: [sdc] Start/Stop Unit failed: Result: hostbyte=DID_BAD_TARGET dri
May 11 19:30:34 Planck udisksd[801]: Unable to resolve /sys/devices/virtual/block/md0/md/dev-sdc1/block symlink
May 11 19:36:15 Planck udisksd[801]: Unable to resolve /sys/devices/virtual/block/md0/md/dev-sdc1/block symlink
May 11 19:36:47 Planck udisksd[801]: Unable to resolve /sys/devices/virtual/block/md0/md/dev-sdc1/block symlink
M 11 19 40 02 Pl k td[796] D i /d / d [SAT] d ATA d i N h d i

Si ca se trouve il est sorti du raid depuis bien longtemps et je ne m'en rends compte que maintenant en reinstallant Ubuntu !
En même temps c'était le but du RAID 1 : pouvoir récupérer mes données en cas de défaillance de disque

Ce serait utile de tenter de le réparer ? avec un fsck par exemple ?


Je pense me tourner vers de l'archivage cloud et ne plus me prendre la tête avec des disques et des raid.

Dernière modification par OdEa (Le 11/05/2020, à 21:42)

bruno Le 11/05/2020, à 22:28 #11

Le RAID n'est pas une sauvegarde


mdadm intègre un dispositif de surveillance qui permet de recevoir automatiquement un courriel en cas de défaillance d'un disque.Encore faut-il l'avoir
configuré.

Je doute que fsck arrive à corriger les problème de secteur défaillant sur un disque. Le mieux est de remplacer le disque et de reconstruire le RAID avec un
disque neuf.

Le mensonge et la crédulité s'accouplent et engendrent l'opinion.

OdEa Le 11/05/2020, à 23:08 #12

Je voulais plutôt dire que le but était de ne pas perdre ses données en cas de défaillance d'un disque.
En tout cas merci pour ton aide !
ps: je confirme, le disque est bien mort et fait des bruits étranges...

geole Le 11/05/2020, à 23:13 #13

Bonsoir.
Je comprends que ton raids a remis en route.
Dépèche toi de sauver tes données ailleurs car le disque sdc est complétement pourri.
tu feras aussi un rapport smartctl de l'autre disque SDB. il n'est probablement pas en meilleur état.

Dernière modification par geole (Le 11/05/2020, à 23:40)

geole Le 11/05/2020, à 23:39 #14

OdEa a écrit :

sudo smartctl -a /dev/sdc


=== START OF INFORMATION SECTION ===
Model Family: Western Digital Caviar Green (AF)
Device Model: WDC WD20EARS-00MVWB0
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===


ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 149 149 140 Pre-fail Always - 973
9 Power_On_Hours 0x0032 001 001 000 Old_age Always - 78758
193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 1315025
196 Reallocated_Event_Count 0x0032 001 001 000 Old_age Always - 378
197 Current_Pending_Sector 0x0032 199 196 000 Old_age Always - 437

SMART Error Log Version: 1


ATA Error Count: 58654 (device log contains only the most recent five errors)
Error 58654 occurred at disk power-on lifetime: 42565 hours (1773 days + 13 hours)
When the command that caused the error occurred, the device was active or idle.

j'arrive maintenant à faire le smartctl, avant le reboot je n'y arrivais pas, a priori tout a l'air OK, si ca se trouve c'était à cause du cable ! EDIT :
quoiqu'il y a eu quand même quelques erreurs...
Que mon conseilles-tu de faire ?

58654 erreurs! Ce n'est pas quelques erreurs mais plus d'une erreur par heure.
437 secteurs totalement illisibles qui risquent de ne jamais être récupérés car la zone de récupération est quasiment pleine avec 973 . Encore 170 à y
mettre et le disque devient "failing-now"

De plus le disque fonctionne depuis 78768 heures. Son espérence de vie est quasiment atteinte peut-être encore 1000 heures.

Souvent dans un raids, les deux disques sont de la même famille et s'usent de façon semblabe.
Poste vite le rapport smartctl de sdb afin de savoir à s'en tenir.

Dernière modification par geole (Le 11/05/2020, à 23:53)

OdEa Le 12/05/2020, à 09:37 #15

Bonjour geole,
merci pour ton message, en effet, le disque sdc est bien mort de chez mort, et son compagnon ne devrait pas tarder à suivre le même chemin.
Les disques ont été achetés en même temps et ont quand même 9 ans !
Je suis actuellement en train de faire des backups !
voici l'état de santé de sdb :

$ sudo smartctl -a /dev/sdb


[sudo] Mot de passe de odea :
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-29-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===


Model Family: Western Digital Caviar Green (AF)
Device Model: WDC WD20EARS-00MVWB0
Serial Number: WD-WCAZA1640530
LU WWN Device Id: 5 0014ee 2afbab94c
Firmware Version: 51.0AB51
User Capacity: 2000398934016 bytes [2,00 TB]
Sector Size: 512 bytes logical/physical
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS (minor revision not indicated)
SATA Version is: SATA 2.6, 3.0 Gb/s
Local Time is: Tue May 12 09:32:05 2020 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===

Pas d'erreur, mais jusqu'à quand ? ...

geole Le 12/05/2020, à 10:42 #16

Bonjour.

Le SDB tient parfaitement le choc. Tant mieux. Lorsque lui aussi aura 1 secteur défectueux, le raids refusera de mettre en route (Peut-être que c'est
maintenant rectifié.)

Donc, pour le moment, tu achètes un autre disque. Lorsqu'il sera arrivé, Tu déclare SDC FAULTY, Tu le remplaces par le neuf.
Cela devrait se resynchroniser. Aucune idée de la durée, Probablement plus de 24 heures.
Par sécurité, ensuite, tu pourrais faire la même chose pour SDB car lui lui aussi est considéré comme vieux. avec ces deux paramètres
9 Power_On_Hours 0x0032 001 001 000 Old_age Always - 78802
193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 3621177
Qui sont très proche de zéro qui est la valeur que le constructeur considère comme un seuil de durée de vie....
Pour le second compteur, il surveille la tête de lecture
"Nombre de cycles de chargement/déchargement dans la position où la tête magnétique est posée. "
Si elle lâche, plus rien ne sera lisible dans ce disque et l'autre n'est pas en bon état. Il y aurait perte importante de données si on devait l'utiliser pour tout
récupérer.

Mais, il reste en bonne santé.


SMART Error Log Version: 1
No Errors Logged

A mon avis, il y a plus de 20000 heures (78758-58654) que le disque SDC n'est plus utilisé.

9 Power_On_Hours 0x0032 001 001 000 Old_age Always - 78758


Error 58654 occurred at disk power-on lifetime: 42565 hours (1773 days + 13 hours)

Car il serait surprenant que leurs erreurs aient cessé de se produire mystérieusement.

La confirmation, vient avec ces compteurs qui devraient être assez proche pour des disques du même modèle utilisés en RAID

193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 1315025


et
193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 3621177

quasiment du simple au triple

Dernière modification par geole (Le 12/05/2020, à 10:55)

OdEa Le 12/05/2020, à 11:29 #17

Oui c'est ma théorie : n'ayant pas activé les notifications email avec mdadm, je ne me suis pas rendu compte que sdc était sorti du raid et été mal en point
depuis...plus de 2 ans !
Comme quoi, au final ca a eu du bon de reinstaller le système et de me rendre compte de ca !
Merci pour l'analyse !

OdEa Le 13/05/2020, à 15:55 #18

Encore moi, finalement, étant assez juste avec 2To et le disque restant étant en fin de vie, je vais finalement acheter 2x 4To que je vais mettre en raid1, si
possible en sdb et sdc pour que ce soit propre.
J'aimerais récupérer les données du disque de 2To pour les mettre sur le futur RAID1.
Que me conseillez-vous de faire ? est-ce que cette manip est risquée ? :
1) supprimer le RAID existant du HDD de 2To afin qu'il ne soit plus détecté comme faisant partie d'un RAID ? de ce que j'ai lu je ne devrais pas perdre les
données
2) débrancher le 2To
3) brancher les 4To, créer le RAID en sdb et sdc
4) brancher le 2To (monté en sdd ?) et copier les données

OdEa Le 13/05/2020, à 18:02 #19

Ah j'ai aussi une autre solution : laisser tomber le RAID1 pour un usage perso : brancher 1 des 2 disques de 4To, faire la copie des fichiers, retirer le disque
de 2To, et régulièrement faire des backups (rsync) du disque de 4To sur l'autre disque (si possible externe) de 4To.

geole Le 13/05/2020, à 18:24 #20

Bonjour
Ce n'est qu'un avis
- Si tu as la possibilité de brancher en plus un disque de 4 TO, tu le fais.
Tu fabriques alors un nouveau RAID1 avec ce seul disque de 4 To en disant qu'il en manque un.
Tu lances la duplication du contenu du premier RAID dans le second.
Lorsque c'est fait, tu dis que le premier RAID a un disque H.S. Tu démontes le disque HS. (Ne te trompes pas) et tu le remplaces par le second gros
disque.
Tu lances alors la synchronisation.
Lorsque c'est fini, tu fais un rapport smartctl des deux gros disques pour connaître leur état neuf. (On peut avoir des surprises).
et tu supprimes le premier raid en reformatant le disque de 2 To qui est encore en bon état. Il pourra toujours servir à quelque chose.
Cette méthode semble sans risque. Le raids actuel reste opérationnel (même si non monté) tant que le nouveau raids n'est pas totalement opérationnel.

Si tu n'as pas la possibilité de brancher en plus un disque de 4 TO, il faut espérer que le bon disque de 2 TO va tenir.
Tu dis que ton RAID actuel a un disque HS . Ne pas se tromper , Tu le démontes
Tu branches un nouveau disque à l'endroit libéré
Tu fabriques alors un nouveau RAID1 avec ce seul disque de 4 To en disant qu'il en manque un
Tu lances la duplication du contenu du premier RAID dans le second.
Lorsque c'est fait, tu démontes le premier disque de 2To restant, tu y branches le seconde disque de 4 To
Tu lances alors la synchronisation.
Lorsque c'est fini, tu fais un rapport smartctl des deux gros pour connaître leur état neuf. (On peut avoir des surprises).

AJOUT: Tu peux aussi ne plus utiliser le RAID à condition de ne pas lancer du RSYNC en permanence. Afin d'avoir une vraie version " Moins Un" sinon tu
te compliques la vie.

Dernière modification par geole (Le 13/05/2020, à 18:27)

OdEa Le 13/05/2020, à 18:33 #21

Merci pour ta réponse, j'hésite encore à faire cette méthode ou carrément ne plus faire de RAID et récupérer les données du Raid 2To (enfin ce qu'il en
reste, c'est à dire 1 des 2 disques) vers 1 disque dur 4To et faire des backups hebdo/mensuels via rsync sur l'autre 4To. Ca pourrait me rendre la vie plus
simple, sachant qu'en effet ce que je recherche c'est la sauvegarde et non la redondance/dispo, à y réfléchir, pas sur que le RAID1 soit vraiment ce que je
cherchais à la base. Sans raid je pourrais aussi balader mes données ailleurs si besoin.
EDIT : oui le rsync ce serait 1 fois par semaine, voire 1 fois par mois...

Dernière modification par OdEa (Le 13/05/2020, à 18:34)

Pages : 1
Forum » Sécurité » Problème RAID1 après reinstall Ubuntu
Atteindre Propulsé par FluxBB
Sécurité Aller
Contact

Vous aimerez peut-être aussi