Reconstrua o RAID1 a partir do disco existente e adicione outro

2

Esta questão é um problema derivado da solução de outro problema que você pode ver em este tópico .

Para simplificar, meu servidor dedicado tem um array RAID1 com 2x3TB HDD. Uma semana atrás, um deles falhou. A empresa proprietária do servidor a substituiu, então agora tenho uma boa unidade com todos os dados e uma nova completamente vazia.

Não tenho ideia de como reconstruir o RAID pelo que tenho.

Esta informação pode ser útil (eu entendo que não há RAID agora):

root@rescue /dev # lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0   2.7T  0 disk
sdb      8:16   0   2.7T  0 disk
├─sdb1   8:17   0     1M  0 part
├─sdb2   8:18   0   127M  0 part
├─sdb3   8:19   0   200M  0 part
├─sdb4   8:20   0   2.7T  0 part
└─sdb5   8:21   0 455.5K  0 part
loop0    7:0    0   1.5G  1 loop
root@rescue /dev # cat /proc/mdstat
Personalities : [raid1]
unused devices: <none>

UPDATE 1 Informação rápida:

   CPU1: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (Cores 8)
   Memory:  15974 MB
   Disk /dev/sda: 3000 GB (=> 2794 GiB) doesn't contain a valid partition table
   Disk /dev/sdb: 3000 GB (=> 2794 GiB)
   Total capacity 5589 GiB with 2 Disks

UPDATE 2:

Como sugerido por Trinue:

root@rescue ~ # lspci
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5)
00:1c.5 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 6 (rev b5)
00:1c.6 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 7 (rev b5)
00:1c.7 PCI bridge: Intel Corporation 82801 PCI Bridge (rev b5)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation H67 Express Chipset Family LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)
03:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
05:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 01)

UPDATE 3:

Como sugerido por @Koko, tentei montar as 4 partições, mas recebi erros em 3 delas. Que esse disco também seja quebrado?

root@rescue / # mount -o ro /dev/sdb1 /mnt/disk
mount: you must specify the filesystem type
root@rescue / # mount -o ro /dev/sdb4 /mnt/disk
ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Failed to calculate free MFT records: Input/output error
NTFS is either inconsistent, or there is a hardware fault, or it's a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.
root@rescue / # mount -o ro /dev/sdb2 /mnt/disk
mount: you must specify the filesystem type
root@rescue / # mount -o ro /dev/sdb3 /mnt/disk
root@rescue / # cd /mnt/disk
root@rescue /mnt/disk # dir
EFI

UPDATE 4:

Como sugerido por Michael Martinez e Koko, tentei duplicar dados de sdb para sda, com os seguintes erros:

root@rescue /mnt/disk # dd if=/dev/sdb of=/dev/sda
dd: reading '/dev/sdb': Input/output error
6619712+0 records in
6619712+0 records out
3389292544 bytes (3.4 GB) copied, 67.7475 s, 50.0 MB/s

UPDATE 5:

Estas são as instruções fornecidas pelo proprietário do servidor: link para substituir um HDD em um de seus servidores. No entanto, você notará que eu não tenho o raid ou as partições como nos exemplos que eles fornecem.

UPDATE 6:

Hetzner já me respondeu: "Devido ao fato de você não ter pedido um controlador RAID de hardware, ele tem um RAID de software. "

UPDATE 7:

root@rescue / # mount /dev/sda1 /mnt/disk
mount: you must specify the filesystem type
root@rescue / # mount /dev/sda2 /mnt/disk
mount: you must specify the filesystem type
root@rescue / # mount /dev/sda3 /mnt/disk
root@rescue / # mount /dev/sda4 /mnt/disk
mount: you must specify the filesystem type
root@rescue / # mount /dev/sda5 /mnt/disk
mount: you must specify the filesystem type
root@rescue / # cd /mnt/disk
root@rescue /mnt/disk # dir
EFI

UPDATE 8:

Devo salientar que antes de executar o comando mount, eu dd sdb em sda e comecei a criar um novo array usando estes comandos:

# mdadm --create root --level=1 --raid-devices=2 missing /dev/sdb1  
# mdadm --create swap --level=1 --raid-devices=2 missing /dev/sdb2

root@rescue / # mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=8176304k,nr_inodes=2044076,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
213.133.99.101:/nfs on /root/.oldroot/nfs type nfs (ro,noatime,vers=3,rsize=8192,wsize=8192,namlen=255,acregmin=600,acregmax=600,acdirmin=600,acdirmax=600,hard,nocto,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=213.133.99.101,mountvers=3,mountproto=tcp,local_lock=all,addr=213.133.99.101)
aufs on / type aufs (rw,relatime,si=1848aabe5590850f)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=1635764k,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3271520k)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)

UPDATE 9:

Quando o servidor se recusou a inicializar pela primeira vez, perguntei ao serviço ao cliente por uma reinicialização manual. A resposta que eles me deram foi:

Caro cliente, Nós reiniciamos seu servidor, mas parece que há um disco rígido com defeito. Se você quiser, podemos repalcá-los, para isso, por favor, confirme-nos a perda de dados sobre este dirigir e o tempo de inatividade cerca de 15 minutos. Seu servidor está agora no sistema de recuperação:

Y imediatamente quando acessar o site do robô, quando eu puder administrar o servidor e pesquisar informações sobre o sistema de recuperação, e aqui está o que eu encontrei:

Depois de ativar o sistema de recuperação, um arquivo de configuração será criado em nosso servidor DHCP. Na próxima reinicialização, seu servidor inicializará a partir da rede e um sistema operacional mínimo será carregado a partir de nosso servidor TFTP. Então você poderá usar o sistema de resgate o quanto quiser. A ordem para o sistema de resgate estará ativa por 60 minutos. Se você reinicializar seu servidor, o sistema normal será iniciado a partir do disco rígido. Por favor, visite nosso Wiki para mais informações

O sistema de resgate é um Debian de 64 bits.

UPDATE 10

root@rescue ~/.oldroot/nfs # ls /root/.oldroot/nfs
bash_aliases                rescue32-wheezy-v006.ext2
check                       rescue32-wheezy-v007.ext2
copy-vnode-lvs-to           rescue32-wheezy-v008.ext2
copy-vnode-lvs-to.bak       rescue32-wheezy-v009.ext2
esxi                        rescue64-lenny-v004.ext2
firmware_update             rescue64-squeeze-v011.ext2
freebsd                     rescue64-squeeze-v012.ext2
functions.sh                rescue64-squeeze-v013.ext2
images                      rescue64-squeeze-v014.ext2
images.old                  rescue64-squeeze-v015.ext2
install                     rescue64-squeeze-v016.ext2
ipmi                        rescue64-test.ext2
iso                         rescue64-wheezy-v000.ext2
knoppix                     rescue64-wheezy-v001.ext2
lost+found                  rescue64-wheezy-v002.ext2
opensolaris                 rescue64-wheezy-v003.ext2
raid_ctrl                   rescue64-wheezy-v004.ext2
README                      rescue64-wheezy-v005.ext2
rescue32-lenny-v004.ext2    rescue64-wheezy-v006.ext2
rescue32-squeeze-v011.ext2  rescue64-wheezy-v007.ext2
rescue32-squeeze-v012.ext2  rescue64-wheezy-v008.ext2
rescue32-squeeze-v013.ext2  rescue64-wheezy-v009.ext2
rescue32-squeeze-v014.ext2  shutdown-h
rescue32-squeeze-v015.ext2  shutdown-h-now
rescue32-squeeze-v016.ext2  tightvnc-vkvm.tar.gz
rescue32-test.ext2          vkvm64-squeeze-v001.ext2
rescue32-wheezy-v000.ext2   vkvm64-squeeze-v002.ext2
rescue32-wheezy-v002.ext2   vkvm64-test.ext2
rescue32-wheezy-v003.ext2   vkvm64-v001.ext2
rescue32-wheezy-v004.ext2   vkvm64-wheezy-overlay.ext2
rescue32-wheezy-v005.ext2   vkvm64-wheezy-overlay-v001.ext2

UPDATE 11:

root@rescue ~ # fdisk -l /dev/sdb

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.


Disk /dev/sdb: 3000.6 GB, 3000592982016 bytes
256 heads, 63 sectors/track, 363376 cylinders, total 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
Disk identifier: 0x8ab49420

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1  4294967295  2147483647+  ee  GPT
Partition 1 does not start on physical sector boundary.

UPDATE 12:

root@rescue ~ # parted -l
Error: The backup GPT table is corrupt, but the primary appears OK, so that will
be used.
OK/Cancel? OK
Model: ATA ST3000DM001-9YN1 (scsi)
Disk /dev/sda: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name                          Flags
 1      17.4kB  1066kB  1049kB               LDM metadata partition
 2      1066kB  134MB   133MB                Microsoft reserved partition  msftres
 3      135MB   345MB   210MB   fat16        EFI system partition          boot
 4      345MB   3001GB  3000GB  ntfs         LDM data partition
 5      3001GB  3001GB  466kB                LDM data partition


Model: ATA ST3000DM001-9YN1 (scsi)
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name                          Flags
 1      17.4kB  1066kB  1049kB               LDM metadata partition
 2      1066kB  134MB   133MB                Microsoft reserved partition  msftres
 3      135MB   345MB   210MB   fat16        EFI system partition          boot
 4      345MB   3001GB  3000GB  ntfs         LDM data partition
 5      3001GB  3001GB  466kB                LDM data partition


Model: Linux Software RAID Array (md)
Disk /dev/md126: 133MB
Sector size (logical/physical): 512B/4096B
Partition Table: loop

Number  Start  End    Size   File system     Flags
 1      0.00B  133MB  133MB  linux-swap(v1)


Model: Linux Software RAID Array (md)
Disk /dev/md127: 983kB
Sector size (logical/physical): 512B/4096B
Partition Table: loop

Number  Start  End    Size   File system  Flags
 1      0.00B  983kB  983kB  ext4
    
por Rui F Ribeiro 30.04.2014 / 17:29

2 respostas

4

Você diz que falou com o Hetzner, que diz ter software RAID. O problema é que isso não acontece. Seu cat /proc/mdstat diz algo como

Personalities : [raid1]

unused devices: <none>

O que significa que não há software RAID. Se você tivesse um RAID de software quebrado, seria algo parecido com

Personalities : [raid1] 
md0 : active raid1 sdb1[1] (F) sda1[0]
      1020032 blocks [2/2] [_U]

md1 : active raid1 sda2[2] sdb2[1] (F)
      975739772 blocks super 1.1 [2/2] [_U]
      bitmap: 3/8 pages [12KB], 65536KB chunk

unused devices: <none>

Eu obtive isso do meu servidor, então alguns dos detalhes seriam diferentes para você, e eu reconstruí isso a partir das anotações no momento da última falha no HDD, então alguns dos detalhes podem estar errados, mas os bits importantes são

  1. [_U] (isso significa que um dos espelhos está inativo; se tudo estivesse bem, diria [UU] ) e
  2. (F) (que informa qual metade falhou, neste caso é a partição em /dev/sdb em ambos os casos).

Suas próprias instruções, às quais você vincula, mostram algo muito semelhante.

Se você viu isso, inserir o novo HDD nos arrays existentes seria uma simples questão de particionar o novo disco e usar mdadm para adicionar as partições aos espelhos. Mas como você atualmente tem um sistema não-RAID, não podemos fazer isso.

Gostaria de perguntar ao Hetzner por que ele não mostra nenhum sinal de RAID de software, com referência à sua própria documentação. Pode ser que eles tenham que extrair as referências do MD RAID para que o sistema seja inicializado, mas se for esse o caso, ao fazer isso, eles estragaram qualquer habilidade que você possa ter para reparar o RAID.

Você diz que é " um TOTAL NEWBIE no Linux e em material relacionado a hardware ". Honestamente, se é assim, então você está muito acima de sua cabeça, aqui. Eu procuraria assistência profissional o mais rápido possível e estaria preparado para algum tempo de inatividade durante o backup do sistema, e então seria restaurado em sua totalidade em um chassi limpo e recondicionado.

    
por 01.05.2014 / 11:22
0

Parece que falta algumas linhas de cat /proc/mdstat . Seria útil saber quais são esses. para adicionar um novo disco a um array de RAID de software existente:

mdadm --add RAID_DEV NEW_DISK .

ex: mdadm --add /dev/md0 /dev/sdd

Você precisará conhecer seu dispositivo de invasão, que às vezes pode ser encontrado em dmesg output:

# dmesg | grep md [7563017.386737] md: data-check of RAID array md0 [7563017.386747] md: minimum _guaranteed_ speed: 1000 KB/sec/disk.

Se a matriz estiver ativa / degradada, a adição do novo disco iniciará automaticamente o processo de reconstrução (que pode ser monitorado com /proc/mdstat ). Dependendo da sua distribuição linux, você também pode ter um arquivo /etc/mdadm/mdadm.conf que pode revelar mais informações sobre o array.

    
por 30.04.2014 / 17:38

Tags