Я запускаю сервер на Ubuntu 16.04. В хранилище данных в этой системе используется lvm поверх программного raid 6, тогда как os устанавливается в отдельном raid 1 с lvm. Рейд 6 состоит из 7 разделов на 7 дисках. После увеличения количества ошибок s.m.a.r.t на одном из этих дисков я решил поменять этот диск на новый, прежде чем массив ухудшится.
Я сделал sudo mdadm /dev/md2 --fail /dev/sdd4, а затем sudo mdadm /dev/md2 --remove /dev/sdd4 до того, как я поменял диски местами. После следующего запуска вроде все было в порядке, поэтому я начал разбивать новый диск. Я сделал sudo parted --list адаптировать разбиение на разделы на других дисках.
В этот момент возникла странная проблема, и parted не смог получить доступ к одному из старых дисков. Я заметил, что из массива ушел еще один диск, а через несколько секунд - еще один. Сбой массива. Я был шокирован и выключил систему, чтобы предотвратить дальнейшие ошибки.
Позже я попытался снова запустить систему, и у меня были такие странные сбои:
ata2: irq_stat 0x00000040, connection status changed
ata2: SError: { CommWake DevExch }
В то время у меня была только аварийная консоль, поэтому я запустил live linux для дальнейшего изучения проблемы. Я читал, что могу безопасно сделать mdadm --assemble --scan чтобы попытаться исправить массив, но он остается в любопытном состоянии, поэтому я только удалил массив из mdadm.conf и fstab.
Теперь рейд отображается как raid0 с 7 запасными дисками, но в оставшемся RAID1 диски, похоже, работают нормально последние часы.
Я не уверен, что мне делать прямо сейчас, и я ожидаю потери всех данных, но я также надеюсь, что есть шанс спасти хотя бы часть данных. У меня есть резервная копия, но только ее часть, потому что это был массив на 19 ТБ.
chris@uranus:~$ sudo mdadm --detail /dev/md2
/dev/md2:
Version : 1.2
Creation Time : Thu Aug 6 00:45:41 2015
Raid Level : raid6
Array Size : 18723832320 (17856.44 GiB 19173.20 GB)
Used Dev Size : 3744766464 (3571.29 GiB 3834.64 GB)
Raid Devices : 7
Total Devices : 7
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Fri Jul 13 17:39:04 2018
State : clean
Active Devices : 7
Working Devices : 7
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : uranus:2 (local to host uranus)
UUID : 607914eb:666e2a46:b2e43557:02cc2983
Events : 2738806
Number Major Minor RaidDevice State
0 8 20 0 active sync /dev/sdb4
1 8 36 1 active sync /dev/sdc4
2 8 52 2 active sync /dev/sdd4
6 8 1 3 active sync /dev/sda1
5 8 68 4 active sync /dev/sde4
8 8 97 5 active sync /dev/sdg1
7 8 81 6 active sync /dev/sdf1
chris@uranus:/$ sudo mdadm --detail /dev/md2
/dev/md2:
Version : 1.2
Raid Level : raid0
Total Devices : 6
Persistence : Superblock is persistent
State : inactive
Name : uranus:2 (local to host uranus)
UUID : 607914eb:666e2a46:b2e43557:02cc2983
Events : 2739360
Number Major Minor RaidDevice
- 8 1 - /dev/sda1
- 8 20 - /dev/sdb4
- 8 36 - /dev/sdc4
- 8 68 - /dev/sde4
- 8 81 - /dev/sdf1
- 8 97 - /dev/sdg1
6 дисков исправны, у 7-го были ошибки, но я переключил его на новый. После переключения одного неисправного диска интеллектуальные данные пригодны для всех дисков. Нет ошибок, плохих блоков, ожидающих, неисправимых или перераспределенных секторов.
Мой последний --detail показывает только 6 дисков, потому что я не добавил новый диск в существующий массив.
Рейд 1, на который опирается операционная система, в основном состоял из 3 + 1 запасных из тех же 7 дисков, но на собственных разделах. Когда я удаляю / dev / sdd, запасной диск занял его место, поэтому теперь он состоит из 3 разделов без запасного. Также есть загрузочные разделы на 3 из этих дисков и разделы подкачки в рейде 1 на 2 из этих дисков.
Проблема в том, что mdadm теперь показывает этот массив как рейд 0 с 7 запасными частями как cat /proc/mdstat показывает, и я должен вернуть его к исходной конфигурации raid6 с 6 из 7 дисков в деградированном состоянии. Кажется, есть проблема с конфигурацией, но я ничего в ней не менял. После и только в том случае, если я смогу восстановить массив, я бы добавил переключенный 7-й раздел обратно в массив, чтобы получить мой исходный 7-й диск raid6.
Если я правильно прочитал справочную страницу, mdadm --assemble --scan восстанавливает информацию о массиве на основе конфигурации или /proc/mdstat но это уже кажется неправильным.
cat /proc/mdstat - Сейчас
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md2 : inactive sdg1[8](S) sdf1[7](S) sdb4[0](S) sda1[6](S) sde4[5](S) sdc4[1](S)
22468633600 blocks super 1.2
md129 : active raid1 sdb3[0] sde3[4] sdc3[1]
146353024 blocks super 1.2 [3/3] [UUU]
md128 : active raid1 sdb2[0] sde2[4](S) sdc2[1]
15616896 blocks super 1.2 [2/2] [UU]
unused devices: <none>
cat /etc/mdadm/mdadm.conf - Сейчас
#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
ARRAY /dev/md128 metadata=1.2 UUID=6813258b:250929d6:8a1e9d34:422a9fbd name=uranus:128
spares=1
ARRAY /dev/md129 metadata=1.2 UUID=ab06d13f:a70de5a6:c83a9383:b1beb84c name=uranus:129
ARRAY /dev/md2 metadata=1.2 UUID=607914eb:666e2a46:b2e43557:02cc2983 name=uranus:2
# This file was auto-generated on Mon, 10 Aug 2015 18:09:47 +0200
# by mkconf $Id$
#ARRAY /dev/md/128 metadata=1.2 UUID=6813258b:250929d6:8a1e9d34:422a9fbd name=uranus:128
# spares=2
#ARRAY /dev/md/129 metadata=1.2 UUID=ab06d13f:a70de5a6:c83a9383:b1beb84c name=uranus:129
# spares=1
#ARRAY /dev/md/2 metadata=1.2 UUID=607914eb:666e2a46:b2e43557:02cc2983 name=uranus:2
cat /etc/fstab - Сейчас
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/vgSystem-vRoot / ext4 errors=remount-ro 0 1
# swap was on /dev/md128 during installation
UUID=5a5b997d-9e94-4391-955f-a2b9a3f63820 none swap sw 0 0
#/dev/vgData/vData /srv ext4 defaults 0 0
#10.10.0.15:/srv/BackupsUranusAutomatic/data /mnt/mars/uranus/automatic/data nfs clientaddr=10.10.0.10,vers=4,noatime,addr=10.10.0.15,noauto 0 0
#10.10.0.15:/srv/BackupsUranusAutomatic/media /mnt/mars/uranus/automatic/media nfs clientaddr=10.10.0.10,vers=4,noatime,addr=10.10.0.15,noauto 0 0
#/srv/shares/Videos/Ungesichert/Videorecorder /srv/vdr/video bind bind 0 0
#/dev/sdh1 /mnt/usbdisk ntfs noatime,noauto 0 0
Диски и разделы - до возникновения проблемы
Medium /dev/sda: 3,7 TiB, 4000787030016 Bytes, 7814037168 Sektoren
Einheiten: sectors von 1 * 512 = 512 Bytes
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Typ der Medienbezeichnung: gpt
Medienkennung: 98C35BD3-BFBC-4A4B-AEC9-6D4AFB775AF4
Gerät Start Ende Sektoren Größe Typ
/dev/sda1 2048 7489808383 7489806336 3,5T Linux RAID
/dev/sda2 7489808384 7791525887 301717504 143,9G Linux RAID
Medium /dev/sdb: 3,7 TiB, 4000787030016 Bytes, 7814037168 Sektoren
Einheiten: sectors von 1 * 512 = 512 Bytes
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Typ der Medienbezeichnung: gpt
Medienkennung: 49102EF7-9FA2-4990-8C30-6C5B463B917E
Gerät Start Ende Sektoren Größe Typ
/dev/sdb1 2048 20479 18432 9M BIOS boot
/dev/sdb2 20480 31270911 31250432 14,9G Linux RAID
/dev/sdb3 31270912 324239359 292968448 139,7G Linux RAID
/dev/sdb4 324239360 7814035455 7489796096 3,5T Linux RAID
Medium /dev/sdc: 3,7 TiB, 4000787030016 Bytes, 7814037168 Sektoren
Einheiten: sectors von 1 * 512 = 512 Bytes
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Typ der Medienbezeichnung: gpt
Medienkennung: 6A037D00-F252-4CA0-8D68-430734BCA765
Gerät Start Ende Sektoren Größe Typ
/dev/sdc1 2048 20479 18432 9M BIOS boot
/dev/sdc2 20480 31270911 31250432 14,9G Linux RAID
/dev/sdc3 31270912 324239359 292968448 139,7G Linux RAID
/dev/sdc4 324239360 7814035455 7489796096 3,5T Linux RAID
Medium /dev/sdd: 3,7 TiB, 4000787030016 Bytes, 7814037168 Sektoren
Einheiten: sectors von 1 * 512 = 512 Bytes
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Typ der Medienbezeichnung: gpt
Medienkennung: EADC29D6-C2E9-4AC8-B1B2-F01A5233467C
Gerät Start Ende Sektoren Größe Typ
/dev/sdd1 2048 20479 18432 9M BIOS boot
/dev/sdd2 20480 31270911 31250432 14,9G Linux RAID
/dev/sdd3 31270912 324239359 292968448 139,7G Linux RAID
/dev/sdd4 324239360 7814035455 7489796096 3,5T Linux RAID
Medium /dev/sde: 3,7 TiB, 4000787030016 Bytes, 7814037168 Sektoren
Einheiten: sectors von 1 * 512 = 512 Bytes
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Typ der Medienbezeichnung: gpt
Medienkennung: 3D7EBBFD-C00D-4503-8BF1-A71534F643E1
Gerät Start Ende Sektoren Größe Typ
/dev/sde1 2048 20479 18432 9M Linux filesystem
/dev/sde2 20480 31270911 31250432 14,9G Linux filesystem
/dev/sde3 31270912 324239359 292968448 139,7G Linux filesystem
/dev/sde4 324239360 7814035455 7489796096 3,5T Linux filesystem
Medium /dev/sdf: 3,7 TiB, 4000787030016 Bytes, 7814037168 Sektoren
Einheiten: sectors von 1 * 512 = 512 Bytes
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Typ der Medienbezeichnung: gpt
Medienkennung: FCA42FC2-C5E9-45B6-9C18-F103C552993D
Gerät Start Ende Sektoren Größe Typ
/dev/sdf1 2048 7489824767 7489822720 3,5T Linux RAID
/dev/sdf2 7489824768 7791525887 301701120 143,9G Linux RAID
Medium /dev/sdg: 3,7 TiB, 4000787030016 Bytes, 7814037168 Sektoren
Einheiten: sectors von 1 * 512 = 512 Bytes
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Typ der Medienbezeichnung: gpt
Medienkennung: 8FF8C4CC-6788-47D7-8264-8FA6EF912555
Gerät Start Ende Sektoren Größe Typ
/dev/sdg1 2048 7489824767 7489822720 3,5T Linux RAID
/dev/sdg2 7489824768 7791525887 301701120 143,9G Linux RAID
Medium /dev/md2: 17,4 TiB, 19173204295680 Bytes, 37447664640 Sektoren
Einheiten: sectors von 1 * 512 = 512 Bytes
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 524288 Bytes / 2621440 Bytes
Medium /dev/md128: 14,9 GiB, 15991701504 Bytes, 31233792 Sektoren
Einheiten: sectors von 1 * 512 = 512 Bytes
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Medium /dev/md129: 139,6 GiB, 149865496576 Bytes, 292706048 Sektoren
Einheiten: sectors von 1 * 512 = 512 Bytes
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Medium /dev/mapper/vgSystem-vRoot: 74,5 GiB, 79997960192 Bytes, 156246016 Sektoren
Einheiten: sectors von 1 * 512 = 512 Bytes
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Medium /dev/mapper/vgData-vData: 17,4 TiB, 19173199577088 Bytes, 37447655424 Sektoren
Einheiten: sectors von 1 * 512 = 512 Bytes
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 524288 Bytes / 2621440 Bytes
Medium /dev/mapper/vgSystem-testBtrfs: 5 GiB, 5368709120 Bytes, 10485760 Sektoren
Einheiten: sectors von 1 * 512 = 512 Bytes
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Диски, разделы, рейдовые устройства и тома - до возникновения проблемы
NAME UUID FSTYPE MOUNTPOINT LABEL SIZE
sda 3,7T
├─sda1 607914eb-666e-2a46-b2e4-355702cc2983 linux_raid_member uranus:2 3,5T
│ └─md2 OTNyDe-fNAP-aLzy-Uwat-yYVH-E11D-d1LyzH LVM2_member 17,4T
│ └─vgData-vData a9b3d18d-e45f-4d0f-ab3d-9fe8bfa42157 ext4 /srv data 17,4T
└─sda2 143,9G
sdb 3,7T
├─sdb1 9M
├─sdb2 6813258b-2509-29d6-8a1e-9d34422a9fbd linux_raid_member uranus:128 14,9G
│ └─md128 5a5b997d-9e94-4391-955f-a2b9a3f63820 swap [SWAP] 14,9G
├─sdb3 ab06d13f-a70d-e5a6-c83a-9383b1beb84c linux_raid_member uranus:129 139,7G
│ └─md129 7QXSVM-dauj-RUQ1-uoQp-IamT-TTZo-slzArT LVM2_member 139,6G
│ ├─vgSystem-vRoot fb4bfbb3-de6c-47ef-b237-27af04fa2f4c ext4 / root 74,5G
│ └─vgSystem-testBtrfs 27bbab4c-3c9f-4743-83ac-61e8b41f2bd3 btrfs 5G
└─sdb4 607914eb-666e-2a46-b2e4-355702cc2983 linux_raid_member uranus:2 3,5T
└─md2 OTNyDe-fNAP-aLzy-Uwat-yYVH-E11D-d1LyzH LVM2_member 17,4T
└─vgData-vData a9b3d18d-e45f-4d0f-ab3d-9fe8bfa42157 ext4 /srv data 17,4T
sdc 3,7T
├─sdc1 9M
├─sdc2 6813258b-2509-29d6-8a1e-9d34422a9fbd linux_raid_member uranus:128 14,9G
│ └─md128 5a5b997d-9e94-4391-955f-a2b9a3f63820 swap [SWAP] 14,9G
├─sdc3 ab06d13f-a70d-e5a6-c83a-9383b1beb84c linux_raid_member uranus:129 139,7G
│ └─md129 7QXSVM-dauj-RUQ1-uoQp-IamT-TTZo-slzArT LVM2_member 139,6G
│ ├─vgSystem-vRoot fb4bfbb3-de6c-47ef-b237-27af04fa2f4c ext4 / root 74,5G
│ └─vgSystem-testBtrfs 27bbab4c-3c9f-4743-83ac-61e8b41f2bd3 btrfs 5G
└─sdc4 607914eb-666e-2a46-b2e4-355702cc2983 linux_raid_member uranus:2 3,5T
└─md2 OTNyDe-fNAP-aLzy-Uwat-yYVH-E11D-d1LyzH LVM2_member 17,4T
└─vgData-vData a9b3d18d-e45f-4d0f-ab3d-9fe8bfa42157 ext4 /srv data 17,4T
sdd 3,7T
├─sdd1 9M
├─sdd2 6813258b-2509-29d6-8a1e-9d34422a9fbd linux_raid_member uranus:128 14,9G
│ └─md128 5a5b997d-9e94-4391-955f-a2b9a3f63820 swap [SWAP] 14,9G
├─sdd3 ab06d13f-a70d-e5a6-c83a-9383b1beb84c linux_raid_member uranus:129 139,7G
│ └─md129 7QXSVM-dauj-RUQ1-uoQp-IamT-TTZo-slzArT LVM2_member 139,6G
│ ├─vgSystem-vRoot fb4bfbb3-de6c-47ef-b237-27af04fa2f4c ext4 / root 74,5G
│ └─vgSystem-testBtrfs 27bbab4c-3c9f-4743-83ac-61e8b41f2bd3 btrfs 5G
└─sdd4 607914eb-666e-2a46-b2e4-355702cc2983 linux_raid_member uranus:2 3,5T
└─md2 OTNyDe-fNAP-aLzy-Uwat-yYVH-E11D-d1LyzH LVM2_member 17,4T
└─vgData-vData a9b3d18d-e45f-4d0f-ab3d-9fe8bfa42157 ext4 /srv data 17,4T
sde 3,7T
├─sde1 9M
├─sde2 6813258b-2509-29d6-8a1e-9d34422a9fbd linux_raid_member uranus:128 14,9G
│ └─md128 5a5b997d-9e94-4391-955f-a2b9a3f63820 swap [SWAP] 14,9G
├─sde3 ab06d13f-a70d-e5a6-c83a-9383b1beb84c linux_raid_member uranus:129 139,7G
│ └─md129 7QXSVM-dauj-RUQ1-uoQp-IamT-TTZo-slzArT LVM2_member 139,6G
│ ├─vgSystem-vRoot fb4bfbb3-de6c-47ef-b237-27af04fa2f4c ext4 / root 74,5G
│ └─vgSystem-testBtrfs 27bbab4c-3c9f-4743-83ac-61e8b41f2bd3 btrfs 5G
└─sde4 607914eb-666e-2a46-b2e4-355702cc2983 linux_raid_member uranus:2 3,5T
└─md2 OTNyDe-fNAP-aLzy-Uwat-yYVH-E11D-d1LyzH LVM2_member 17,4T
└─vgData-vData a9b3d18d-e45f-4d0f-ab3d-9fe8bfa42157 ext4 /srv data 17,4T
sdf 3,7T
├─sdf1 607914eb-666e-2a46-b2e4-355702cc2983 linux_raid_member uranus:2 3,5T
│ └─md2 OTNyDe-fNAP-aLzy-Uwat-yYVH-E11D-d1LyzH LVM2_member 17,4T
│ └─vgData-vData a9b3d18d-e45f-4d0f-ab3d-9fe8bfa42157 ext4 /srv data 17,4T
└─sdf2 143,9G
sdg 3,7T
├─sdg1 607914eb-666e-2a46-b2e4-355702cc2983 linux_raid_member uranus:2 3,5T
│ └─md2 OTNyDe-fNAP-aLzy-Uwat-yYVH-E11D-d1LyzH LVM2_member 17,4T
│ └─vgData-vData a9b3d18d-e45f-4d0f-ab3d-9fe8bfa42157 ext4 /srv data 17,4T
└─sdg2
mdadm --examine /dev/sd<array-member-harddrives> - Сейчас
Накопителей всего 6, потому что седьмой «новый» накопитель еще не добавлен в массив.
chris@uranus:/$ sudo mdadm --examine /dev/sda1
[sudo] Passwort für chris:
/dev/sda1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 607914eb:666e2a46:b2e43557:02cc2983
Name : uranus:2 (local to host uranus)
Creation Time : Thu Aug 6 00:45:41 2015
Raid Level : raid6
Raid Devices : 7
Avail Dev Size : 7489544192 (3571.29 GiB 3834.65 GB)
Array Size : 18723832320 (17856.44 GiB 19173.20 GB)
Used Dev Size : 7489532928 (3571.29 GiB 3834.64 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=11264 sectors
State : active
Device UUID : 49c6404e:ee9509ba:c980942a:1db9cf3c
Internal Bitmap : 8 sectors from superblock
Update Time : Fri Jul 13 22:34:48 2018
Checksum : aae603a7 - correct
Events : 2739360
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 3
Array State : AA.AAAA ('A' == active, '.' == missing, 'R' == replacing)
chris@uranus:/$ sudo mdadm --examine /dev/sdb4
/dev/sdb4:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 607914eb:666e2a46:b2e43557:02cc2983
Name : uranus:2 (local to host uranus)
Creation Time : Thu Aug 6 00:45:41 2015
Raid Level : raid6
Raid Devices : 7
Avail Dev Size : 7489533952 (3571.29 GiB 3834.64 GB)
Array Size : 18723832320 (17856.44 GiB 19173.20 GB)
Used Dev Size : 7489532928 (3571.29 GiB 3834.64 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=1024 sectors
State : clean
Device UUID : 61d97294:3ce7cd84:7bb4d5f1:d301c842
Internal Bitmap : 8 sectors from superblock
Update Time : Fri Jul 13 22:42:15 2018
Checksum : 890fbe3d - correct
Events : 2739385
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AA..A.. ('A' == active, '.' == missing, 'R' == replacing)
chris@uranus:/$ sudo mdadm --examine /dev/sdc4
/dev/sdc4:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 607914eb:666e2a46:b2e43557:02cc2983
Name : uranus:2 (local to host uranus)
Creation Time : Thu Aug 6 00:45:41 2015
Raid Level : raid6
Raid Devices : 7
Avail Dev Size : 7489533952 (3571.29 GiB 3834.64 GB)
Array Size : 18723832320 (17856.44 GiB 19173.20 GB)
Used Dev Size : 7489532928 (3571.29 GiB 3834.64 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=1024 sectors
State : clean
Device UUID : ee70c4ab:5b65dae7:df3a78f0:e8bdcead
Internal Bitmap : 8 sectors from superblock
Update Time : Fri Jul 13 22:42:15 2018
Checksum : 6d171664 - correct
Events : 2739385
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA..A.. ('A' == active, '.' == missing, 'R' == replacing)
chris@uranus:/$ sudo mdadm --examine /dev/sde4
/dev/sde4:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 607914eb:666e2a46:b2e43557:02cc2983
Name : uranus:2 (local to host uranus)
Creation Time : Thu Aug 6 00:45:41 2015
Raid Level : raid6
Raid Devices : 7
Avail Dev Size : 7489533952 (3571.29 GiB 3834.64 GB)
Array Size : 18723832320 (17856.44 GiB 19173.20 GB)
Used Dev Size : 7489532928 (3571.29 GiB 3834.64 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=1024 sectors
State : clean
Device UUID : 6ce5311f:084ded8e:ba3d4e06:43e38c67
Internal Bitmap : 8 sectors from superblock
Update Time : Fri Jul 13 22:42:15 2018
Checksum : 572b9ac7 - correct
Events : 2739385
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 4
Array State : AA..A.. ('A' == active, '.' == missing, 'R' == replacing)
chris@uranus:/$ sudo mdadm --examine /dev/sdf1
/dev/sdf1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 607914eb:666e2a46:b2e43557:02cc2983
Name : uranus:2 (local to host uranus)
Creation Time : Thu Aug 6 00:45:41 2015
Raid Level : raid6
Raid Devices : 7
Avail Dev Size : 7489560576 (3571.30 GiB 3834.66 GB)
Array Size : 18723832320 (17856.44 GiB 19173.20 GB)
Used Dev Size : 7489532928 (3571.29 GiB 3834.64 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=27648 sectors
State : clean
Device UUID : 7c4fbe19:d63eced4:1b40cf79:e759fe4b
Internal Bitmap : 8 sectors from superblock
Update Time : Fri Jul 13 22:36:17 2018
Checksum : ef93d641 - correct
Events : 2739381
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 6
Array State : AA..A.A ('A' == active, '.' == missing, 'R' == replacing)
chris@uranus:/$ sudo mdadm --examine /dev/sdg1
/dev/sdg1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 607914eb:666e2a46:b2e43557:02cc2983
Name : uranus:2 (local to host uranus)
Creation Time : Thu Aug 6 00:45:41 2015
Raid Level : raid6
Raid Devices : 7
Avail Dev Size : 7489560576 (3571.30 GiB 3834.66 GB)
Array Size : 18723832320 (17856.44 GiB 19173.20 GB)
Used Dev Size : 7489532928 (3571.29 GiB 3834.64 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=27648 sectors
State : clean
Device UUID : 36d9dffc:27699128:e84f87e7:38960357
Internal Bitmap : 8 sectors from superblock
Update Time : Fri Jul 13 22:35:47 2018
Checksum : 9f34d651 - correct
Events : 2739377
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 5
Array State : AA..AAA ('A' == active, '.' == missing, 'R' == replacing)
У вас была одна остановка (та, которую вы заменяли), когда это произошло:
В этот момент возникла странная проблема, и у parted были проблемы с доступом к одному из старых дисков. Я заметил, что из массива ушел еще один диск, а через несколько секунд - еще один. Сбой массива. Я был шокирован и выключил систему, чтобы предотвратить дальнейшие ошибки.
Это составляет 3 диска, если сбои были фатальными.
Вы заявили, что ОС была на RAID 1, я предполагаю, что это были 2 диска, а остальные 7 дисков были на RAID 6.
RAID 6 выдерживает потерю двух дисков в массиве. Если у вас было 3 сбоя в массиве RAID 6 (при условии, что ни один из отказавших дисков не был из RAID 1), и если диски не в хорошем состоянии, то, скорее всего, данные потеряны.
Вы можете проверить состояние каждого диска с помощью:
sudo smartctl -a /dev/sdX
И тогда вы можете узнать, выпали ли 3 диска или это была случайность. Если это была случайность, и ты уверен, что все в порядке, что ваши mdadm.conf и fstab верны, так как ваш массив кажется неактивный, то вы можете попытаться выполнить повторную сборку с помощью (предупреждение: опасно, прочтите отказ от ответственности ниже):
sudo mdadm --stop /dev/md2
sudo mdadm --assemble --scan --force
Примечание: на вашем последнем --detail вывод показывает 6 дисков, а не 7. /dev/sdd отсутствует похоже.
Вы можете вставить свой mdadm.conf, fstab и LVM VG, LV и разделы, чтобы помочь понять конфигурацию.
Отказ от ответственности: Пробовать что-то со сломанным RAID опасно, я рекомендую шаги, основанные на доступной информации, которую вы предоставили, я не могу гарантировать, что это сработает или что это не уничтожит ваши данные. Бегите под свою ответственность и на свой страх и риск.
1. Would you suggest first trying --assemble --force, maybe with an overlay file?
На мой взгляд, это определенно первый вариант, который стоит попробовать. Использование файла наложения зависит от ваших данных и вашей готовности к риску. До сих пор у меня были резервные копии в таких ситуациях, поэтому я не использовал опцию наложения. Если вы хотите быть в безопасности, используйте его. В этой области я хотел бы выделить несколько моментов:
Не рассматривайте использование mdadm < 4.0 версии. Сделайте бэкпорт или скомпилируйте версию >= 4.0. В 3.x что в результате потерпело неудачу assemble --force действия, которые хорошо работали с 4.0.
При попытке assemble --force использовать --verbose он предоставит вам хороший набор информации, которая может быть полезна для дальнейших шагов и понимания того, что произошло или что не удалось.
2. If i use a --create --assume-clean, is it a better choice to create the last functioning setup with 6 disks or maybe a setup with only 5 drives that have the highest event count? The Is this even possible? My goal is restoring some important data from the array and no permanent solution.
В вашем случае, когда Event-offset такое маленькое, я думаю, нет ничего плохого в воссоздании массива с дисками 6/7. Если вы подозреваете, что HBA (контроллер sata / ide / scsi) может иметь проблему, в конечном итоге следует рассмотреть возможность исключения подозрительных портов. Но это зависит от оборудования и проводки. И да, это возможно, но это зависит от типа рейда. С raid6 вы можете попытаться перестроить только с дисками 5/7, технически для этого не должно быть никаких ограничений. Важно только то, что если вы воссоздаете его с помощью 5/7, определенно больше не будет возможности для отказа диска.
3. I have details about the array before the crash occured. According to this i would come up with a mdadm --create --assume-clean --level=6 --raid-devices=7 --size=3744766464 /dev/sdb4 /dev/sdc4 missing /dev/sda1 /dev/sde4 /dev/sdg1 /dev/sdf1 for 6 drives, respectively mdadm --create --assume-clean --level=6 --raid-devices=7 --size=3744766464 /dev/sdb4 /dev/sdc4 missing missing /dev/sde4 /dev/sdg1 /dev/sdf1 on a 5 drive solution. Would you agree with this?
Я не проверял детали (порядок дисков, размер, недостающие позиции, ...), но команды выглядят хорошо. Тем не менее, как упоминалось в Linux Raid Wiki, отдых следует рассматривать как ПОСЛЕДНИЙ курорт. Когда это необходимо, я всегда стараюсь быть максимально конкретным. Просто помните, что в прошлый раз я просмотрел справочную страницу mdadm и добавил все параметры, в которых я знал данные из имеющейся информации (например, даже размер блока, выравнивание, ...). Есть много значений по умолчанию, которые можно опустить, но если вы уверены в значениях, почему бы не быть конкретным.
В вашей ситуации я бы попробовал следующее:
mdadm до версии >=4.0/proc/mdstat и использовать mdadm --stop ....dmesg и smartctl журналы. Попробуйте прочитать с диска (например, dd if=/dev/hda1 of=/dev/null bs=1M count=2048. Перепроверить dmesg и smartctl журналы. Повторите это, добавьте немного ibs= и skip=. Перепроверить dmesg и smartctl журналы. Если вы видите resets|timeouts|failures на ata|sata|scsi|... HBA останавливает любые процедуры на диске с использованием этого оборудования.mdadm --assemble --scan --verbose. Скорее всего, это не удастся, но это даст вам хороший обзор того, что обнаруживает mdadm, и подскажет, что произойдет, если вы force который.--assemble --scan --verbose, пробовать --force Это.Я просто предоставлю несколько идей, как и что анализировать, чтобы получить представление о текущем состоянии:
Первый раздел не очень интересен и должен быть одинаковым для всех членов массива.
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 607914eb:666e2a46:b2e43557:02cc2983
Name : uranus:2 (local to host uranus)
Creation Time : Thu Aug 6 00:45:41 2015
Raid Level : raid6
Raid Devices : 7
Avail Dev Size : 7489544192 (3571.29 GiB 3834.65 GB)
Array Size : 18723832320 (17856.44 GiB 19173.20 GB)
Used Dev Size : 7489532928 (3571.29 GiB 3834.64 GB)
Все еще не очень интересно, смещения могут отличаться, если диски не одинакового размера. UUID - это UUID жесткого диска, уникальный для каждого диска.
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=11264 sectors
State : active
Device UUID : 49c6404e:ee9509ba:c980942a:1db9cf3c
Internal Bitmap : 8 sectors from superblock
Здесь начинается самое интересное, комментарии начинаются с #:
Update Time : Fri Jul 13 22:34:48 2018 # last write activity on the drive
Checksum : aae603a7 - correct # should be equal on all disks, when the state is clean
Events : 2739360 # Events on the disk, in bock/chunk units
Layout : left-symmetric # could be relevant for rebuilding the array, left-symmetric is default for x86
Chunk Size : 512K
Следующий раздел интересен для перестроения массива, особенно при формировании команды Device Role является важным.
Device Role : Active device 3
Array State : AA.AAAA ('A' == active, '.' == missing, 'R' == replacing)
Состояние массива просто информативно, но не сильно поможет.
Прежде всего мы хотим получить представление о How far have disks run apart during the failure?
Если я правильно помню, есть порог 50 события в коде mdadm при попытке assemble --force. Значит, если у нас есть разница в событиях >50 assemble --force больше работать не будет. Хотя разница в <50 События также не гарантируют, что принудительная сборка будет работать. В таком случае единственная возможность - воссоздать массив с теми же параметрами, что и он, и указать mdadm --create --assume-clean. Когда кто-то находится в «удачной» ситуации, когда все суперблоки доступны и могут быть прочитаны, тогда это должно быть возможно довольно «легко», но с осторожностью.
Счетчик событий выглядит так, как если бы сначала отключился первый диск, затем последний и предпоследний. Разница <50, со временем это может стать довольно простым.
Events : 2739360
Events : 2739385
Events : 2739385
Events : 2739385
Events : 2739381
Events : 2739377
Правильно интерпретируя Array State возможно только при условии, что Events считать & Drive Role.
Device Role : Active device 3
Device Role : Active device 0
Device Role : Active device 1
Device Role : Active device 4
Device Role : Active device 6
Device Role : Active device 5
Array State : AA.AAAA ('A' == active, '.' == missing, 'R' == replacing)
Array State : AA..A.. ('A' == active, '.' == missing, 'R' == replacing)
Array State : AA..A.. ('A' == active, '.' == missing, 'R' == replacing)
Array State : AA..A.. ('A' == active, '.' == missing, 'R' == replacing)
Array State : AA..A.A ('A' == active, '.' == missing, 'R' == replacing)
Array State : AA..AAA ('A' == active, '.' == missing, 'R' == replacing)
mdadm начинает считать в 0. Водить машину 2 сначала не удалось, затем ехать 3, позже ехать 5 и в конце концов на машине 6. Обратите внимание на этот привод 5 все еще перечисляет диск 6 так же активен, как и драйв 3 списки 3, 5 и 6 как активный. Таким образом, скорее всего, диски не обновили суперблок при выходе из строя другого диска.
Увидев Array States, Я полагаю, что автоматический assemble --force не будет хорошо разыгрываться, так как нет согласованности на 5 устройствах на Array State. Массив был raid6 с 7 дисками, поэтому в этом случае нам потребуется 5 дисков, Array State и имеют разницу менее 50 событий, что не так.
Помните, mdadm/raid построен так, чтобы не терять данные. Итак, в коде есть механизмы, предотвращающие mdadm от действий, которые могут нанести вред данным. Автоматическая сборка, даже с параметром --force, вызовет только действия, которые, скорее всего, будут успешными. Если в суперблоках недостаточно / непротиворечивой информации, чтобы mdadm принял решение о сохранении, он потерпит неудачу. Если вы действительно знаете, что делаете, вы можете просто переписать суперблоки с помощью create --assume-clean и вся информация, необходимая для возобновления работы рейда. Но это будет ручная задача, когда вы, как администратор / пользователь, должны указать программе, что именно делать.
Я не собираюсь приводить здесь команду копирования и вставки, потому что считаю важным в такой ситуации знать, что он делает, перед выполнением команды «repair-my-raid». И для углубления знаний важно прочитать все статьи, связанные с RAID Recovery, на Linux RAID Wiki, и мой вывод для этого ответа.
https://raid.wiki.kernel.org/index.php/Linux_Raid#When_Things_Go_Wrogn https://raid.wiki.kernel.org/index.php/RAID_Recovery https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID
mdadm использует superblocks определять, как собирать диски и тд. В таком случае всегда очень полезно и информативно посмотреть на фактические данные суперблока физического диска. перед делать любой действия, которые записывать что-то на диски (например. mdadm --assemble --scan --force, который обновит суперблоки mdadm).
Использовать mdadm --examine /dev/sd<your-array-member-harddrives> чтобы увидеть, что содержит суперблок. Это должно дать вам представление о том, когда что-то вышло из строя, сколько у вас смещения между дисками с точки зрения записи и многое другое.
Получив четкое представление о том, что является текущее состояние физических дисков, вы можете придумать стратегию, чтобы исправить ситуацию.
Но прежде всего я бы также подумал, что материнская плата / sata-controller / scsi-controller / ... имеет физический дефект. Такое количество дисков, выходящих из строя в течение очень короткого периода времени, является необычным (за исключением того, что у одного была прекрасная идея использовать все диски одного производителя и производственную партию для создания системы рейдов), и это может указывать на проблему с контроллером. Восстановление / повторная синхронизация поврежденного рейда на контроллере жесткого диска, который в конечном итоге не работает, приведет только к катастрофе.