У меня в 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. Я публикую этот вопрос здесь в надежде, что он поможет мне собрать достаточно информации для разумного, структурированного, контролируемого, информированного, знающего подхода, чтобы вернуть мои данные - и, надеюсь, помочь кому-то еще в той же ситуации.
Первым результатом поиска при поиске «zfs recovery» является глава « Устранение неполадок и восстановление данных 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 Developer Conference в Праге 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 выше, прочитайте статью Bens и постарайтесь выяснить, что что...
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 500GB . Тем не менее, я помню, что начал пул с 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 SeaTools, чтобы проверить, есть ли что-то физически не так с дисками (все еще на старом оборудовании), и я получил сообщение о том, что некоторые из моих дисков нуждаются в обновлении BIOS. Сейчас, когда я пытаюсь воспроизвести точные детали этого сообщения и ссылку на загрузку обновления прошивки, кажется, что поскольку материнская плата создала HPA, обе версии SeaTools DOS не смогли обнаружить рассматриваемые жесткие диски - быстрое invalid partitionили что-то подобное мелькает, когда они начинают, вот и все. По иронии судьбы, они действительно находят набор дисков Samsung.
(Я пропустил болезненные, отнимающие много времени и, в конечном итоге, бесполезные подробности, связанные с использованием оболочки FreeDOS в не-сетевой системе.) В конце я установил Windows 7 на отдельную машину, чтобы запустить Windows SeaTools версия 1.2.0.5. Еще одно замечание о DOS SeaTools: не пытайтесь загружать их автономно - вместо этого потратьте пару минут и создайте загрузочную флешку с удивительным компакт-диском Ultimate Boot, который помимо DOS SeaTools также дает вам много других действительно полезных возможностей. полезные инструменты.
При запуске SeaTools для Windows открывает этот диалог:
Ссылки ведут на проверку серийного номера (которая по какой-то причине защищена капчей - моя была «Инвазивные пользователи») и в статье базы знаний об обновлении прошивки. Вероятно, есть дополнительные ссылки, специфичные для модели жесткого диска и некоторых загрузок, а что нет, но я пока не буду следовать этому пути:
Я не буду спешить с обновлением микропрограммы трех дисков одновременно, которые имеют усеченные разделы и являются частью поврежденного пула хранения. Это напрашивается на неприятности. Для начала, обновление прошивки, скорее всего, не может быть отменено - и это может безвозвратно разрушить мои шансы вернуть мои данные.
Поэтому самое первое, что я собираюсь сделать дальше, - это образ дисков и работа с копиями, поэтому есть оригинал, к которому можно вернуться, если что-то пойдет не так. Это может создать дополнительную сложность, поскольку ZFS, вероятно, заметит, что диски были поменяны местами (с помощью серийного номера диска или еще одного UUID или чего-либо еще), даже если это точные битовые копии dd на той же модели жесткого диска. Более того, зпул даже не живет. Мальчик, это может быть сложно.
Другой вариант, однако, заключался бы в работе с оригиналами и сохранении зеркальных дисков в качестве резервной копии, но тогда я, вероятно, столкнусь со сложностью выше, когда что-то пойдет не так с оригиналами. Наа, не хорошо.
Чтобы очистить три жестких диска, которые будут служить заменой для трех дисков с неисправным BIOS в поврежденном пуле, мне нужно создать место для хранения того, что сейчас там, так что я углублюсь в аппаратный блок и собрать временный zpool из некоторых старых дисков - который я также могу использовать, чтобы проверить, как ZFS справляется с заменой дисков dd'd.
Это может занять некоторое время ...
20111213-1930 + 1100
Обновление 02:
Это действительно заняло некоторое время. Я провел месяцы с несколькими открытыми корпусами компьютеров на моем столе с различным количеством стеков жестких дисков, а также спал несколько ночей с затычками для ушей, потому что я не мог выключить машину перед сном, поскольку она выполняла какую-то длительную критическую операцию , Тем не менее, я победил наконец! :-) Я также многому научился в процессе, и я хотел бы поделиться этими знаниями здесь для любого в подобной ситуации.
Эта статья уже намного длиннее, чем у любого, у кого из файлового сервера ZFS нет времени, чтобы прочитать ее, поэтому я подробно расскажу здесь и составлю ответ с основными выводами ниже.
Я покопался глубоко в устаревшем аппаратном блоке, чтобы собрать достаточно места для хранения, чтобы перенести вещи с отдельных 500-Гбайт дисков, на которые были отражены неисправные диски. Мне также пришлось извлечь несколько жестких дисков из их USB-накопителей, чтобы я мог подключить их напрямую через SATA. Было еще несколько связанных проблем, и некоторые из старых дисков начали выходить из строя, когда я возвращал их в действие, требуя замены zpool, но я пропущу это.
Подсказка: на каком-то этапе в этом было задействовано около 30 жестких дисков. С таким большим количеством оборудования очень важно правильно расположить их; отсоединение кабелей или падение жесткого диска со стола точно не помогут в этом процессе и могут привести к дальнейшему нарушению целостности ваших данных.
Я потратил пару минут на создание некоторых картонных креплений для жестких дисков, которые действительно помогли сохранить сортировку:
По иронии судьбы, когда я подключил старые диски в первый раз, я понял, что там есть старый zpool, который я должен был создать для тестирования со старой версией некоторых, но не со всеми личными данными, которые пропали, поэтому, пока потеря данных была несколько уменьшенный, это означало дополнительное перемещение файлов вперед и назад.
Наконец, я отразил проблемные диски на резервные диски, использовал их для zpool и оставил оригинальные отключенные. Резервные диски имеют более новую прошивку, по крайней мере SeaTools не сообщает о каких-либо необходимых обновлениях прошивки. Я сделал зеркалирование с простым дд с одного устройства на другое, например
sudo dd if=/dev/sda of=/dev/sde
Я полагаю, что ZFS замечает смену аппаратного обеспечения (с помощью некоторого UUID жесткого диска или чего-то еще), но, похоже, это не волнует
Однако zpool все еще находился в том же состоянии, недостаточно реплик / поврежденных данных.
Как упоминалось в статье HPA Wikipedia, упомянутой ранее, наличие защищенной области хоста сообщается при загрузке 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, которые создали эту систему, есть все основания называть это последним словом в файловых системах. Респект!