Plano de fundo Eu tive um dado 3.0TB em mim recentemente e foi em um ataque Linux em um Synology NAS com redundância RAID 1. Eu comprei recentemente dois drives de 8.0TB e eu queria fazer backup do 3.0TB, mas minha sincronização continua sendo interrompida aleatoriamente e estava tendo momentos altos. Para consertar isso eu coloquei todas as unidades no meu computador que está executando o Linux Mint 18.x Live. Eu estou tentando montar ambos os ataques para que eu possa rsync o 3.0TB para o ataque de 8.0TB.
Problema
Não consigo reconstruir nenhuma das invasões e, portanto, acessar qualquer uma das unidades. Minha saída fidsk -l é assim:
mint ~ # fdisk -l
Disk /dev/loop0: 1.5 GiB, 1618886656 bytes, 3161888 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/nvme0n1: 477 GiB, 512110190592 bytes, 1000215216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: DB2D71AC-EF2C-4540-A8E5-03C5D8F72D01
Device Start End Sectors Size Type
/dev/nvme0n1p1 40 409639 409600 200M EFI System
/dev/nvme0n1p2 409640 552935535 552525896 263.5G Apple HFS/HFS+
/dev/nvme0n1p3 552935536 554205071 1269536 619.9M Apple boot
/dev/nvme0n1p4 554205184 554237951 32768 16M Microsoft reserved
/dev/nvme0n1p5 554237952 1000214527 445976576 212.7G Microsoft basic data
Disk /dev/sda: 7.3 TiB, 8001563222016 bytes, 15628053168 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: gpt
Disk identifier: 0A352E59-20D3-4471-AE03-F44E1C73E3EE
Device Start End Sectors Size Type
/dev/sda1 2048 4982527 4980480 2.4G Linux RAID
/dev/sda2 4982528 9176831 4194304 2G Linux RAID
/dev/sda5 9453280 15627846239 15618392960 7.3T Linux RAID
Disk /dev/sdb: 2.7 TiB, 3000592982016 bytes, 5860533168 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: gpt
Disk identifier: FDB68AFA-6AA2-4AFF-B950-A65803C3E831
Device Start End Sectors Size Type
/dev/sdb1 256 4980735 4980480 2.4G Linux RAID
/dev/sdb2 4980736 9175039 4194304 2G Linux RAID
/dev/sdb3 9437184 5860328351 5850891168 2.7T Linux RAID
Disk /dev/sdc: 7.3 TiB, 8001563222016 bytes, 15628053168 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: gpt
Disk identifier: 655B6D2C-8FDB-40B2-8A57-4A4C6CEA81FA
Device Start End Sectors Size Type
/dev/sdc1 2048 4982527 4980480 2.4G Linux RAID
/dev/sdc2 4982528 9176831 4194304 2G Linux RAID
/dev/sdc5 9453280 15627846239 15618392960 7.3T Linux RAID
Disk /dev/sdd: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: AB7A0C0E-F0F0-4169-A6CC-AFD36D13706B
Device Start End Sectors Size Type
/dev/sdd1 40 409639 409600 200M EFI System
/dev/sdd2 409640 976510983 976101344 465.5G Apple HFS/HFS+
Disk /dev/sde: 14.9 GiB, 16008609792 bytes, 31266816 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 112D01E3-9B10-4E53-831E-6122DE30212F
Device Start End Sectors Size Type
/dev/sde1 40 409639 409600 200M EFI System
/dev/sde2 409640 31004631 30594992 14.6G Apple HFS/HFS+
Disk /dev/sdf: 3.8 GiB, 4026531840 bytes, 7864320 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: C0FCDDB9-DB52-4F40-8615-EB3CE0E2D4F4
Device Start End Sectors Size Type
/dev/sdf1 2048 7864286 7862239 3.8G Microsoft basic data
As únicas unidades importantes são /dev/sda, /dev/sdb, /dev/sdc
Coisas que tentei
mdadm -Asf && vgchange -ay de acordo com a recomendação do website Synology retorna
mdadm: Devices UUID-f2e5c234:6e894003:d490d253:6ab62f4d and UUID-f8782d0e:605a2e0e:4c50beb7:39f5970b have the same name: /dev/md/2
mdadm: Duplicate MD device names in conf file were found.
Bom ol ' mdadm --assemble --scan retorna o mesmo.
Eu também tentei mdadm --stop /dev/sdb quando li aqui . Resumindo, eles disseram que o mdadm possui a unidade, então você não pode montá-lo normalmente, mas como é uma unidade, você pode destruir os metadados do RAID do mdadm e montá-los normalmente.
Este código retornou
mdadm --stop /dev/sdb
mdadm: /dev/sdb does not appear to be an md device
Tentando montar uma única unidade de forma independente com mdadm -A /dev/sdb returns:
mdadm: /dev/sdb does not appear to be an md device
Por que acho que as coisas não estão quebradas Eu tive sucesso montando a unidade de 3,0 TB / dev / sdb no passado quando o irmão morto também estava conectado. Nesses casos, o mdadm apenas disse que construiu o array com um drive. Eu sei que essas unidades 8.0TB funcionam porque acabei de extraí-las do meu servidor Synology, embora elas não estivessem em uma configuração RAID 1, mas em um Synology Hybrid RAID, não sei se isso faz diferença.
O que eu acho que o problema é
Acredito sinceramente (em minha experiência incrivelmente limitada) que o problema vem de duas matrizes RAID estarem na mesma máquina ao mesmo tempo e isso é confuso mdadm. Eu acho que a solução pode ter a ver com a edição /etc/mdadm.conf para especificar qual RAID pertence a qual e, em seguida, tente montar novamente. No entanto, estou preocupado que, independentemente de tentar reconstruir o array, a unidade não parece ser um dispositivo md. Então agora eu não sei o que fazer.