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 \
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
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!