ZFS na FreeBSD: odzyskiwanie po uszkodzeniu danych

44

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                          \
  [email protected]:/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:

Okno dialogowe aktualizacji oprogramowania układowego SeaTools

Łą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:

część prowizorycznego miejsca do przechowywania tylko kilka śrubek i trochę kartonu wentylator nie jest dokładnie wymagany, stos pochodzi z wcześniejszego projektu elementy odległościowe nie są również wymagane ...

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!

ssc
źródło
2
Zanim cokolwiek zrobisz, wyobraź sobie te dyski! Zrób kopię zapasową „uszkodzonych” danych na wypadek, gdybyś pogorszył sytuację.
MikeyB,
tak, to bardzo dobra uwaga! i jest to również powód, dla którego nie zaktualizowałem jeszcze tego artykułu o moich postępach - wciąż jestem zajęty czyszczeniem zastępczych dysków twardych ...
ssc

Odpowiedzi:

24

Problem polegał na tym, że system BIOS nowej płyty głównej utworzył na niektórych dyskach obszar chroniony przez hosta (HPA), niewielką sekcję używaną przez producentów OEM do odzyskiwania systemu, zwykle umieszczoną na końcu dysku twardego.

ZFS utrzymuje 4 etykiety z meta informacjami o partycjach, a HPA uniemożliwia ZFS zobaczenie dwóch górnych.

Rozwiązanie: Uruchom system Linux, użyj hdparm, aby sprawdzić i usunąć HPA. Bądź bardzo ostrożny, może to łatwo zniszczyć twoje dane na dobre. Szczegółowe informacje można znaleźć w artykule i na stronie podręcznika hdparm (parametr -N).

Problem pojawił się nie tylko w przypadku nowej płyty głównej, miałem podobny problem podczas podłączania napędów do karty kontrolera SAS. Rozwiązanie jest takie samo.

ssc
źródło
5

Pierwszą rzeczą, którą poleciłbym zrobić, jest zdobycie dodatkowych dysków twardych i zrobienie zduplikowanych kopii 8 dysków, które masz z danymi na nich, za pomocą ddpolecenia. W ten sposób, jeśli podejmując próby ich odzyskania, pogorszysz sytuację, nadal możesz wrócić do tego poziomu wyjściowego.

Zrobiłem to już wcześniej i były chwile, kiedy tego nie potrzebowałem, ale czasy, których potrzebowałem, sprawiły, że było to całkowicie warte wysiłku.

Nie pracuj bez siatki.

Sean Reifschneider
źródło
Właściwie poleciłbym ddrescueponad dd. Nie działa tak naprawdę inaczej, gdy dyski działają idealnie (ale daje dobre wskazanie postępu), ale jeśli występują jakieś problematyczne sektory lub coś takiego, ddrescue radzi sobie z tą sytuacją znacznie lepiej niż dd (a przynajmniej ja powiedziano mi).
CVn
2

Wygląda na to, że jesteś na dobrej drodze do rozwiązania tego problemu. Jeśli chcesz mieć inny, możliwy nowszy punkt widzenia, możesz wypróbować Live CD Solaris 11 Express. Prawdopodobnie działa tam dużo nowszy kod (zpool w Solarisie jest teraz w wersji 31, podczas gdy jesteś w wersji 6) i może oferować lepsze możliwości odzyskiwania. Nie uruchamiaj jednak w zpool upgradesystemie Solaris, jeśli chcesz zachować pulę do zamontowania w systemie FreeBSD.

Jakob Borg
źródło
Dzięki za tę wskazówkę! :-) Przyglądałem się OpenSolarisowi mniej więcej w 2009 roku, kiedy zaczynałem cały biznes ZFS, ale niestety nie obsługiwał kontrolerów, których używam - w końcu jest to sprzęt klasy konsumenckiej. Niedawno przyjrzałem się również OpenIndiana, ale nie jestem pewien, czy sytuacja się zmieniła. Na pewnym etapie mogę zaktualizować kontrolery do SAS i rozważyć migrację.
ssc
Myślę, że OpenIndiana może być wart nowego wyglądu. Jeśli nic więcej, mogą być bardziej przyjazne dla „taniego” sprzętu niż Oracle ... Poleciłem Live CD, ponieważ można go wypróbować - można go również uruchomić na maszynie wirtualnej.
Jakob Borg,
1

Listy mailingowe FreeBSD mogą być dobrym punktem wyjścia do wyszukiwania. Pamiętam, że widziałem podobne żądania w FreeBSD-Stable i -Current. W zależności od znaczenia danych możesz jednak skontaktować się z profesjonalną firmą zajmującą się odzyskiwaniem danych, ponieważ manipulowanie niedostępnymi pulami pamięci masowej niesie ze sobą dużą szansę na pogorszenie sytuacji.

Andreas Turriff
źródło
1

Podobny problem wystąpił po aktualizacji z FreeBSD 10.3 do 11.1, potem zpool był uszkodzony i nie było sposobu na odzyskanie danych, mimo że zdb -lllwszystkie cztery etykiety były prawidłowe.

Okazuje się, że w jakiś sposób aktualizacja spowodowała, że ​​sterowniki zarządzania pamięcią masową firmy Intel utworzyły miękkie dyski dublujące z dysków (być może było włączone, ale nie obsługiwane przez geomdostawcę Intela do czasu po aktualizacji?) I że zablokowało ZFS montowanie dysków.

Podłączanie ich do innego komputera z włączonym oprogramowaniem rozruchowym Intel RST i wyłączanie dysku twardego ( bardzo ważne: istnieją dwa sposoby na przerwanie dysku twardego, którego domyślne ustawienie inicjuje (inaczej formaty!) Dyski. Musisz wybrać opcję wyłącz bez dotykania danych), a następnie pozwól ZFS rozpoznać pierwszy dysk w kopii lustrzanej, chociaż nic, co zrobiłem, nie pozwoliłoby mu zidentyfikować pozostałych dysków jako tych samych, które były w aktualizacji wstępnej komputera. Na szczęście był to lustrzany zpool i mogłem po prostu odłączyć dyski i ponownie je podłączyć do odpowiedniej puli, a resilver zakończył się bez zdarzenia.

Uwaga dodatkowa: W moim przypadku hdparm(działający z Live Ubuntu Server ISO) zgłosił, że HBA został wyłączony na wszystkich dyskach i nie był w stanie pomóc.

Mahmoud Al-Qudsi
źródło
-2

jeśli byłby to tylko problem z partycją, dodałbym partycje dysku + MBR i po prostu ustawiłem odpowiedni rozmiar partycji ...

jeśli nie sformatujesz partycji, tworząc lub zmieniając tablicę partycji, nie ma to żadnego wpływu (więc możesz to cofnąć!), dopóki nie ma formatu, wówczas większość danych jest nadal dostępna / dostępna, jeśli nowa partycja jest włożona na końcu dysku możesz mieć uszkodzone pliki tam, gdzie nowe rzeczy zostały napisane jako trudne, dlatego jedyną dobrą rzeczą do tej sztuczki jest formatowanie (nowy mbr, tabela plików itp.)

npn
źródło