Mam kilka TB bardzo cennych danych osobowych w zpool, do których nie mogę uzyskać dostępu z powodu uszkodzenia danych. Pula została pierwotnie skonfigurowana w 2009 roku w systemie FreeBSD 7.2 działającym na maszynie wirtualnej VMWare na systemie Ubuntu 8.04. Maszyna FreeBSD jest nadal dostępna i działa poprawnie, tylko system operacyjny hosta zmienił się teraz na Debian 6. Dyski twarde są udostępniane maszynie-gościowi za pomocą ogólnych urządzeń SCSI VMWare, w sumie 12.
Istnieją 2 baseny:
- zpool01: 2x 4x 500GB
- zpool02: 1x 4x 160 GB
Ten, który działa, jest pusty, uszkodzony ma wszystkie ważne dane:
[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
Kilka tygodni temu mogłem uzyskać dostęp do basenu. Od tego czasu musiałem wymienić prawie cały sprzęt komputera hosta i zainstalować kilka systemów operacyjnych hosta.
Podejrzewam, że jedna z tych instalacji systemu operacyjnego napisała program ładujący (lub cokolwiek) na jeden (pierwszy?) Z dysków 500 GB i zniszczył niektóre metadane Zpool (lub cokolwiek innego) - „lub cokolwiek”, co oznacza, że jest to bardzo niejasny pomysł i ten temat nie jest dokładnie moją mocną stroną ...
Istnieje wiele stron internetowych, blogów, list mailingowych itp. Na temat ZFS. Zadaję to pytanie tutaj z nadzieją, że pomoże mi zebrać wystarczającą ilość informacji do rozsądnego, uporządkowanego, kontrolowanego, poinformowanego i kompetentnego podejścia do odzyskania moich danych - i mam nadzieję, że pomoże komuś innemu w tej samej sytuacji.
Pierwszym wynikiem wyszukiwania podczas wyszukiwania hasła „zfs recovery” jest rozdział ZFS Rozwiązywanie problemów i odzyskiwanie danych z Solaris ZFS Administration Guide. W pierwszej sekcji Tryby awarii ZFS napisano w akapicie „Uszkodzone dane ZFS”:
Uszkodzenie danych jest zawsze trwałe i wymaga szczególnej uwagi podczas naprawy. Nawet jeśli podstawowe urządzenia zostaną naprawione lub wymienione, oryginalne dane zostaną utracone na zawsze.
Nieco przygnębiające.
Jednak drugim wynikiem wyszukiwania w Google jest blog Maxa Bruninga i tam czytam
Niedawno otrzymałem wiadomość e-mail od kogoś, kto miał 15 lat filmów i muzyki przechowywanych w puli ZFS o pojemności 10 TB, która po awarii zasilania uległa awarii. Niestety nie miał kopii zapasowej. Używał ZFS w wersji 6 na FreeBSD 7 [...] Po około tygodniu analizowania danych na dysku byłem w stanie przywrócić wszystko w zasadzie.
i
Jeśli chodzi o utratę danych przez ZFS, wątpię w to. Podejrzewam, że Twoje dane tam są, ale musisz znaleźć właściwy sposób na ich uzyskanie.
(to brzmi bardziej jak coś, co chcę usłyszeć ...)
Pierwszy krok : na czym dokładnie polega problem?
Jak zdiagnozować, dlaczego dokładnie zpool jest zgłaszany jako uszkodzony? Widzę, że istnieje zdb, który nie wydaje się być oficjalnie udokumentowany przez Sun ani Oracle w dowolnym miejscu w sieci. Ze strony podręcznika:
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.
Co więcej, Ben Rockwood opublikował szczegółowy artykuł, a wideo Maxa Bruninga mówi o tym (i mdb) na konferencji Open Solaris Developer Conference w Pradze 28 czerwca 2008 r.
Uruchomienie zdb jako root na zepsutym zpool daje następujące wyniki:
[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
Podejrzewam, że błąd „nieprawidłowy argument” na końcu występuje, ponieważ zpool01 tak naprawdę nie istnieje: nie występuje na działającym zpool02, ale wydaje się, że nie ma żadnych dalszych danych wyjściowych ...
OK, na tym etapie prawdopodobnie lepiej opublikować to, zanim artykuł stanie się zbyt długi.
Może ktoś może udzielić mi porady, jak przejść stąd i czekając na odpowiedź, obejrzę wideo, przejrzę szczegóły dotyczące wyjścia zdb powyżej, przeczytam artykuł Bensa i spróbuję dowiedzieć się, co jest co...
20110806-1600 + 1000
Aktualizacja 01:
Myślę, że znalazłem główną przyczynę: Max Bruning był na tyle uprzejmy, że bardzo szybko odpowiedział na mój e-mail, prosząc o wynik zdb -lll. Na każdym z 4 dysków twardych w „dobrej” połówce puli 1, wyjście jest podobne do tego, co napisałem powyżej. Jednak w przypadku pierwszych 3 z 4 dysków w „połamanej” połowie zdbraporty failed to unpack labeldla etykiet 2 i 3. Czwarty dysk w puli wydaje się OK, zdbpokazuje wszystkie etykiety.
Googlowania, że komunikat o błędzie wywołuje ten post . Od pierwszej odpowiedzi na ten post:
W przypadku ZFS są to 4 identyczne etykiety na każdym fizycznym vdev, w tym przypadku jeden dysk twardy. L0 / L1 na początku vdev i L2 / L3 na końcu vdev.
Wszystkie 8 dysków w puli jest tego samego modelu, Seagate Barracuda 500GB . Pamiętam jednak, że uruchomiłem pulę z 4 dyskami, a potem jeden z nich zmarł i został zastąpiony przez Seagate na gwarancji. Później dodałem kolejne 4 dyski. Z tego powodu identyfikatory napędu i oprogramowania układowego są różne:
[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
Pamiętam jednak, że wszystkie dyski miały ten sam rozmiar. Patrząc teraz na dyski, pokazuje, że rozmiar zmienił się dla trzech z nich, zmniejszyły się o 2 MB:
[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)
Wygląda więc na to, że nie była to jedna z instalacji systemu operacyjnego, która „napisała bootloader na jednym z dysków” (jak wcześniej zakładałem), tak naprawdę była to nowa płyta główna ( ASUS P8P67 LE ) tworząca host o pojemności 2 MB obszar chroniony na końcu trzech dysków, które pomieszały moje metadane ZFS.
Dlaczego nie stworzył HPA na wszystkich dyskach? Wierzę, że dzieje się tak, ponieważ tworzenie HPA odbywa się tylko na starszych dyskach z błędem, który został naprawiony później przez aktualizację BIOS dysku twardego Seagate: Gdy cały ten incydent zaczął się kilka tygodni temu, uruchomiłem narzędzie Seagate SeaTools, aby sprawdzić, czy jest coś fizycznie nie tak z napędami (wciąż na starym sprzęcie) i dostałem komunikat informujący, że niektóre z moich napędów wymagają aktualizacji BIOS-u. Gdy próbuję teraz odtworzyć dokładne szczegóły tego komunikatu oraz łącze do pobrania aktualizacji oprogramowania układowego, wydaje się, że skoro płyta główna utworzyła HPA, obie wersje DOS SeaTools nie wykrywają danych dysków twardych - szybkie invalid partitionlub podobne miga, gdy zaczynają, to wszystko. Jak na ironię, znajdują oni zestaw napędów Samsung.
(Pominąłem bolesne, czasochłonne i ostatecznie bezowocne szczegóły wkręcania się w powłokę FreeDOS w systemie niesieciowym). Ostatecznie zainstalowałem Windows 7 na osobnej maszynie, aby uruchomić Windows SeaTools wersja 1.2.0.5. Ostatnia uwaga na temat DOS SeaTools: nie zawracaj sobie głowy próbą uruchomienia ich samodzielnie - zamiast tego zainwestuj kilka minut i stwórz bootowalną pamięć USB z niesamowitą płytą Ultimate Boot CD - która oprócz DOS SeaTools daje ci również wiele innych naprawdę użyteczne narzędzia.
Po uruchomieniu SeaTools dla Windows wyświetla następujące okno dialogowe:
Łącza prowadzą do narzędzia do sprawdzania numeru seryjnego (który z jakiegoś powodu jest chroniony przez captcha - „Invasive users”) i artykułu bazy wiedzy na temat aktualizacji oprogramowania układowego. Prawdopodobnie istnieją dalsze linki specyficzne dla modelu dysku twardego i niektórych plików do pobrania, a co nie, ale na razie nie podążę tą ścieżką:
Nie będę spieszył się z aktualizowaniem oprogramowania wewnętrznego trzech dysków naraz, które mają obcięte partycje i są częścią uszkodzonej puli pamięci. To prosi o kłopoty. Po pierwsze, aktualizacji oprogramowania najprawdopodobniej nie można cofnąć - a to nieodwracalnie zrujnuje moje szanse na odzyskanie danych.
Dlatego pierwszą rzeczą, którą zamierzam zrobić, to zobrazować dyski i pracować z kopiami, więc jest oryginał, do którego można wrócić, jeśli coś pójdzie nie tak. Może to wprowadzić dodatkową złożoność, ponieważ ZFS prawdopodobnie zauważy, że dyski zostały zamienione (za pomocą numeru seryjnego dysku lub jeszcze innego UUID lub cokolwiek innego), nawet jeśli są to dokładne bity kopie dd na ten sam model dysku twardego. Co więcej, zpool nawet nie działa. Chłopcze, może to być trudne.
Inną opcją byłoby jednak praca z oryginałami i zachowanie kopii zapasowych dysków jako kopii zapasowej, ale prawdopodobnie napotkam na większą złożoność, gdy coś pójdzie nie tak z oryginałami. Nie, nie dobrze.
Aby wyczyścić trzy dyski twarde, które będą służyć jako obrazowe zamienniki trzech dysków z wadliwym BIOS-em w uszkodzonej puli, muszę stworzyć miejsce do przechowywania rzeczy, które są tam teraz, więc zagłębię się głęboko sprzętu i zmontuj tymczasowe zpool ze starych dysków - których mogę również użyć do przetestowania, jak ZFS radzi sobie z zamianą dysków dd'd.
To może zająć chwilę...
20111213–1930 + 1100
Aktualizacja 02:
Zajęło to naprawdę trochę czasu. Spędziłem miesiące z kilkoma otwartymi obudowami komputerów na biurku z różnymi ilościami stosów dysków twardych, a także spałem kilka nocy z zatyczkami do uszu, ponieważ nie mogłem wyłączyć urządzenia przed pójściem spać, ponieważ trwało ono przez długi czas krytyczna operacja . W końcu zwyciężyłem! :-) Wiele się też nauczyłem i chciałbym podzielić się tą wiedzą tutaj dla każdego w podobnej sytuacji.
Ten artykuł jest już znacznie dłuższy niż ktokolwiek z serwerem plików ZFS, który nie działa, ma czas na przeczytanie, więc przejdę tutaj do szczegółów i dam odpowiedź z niezbędnymi ustaleniami w dalszej części.
Wykopałem głęboko w przestarzałym pudełku sprzętowym, aby zebrać wystarczającą ilość miejsca do przechowywania rzeczy z pojedynczych dysków 500 GB, na których dublowane były wadliwe dyski. Musiałem też wyrwać kilka dysków twardych z ich obudów USB, aby móc podłączyć je bezpośrednio przez SATA. Były jeszcze inne, niezwiązane z tym problemy, a niektóre stare dyski zaczęły się psuć, kiedy włączyłem je z powrotem do działania wymagającego wymiany Zpool, ale pominę to.
Wskazówka: na pewnym etapie było w to zaangażowanych około 30 dysków twardych. Przy tak dużym sprzęcie ogromną pomocą jest ich prawidłowe ułożenie; luźne kable lub wypadnięcie dysku twardego z biurka z pewnością nie pomoże w tym procesie i może spowodować dalsze uszkodzenie integralności danych.
Poświęciłem kilka minut na tworzenie kartonowych urządzeń typu make-shift, które naprawdę pomogły utrzymać porządek:
Jak na ironię, kiedy po raz pierwszy podłączyłem stare dyski, zdałem sobie sprawę, że jest tam stary zpool, który musiałem stworzyć do testowania ze starszą wersją niektórych, ale nie wszystkich danych osobowych, które zaginęły, więc podczas utraty danych nieco zmniejszony, oznaczało to dodatkowe przesuwanie plików do przodu i do tyłu.
Wreszcie dublowałem problematyczne dyski na dyski zapasowe, użyłem tych dla Zpool i pozostawiłem oryginalne odłączone. Dyski kopii zapasowych mają nowsze oprogramowanie układowe, przynajmniej SeaTools nie zgłasza wymaganych aktualizacji oprogramowania układowego. Zrobiłem dublowanie za pomocą prostego dd z jednego urządzenia na drugie, np
sudo dd if=/dev/sda of=/dev/sde
Uważam, że ZFS zauważa zmianę sprzętu (przez UUID dysku twardego lub cokolwiek innego), ale wydaje się, że to nie obchodzi.
Zpool był jednak nadal w tym samym stanie, niewystarczająca liczba replik / uszkodzonych danych.
Jak wspomniano w wcześniej wspomnianym artykule na temat HPA Wikipedia , obecność obszaru chronionego przez hosta jest zgłaszana podczas uruchamiania systemu Linux i można to zbadać za pomocą hdparm . O ile mi wiadomo, na FreeBSD nie ma dostępnego narzędzia hdparm, ale do tej pory miałem FreeBSD 8.2 i Debian 6.0 zainstalowane jako system podwójnego rozruchu, więc uruchomiłem system 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
...
Problem polegał więc oczywiście na tym, że nowa płyta główna stworzyła HPA na poziomie kilku megabajtów na końcu dysku, który „ukrył” dwie górne etykiety ZFS, tj. Uniemożliwił ZFS ich zobaczenie.
Dabing z HPA wydaje się niebezpiecznym biznesem. Na stronie podręcznika hdparm parametr -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.
...
W moim przypadku HPA jest usuwany w następujący sposób:
user@host:~$ sudo hdparm -Np976773168 /dev/sde
/dev/sde:
setting max visible sectors to 976773168 (permanent)
max sectors = 976773168/976773168, HPA is disabled
i w ten sam sposób dla innych dysków z HPA. Jeśli otrzymasz niewłaściwy dysk lub coś w parametrze rozmiaru, który podałeś, nie jest prawdopodobne, hdparm jest wystarczająco inteligentny, aby stwierdzić:
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.
Następnie zrestartowałem maszynę wirtualną FreeBSD 7.2, na której pierwotnie utworzono zpool, a status zpool ponownie zgłosił działającą pulę. TAK! :-)
Wyeksportowałem pulę do systemu wirtualnego i ponownie zaimportowałem ją do hosta FreeBSD 8.2.
Kilka innych poważniejszych aktualizacji sprzętu, kolejna zamiana płyty głównej, aktualizacja puli ZFS do ZFS 4/15, dokładne czyszczenie i teraz mój zpool składa się z 8x1 TB i 8x500GB części 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
Na koniec wydaje mi się, że pule ZFS są bardzo, bardzo trudne do zabicia. Faceci z Sun, którzy stworzyli ten system, mają powód, dla którego nazywają go ostatnim słowem w systemach plików. Szacunek!