У меня был массив raid5 на / dev / md0 создан с помощью mdadm, и он работал нормально около года. Он состоял из трех жестких дисков по 1 ТБ каждый. Несколько дней назад произошел сбой питания и отказ ИБП. К сожалению, это было не в первый раз.
ОС находится на отдельном SSD-диске (/ dev / sda), который не является частью массива raid, поэтому он загружается, но больше не может монтировать массив. Иногда / dev / md0 не существует вообще. Также я сделал кое-что, что могло ухудшить положение. Я побежал fsck /dev/sdb -y который много раз записывал на диск.
Боюсь, что не смогу восстановить свои файлы. Вы можете помочь мне решить эту проблему?
Спасибо.
монтировать / dev / md0 / mnt / raid5
mount: /dev/md0: can't read superblock
системный журнал:
Feb 25 15:59:53 pve kernel: [ 365.559378] EXT4-fs (md0): unable to read superblock
Feb 25 15:59:53 pve kernel: [ 365.560118] EXT4-fs (md0): unable to read superblock
Feb 25 15:59:53 pve kernel: [ 365.560216] EXT4-fs (md0): unable to read superblock
Feb 25 15:59:53 pve kernel: [ 365.560310] FAT-fs (md0): unable to read boot sector
cat / proc / mdstat
Personalities : [raid6] [raid5] [raid4]
unused devices: <none>
fdisk -l
Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 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: dos
Disk identifier: 0x75633c0d
Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 1950353407 1950351360 930G fd Linux raid autodetect
Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 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: F397C12B-1549-45EA-97EA-6A41B713B58F
Device Start End Sectors Size Type
/dev/sdc1 2048 1950353407 1950351360 930G Linux RAID
Disk /dev/sdd: 931.5 GiB, 1000203804160 bytes, 1953523055 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: dos
Disk identifier: 0xcced27e3
Device Boot Start End Sectors Size Id Type
/dev/sdd1 2048 1950353407 1950351360 930G fd Linux raid autodetect
иногда fdisk -l
-bash: /sbin/fdisk: Input/output error
системный журнал:
Feb 25 16:03:25 pve kernel: [ 577.221547] ata1.00: SRST failed (errno=-16)
Feb 25 16:03:25 pve kernel: [ 577.232569] ata1.00: reset failed, giving up
Feb 25 16:03:25 pve kernel: [ 577.232640] ata1.00: disabled
Feb 25 16:03:25 pve kernel: [ 577.232643] ata1.01: disabled
Feb 25 16:03:25 pve kernel: [ 577.232658] ata1: EH complete
Feb 25 16:03:25 pve kernel: [ 577.232683] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Feb 25 16:03:25 pve kernel: [ 577.232697] sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 05 13 a0 38 00 00 08 00
Feb 25 16:03:25 pve kernel: [ 577.232702] blk_update_request: I/O error, dev sda, sector 85172280
Feb 25 16:03:25 pve kernel: [ 577.232784] Buffer I/O error on dev dm-6, logical block 9255, lost sync page write
Feb 25 16:03:25 pve kernel: [ 577.232928] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Feb 25 16:03:25 pve kernel: [ 577.232936] sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 02 88 6a 10 00 00 68 00
Feb 25 16:03:25 pve kernel: [ 577.232941] blk_update_request: I/O error, dev sda, sector 42494480
Feb 25 16:03:25 pve kernel: [ 577.232948] EXT4-fs error (device dm-6): kmmpd:176: comm kmmpd-dm-6: Error writing to MMP block
sudo mdadm --examine / dev / sdb1
mdadm: No md superblock detected on /dev/sdb1.
sudo mdadm --examine / dev / sdc1
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 34c11bda:11bbb8c9:c4cf5f56:7c38e1c3
Name : pve:0
Creation Time : Sun Jun 5 21:06:33 2016
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 1950089216 (929.88 GiB 998.45 GB)
Array Size : 1950089216 (1859.75 GiB 1996.89 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=0 sectors
State : active
Device UUID : be76ecf7:b0f28a7d:718c3d58:3afae9f7
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Feb 20 14:48:51 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : ffbc1988 - correct
Events : 2901112
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : .AA ('A' == active, '.' == missing, 'R' == replacing)
sudo mdadm --examine / dev / sdd1
/dev/sdd1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x9
Array UUID : 34c11bda:11bbb8c9:c4cf5f56:7c38e1c3
Name : pve:0
Creation Time : Sun Jun 5 21:06:33 2016
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 1950089216 (929.88 GiB 998.45 GB)
Array Size : 1950089216 (1859.75 GiB 1996.89 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=0 sectors
State : active
Device UUID : 7b9ed6e0:ffad7603:b226e752:355765a8
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Feb 20 14:48:51 2017
Bad Block Log : 512 entries available at offset 72 sectors - bad blocks present.
Checksum : 19b6f3da - correct
Events : 2901112
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : .AA ('A' == active, '.' == missing, 'R' == replacing)
Спасибо всем, что восстановил данные.
Я побежал sudo mdadm --verbose --assemble --force /dev/md0 /dev/sdc1 /dev/sdd1 собрать массив из двух оставшихся хороших HDD и все заработало!
Затем я отформатировал sdb и повторно добавил его в массив с помощью sudo mdadm --manage /dev/md0 --add /dev/sdb1 и я собираюсь купить новый, чтобы заменить его в ближайшее время. Также я ищу решения для резервного копирования ..
Если вы указали ошибки ввода / вывода, я думаю, у вас один или несколько неисправных дисков. Вам нужно проверить SMART атрибуты всех дисков командой smartctl -a /dev/sdx. Проверьте status и Update Time каждого диска по команде mdadm --examine /dev/sdx1. Выберите одну худшую дисковую ведьму, у которой больше плохих умных атрибутов и самый старый Update Time и удалите его из массива.
Если у вас два плохих диска, вам нужно выбрать менее плохой диск, и его необходимо восстановить на новый диск с помощью программы ddrecovery. Удалите этот плохой диск и вставьте новый восстановленный диск в то же место.
После этого вы сможете восстановить массив RAID 5 с одним пропущенным диском (например, sdc) по команде:
mdadm --verbose --create /dev/md0 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 missing /dev/sdd1
Будь уверен, что chunk параметр такой же, как на хороших дисках.
Также у вас плохой sda-диск, который не входит в массив RAID 5.
Будьте внимательны с каждой командой. Есть только способ восстановить ваш RAID-массив.
Читать этот своим примером.
Запуск fsck был правильной идеей, но я думаю, вы запустили его не на том устройстве. Попробуйте запустить fsck на / dev / md0, используя резервный суперблок. Эта ссылка даст вам несколько советов о том, как найти резервную копию и исправить ее, когда вы это сделаете. В частности, бег dumpe2fs лучше всего подходит для определения размера блока файловой системы. Даже если первая резервная копия повреждена, ext4 создаст другие.
У вас несколько проблем.
Первый, вы говорите, что / dev / sda - это ваш системный диск, а не часть RAID-массива с ОС на нем. Что ж, посмотрите точный фрагмент системного журнала, который вы нам показали:
Feb 25 16:03:25 pve kernel: [ 577.232702] blk_update_request: I/O error, dev sda, sector 85172280
Feb 25 16:03:25 pve kernel: [ 577.232941] blk_update_request: I/O error, dev sda, sector 42494480
Две ошибки ввода-вывода во время записи, сообщаемые с интервалом в миллисекунды, в два разных места на системном диске. У вашего системного диска серьезные проблемы; заменить его немедленно. Возможно, стоит заменить к нему и кабели, пока вы занимаетесь этим. По моему опыту, ошибки ввода-вывода обычно указывают на проблемы с кабелем или диском (хотя HBA жестяная банка быть виноватым). Ожидайте, что данные на системном диске будут повреждены, по крайней мере, в некоторой степени в результате этой проблемы.
Во-вторых, fsck /dev/sdb -y очень вероятно, что он нацарапал все ваши данные RAID, пытаясь понять частичные данные файловой системы и автоматически записывая все, что казалось правильным. Я бы посоветовал физически отключить этот диск, удалить его из системы и пока поместить в безопасное место. Считайте его мертвым.
К счастью, вам повезло; система по-прежнему обменивается данными со всеми тремя дисками, и метаданные выглядят нормально на двух дисках из трех, которые все еще содержат метаданные MD.
Возьмите три новых диска и используйте ddrescue скопировать все, что можно с двух оставшихся дисков, на два новых. Отключите старые диски и установите их вместе с тем, что раньше было / dev / sdb (убедитесь, что вы отслеживаете, какой диск какой), и подключите два новых диска вместе с третьим новым, пустым, одним.
Подайте полученный массив в mdadm и молитесь своему избранному божеству, чтобы md смог разобраться в сложившейся ситуации. Если вам повезет, он сможет восстановить и восстановит большую часть данных до читаемого состояния теперь, когда нет ошибок чтения (поскольку вы ввели новые диски). Опять же, местами может быть некоторая коррупция.
Третий, выяснить, что вызвало отказ ИБП, и исправить это, а также настроить регулярное резервное копирование, чтобы в худшем случае у вас, по крайней мере, была резервная копия, которую можно было восстановить на новый носитель. Считайте этот инцидент учебным опытом, иллюстрирующим почему RAID не является резервной копией.