mdadm raid5 memulihkan kegagalan disk ganda - dengan twist (urutan drive)


14

Biarkan saya mengakui terlebih dahulu bahwa saya telah membuat kesalahan, dan bahwa saya memiliki cadangan untuk sebagian besar tetapi tidak semua data pada RAID ini. Saya masih memiliki harapan untuk memulihkan sisa data. Saya tidak punya uang untuk membawa drive ke perusahaan ahli pemulihan.

Kesalahan # 0, tidak memiliki cadangan 100%. Aku tahu.

Saya memiliki mdadmsistem RAID5 4x3TB. Drive / dev / sd, semua dengan satu partisi /dev/sd[b-e]1. Saya sadar bahwa RAID5 pada drive yang sangat besar berisiko, namun saya tetap melakukannya.

Peristiwa terbaru

RAID menjadi menurun setelah dua drive gagal. Satu drive [/ dev / sdc] benar-benar hilang, yang lain [/ dev / sde] muncul kembali setelah siklus daya, tetapi tidak secara otomatis ditambahkan kembali ke RAID. Jadi saya dibiarkan dengan 4 perangkat RAID dengan hanya 2 drive aktif [/ dev / sdb dan / dev / sdd].

Kesalahan # 1, tidak menggunakan salinan dd drive untuk mengembalikan RAID. Saya tidak punya drive atau waktu. Kesalahan # 2, tidak membuat cadangan superblok dan mdadm -Edrive yang tersisa.

Upaya pemulihan

Saya memasang kembali RAID dalam mode terdegradasi dengan

mdadm --assemble --force /dev/md0, using /dev/sd[bde]1.

Saya kemudian dapat mengakses data saya. Saya diganti /dev/sdcdengan cadangan; kosong; drive identik.

Saya menghapus yang lama /dev/sdc1dari RAID

mdadm --fail /dev/md0 /dev/sdc1

Kesalahan # 3, tidak melakukan ini sebelum mengganti drive

Saya kemudian mempartisi yang baru /dev/sdcdan menambahkannya ke RAID.

mdadm --add /dev/md0 /dev/sdc1

Kemudian mulai mengembalikan RAID. ETA 300 menit. Saya mengikuti proses /proc/mdstathingga 2% dan kemudian melakukan hal-hal lain.

Memeriksa hasilnya

Beberapa jam (tetapi kurang dari 300 menit) kemudian, saya memeriksa prosesnya. Itu telah berhenti karena kesalahan baca pada /dev/sde1.

Di sinilah masalah sebenarnya dimulai

Saya kemudian dihapus /dev/sde1dari RAID dan menambahkannya kembali. Saya tidak ingat mengapa saya melakukan ini; sudah terlambat.

mdadm --manage /dev/md0 --remove /dev/sde1
mdadm --manage /dev/md0 --add /dev/sde1

Namun, /dev/sde1sekarang ditandai sebagai cadangan. Jadi saya memutuskan untuk membuat ulang seluruh array menggunakan --assume-clean menggunakan apa yang saya pikir adalah urutan yang benar, dan dengan /dev/sdc1hilang.

mdadm --create /dev/md0 --assume-clean -l5 -n4 /dev/sdb1 missing /dev/sdd1 /dev/sde1

Itu berhasil, tetapi sistem file tidak dikenali saat mencoba me-mount. (Seharusnya EXT4).

Pesanan perangkat

Saya kemudian memeriksa cadangan yang saya miliki /proc/mdstat, dan saya menemukan urutan drive.

md0 : active raid5 sdb1[0] sde1[4] sdd1[2] sdc1[1]
      8790402048 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]

Saya kemudian ingat bahwa RAID ini mengalami kehilangan drive sekitar setahun yang lalu, dan pulih darinya dengan mengganti drive yang rusak dengan yang cadangan. Itu mungkin sedikit mengacak urutan perangkat ... jadi tidak ada drive [3] tetapi hanya [0], [1], [2], dan [4].

Saya mencoba untuk menemukan urutan drive dengan skrip Permute_array: https://raid.wiki.kernel.org/index.php/Permute_array.pl tetapi itu tidak menemukan urutan yang benar.

Pertanyaan

Saya sekarang memiliki dua pertanyaan utama:

  1. Saya mengacaukan semua superblok pada drive, tetapi hanya memberikan:

    mdadm --create --assume-clean
    

    perintah (jadi saya seharusnya tidak menimpa data itu sendiri /dev/sd[bde]1. Apakah saya benar bahwa secara teori RAID dapat dipulihkan [dengan asumsi untuk saat yang /dev/sde1ok] jika saya hanya menemukan urutan perangkat yang tepat?

  2. Apakah penting /dev/sde1memberikan nomor perangkat [4] dalam RAID? Ketika saya membuatnya dengan

    mdadm --create /dev/md0 --assume-clean -l5 -n4 \
      /dev/sdb1 missing /dev/sdd1 /dev/sde1
    

    itu diberi nomor [3]. Saya ingin tahu apakah itu relevan dengan perhitungan blok paritas. Jika ternyata penting, bagaimana saya bisa membuat ulang array dengan /dev/sdb1[0]hilang [1] /dev/sdd1[2] /dev/sde1[4]? Jika saya bisa membuatnya berfungsi, saya bisa memulainya dalam mode terdegradasi dan menambahkan drive baru /dev/sdc1dan membiarkannya melakukan sinkronisasi ulang lagi.

Tidak apa-apa jika Anda ingin menunjukkan kepada saya bahwa ini mungkin bukan tindakan terbaik, tetapi Anda akan menemukan bahwa saya menyadari hal ini. Alangkah baiknya jika ada yang punya saran.


1
+1 Ini adalah pertanyaan yang sangat dipikirkan dan didokumentasikan dengan baik. Saya berharap saya punya jawaban untuk Anda.
Berikan

Terima kasih atas komentar Anda, saya kira ini yang sulit.
Peter Bos

Apakah Anda sudah menyerah pada ini, atau Anda masih mengerjakannya? Jika Anda sedang mengusahakannya, saran saya, mencari semua drive yang telah Anda letakkan dan membuat JBOD di komputer lain yang dapat Anda gunakan untuk membuat gambar DD, lebih baik mengatasinya dengan cara itu karena Anda dapat terus mencoba berulang kali . (Gunakan LVM dan kemudian gunakan snapshot setelah selesai, sehingga Anda dapat terus menghapus snapshot dan tidak perlu menyalin ulang semuanya). Saya telah berada di kapal yang sama, dan saya berhasil memulihkan array dengan sebagian besar data utuh.
Regan

Terima kasih atas reaksimu. Setelah beberapa saat saya menyerah, mengganti dua drive dengan yang baru, memulihkan 98% dari cadangan, menerima kehilangan data 2% dan melanjutkan. Saya sekarang menggunakan RAID-Z dan telah memperbarui strategi cadangan saya. Sejauh ini baik.
Peter Bos

Jawaban:


3

Untuk menjawab pertanyaan Anda,

  1. Bisakah itu dipulihkan?

    • Hal pertama yang pertama - BERHENTI, duduk dan berpikirlah sedikit. Ya, algoritma, ukuran chunk, dan urutan disk sangat penting untuk mendapatkan sistem file apa pun yang ada, untuk dirakit kembali. Tetapi karena Anda telah menimpa superblok, kini Anda memiliki trial and error.
    • Kedua, apakah ada cara Anda dapat mengambil tata letak disk sebelumnya? Saya selalu melakukan mdadm --detail> backupfile hanya untuk menjaga tata letak disk di tempat yang aman. Periksa dmesg, / var / log untuk bukti bagaimana disk dikonfigurasikan dalam serangan itu.
    • Terakhir, jika Anda cocok dengan ukuran chunk dan urutan disk sebelumnya, Anda mungkin telah merusak superblock ext4 - ada cara untuk memindai dengan cepat untuk superblok lainnya (dan ada program bagus bernama TestDisk yang memindai superblok dari filesystem yang ada dan mencoba menjelajahinya secara manual: http://www.cgsecurity.org/wiki/Main_Page )
  2. Karena sdc baru, saya akan terus mencoba dan merakit secara manual melalui klausa yang hilang, dan ya, sde harus berada dalam urutan yang benar agar dapat berkumpul dalam mode terdegradasi. Setelah Anda menemukan tata letak yang benar - salin semua data dari larik dan mulai lagi, dokumentasikan tata letak (sehingga Anda tidak mengalami masalah ini lagi).

Semoga berhasil


1
ext3 / 4 menulis superblocks yang berlebihan. Anda dapat melewatkan offset superblock sebagai argumen untuk memasang atau fsck sebagai gantinya menggunakan superblok cadangan. Namun, dua drive turun dalam RAID 5 = game over.
dmourati

1

Sebelum Anda melakukan hal lain, ambil 'mdadm --examine / dev / sdX1' untuk masing-masing drive yang ada di dalam array Anda, dan 'mdadm --detail / dev / md0' dari itu, Anda harus dapat menentukan tata letak yang tepat.

Saya hanya perlu melakukan ini sendiri untuk memulihkan array Synology dalam pertanyaan terpisah:

Bagaimana memulihkan array mdadm di Synology NAS dengan drive dalam keadaan "E"?

Sunting: Maaf, baru saja melihat bahwa Anda mengatakan Anda kehilangan superblok di semua drive.

Perintah Anda di kemudian hari LIHAT benar. Opsi paling sederhana adalah dengan menjalankan create dengan setiap kemungkinan pemesanan, dan kemudian melihat apakah Anda dapat me-mount dan mengakses sistem file hanya pada read-only.


1

Pertanyaan ini sudah lama dan saya yakin tidak ada yang dapat membantu Anda sekarang, tetapi untuk orang lain membaca:

kesalahan paling berbahaya yang Anda buat bukanlah kesalahan yang Anda lakukan, yaitu menjalankan:

mdadm --create ...

pada disk asli, sebelum Anda siap mengetahui apa yang harus dilakukan. Ini telah menimpa metadata, sehingga Anda tidak memiliki catatan urutan drive, offset data, ukuran chunk, dll.

Untuk memulihkan dari ini, Anda perlu menimpa mereka lagi dengan nilai yang benar. Cara termudah untuk mengetahui ini adalah dengan melihat metadata, tetapi Anda sudah menghancurkannya. Cara selanjutnya adalah menebak. Tebak kombinasi-kombinasi perintah yang berbeda seperti ini, dengan nilai yang berbeda untuk setiap opsi kecuali yang Anda ketahui (4 perangkat, level 5), dan juga urutan disk yang berbeda:

mdadm --create /dev/md0 --assume-clean --metadata=1.2 --raid-devices=4 --level=5 --layout=... --chunk=512 --data-offset=128M /dev/sdb1 missing /dev/sdd1 /dev/sde1

Tetapi karena Anda TIDAK tahu hasil yang benar, sekali lagi, Anda tidak boleh menjalankannya pada disk lama yang menghancurkan mereka lebih jauh, membuat kesalahan fatal yang sama. Sebagai gantinya, gunakan overlay; misalnya prosedur ini harus berfungsi untuk menjaga dokumen asli tetap aman.

Setelah Anda menemukan beberapa argumen yang menghasilkan array kerja yang dapat Anda fsck atau mount dan verifikasi (mis. Periksa checksum dari file yang cukup besar untuk menjangkau semua anggota raid seperti iso yang seharusnya Anda simpan dengan checksum / pgpnya) tanda tangan, atau unzip -t atau gunzip -ta arsip besar)


Terima kasih. Sementara itu, saya telah beralih menggunakan ZFS (RAIDZ2). Namun, sangat menarik untuk membaca catatan Anda. Saya menyadari sekarang bahwa perintah create memang menimpa metadata, sementara pada saat itu saya berasumsi tidak akan melakukannya. Juga, saya tidak tahu tentang file overlay. Itu sangat rapi! Terima kasih!
Peter Bos
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.