ZFS на FreeBSD: восстановление после повреждения данных

У меня есть несколько ТБ очень ценных личных данных в zpool, к которым я не могу получить доступ из-за повреждения данных. Первоначально пул был создан еще в 2009 году или около того в системе FreeBSD 7.2, работающей внутри виртуальной машины VMWare поверх системы Ubuntu 8.04. Виртуальная машина FreeBSD по-прежнему доступна и работает нормально, только операционная система хоста теперь изменена на Debian 6. Жесткие диски стали доступными для гостевой виртуальной машины с помощью общих устройств SCSI VMWare, всего 12.

Есть 2 бассейна:

• zpool01: 2x 4x 500 ГБ
• zpool02: 1x 4x 160 ГБ

Тот, что работает, пустой, сломанный хранит все важные данные:

[user@host~]$ uname -a
FreeBSD host.domain 7.2-RELEASE FreeBSD 7.2-RELEASE #0: \
  Fri May  1 07:18:07 UTC 2009                          \
  root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

[user@host ~]$ dmesg | grep ZFS
WARNING: ZFS is considered to be an experimental feature in FreeBSD.
ZFS filesystem version 6
ZFS storage pool version 6

[user@host ~]$ sudo zpool status
  pool: zpool01
 state: UNAVAIL
 scrub: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    zpool01     UNAVAIL      0     0     0  insufficient replicas
      raidz1    UNAVAIL      0     0     0  corrupted data
        da5     ONLINE       0     0     0
        da6     ONLINE       0     0     0
        da7     ONLINE       0     0     0
        da8     ONLINE       0     0     0
      raidz1    ONLINE       0     0     0
        da1     ONLINE       0     0     0
        da2     ONLINE       0     0     0
        da3     ONLINE       0     0     0
        da4     ONLINE       0     0     0

  pool: zpool02
 state: ONLINE
 scrub: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    zpool02     ONLINE       0     0     0
      raidz1    ONLINE       0     0     0
        da9     ONLINE       0     0     0
        da10    ONLINE       0     0     0
        da11    ONLINE       0     0     0
        da12    ONLINE       0     0     0

errors: No known data errors

Пару недель назад я смог получить доступ к бассейну. С тех пор мне пришлось заменить практически все оборудование хост-машины и установить несколько операционных систем хоста.

Я подозреваю, что одна из этих установок ОС написала загрузчик (или что-то еще) на один (первый?) Из дисков 500 ГБ и уничтожила некоторые метаданные zpool (или что-то еще) - `` или что-то еще '', что означает, что это очень расплывчатая идея и эта тема не совсем моя сильная сторона ...

---

О ZFS существует множество веб-сайтов, блогов, списков рассылки и т. Д. Я публикую этот вопрос здесь в надежде, что он поможет мне собрать достаточно информации для разумного, структурированного, контролируемого, информированного, знающего подхода, чтобы вернуть мои данные - и, надеюсь, помочь кому-то еще в такой же ситуации.

---

Первым результатом поиска при поиске в Google "восстановления zfs" является Устранение неполадок ZFS и восстановление данных главу из Руководства по администрированию Solaris ZFS. Во-первых Режимы отказа ZFS В разделе «Поврежденные данные ZFS» говорится:

Повреждение данных всегда необратимо и требует особого внимания во время ремонта. Даже если базовые устройства отремонтированы или заменены, исходные данные будут потеряны навсегда.

Несколько обескураживает.

Однако второй результат поиска Google Блог Макса Брунинга и там я прочитал

Недавно мне прислали электронное письмо от человека, у которого 15 лет видео и музыки хранились в пуле ZFS на 10 ТБ, который после сбоя питания стал неисправным. К сожалению, у него не было резервной копии. Он использовал ZFS версии 6 на FreeBSD 7. [...] Проведя около 1 недели на изучение данных на диске, я смог восстановить практически все их.

и

Что касается потери данных ZFS, я сомневаюсь. Я подозреваю, что ваши данные там, но вам нужно найти правильный способ получить их.

(это больше похоже на то, что я хочу услышать ...)

Первый шаг: В чем именно проблема ?

Как я могу определить, почему zpool считается поврежденным? Я вижу, что существует zdb, который, похоже, официально не документирован ни Sun, ни Oracle где-либо в сети. На его странице руководства:

NAME
       zdb - ZFS debugger

SYNOPSIS
       zdb pool

DESCRIPTION
       The  zdb  command is used by support engineers to diagnose failures and
       gather statistics. Since the ZFS file system is  always  consistent  on
       disk  and is self-repairing, zdb should only be run under the direction
       by a support engineer.

       If no arguments are specified, zdb, performs basic  consistency  checks
       on  the pool and associated datasets, and report any problems detected.

       Any options supported by this command are internal to Sun  and  subject
       to change at any time.

Кроме того, Бен Роквуд опубликовал подробная статья и есть видео Макса Брюнинга, рассказывающего об этом (и mdb) на конференции разработчиков Open Solaris в Праге 28 июня 2008 г.

Запуск zdb от имени root на сломанном zpool дает следующий результат:

[user@host ~]$ sudo zdb zpool01
    version=6
    name='zpool01'
    state=0
    txg=83216
    pool_guid=16471197341102820829
    hostid=3885370542
    hostname='host.domain'
    vdev_tree
        type='root'
        id=0
        guid=16471197341102820829
        children[0]
                type='raidz'
                id=0
                guid=48739167677596410
                nparity=1
                metaslab_array=14
                metaslab_shift=34
                ashift=9
                asize=2000412475392
                children[0]
                        type='disk'
                        id=0
                        guid=4795262086800816238
                        path='/dev/da5'
                        whole_disk=0
                        DTL=202
                children[1]
                        type='disk'
                        id=1
                        guid=16218262712375173260
                        path='/dev/da6'
                        whole_disk=0
                        DTL=201
                children[2]
                        type='disk'
                        id=2
                        guid=15597847700365748450
                        path='/dev/da7'
                        whole_disk=0
                        DTL=200
                children[3]
                        type='disk'
                        id=3
                        guid=9839399967725049819
                        path='/dev/da8'
                        whole_disk=0
                        DTL=199
        children[1]
                type='raidz'
                id=1
                guid=8910308849729789724
                nparity=1
                metaslab_array=119
                metaslab_shift=34
                ashift=9
                asize=2000412475392
                children[0]
                        type='disk'
                        id=0
                        guid=5438331695267373463
                        path='/dev/da1'
                        whole_disk=0
                        DTL=198
                children[1]
                        type='disk'
                        id=1
                        guid=2722163893739409369
                        path='/dev/da2'
                        whole_disk=0
                        DTL=197
                children[2]
                        type='disk'
                        id=2
                        guid=11729319950433483953
                        path='/dev/da3'
                        whole_disk=0
                        DTL=196
                children[3]
                        type='disk'
                        id=3
                        guid=7885201945644860203
                        path='/dev/da4'
                        whole_disk=0
                        DTL=195
zdb: can't open zpool01: Invalid argument

Я полагаю, что ошибка «недопустимый аргумент» в конце возникает из-за того, что zpool01 на самом деле не существует: этого не происходит на рабочем zpool02, но, похоже, нет и дальнейшего вывода ...

Хорошо, на данном этапе, вероятно, лучше опубликовать это, прежде чем статья станет слишком длинной.

Может быть, кто-нибудь даст мне совет, как двигаться дальше, и пока я жду ответа, я посмотрю видео, изучу детали вывода zdb выше, прочитаю статью Бенса и попытаюсь выяснить, что какие...

---

20110806-1600 + 1000

Обновление 01:

Я думаю, что нашел основную причину: Макс Брунинг был достаточно любезен, чтобы очень быстро ответить на мое электронное письмо с просьбой предоставить вывод zdb -lll. На любом из 4 жестких дисков в «хорошей» половине пула raidz1 результат аналогичен тому, что я опубликовал выше. Однако на первых 3-х из 4-х передач «сломанной» половины zdb отчеты failed to unpack label для меток 2 и 3. Четвертый диск в пуле в порядке, zdb показывает все ярлыки.

Погуглите это сообщение об ошибке эта почта. Из первого ответа на этот пост:

В ZFS это 4 идентичные метки на каждом физическом vdev, в данном случае на одном жестком диске. L0 / L1 в начале vdev и L2 / L3 в конце vdev.

Все 8 дисков в пуле одной модели, Seagate Barracuda 500 ГБ. Однако я помню, что запускал пул с 4-мя дисками, потом один из них умер и был заменен по гарантии Seagate. Позже я добавил еще 4 диска. По этой причине идентификаторы накопителя и микропрограммы разные:

[user@host ~]$ dmesg | egrep '^da.*?: <'
da0:  <VMware, VMware Virtual S 1.0> Fixed Direct Access SCSI-2 device 
da1:  <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device 
da2:  <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device 
da3:  <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device 
da4:  <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device 
da5:  <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device 
da6:  <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device 
da7:  <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device 
da8:  <ATA ST3500418AS CC35> Fixed Direct Access SCSI-5 device 
da9:  <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device 
da10: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device 
da11: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device 
da12: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device 

Я помню, что все диски были одинакового размера. Глядя на диски сейчас, видно, что у трех из них изменился размер, они уменьшились на 2 МБ:

[user@host ~]$ dmesg | egrep '^da.*?: .*?MB '
da0:   10240MB (20971520  512 byte sectors: 255H 63S/T 1305C)
da1:  476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da2:  476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da3:  476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da4:  476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da5:  476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da6:  476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da7:  476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da8:  476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da9:  152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da10: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da11: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da12: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)

Так что, судя по всему, это была не одна из инсталляций ОС, которая `` записала загрузчик на один из дисков '' (как я предполагал раньше), это была фактически новая материнская плата ( ASUS P8P67 LE) создание 2 МБ принимающая охраняемая территория в конце трех дисков, которые испортили мои метаданные ZFS.

Почему он не создал HPA на всех дисках? Я считаю, что это связано с тем, что создание HPA выполняется только на старых дисках с ошибкой, которая была исправлена ​​позже обновлением BIOS жесткого диска Seagate: когда весь этот инцидент начался пару недель назад, я запустил Seagate's SeaTools чтобы проверить, есть ли что-нибудь физически не в порядке с дисками (все еще на старом оборудовании), и я получил сообщение о том, что некоторые из моих дисков нуждаются в обновлении BIOS. Поскольку сейчас я пытаюсь воспроизвести точные детали этого сообщения и ссылку на загрузку обновления микропрограммы, кажется, что, поскольку материнская плата создала HPA, обе версии SeaTools DOS не могут обнаружить рассматриваемые жесткие диски - быстрое invalid partition или что-то подобное мигает при запуске, вот и все. Как ни странно, они все же находят набор дисков Samsung.

(Я пропустил болезненные, отнимающие много времени и, в конечном счете, бесполезные детали работы с оболочкой FreeDOS в несетевой системе.) В конце концов, я установил Windows 7 на отдельную машину, чтобы запустить SeaTools Windows версия 1.2.0.5. И последнее замечание о DOS SeaTools: не пытайтесь загрузить их в автономном режиме - вместо этого потратьте пару минут и сделайте загрузочную USB-флешку с потрясающим Окончательный загрузочный компакт-диск - который помимо DOS SeaTools также предоставляет вам множество других действительно полезных инструментов.

При запуске SeaTools для Windows вызывает этот диалог:

Ссылки ведут на Проверка серийного номера (который по какой-то причине защищен капчой - у меня была «Инвазивные пользователи») и статья базы знаний по поводу обновления прошивки. Вероятно, есть дополнительные ссылки, относящиеся к модели жесткого диска и некоторые загрузки, а также другие, но я пока не буду следовать по этому пути:

Я не буду спешить с обновлением прошивки сразу трех дисков, которые имеют обрезанные разделы и являются частью сломанного пула хранения. Это напрашивается на неприятности. Во-первых, обновление прошивки, скорее всего, нельзя будет отменить - и это может безвозвратно испортить мои шансы вернуть свои данные.

Поэтому первое, что я собираюсь сделать дальше, - это создать образ дисков и работать с копиями, так что есть оригинал, к которому можно вернуться, если что-то пойдет не так. Это может внести дополнительную сложность, поскольку ZFS, вероятно, заметит, что диски были заменены местами (с помощью серийного номера диска или еще одного UUID или чего-то еще), даже если dd-файлы с точностью до бита копируются на ту же модель жесткого диска. Более того, zpool даже не жив. Боже, это может быть сложно.

Другой вариант, однако, - работать с оригиналами и сохранять зеркальные диски в качестве резервных копий, но тогда я, вероятно, столкнусь с вышеуказанной сложностью, когда что-то пойдет не так с оригиналами. Неа, не хорошо.

Чтобы очистить три жестких диска, которые будут служить заменой образа для трех дисков с ошибочным BIOS в сломанном пуле, мне нужно создать некоторое пространство для хранения вещей, которые там сейчас есть, поэтому я углублюсь в аппаратный блок и соберите временный zpool из некоторых старых дисков, который я также могу использовать для проверки того, как ZFS справляется с заменой дисков dd'd.

Это может занять некоторое время ...

---

20111213-1930 + 1100

Обновление 02:

Это действительно заняло время. Я провел месяцы с несколькими открытыми компьютерными корпусами на моем столе с различным количеством свисающих жестких дисков, а также проспал несколько ночей с затычками для ушей, потому что я не мог выключить машину перед сном, так как на ней выполнялась длительная критическая операция . Однако, наконец, я победил! :-) Я тоже многому научился в процессе, и я хотел бы поделиться этими знаниями здесь для всех, кто попал в подобную ситуацию.

Эта статья уже намного длиннее, чем у кого-либо, у кого файловый сервер ZFS не работает, есть время, чтобы ее прочитать, поэтому я подробно расскажу здесь и дам ответ с основными выводами ниже.

Я покопался в коробке с устаревшим оборудованием, чтобы собрать достаточно места для хранения, чтобы переместить материал с отдельных дисков емкостью 500 ГБ, на которые были скопированы неисправные диски. Мне также пришлось вытащить несколько жестких дисков из их USB-футляров, чтобы я мог подключить их напрямую через SATA. Было еще несколько несвязанных проблем, и некоторые из старых дисков начали выходить из строя, когда я вернул их в действие, требуя замены zpool, но я пропущу это.

Наконечник: На каком-то этапе всего в этом было задействовано около 30 жестких дисков. При таком большом количестве оборудования их правильное расположение становится огромной помощью; Отсоединение кабелей или падение жесткого диска с вашего стола, безусловно, не помогут в процессе и могут нанести дальнейший ущерб целостности ваших данных.

Я потратил пару минут на создание самодельных креплений для жестких дисков из картона, которые действительно помогли упорядочить вещи:

По иронии судьбы, когда я подключил старые диски в первый раз, я понял, что там есть старый zpool, который я, должно быть, создал для тестирования с более старой версией некоторых, но не всех личных данных, которые пропали, поэтому, хотя потеря данных была несколько уменьшено, это означало дополнительное перемещение файлов вперед и назад.

Наконец, я отразил проблемные диски на резервные диски, использовал их для zpool, а исходные оставил отключенными. На накопителях резервного копирования установлено более новое микропрограммное обеспечение, по крайней мере, SeaTools не сообщает о каких-либо необходимых обновлениях микропрограмм. Я сделал зеркалирование с помощью простого dd с одного устройства на другое, например

sudo dd if=/dev/sda of=/dev/sde

Я считаю, что ZFS действительно замечает изменение оборудования (по UUID какого-либо жесткого диска или что-то еще), но, похоже, это не заботит.

Однако zpool все еще был в том же состоянии, недостаточно реплик / поврежденных данных.

Как упоминалось в Статья в Википедии HPA упоминалось ранее, наличие защищенной области хоста сообщается при загрузке Linux и может быть исследовано с помощью hdparm. Насколько мне известно, на FreeBSD нет инструмента hdparm, но к тому времени у меня все равно были установлены FreeBSD 8.2 и Debian 6.0 как система с двойной загрузкой, поэтому я загрузился в Linux:

user@host:~$ for i in {a..l}; do sudo hdparm -N /dev/sd$i; done

   ...
/dev/sdd:
 max sectors   = 976773168/976773168, HPA is disabled
/dev/sde:
 max sectors   = 976771055/976773168, HPA is enabled
/dev/sdf:
 max sectors   = 976771055/976773168, HPA is enabled
/dev/sdg:
 max sectors   = 976771055/976773168, HPA is enabled
/dev/sdh:
 max sectors   = 976773168/976773168, HPA is disabled
   ...

---

Таким образом, проблема, очевидно, заключалась в том, что новая материнская плата создала HPA размером в пару мегабайт на конце диска, который «спрятал» две верхние метки ZFS, то есть не позволил ZFS их увидеть.

---

Возникновение HPA кажется опасным делом. На странице руководства hdparm параметр -N:

Get/set max visible number of sectors, also known as the Host Protected Area setting.
  ...
To change the current max (VERY DANGEROUS, DATA LOSS IS EXTREMELY LIKELY), a new value
should be provided (in base10) immediately following the -N option.
This value is specified as a count of sectors, rather than the "max sector address"
of the drive. Drives have the concept of a temporary (volatile) setting which is lost on
the next hardware reset, as well as a more permanent (non-volatile) value which survives
resets and power cycles.  By default, -N affects only the temporary (volatile) setting.
To change the permanent (non-volatile) value, prepend a leading p character immediately
before the first digit of the value. Drives are supposed to allow only a single permanent
change per session. A hardware reset (or power cycle) is required before another
permanent -N operation can succeed.
  ...

В моем случае HPA удаляется так:

user@host:~$ sudo hdparm -Np976773168 /dev/sde

/dev/sde:
 setting max visible sectors to 976773168 (permanent)
 max sectors   = 976773168/976773168, HPA is disabled

и точно так же для других дисков с HPA. Если вы выбрали неправильный диск или что-то в указанном вами параметре размера не соответствует действительности, hdparm достаточно умен, чтобы вычислить:

user@host:~$ sudo hdparm -Np976773168 /dev/sdx

/dev/sdx:
 setting max visible sectors to 976773168 (permanent)
Use of -Nnnnnn is VERY DANGEROUS.
You have requested reducing the apparent size of the drive.
This is a BAD idea, and can easily destroy all of the drive's contents.
Please supply the --yes-i-know-what-i-am-doing flag if you really want this.
Program aborted.

После этого я перезапустил виртуальную машину FreeBSD 7.2, на которой изначально был создан zpool, и статус zpool снова сообщил о рабочем пуле. УРА! :-)

Я экспортировал пул в виртуальную систему и повторно импортировал его в хост-систему FreeBSD 8.2.

Еще несколько серьезных обновлений оборудования, еще одна замена материнской платы, обновление пула ZFS до ZFS 4/15, тщательная очистка, и теперь мой zpool состоит из 8x1TB плюс 8x500GB raidz2 частей:

[user@host ~]$ sudo zpool status
  pool: zpool
 state: ONLINE
 scrub: none requested
config:

NAME        STATE     READ WRITE CKSUM
zpool       ONLINE       0     0     0
  raidz2    ONLINE       0     0     0
    ad0     ONLINE       0     0     0
    ad1     ONLINE       0     0     0
    ad2     ONLINE       0     0     0
    ad3     ONLINE       0     0     0
    ad8     ONLINE       0     0     0
    ad10    ONLINE       0     0     0
    ad14    ONLINE       0     0     0
    ad16    ONLINE       0     0     0
  raidz2    ONLINE       0     0     0
    da0     ONLINE       0     0     0
    da1     ONLINE       0     0     0
    da2     ONLINE       0     0     0
    da3     ONLINE       0     0     0
    da4     ONLINE       0     0     0
    da5     ONLINE       0     0     0
    da6     ONLINE       0     0     0
    da7     ONLINE       0     0     0

errors: No known data errors

[user@host ~]$ df -h
Filesystem         Size    Used   Avail Capacity  Mounted on
/dev/label/root     29G     13G     14G    49%    /
devfs              1.0K    1.0K      0B   100%    /dev
zpool              8.0T    3.6T    4.5T    44%    /mnt/zpool

В заключение, мне кажется, пулы ZFS очень и очень трудно убить. Парни из Sun, создавшие эту систему, не зря называют ее последним словом в файловых системах. Респект!

freebsdzfsdata-recovery