Назад | Перейти на главную страницу

Восстановите потерянный том RAID1 на Synology с помощью mdam

Несколько дней назад я обнаружил, что мой 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

/ dev / sdc Таблица разделов

Затем я хотел восстановить и проверить таблицу разделов sdc: я использовал testdisk который не входит в стандартный дистрибутив Synology, но может быть установлен из [Synocommunity repository][1]. После установки к нему можно будет получить доступ с консоли через /usr/local/testdisk/bin/testdisk .

  1. Выберите диск, затем карту разделов [EFI GPT].
  2. Анализируйте и Быстрый поиск. Обнаружил несколько разделов.
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]
  1. Помечены все Linux Raid как P (первичные) разделы, остальной рынок как D (удален). Записать таблицу разделов.

В конце концов - 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

Итак, я успешно скопировал все данные.