Tout d'abord, comment je me suis retrouvé dans cette situation :
J'avais une matrice RAID5 avec des disques de 2 To chacun (disques USB externes), j'ai ensuite voulu créer une matrice cryptée plus grande. Par conséquent, j'ai obtenu 2 disques supplémentaires (également de 2 To chacun) et le plan était d'exécuter la baie d'origine en mode dégradé, de configurer la nouvelle baie cryptée, de copier une partie des données, puis de réduire la baie d'origine à 2 disques en mode dégradé, agrandissez le nouveau, copiez le reste des données et enfin agrandissez-le à 7 disques RAID5 non dégradés. J'ai fait toute la procédure avec /dev/loopX appareils de 2 Go chacun pour tester si mon plan comporte des mises en garde.
Tout s'est bien passé avec la vraie matrice jusqu'au point où l'un des nouveaux disques est tombé en panne. Lorsque j'ai remplacé celui-ci, l'ordre dans lequel les disques sont reconnus par le noyau a changé après le prochain redémarrage (/dev/sdb , /dev/sdc , … étaient tous des disques différents qu'avant). Tout a été foiré et je ne m'en suis pas rendu compte jusqu'à ce que l'un des disques soit resynchronisé en tant que membre de la mauvaise matrice. J'épargne les détails de cette histoire et vais droit au but :
J'ai maintenant une matrice chiffrée, RAID5 à 3 disques, dégradée sur /dev/sdc1 et /dev/sdd1 , fonctionne parfaitement bien, toutes les données sont là et un système de fichiers sain selon fsck -f .
Jusqu'ici tout va bien.
Tout le problème est maintenant réduit à 3 disques - je ne peux pas faire fonctionner à nouveau cette matrice non cryptée. Je suis à peu près sûr que les données A être là sur /dev/sdf1 , /dev/sdg1 , /dev/sdh1 , car il s'agissait d'un tableau de travail juste avant qu'UN des disques ne soit gâché (accidentellement resynchronisé en tant que membre de l'autre tableau chiffré, comme indiqué précédemment). Ainsi, l'un de ces trois disques peut avoir des données de matrice incorrectes, mais lequel ? Et deux d'entre eux doivent être bons, mais comment puis-je comprendre cela ?
J'ai essayé toutes les permutations de mdadm --create … avec /dev/sdf1 , /dev/sdg1 , /dev/sdh1 et "manquant" comme :
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdf1 /dev/sdg1 missing
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdf1 missing /dev/sdg1
...et bien sûr vérifié à chaque fois avec
fsck /dev/md0
qui se plaignait d'un superbloc invalide.
Chaque fois que mdadm créait le tableau, mais qu'il n'y avait pas de système de fichiers lisible, il contenait juste des ordures, aucune des permutations utilisées avec mdadm n'a finalement fonctionné.
Donc ma question est maintenant :quelles options me reste-t-il ? En plus de perdre mes données et de reconstruire le tableau à partir de zéro, bien sûr.
Voici quelques informations supplémentaires (tous les disques) :
mdadm --examine /dev/sdb1
/dev/sdb1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : cfee26c0:414eee94:e470810c:17141589
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 11:38:32 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Array Size : 3906759680 (3725.78 GiB 4000.52 GB)
Used Dev Size : 3906759680 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : f4f0753e:56b8d6a5:84ec2ce8:dbc933f0
Update Time : Sun Oct 28 11:38:32 2012
Checksum : 60093b72 - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sdc1
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 5cb45bae:7a4843ba:4ad7dbfb:5c129d2a
Name : merlin:1 (local to host merlin)
Creation Time : Wed Sep 26 07:32:32 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Array Size : 3905299456 (3724.38 GiB 3999.03 GB)
Used Dev Size : 3905299456 (1862.19 GiB 1999.51 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 9e2f9ae6:6c95d05e:8d83970b:f1308de0
Update Time : Fri Oct 26 03:26:37 2012
Checksum : 79d4964b - correct
Events : 220
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sdd1
/dev/sdd1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 5cb45bae:7a4843ba:4ad7dbfb:5c129d2a
Name : merlin:1 (local to host merlin)
Creation Time : Wed Sep 26 07:32:32 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Array Size : 3905299456 (3724.38 GiB 3999.03 GB)
Used Dev Size : 3905299456 (1862.19 GiB 1999.51 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 98b07c41:ff4bea98:2a765a6b:63d820e0
Update Time : Fri Oct 26 03:26:37 2012
Checksum : 6e2767e8 - correct
Events : 220
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sde1
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 6db9959d:3cdd4bc3:32a241ad:a9f37a0c
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 12:12:59 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3905299943 (1862.19 GiB 1999.51 GB)
Array Size : 3905299456 (3724.38 GiB 3999.03 GB)
Used Dev Size : 3905299456 (1862.19 GiB 1999.51 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 677a4410:8931e239:2c789f83:e130e6f7
Update Time : Sun Oct 28 12:12:59 2012
Checksum : 98cb1950 - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : A.A ('A' == active, '.' == missing)
mdadm --examine /dev/sdf1
/dev/sdf1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3700a0a6:3fadfd73:bc74b618:a5526767
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 11:28:30 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3905392640 (1862.24 GiB 1999.56 GB)
Array Size : 3905391616 (3724.47 GiB 3999.12 GB)
Used Dev Size : 3905391616 (1862.24 GiB 1999.56 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 5a8a5423:10b7a542:26b5e2b3:f0887121
Update Time : Sun Oct 28 11:28:30 2012
Checksum : 8e90495f - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sdg1
/dev/sdg1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 202255c9:786f474d:ba928527:68425dd6
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 11:24:36 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3905299943 (1862.19 GiB 1999.51 GB)
Array Size : 3905299456 (3724.38 GiB 3999.03 GB)
Used Dev Size : 3905299456 (1862.19 GiB 1999.51 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 4605c729:c290febb:92901971:9a3ed814
Update Time : Sun Oct 28 11:24:36 2012
Checksum : 38ba4d0a - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sdh1
/dev/sdh1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 682356f5:da2c442e:7bfc85f7:53aa9ea7
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 12:13:44 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906761858 (1862.89 GiB 2000.26 GB)
Array Size : 3906760704 (3725.78 GiB 4000.52 GB)
Used Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 489943b3:d5e35022:f52c917a:9ca6ff2a
Update Time : Sun Oct 28 12:13:44 2012
Checksum : f6947a7d - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdc1[0] sdd1[1]
3905299456 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
unused devices: <none>
Toute aide serait grandement appréciée !
En relation :Pourquoi le rsync n'autorise-t-il pas la taille de bloc> 128 Ko ?Réponse acceptée :
Si vous venez de perdre un disque, vous devriez ont pu récupérer de cela en utilisant le beaucoup plus sûr --assemble .
Vous avez tellement exécuté créer maintenant que tous les UUID sont différents. sdc1 et sdd1 partagez un UUID (attendu, car c'est votre tableau de travail)… le reste, les disques partagent un nom, mais tous ont des UUID différents. Je suppose donc qu'aucun de ceux-ci n'est le superbloc d'origine. Dommage…
Quoi qu'il en soit, je suppose que vous essayez d'utiliser les mauvais disques ou que vous essayez d'utiliser la mauvaise taille de bloc (la valeur par défaut a changé avec le temps, je crois). Votre ancien tableau peut également avoir utilisé une version de superbloc différente - cette valeur par défaut a définitivement changé - ce qui pourrait compenser tous les secteurs (et également détruire certaines des données). Enfin, il est possible que vous utilisiez la mauvaise mise en page, bien que cela soit moins probable.
Il est également possible que votre tableau de test soit en lecture-écriture (d'un point de vue md) et que les tentatives d'utilisation d'ext3 aient en fait effectué des écritures. Par exemple, une rediffusion de journal. Mais ce n'est que s'il a trouvé un superbloc à un moment donné, je pense.
BTW :Je pense que vous devriez vraiment utiliser --assume-clean , même si bien sûr une baie dégradée n'essaiera pas de démarrer la reconstruction. Ensuite, vous voudrez probablement définir immédiatement la lecture seule.