У мене є кілька туберкульозів дуже цінних особистих даних у зоопарку, до яких я не можу отримати доступ через корупцію даних. Спочатку пул був створений ще в 2009 році або близько того на системі FreeBSD 7.2, що працює у віртуальній машині VMWare поверх системи Ubuntu 8.04. FreeBSD VM все ще доступний і працює нормально, лише хост ОС змінився на Debian 6. Жорсткі диски робляться доступними для запрошеного VM за допомогою загальних пристроїв SCSI VMWare, загалом 12.
Є 2 басейни:
- zpool01: 2x 4x 500GB
- zpool02: 1x 4x 160GB
Той, хто працює, порожній, зламаний містить усі важливі дані:
[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 існує багато веб-сайтів, блогів, списків розсилки тощо. Я розміщую це запитання тут, сподіваючись, що це допоможе мені зібрати достатньо інформації для розумного, структурованого, контрольованого, поінформованого підходу, щоб повернути мої дані - і, сподіваємось, допомогти комусь іншому там у тій же ситуації.
Перший результат пошуку під час googling для 'zfs recovery' - це розділ щодо усунення несправностей та відновлення даних ZFS з Посібника з адміністрації Solaris ZFS. У першому розділі режимів відмов ZFS в розділі "Пошкоджені дані ZFS" зазначено:
Корупція даних завжди є постійною і потребує особливої уваги під час ремонту. Навіть якщо основні пристрої відремонтовані або замінені, вихідні дані втрачаються назавжди.
Дещо зневажливо.
Однак другий результат пошуку в Google - це веб-журнал Макса Брунінга, і я там прочитав
Нещодавно мені надіслали електронний лист від того, хто 15 років зберігав відео та музику в пулі ZFS 10 ТБ, який після відключення електроенергії став несправним. У нього, на жаль, не було резервного копіювання. Він використовував ZFS версії 6 на FreeBSD 7 [...] Провівши близько 1 тижня на вивчення даних на диску, я зміг відновити все це.
і
Що стосується втрати вами даних ZFS, я сумніваюся. Я підозрюю, що ваші дані є, але вам потрібно знайти правильний спосіб отримати їх.
(це звучить набагато більше, як щось, що я хочу почути ...)
Перший крок : Яка саме проблема?
Як я можу діагностувати, чому саме зоопарк повідомляється про пошкоджений? Я бачу, є 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) на Відкритій конференції розробників Solaris у Празі 28 червня 2008 року.
Запуск zdb як кореня на розбитому 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 жорстких дисків у «хорошій» половині пулу, вихід виходить аналогічним тому, що я розмістив вище. Однак на перших 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: Коли весь цей інцидент розпочався пару тижнів тому, я запустив SeaTools Seagate, щоб перевірити, чи є нічого фізично не в порядку з накопичувачами (все ще на старому апаратному забезпеченні), і я отримав повідомлення про те, що для деяких моїх дисків потрібне оновлення BIOS. Оскільки я зараз намагаюся відтворити точні деталі цього повідомлення та посилання на завантаження оновлення прошивки, схоже, що оскільки материнська плата створила HPA, обидві версії DOS SeaTools не змогли виявити спірний жорсткий диск - швидкий invalid partitionабо щось подібне спалахує, коли вони починаються, ось і все. Як не дивно, вони все ж знаходять набір накопичувачів Samsung.
(Я пропустив болючі, трудомісткі і в кінцевому рахунку безрезультатні деталі вкручування оболонки FreeDOS в немережевій системі.) Зрештою, я встановив Windows 7 на окрему машину для того, щоб запустити SeaTools Windows версія 1.2.0.5. Лише останнє зауваження про DOS SeaTools: Не турбуйтеся намагатися завантажувати їх самостійно - замість цього вкладіть пару хвилин і зробіть завантажувальний USB-накопичувач із дивовижним компакт-диском для завантаження - який, окрім 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 , про наявність захищеної зони хоста повідомляється, коли 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 здається небезпечним бізнесом. На сторінці man-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 від того, хто створив цю систему, мають усі підстави називати її останнім словом у файлових системах. Повага!