Saya memiliki beberapa TB data pribadi yang sangat berharga di zpool yang tidak dapat saya akses karena korupsi data. Kumpulan awalnya dibuat pada tahun 2009 atau lebih pada sistem FreeBSD 7.2 yang berjalan di dalam mesin virtual VMWare di atas sistem Ubuntu 8.04. VM FreeBSD masih tersedia dan berfungsi dengan baik, hanya OS host yang sekarang telah berubah menjadi Debian 6. Hard drive dibuat dapat diakses oleh VM tamu melalui perangkat VMWare SCSI generik, total 12.
Ada 2 kolam:
- zpool01: 2x 4x 500GB
- zpool02: 1x 4x 160GB
Yang berfungsi kosong, yang rusak menampung semua data penting:
[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
Saya dapat mengakses kolam beberapa minggu yang lalu. Sejak itu, saya harus mengganti hampir semua perangkat keras mesin host dan menginstal beberapa sistem operasi host.
Kecurigaan saya adalah bahwa salah satu instalasi OS ini menulis bootloader (atau apa pun) ke salah satu (yang pertama?) Dari drive 500GB dan menghancurkan beberapa metadata zpool (atau apa pun) - 'atau apa pun' yang berarti bahwa ini hanya ide yang sangat kabur dan subjek itu bukan sisi kuatku ...
Ada banyak situs web, blog, milis, dll. Tentang ZFS. Saya memposting pertanyaan ini di sini dengan harapan dapat membantu saya mengumpulkan informasi yang cukup untuk pendekatan yang waras, terstruktur, terkontrol, informasi, dan berpengetahuan untuk mendapatkan kembali data saya - dan semoga membantu orang lain di luar sana dalam situasi yang sama.
Hasil pencarian pertama saat googling untuk 'zfs recover' adalah bab Pemecahan Masalah dan Pemulihan Data ZFS dari Solaris ZFS Administration Guide. Di bagian Mode Kegagalan ZFS pertama , dikatakan di paragraf 'Data ZFS terkorupsi':
Korupsi data selalu permanen dan memerlukan pertimbangan khusus selama perbaikan. Bahkan jika perangkat yang mendasarinya diperbaiki atau diganti, data asli hilang selamanya.
Agak mengecewakan.
Namun, hasil pencarian google kedua adalah weblog Max Bruning dan di sana, saya membaca
Baru-baru ini, saya dikirimi email dari seseorang yang memiliki 15 tahun video dan musik yang disimpan dalam kumpulan ZFS 10TB yang, setelah listrik mati, menjadi rusak. Sayangnya dia tidak memiliki cadangan. Dia menggunakan ZFS versi 6 pada FreeBSD 7 [...] Setelah menghabiskan sekitar 1 minggu memeriksa data pada disk, pada dasarnya saya dapat mengembalikan semuanya.
dan
Adapun ZFS kehilangan data Anda, saya meragukannya. Saya menduga data Anda ada di sana, tetapi Anda perlu menemukan cara yang tepat untuk mendapatkannya.
(Kedengarannya jauh lebih seperti sesuatu yang ingin saya dengar ...)
Langkah pertama : Apa sebenarnya masalahnya?
Bagaimana saya bisa mendiagnosis mengapa zpool dilaporkan rusak? Saya melihat ada zdb yang sepertinya tidak didokumentasikan secara resmi oleh Sun atau Oracle di manapun di web. Dari halaman manualnya:
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.
Selanjutnya, Ben Rockwood telah memposting artikel terperinci dan ada video Max Bruning membicarakannya (dan mdb) di Open Solaris Developer Conference di Praha pada 28 Juni 2008.
Menjalankan zdb sebagai root pada zpool yang rusak memberikan output berikut:
[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
Saya kira kesalahan 'argumen tidak valid' pada akhirnya terjadi karena zpool01 sebenarnya tidak ada: Itu tidak terjadi pada zpool02 yang berfungsi, tetapi sepertinya tidak ada output lebih lanjut ...
OK, pada tahap ini, mungkin lebih baik untuk memposting ini sebelum artikel terlalu panjang.
Mungkin seseorang dapat memberi saya beberapa saran tentang bagaimana untuk bergerak maju dari sini dan sementara saya menunggu tanggapan, saya akan menonton video, melihat rincian output zdb di atas, membaca artikel Bens dan mencoba mencari tahu apa apa...
20110806-1600 + 1000
Pembaruan 01:
Saya pikir saya telah menemukan akar penyebabnya: Max Bruning cukup baik untuk menanggapi email saya dengan sangat cepat, meminta hasilnya zdb -lll. Pada salah satu dari 4 hard drive di raidz1 'baik' setengah dari kolam, hasilnya mirip dengan apa yang saya posting di atas. Namun, pada 3 pertama dari 4 drive di 'rusak' setengah, zdbmelaporkan failed to unpack labeluntuk label 2 dan 3. Drive keempat di kelompok tampaknya OK, zdbmenunjukkan semua label.
Googling bahwa pesan kesalahan menampilkan pos ini . Dari respons pertama ke pos itu:
Dengan ZFS, itu adalah 4 label identik pada setiap vdev fisik, dalam hal ini satu hard drive. L0 / L1 pada awal vdev, dan L2 / L3 pada akhir vdev.
Semua 8 drive di kolam renang adalah dari model yang sama, Seagate Barracuda 500GB . Namun, saya ingat saya memulai kolam dengan 4 drive, kemudian salah satunya mati dan diganti dengan garansi oleh Seagate. Kemudian, saya menambahkan 4 drive lagi. Karenanya, pengidentifikasi drive dan firmware berbeda:
[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
Saya ingat bahwa semua drive memiliki ukuran yang sama. Melihat drive sekarang, itu menunjukkan bahwa ukuran telah berubah untuk mereka bertiga, mereka telah menyusut sebesar 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)
Jadi dari penampilannya, bukan salah satu dari instalasi OS yang 'menulis bootloader ke salah satu drive' (seperti yang saya asumsikan sebelumnya), sebenarnya itu adalah motherboard baru ( ASUS P8P67 LE ) yang menciptakan host 2 MB area terlindungi pada akhir tiga drive yang mengacaukan metadata ZFS saya.
Mengapa tidak membuat HPA di semua drive? Saya percaya ini karena kreasi HPA hanya dilakukan pada drive yang lebih lama dengan bug yang diperbaiki kemudian oleh pembaruan BIOS hard drive Seagate: Ketika seluruh insiden ini dimulai beberapa minggu yang lalu, saya menjalankan SeaTools Seagate untuk memeriksa apakah ada secara fisik ada yang salah dengan drive (masih pada perangkat keras lama) dan saya mendapat pesan yang mengatakan bahwa beberapa drive saya memerlukan pembaruan BIOS. Saat saya sekarang mencoba mereproduksi detail yang tepat dari pesan itu dan tautan ke unduhan pembaruan firmware, sepertinya sejak motherboard menciptakan HPA, kedua SeaTools versi DOS gagal mendeteksi harddisk yang dimaksud - cepat invalid partitionatau serupa berkedip ketika mereka mulai, itu saja. Ironisnya, mereka menemukan satu set drive Samsung.
(Saya telah melewatkan rincian menyakitkan, memakan waktu, dan akhirnya sia-sia mengacaukan dalam shell FreeDOS pada sistem non-jaringan.) Pada akhirnya, saya menginstal Windows 7 pada mesin yang terpisah untuk menjalankan SeaTools Windows versi 1.2.0.5. Hanya komentar terakhir tentang DOS SeaTools: Jangan repot-repot mencoba untuk mem-bootnya sendiri - sebagai gantinya, investasikan beberapa menit dan buat USB stick yang dapat di-boot dengan Ultimate Boot CD yang mengagumkan - yang selain dari DOS SeaTools juga membuat Anda banyak yang lain alat yang berguna.
Ketika dimulai, SeaTools untuk Windows membuka dialog ini:
Tautan mengarah ke Pemeriksa Nomor Seri (yang karena alasan tertentu dilindungi oleh captcha - mine adalah 'Pengguna invasif') dan artikel basis pengetahuan tentang pembaruan firmware. Mungkin ada tautan lebih lanjut yang spesifik untuk model hard drive dan beberapa unduhan dan yang tidak, tapi saya tidak akan mengikuti jalur itu untuk saat ini:
Saya tidak akan tergesa-gesa memperbarui firmware dari tiga drive pada waktu yang telah memotong partisi dan merupakan bagian dari kumpulan penyimpanan yang rusak. Itu meminta masalah. Sebagai permulaan, pembaruan firmware kemungkinan besar tidak dapat diurungkan - dan itu mungkin akan merusak peluang saya untuk mendapatkan kembali data saya.
Oleh karena itu, hal pertama yang akan saya lakukan selanjutnya adalah gambar drive dan bekerja dengan salinan, jadi ada yang asli untuk kembali ke jika ada masalah. Ini mungkin memperkenalkan kompleksitas tambahan, karena ZFS mungkin akan melihat bahwa drive ditukar (melalui nomor seri drive atau UUID lain atau apa pun), meskipun itu adalah salinan dd bit-persis ke model hard drive yang sama. Selain itu, zpool bahkan tidak hidup. Wah, ini mungkin rumit.
Namun pilihan lain adalah bekerja dengan yang asli dan menyimpan drive yang dicerminkan sebagai cadangan, tapi kemudian saya mungkin akan mengalami kompleksitas di atas ketika ada yang salah dengan aslinya. Naa, tidak bagus.
Untuk menghapus tiga hard drive yang akan berfungsi sebagai pengganti gambar untuk tiga drive dengan BIOS kereta di kolam rusak, saya perlu membuat beberapa ruang penyimpanan untuk barang-barang yang ada di sana sekarang, jadi saya akan menggali lebih dalam kotak perangkat keras dan merakit zpool sementara dari beberapa drive lama - yang juga dapat saya gunakan untuk menguji bagaimana ZFS menangani swapping dd'd drive.
Ini mungkin memakan waktu cukup lama ...
20111213-1930 + 1100
Perbarui 02:
Ini memang memakan waktu cukup lama. Saya telah menghabiskan waktu berbulan-bulan dengan beberapa kasing komputer terbuka di meja saya dengan berbagai jumlah tumpukan harddisk yang nongkrong dan juga tidur beberapa malam dengan penyumbat telinga, karena saya tidak dapat mematikan mesin sebelum tidur karena sedang menjalankan beberapa operasi kritis yang panjang . Namun, akhirnya aku menang! :-) Saya juga belajar banyak dalam proses dan saya ingin membagikan pengetahuan itu di sini untuk siapa pun dalam situasi yang sama.
Artikel ini sudah jauh lebih lama daripada siapa pun yang tidak memiliki server file ZFS untuk membaca, jadi saya akan masuk ke detail di sini dan membuat jawaban dengan temuan penting lebih lanjut di bawah ini.
Saya menggali jauh di dalam kotak perangkat keras yang sudah usang untuk mengumpulkan ruang penyimpanan yang cukup untuk memindahkan barang-barang dari drive 500GB tunggal yang dicerminkan oleh drive yang rusak. Saya juga harus merobek beberapa hard drive dari case USB mereka, sehingga saya dapat menghubungkannya melalui SATA secara langsung. Ada beberapa masalah lain yang tidak terkait yang terlibat dan beberapa drive lama mulai gagal ketika saya mengembalikannya ke tindakan yang memerlukan penggantian zpool, tetapi saya akan melewatkannya.
Tip: Pada tahap tertentu, ada total sekitar 30 hard drive yang terlibat dalam hal ini. Dengan perangkat keras sebanyak itu, sangat membantu untuk membuatnya ditumpuk dengan benar; kabel lepas atau hard drive jatuh dari meja Anda pasti tidak akan membantu dalam proses dan dapat menyebabkan kerusakan lebih lanjut pada integritas data Anda.
Saya menghabiskan beberapa menit untuk membuat beberapa perlengkapan hard drive kardus make-shift yang benar-benar membantu menjaga hal-hal diurutkan:
Ironisnya, ketika saya menghubungkan drive lama pertama kali, saya menyadari ada zpool tua di sana yang saya harus buat untuk pengujian dengan versi yang lebih lama dari beberapa, tetapi tidak semua data pribadi yang hilang, jadi sementara kehilangan data adalah agak berkurang, ini berarti tambahan bolak-balik file.
Akhirnya, saya merefleksikan drive yang bermasalah ke drive cadangan, menggunakannya untuk zpool dan meninggalkan yang asli terputus. Drive cadangan memiliki firmware yang lebih baru, setidaknya SeaTools tidak melaporkan pembaruan firmware yang diperlukan. Saya melakukan mirroring dengan dd sederhana dari satu perangkat ke perangkat lainnya, mis
sudo dd if=/dev/sda of=/dev/sde
Saya percaya ZFS memang memperhatikan perubahan perangkat keras (oleh beberapa UUID hard drive atau apa pun), tetapi tampaknya tidak peduli.
Namun zpool masih dalam keadaan yang sama, replika / data yang rusak tidak memadai.
Seperti yang disebutkan dalam artikel Wikipedia HPA yang disebutkan sebelumnya, keberadaan area yang dilindungi host dilaporkan saat Linux melakukan booting dan dapat diselidiki menggunakan hdparm . Sejauh yang saya tahu, tidak ada alat hdparm yang tersedia di FreeBSD, tetapi pada saat ini, saya tetap menginstal FreeBSD 8.2 dan Debian 6.0 sebagai sistem dual-boot, jadi saya boot ke 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
...
Jadi masalahnya jelas adalah bahwa motherboard baru menciptakan HPA dari beberapa megabita pada akhir drive yang 'menyembunyikan' dua label ZFS atas, yaitu mencegah ZFS melihat mereka.
Berkecimpung dengan HPA tampaknya bisnis yang berbahaya. Dari halaman manual hdparm, parameter -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.
...
Dalam kasus saya, HPA dihapus seperti ini:
user@host:~$ sudo hdparm -Np976773168 /dev/sde
/dev/sde:
setting max visible sectors to 976773168 (permanent)
max sectors = 976773168/976773168, HPA is disabled
dan dengan cara yang sama untuk drive lain dengan HPA. Jika Anda mendapatkan drive yang salah atau sesuatu tentang parameter ukuran yang Anda tentukan tidak masuk akal, hdparm cukup pintar untuk menggambarkan:
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.
Setelah itu, saya menyalakan kembali mesin virtual FreeBSD 7.2 yang pada awalnya dibuat zpool dan status zpool melaporkan kolam yang berfungsi kembali. YAY! :-)
Saya mengekspor kumpulan pada sistem virtual dan mengimpor kembali pada sistem host FreeBSD 8.2.
Beberapa peningkatan perangkat keras yang lebih utama, motherboard lain swap, pembaruan ZFS pool ke ZFS 4/15, scrubbing menyeluruh dan sekarang zpool saya terdiri dari 8x1TB plus 8x500GB bagian 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
Sebagai kata terakhir, menurut saya kolam ZFS sangat, sangat sulit untuk dibunuh. Orang-orang dari Sun yang menciptakan sistem itu memiliki semua alasan menyebutnya sebagai kata terakhir dalam sistem file. Menghormati!
Jawaban:
Masalahnya adalah bahwa motherboard BIOS baru menciptakan area yang dilindungi host (HPA) pada beberapa drive, bagian kecil yang digunakan oleh OEM untuk tujuan pemulihan sistem, biasanya terletak di ujung harddisk.
ZFS menyimpan 4 label dengan informasi meta partisi dan HPA mencegah ZFS melihat dua label teratas.
Solusi: Boot Linux, gunakan hdparm untuk memeriksa dan menghapus HPA. Berhati-hatilah, ini bisa menghancurkan data Anda untuk selamanya. Baca artikel dan halaman manual hdparm (parameter -N) untuk detailnya.
Masalahnya tidak hanya terjadi pada motherboard baru, saya memiliki masalah serupa ketika menghubungkan drive ke kartu pengontrol SAS. Solusinya sama.
sumber
Hal pertama yang saya sarankan Anda lakukan adalah mendapatkan lebih banyak hard drive dan membuat salinan duplikat dari 8 drive yang Anda miliki dengan data Anda pada mereka, menggunakan
ddperintah. Dengan begitu, jika dalam upaya Anda untuk memulihkannya, Anda malah memperburuk keadaan, Anda masih bisa kembali ke garis dasar ini.Saya sudah melakukan ini sebelumnya dan ada saat-saat saya tidak membutuhkannya, tetapi saat saya memang membutuhkannya membuatnya benar-benar sepadan dengan usaha.
Jangan bekerja tanpa jaring.
sumber
ddrescuelebihdd. Itu tidak benar-benar bekerja jauh berbeda ketika drive berfungsi dengan sempurna (tapi itu memberi Anda indikasi kemajuan yang bagus) tetapi jika ada sektor yang bermasalah atau sesuatu seperti itu, ddrescue menangani situasi itu jauh lebih baik daripada dd tidak (atau jadi saya sudah diberitahu).Anda tampaknya berada di jalur untuk menyelesaikan ini. Jika Anda menginginkan yang lain, kemungkinan sudut pandang yang lebih baru Anda dapat mencoba CD live Solaris 11 Express. Kemungkinan ada banyak kode baru yang berjalan di sana (zpool di Solaris sekarang di versi 31, sedangkan Anda berada di versi 6) dan mungkin menawarkan kemungkinan pemulihan yang lebih baik. Jangan lari di
zpool upgradebawah Solaris jika Anda ingin agar kolam tetap dapat dipasang di bawah FreeBSD.sumber
Milis FreeBSD mungkin merupakan titik awal yang baik untuk pencarian Anda. Saya ingat pernah melihat permintaan serupa lewat di FreeBSD-Stable dan -Current. Bergantung pada pentingnya data Anda, Anda mungkin ingin menghubungi perusahaan pemulihan profesional, karena mengutak-atik kumpulan penyimpanan data yang tidak dapat diakses membawa peluang bagus untuk memperburuk keadaan.
sumber
Saya mengalami masalah yang sama setelah memutakhirkan dari FreeBSD 10.3 ke 11.1, setelah itu zpool rusak dan tidak ada cara untuk memulihkan data, meskipun
zdb -lllmengembalikan keempat label yang valid.Ternyata entah bagaimana pembaruan memicu driver manajemen penyimpanan Intel untuk membuat mirror softraid dari disk (mungkin itu diaktifkan tetapi tidak didukung oleh
geompenyedia Intel sampai pasca-pembaruan?) Dan yang memblokir ZFS dari pemasangan disk.Menyambungkannya ke PC lain dengan firmware waktu boot Intel RST diaktifkan dan menonaktifkan softraid ( sangat penting: ada dua cara untuk memecah softraid, default yang menginisialisasi (alias format!) Disk. Anda harus memilih opsi untuk nonaktifkan tanpa menyentuh data sebagai gantinya) kemudian biarkan ZFS mengenali disk pertama di mirror, meskipun tidak ada yang saya lakukan akan memungkinkannya untuk mengidentifikasi disk yang tersisa sebagai sama dengan yang ada di mesin pra-pembaruan. Untungnya itu adalah zpool cermin dan saya bisa melepaskan dan memasang kembali disk ke kolam yang dimaksud dan resilver selesai tanpa acara.
Catatan: Dalam kasus saya,
hdparm(berjalan dari ISO Server Ubuntu langsung) melaporkan bahwa HBA dinonaktifkan pada semua disk dan tidak dapat membantu.sumber
jika itu hanya masalah jenis partisi saya akan dd partisi drive + MBR dan hanya membuat partisi ukuran yang tepat ...
jika Anda tidak memformat partisi yang membuat atau mengubah tabel partisi tidak memengaruhi apa pun (sehingga Anda dapat mengembalikannya!) selama tidak ada format maka sebagian besar data masih ada / dapat diakses jika partisi baru dimasukkan pada akhir drive Anda mungkin memiliki file korup di sana di mana hal-hal baru itu sulit dituliskan itu sebabnya Anda hanya baik untuk trik itu sampai Anda memformat (mbr baru, tabel file dll ...)
sumber