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 жестких дисков. При таком большом количестве оборудования их правильное расположение становится огромной помощью; Отсоединение кабелей или падение жесткого диска с вашего стола, безусловно, не помогут в процессе и могут нанести дальнейший ущерб целостности ваших данных.
Я потратил пару минут на создание самодельных креплений для жестких дисков из картона, которые действительно помогли упорядочить вещи:
