Apakah saya perlu menjalankan verifikasi pada cadangan kaset KPP meskipun drive itu sendiri melakukan verifikasi saat mereka menulis?

Kami memiliki drive LTO-3 Tape di perpustakaan media Dell yang kami gunakan untuk cadangan tape kami. The Artikel tentang LTO di Wikipedia menyatakan bahwa:

LTO menggunakan teknologi verifikasi-setelah-tulis otomatis untuk segera memeriksa data ketika sedang ditulis, tetapi beberapa sistem cadangan secara eksplisit melakukan operasi pembacaan kaset yang sepenuhnya terpisah untuk memverifikasi rekaman itu ditulis dengan benar. Operasi verifikasi yang terpisah ini menggandakan jumlah lintasan ujung ke ujung untuk setiap cadangan yang dijadwalkan, dan mengurangi masa pakai pita menjadi setengahnya.

Yang ingin saya ketahui adalah, apakah saya memerlukan perangkat lunak cadangan saya (Backup Exec dalam hal ini) untuk melakukan verifikasi pada kaset ini atau apakah teknologi verifikasi-setelah-penulisan yang melekat pada drive KPP cukup?

Saya juga akan penasaran jika Backup Exec memahami teknologi verifikasi-setelah-menulis cukup untuk mengingatkan saya jika teknologi itu tidak dapat membekukan data atau akan mengabaikannya membuatnya sia-sia karena meskipun drive mendeteksi masalah saya tidak akan pernah tahu tentang itu.

backup tape

— Chris Magnuson
sumber

Jawaban:

Pertanyaan bagus!

Sementara saya akan mengatakan bahwa ya Anda harus mengujinya, saya akan mengatakan bahwa menguji kaset / drive itu sendiri adalah penting, yang jauh lebih penting adalah menguji ujung ke ujung proses restorasi .

Saya tidak bisa merekomendasikan pemulihan sistem lengkap dan pengujian layanan yang cukup, itu satu-satunya cara untuk mengetahui dengan pasti bahwa seluruh sistem melakukan apa yang Anda beli. Anda tidak perlu melihat jauh di situs ini untuk melihat orang-orang yang berjuang untuk memulihkan layanan mereka meskipun mereka pikir mereka telah membahas semua langkah secara individual.

Semoga ini membantu.

— Chopper3
sumber

+1 untuk pemulihan. Pada titik ini saya berpadu dengan "mesin virtual!" - memulihkan ke mesin virtual bisa menjadi indikator non-disruptif yang baik bahwa cadangan Anda berguna

— Sirex

Apa yang Anda katakan jelas merupakan ide yang bagus dan kita harus mulai melakukan itu, tetapi saya masih tidak yakin apakah teknologi verifikasi pada penulisan di drive LTO 3 akan menyebabkan cadangan saya gagal jika karena alasan tertentu data tidak dapat diverifikasi seperti halnya terjadi jika perangkat lunak cadangan saya menjalankan verifikasi pada data. Saya suka ide untuk melakukan sesuatu yang lebih tetapi saya masih perlu tahu apakah saya saat ini melakukan sesuatu yang berlebihan yang tidak perlu. Terima kasih

— Chris Magnuson

Pastikan juga Anda melakukan pemulihan menggunakan tape drive yang berbeda dari yang dibuat dengan cadangan karena beberapa kaset hanya dapat dibaca pada drive yang membuatnya (atau setidaknya ini mungkin di masa lalu).

— James

@ChrisMagnuson Apakah Anda pernah mencari tahu apa yang terjadi jika drive mendeteksi kesalahan menggunakan skema verifikasi-setelah-menulis sendiri?

— alx9r

@ alx9r Saya takut tidak. Sepertinya tidak ada yang tahu pasti dan saya tidak yakin bagaimana Anda dapat dengan sengaja mengacaukan data segera setelah ditulis oleh kepala kaset tetapi sebelum dibaca oleh mekanisme apa pun yang dilakukan verifikasi-setelah-penulisan sehingga Anda dapat melihat bagaimana perangkat lunak cadangan Anda merespons ada kesalahan yang terdeteksi.

— Chris Magnuson

Pertama-tama verifikasi otomatis ini bukan pengganti untuk verifikasi ujung ke ujung. Saya telah melihat drive yang dikirim dengan bug firmware yang menyebabkan pemulihan pembacaan kurang dapat diandalkan dibandingkan pembacaan verifikasi.

Hasil dari itu adalah bahwa Anda dapat menulis kaset tanpa ada kesalahan yang dilaporkan, tetapi ketika mencoba untuk memulihkan Anda akan melihat membaca mendapatkan kesalahan atau jatuh dalam kecepatan oleh beberapa urutan besar.

Sebagian besar pelanggan tidak pernah melihat bug firmware ini. Menurut vendor karena pelanggan tidak benar-benar melakukan tes pemulihan. Bug khusus ini diperbaiki. Tapi saya yakin kami belum melihat bug firmware terakhir, dan beberapa bug firmware hanya akan ditemukan jika Anda benar-benar menguji pembacaan yang sebenarnya.

Apa yang terjadi ketika verifikasi gagal adalah bahwa firmware secara otomatis menulis salinan kedua (dan selama mengembalikan firmware secara transparan ke host hanya mengembalikan satu dari dua salinan). Ini berarti bahwa kapasitas yang tersedia bervariasi tergantung pada kesehatan drive dan kualitas media.

Jika terlalu banyak upaya penulisan gagal dalam verifikasi, pembacaan kesalahan dilaporkan kembali di tingkat SCSI. Orang akan berpikir kesalahan yang dilaporkan dengan cara ini sulit untuk dilewatkan pada lapisan perangkat lunak, tetapi bug dalam jalur kode yang hanya dipicu oleh perangkat keras yang rapuh terkenal sulit untuk diuji.

— kasperd
sumber