Движущийся RAID 5 к другому компьютеру
Проблема RAID 5
Четкая проблема - то, что я не уверен как активному неактивный RAID без моих усилий, являющихся необратимым. Попытка повторно собраться непагубно. Это даже возможно?
Передача RAID 5 к новому компьютеру, если ЦП перестал работать.
Фон
UBUNTU 16.04, работающая mdadm программное обеспечение RAID 5, перестала работать и перезагрузки с Нажатием ctrl D для продолжения.
Я думаю, что мой RAID-МАССИВ, кажется, неповрежден. Посмотрите распечатки ниже. Я хочу переместить свой RAID 5 от одного компьютера до другого в случае, если проблемой были аппаратные средства.
Проблема с разделом начальной загрузки UBUNTU может просто состоять в том, что он исчерпал пространство на разделе начальной загрузки. Раздел начальной загрузки был только 10G и хотя установка Ubuntu была первоначально минимальной установкой сервера, я развернул его для выполнения рабочего стола также. 10G мог не быть достаточно, но работал как этот в течение 2 месяцев. Я просто хотел графический интерфейс.
Также я недавно считал, что RAID 5 разделов не должен был превышать 1.5 T на каждом диске. Я не знал, что в то время и это работало в течение приблизительно 6 месяцев как этот, хотя недавно это, возможно, превысило тот предел. Это работает приблизительно в 6T теперь.
Мой план состоит в том, чтобы переместить RAID 5 в новую машину с новой установкой Ubuntu 16 на новом диске ‘sde’ и повторно смонтировать RAID в новой системе.
Вопросы
Как я перемещаю RAID 5 в новый компьютер? Если бы UBUNTU перестала работать при начальной загрузке затем, то я должен смочь собрать RAID на новом компьютере.
Действительно "собирается" перезаписывают разделы RAID? Это будет необратимо?
Если бы RAID исчерпал пространство, то можно было бы ожидать, что RAID перестанет работать а не начальная загрузка UBUNTU.
Кроме того, я могу безопасно удалить все устройства из МАССИВА и смонтироваться как нормальные стандартные разделы для чтения моих данных? Существует о 6T распространения данных через RAID.
Отчеты о состоянии
root@UbuntuServer17:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# fstab on WDD running as 5th disk sde
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda2 during installation
UUID=f37bd21c-9464-4763-b3e7-7f9f6f5154df / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=4993-9AE3 /boot/efi vfat umask=0077 0 1
# swap was on /dev/sda3 during installation
UUID=e3b9f5e9-5eb9-47e0-9288-68649263093c none swap sw 0 0
# Steve added - from RAID17 when it crashed
# / was on /dev/sda1 during installation on RAID17
#UUID=1672f12a-9cf2-488b-9c8f-a701f1bc985c / ext4 errors=remount-ro 0 1
#/dev/md0p1 /media/steve/RAID17 ext4 data=ordered,relatime,stripe=384,nodev,nosuid 0 0
#UUID=1672f12a-9cf2-488b-9c8f-a701f1bc985c / ext4 errors=remount-ro 0 1
#/dev/md0 /media/steve/RAID17 ext4 data=ordered,relatime,stripe=384,nodev,nosuid 0 0
root@UbuntuServer17:~# cat /etc/mdadm/mdadm.conf
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#
# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes
# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# instruct the monitoring daemon where to send mail alerts
MAILADDR root
# definitions of existing MD arrays
# This file was auto-generated on Sun, 05 Feb 2017 20:34:00 +0200
# by mkconf $Id$
# Steve added - maybe should add uuid to fstab file to mount on WD at start - But no sure
# ARRAY /dev/md0 uuid=3b92382f:78784c2b:e7a07a35:c1afcf1d
ARRAY /dev/md0 uuid=32c91cbf:266a5d14:182f1b34:f92b1ebe
root@UbuntuServer17:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : inactive sda2[0](S) sdd1[4](S) sdb1[1](S) sdc1[2](S)
7803273216 blocks super 1.2
unused devices: <none>
root@UbuntuServer17:~# mdadm --examine --scan
ARRAY /dev/md/0 metadata=1.2 UUID=3b92382f:78784c2b:e7a07a35:c1afcf1d name=RAID17:0
root@UbuntuServer17:~#
root@UbuntuServer17:~# sudo fdisk -l
Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 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: dos
Disk identifier: 0x5120487a
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 20482047 20480000 9.8G 83 Linux
/dev/sda2 20514816 3907028991 3886514176 1.8T 83 Linux
/dev/sda3 20482048 20514815 32768 16M 82 Linux swap / Solaris
Partition table entries are not in disk order.
Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 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: dos
Disk identifier: 0x000a439d
Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 3907028991 3907026944 1.8T 83 Linux
Disk /dev/sdc: 1.8 TiB, 2000398934016 bytes, 3907029168 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: dos
Disk identifier: 0x00044e92
Device Boot Start End Sectors Size Id Type
/dev/sdc1 2048 3907028991 3907026944 1.8T 83 Linux
Disk /dev/sdd: 1.8 TiB, 2000398934016 bytes, 3907029168 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: dos
Disk identifier: 0xc7703e92
Device Boot Start End Sectors Size Id Type
/dev/sdd1 2048 3907028991 3907026944 1.8T 83 Linux
Disk /dev/sde: 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: AEC0A022-299A-4283-9F5F-2FCC4CC4609E
Device Start End Sectors Size Type
/dev/sde1 2048 1050623 1048576 512M EFI System
/dev/sde2 1050624 960124927 959074304 457.3G Linux filesystem
/dev/sde3 960124928 976771071 16646144 8G Linux swap
root@UbuntuServer17:~#
root@UbuntuServer17:~# sudo dumpe2fs /dev/sda2
dumpe2fs 1.42.13 (17-May-2015)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: b474c4d4-af7f-4730-b746-a0c0c49ca08d
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 121454592
Block count: 485814272
Reserved block count: 24290713
Free blocks: 478141459
Free inodes: 121454581
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 908
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Sat Feb 25 02:16:09 2017
Last mount time: n/a
Last write time: Sat Feb 25 02:16:09 2017
Mount count: 0
Maximum mount count: -1
Last checked: Sat Feb 25 02:16:09 2017
Check interval: 0 (<none>)
Lifetime writes: 135 MB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: e1e7da74-6e2f-4fa4-a9e0-a13a44338170
Journal backup: inode blocks
dumpe2fs: Corrupt extent header while reading journal super block
root@UbuntuServer17:~#
2 ответа
Я в конечном счете нашел ответ на https://serverfault.com/questions/32709/how-do-i-move-a-linux-software-raid-to-a-new-machine.
Вот то, что я сделал:
Загруженный от новой установки и сохраненный старый fstab и mdadm.conf файлы к моему облаку.
похоже, что раздел Набега на sda2 (один эти 4 физических диска) на самом деле перестал работать. У меня были начальная загрузка на sda1 и Налет на sda2, sdb1, sdc1, sdd1.
я переустановил Ubuntu на новый диск sde.
Переустановленный mdadm.
я знал, где эти 4 раздела были то, потому что я не изменил порядок, и начальная загрузка была теперь sde1;
я вынудил Массив RAID повторно собраться на тех же разделах;
Очень к счастью три изгоняют из четыре, работают так, Набег ухудшается, но до сих пор его работа.
шаги, которые я выполнил, аккуратно изложены в вышеупомянутой ссылке. Я должен сказать, что нашел, что Цифровой Океан был большой помощи по пути также. Это всегда кажется настолько простым впоследствии, но трасса является предательской.
Я наткнулся на этот ответ, пытаясь переместить массив RAID1 из двух дисков со старой коробки на новую. В сообщении предлагалось просто переместить диски на новый компьютер и подключить их, независимо от того, какие порты SATA на МБ. После этого этой команды должно было хватить:
mdadm --assemble --scan
Однако для меня это не обнаружило никаких массивов для сборки. Итак, немного покопавшись, я обнаружил, что есть конфигурационный файл, в котором есть детали вашего массива — надеюсь, он у вас все еще есть на старой машине:
cat /etc/mdadm/mdadm.conf
Для меня это было довольно упрощенным делом; новый и старый ящик имели только одну разницу в строке для начала, в зависимости от сложности вашего массива, это может быть немного сложнее, конечно:
ARRAY /dev/md/0 metadata=1.2 UUID=<THE__UUID> name=qnap:0
Я вставил эту строку вручную в новый сервер /etc /mdadm/mdadm.conf и снова запустил команду:
mdadm --assemble --scan
На этот раз он нашел массив и инициализировал его в состоянии только для чтения. Теперь вы можете запустить проверку массива (все для всех массивов на компьютере):
/usr/share/mdadm/checkarray --all
или просто посмотреть, в каком состоянии он находится:
cat /proc/mdstat
Последний файл обновляется информацией о ходе выполнения из mdstat.
Переключение в состояние чтения и записи следующим образом:
mdadm --readwrite md127
вызвало повторную синхронизацию, которая, конечно, занимает несколько часов в зависимости от размера и конфигурации вашего массива, но после этого у меня не было проблем с открытием зашифрованного тома на рейд и монтирование из него разделов LVM. Я взял md127 для этой последней команды, проверив, на что указывает символическая ссылка в /dev/md/0, что файл mdadm.conf указан как физическое устройство для массива.
Надеюсь, это кому-нибудь поможет :)