Несколько дней назад я обнаружил, что мой DS412 + находится в фатальном состоянии. Volume1 разбился, системный объем тоже. Более того, Volume2 пропал из системы! Похоже, на Томе 1 нет свободного места, и он не может передать данные из пары плохих блоков в новое место, что повредило системные данные. (это всего лишь теория).
Мне удалось вернуть Volume1 к жизни с помощью процедур описано здесь (e2fsck, mdadm reassemble
). Кстати, нужно упомянуть новые syno_poweroff_task
команда, которая упрощает процесс!
Затем я восстановил системный том с помощью графического интерфейса пользователя Synology. Все заработало нормально, за исключением того, что не могу восстановить Volume2. Это был массив RAID1, состоящий из 2-х дисков одинакового размера. Это отрывок из /etc/space_history*.xml
даты непосредственно перед аварией:
<space path="/dev/md3" reference="/volume2" >
<device>
<raid path="/dev/md3" uuid="927afd83:*" level="raid1" version="1.2">
<disks>
<disk status="normal" dev_path="/dev/sdc3" model="WD30EFRX-68AX9N0 " serial="WD-*" partition_version="7" slot="1">
</disk>
<disk status="normal" dev_path="/dev/sdd3" model="WD30EFRX-68AX9N0 " serial="WD-*" partition_version="7" slot="0">
</disk>
</disks>
</raid>
</device>
<reference>
<volume path="/volume2" dev_path="/dev/md3">
</volume>
</reference>
Члены RAID (/ dev / sdc3 и / dev / sdd3) все еще на своих местах, и похоже, что с ними все в порядке, по крайней мере, / dev / sdc3.
DiskStation> mdadm --misc --examine /dev/sdc3
/dev/sdc3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 600cff1e:0e27a96d:883007c3:610e73ef
Name : DiskStation:3 (local to host DiskStation)
Creation Time : Thu Mar 19 22:21:08 2015
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 5851088833 (2790.02 GiB 2995.76 GB)
Array Size : 5851088512 (2790.02 GiB 2995.76 GB)
Used Dev Size : 5851088512 (2790.02 GiB 2995.76 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : f0b910a0:1de7081f:dd65ec22:a2a16d58
Update Time : Thu Mar 19 22:21:08 2015
Checksum : a09b6690 - correct
Events : 0
Device Role : Active device 0
Array State : A. ('A' == active, '.' == missing)
Я пробовал много трюков с mdadm, во многих формах вроде этого:
mdadm -v --assemble /dev/md3 /dev/sdc3 /dev/sdd3
mdadm --verbose --create /dev/md3 --level=1 --raid-devices=2 /dev/sdc3 /dev/sdd3 --force
mdadm --verbose --create /dev/md3 --level=1 --raid-devices=2 /dev/sdc3 missing
Все они приводят к примерно следующему:
mdadm: ADD_NEW_DISK for /dev/sdc3 failed: Invalid argument
Есть ли шанс восстановить объем RAID? Или есть шанс восстановить данные с тома? Например, монтировать член / dev / sdc3 напрямую?
Дополнительная информация о mdadm:
DiskStation> cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid1 sdb3[0]
2925544256 blocks super 1.2 [1/1] [U]
md1 : active raid1 sdb2[0] sdc2[1]
2097088 blocks [4/2] [UU__]
md0 : active raid1 sdb1[2] sdc1[0]
2490176 blocks [4/2] [U_U_]
В конце концов (после нескольких дней исследований) мне удалось заставить массив работать и скопировать данные.
Во-первых, причиной были битые сектора диска - я полагаю, в области суперблока рейда и / или таблицы разделов.
Во-вторых, мне пришлось использовать dmesg
видеть ошибки во время mdadm --assemble
или mdadm --create
:
[Thu Mar 19 23:27:04 2015] end_request: I/O error, dev sdc, sector 9437194
Поэтому я предпринял следующие шаги, чтобы избавиться от ситуации. Имейте в виду, я не гарантирую, что этот способ верен во всех деталях, и, возможно, может привести к потере данных, но мне это помогло.
Прежде всего, я забочусь о плохих секторах диска (я не знаю, почему они не переназначены автоматически). И, вероятно, это вызвало некоторые проблемы с данными на другом диске.
Проверил несколько секторов вокруг первой неисправности:
hdparm --read-sector 9437191 /dev/sdc ... hdparm --read-sector 9437195 /dev/sdc .... hdparm --read-sector 9437199 /dev/sdc
А потом исправили плохие:
hdparm --yes-i-know-what-i-am-doing --write-sector 9437198 /dev/sdc
Затем я хотел восстановить и проверить таблицу разделов sdc: я использовал testdisk
который не входит в стандартный дистрибутив Synology, но может быть установлен из [Synocommunity repository][1]
. После установки к нему можно будет получить доступ с консоли через /usr/local/testdisk/bin/testdisk
.
TestDisk 7.0-WIP, Data Recovery Utility, January 2015 Christophe GRENIER http://www.cgsecurity.org Disk /dev/sdc - 3000 GB / 2794 GiB - CHS 364801 255 63 Partition Start End Size in sectors D MS Data 256 4980607 4980352 [1.41.10-2219] P Linux Raid 256 4980735 4980480 [md0] D Linux Swap 4980736 9174895 4194160 >P Linux Raid 4980736 9175039 4194304 [md1] P Linux Raid 9437184 5860523271 5851086088 [DiskStation:3]
В конце концов - partprobe /dev/sdc
для обновления таблицы разделов системы (без перезагрузки).
Теперь появилась возможность восстановить суперблок рейда.
mdadm --zero-superblock /dev/sdc3
Это помогло мне очистить старую и, возможно, поврежденную информацию о массиве рейдов. Я считаю, что во многих случаях это действие опасно.
mdadm --create /dev/md3 --verbose --assume-clean --metadata=1.2 --level=1 --raid-devices=2 /dev/sdc3 missing
Но в моем случае он восстановил raid1 с 1 доступным диском и без потери данных.
Я не знаю, в чем была причина, но размер файловой системы (ext4) на md3 немного отличался от физического размера md3. Итак, я бегу:
resize2fs /dev/md3
И проверка файловой системы:
fsck.ext4 -f -C 0 /dev/md3
И теперь появилась возможность монтировать массив:
mount -t ext4 -o ro /dev/sdc3 /volume2
Итак, я успешно скопировал все данные.