Memahami dampak / risiko mematikan "verifikasi integritas cadangan" pada cadangan SQL

Saat ini kami menggunakan rencana perawatan standar untuk cadangan di server SQL Server 2005/2008 / 2008R2 / 2012 di lingkungan kami, dan kotak "Verifikasi integritas cadangan" selalu dicentang.

Beberapa cadangan berjalan sangat lama, jadi saya merekomendasikan untuk mematikan opsi itu, tetapi manajemen membutuhkan saya untuk mendokumentasikan dampak dan risiko dari perubahan ini.

Saya memahami penggunaan dan riwayat opsi ini, sepertinya tidak perlu bagi saya untuk menggandakan waktu untuk pekerjaan pencadangan ketika (menurut saya), setiap kesalahan yang mungkin terjadi akan terjadi selama langkah pencadangan , bukan selama verifikasi.

Apakah aku salah? Apakah risiko minimal untuk mematikan ini, jika saya mencadangkan ke disk dan tidak untuk streaming rekaman atau sesuatu? (Kami mencadangkan melalui jaringan ke alat cadangan EMC DD-800, jika itu relevan.)

Apakah ada rekomendasi resmi MS tentang kapan aman untuk mematikan ini?

Apakah Anda menjalankan "verifikasi" pada setiap cadangan di lingkungan Anda? Apakah Anda memeriksa mereka?

EDIT : Untuk memperjelas, ketika Anda memeriksa "verifikasi integritas cadangan" dalam rencana pemeliharaan, SQL akan melakukan KEMBALIKAN VERIFIKASI lengkap pada setiap database segera setelah setiap cadangan. Ini hanya sebagai data / IO intensif seperti cadangan asli, dan (pada dasarnya) menggandakan waktu keseluruhan pekerjaan cadangan. Ini tidak sama dengan mengaktifkan opsi "checksum" pada cadangan (yang tidak dapat dilakukan di wizard, sejauh yang saya tahu).

Apakah aku salah? Apakah risiko minimal untuk mematikan ini, jika saya mencadangkan ke disk dan tidak untuk streaming rekaman atau sesuatu?

Tidak, Anda benar :-)

RESTORE VERIFYONLYhanya tidak akan memastikan bahwa Anda akan dapat memulihkan database Anda jika terjadi korupsi. Secara alami, itu tidak akan melakukan pemeriksaan integritas.

Cara yang lebih baik adalah mengambil cadangan Anda secara berkala dan melakukan pengembalian yang valid pada server yang berbeda dan melakukan DBCC CHECKDB di atasnya.

Ini adalah salah satu alasan, mengapa saya bukan penggemar besar rencana pemeliharaan karena GUI tidak mengekspos banyak opsi seperti backup .. with CHECKSUMitu dapat dicapai oleh T-SQL.

Dari blog Mitos Paul Randal

24p) menggunakan KEMBALIKAN ... DENGAN VERIFIKASI memvalidasi seluruh cadangan

Tidak. Menggunakan VERIFYONLY hanya memvalidasi header cadangan yang tampak seperti header cadangan. Hanya ketika Anda mengambil cadangan menggunakan CHECKSUM dan melakukan RESTORE ... DENGAN VERIFIKASI dan menggunakan DENGAN CHECKSUM bahwa pemulihan melakukan pemeriksaan yang lebih luas, termasuk checksum atas seluruh cadangan.

Apakah Anda menjalankan "verifikasi" pada setiap cadangan di lingkungan Anda? Apakah Anda memeriksa mereka?

Saya tidak menjalankan VERIFYONLY. Sebaliknya saya mengambil cadangan dengan CHECKSUM dan kemudian mengembalikannya + CHECKDB'ed pada server yang berbeda. Anda dapat mengikuti Sampling Statistik untuk memverifikasi cadangan Database pendekatan jika Anda ingin menjadi kreatif.

Ini tidak sama dengan mengaktifkan opsi "checksum" pada cadangan (yang tidak dapat dilakukan di wizard, sejauh yang saya tahu).

Anda dapat mengaktifkan Trace Flag 3023 sehingga CHECKSUMopsi diaktifkan secara otomatis untuk perintah BACKUP. Seperti biasa, uji perilaku tanda jejak di lingkungan Anda!

Intinya adalah - rencana pemeliharaan parit dan menggunakan solusi cadangan yang lebih masuk akal (petunjuk: solusi cadangan Ola) yang akan memungkinkan Anda untuk menyesuaikannya berdasarkan kebutuhan Anda.

(Kami mencadangkan melalui jaringan ke alat cadangan EMC DD-800, jika itu relevan.)

Cadangkan secara lokal ke disk dan kemudian miliki tugas transfer PowerShell yang akan menyalin cadangan secara lokal dari server ke jaringan berbagi (server cadangan). Itu akan lebih cepat daripada langsung menyalin ke jaringan berbagi.

Juga, aktifkan inisialisasi file instan, yang akan membantu dengan pertumbuhan otomatis pada file data dan juga akan membantu mengurangi waktu pemulihan (jika Anda harus mengembalikan database Anda). Itu selalu baik untuk memiliki opsi berguna.

Bacaan yang bagus adalah: Cadangan: Merencanakan Strategi Pemulihan

Intinya adalah bahwa kecuali Anda melakukan pemulihan database di suatu tempat, Anda tidak dapat sepenuhnya yakin bahwa file cadangan yang diberikan baik.

Tes ideal untuk memverifikasi cadangan Anda adalah mengatur lingkungan di mana cadangan basis data, dan cadangan basis data log, dipulihkan setiap saat sebagai bagian dari proses Anda sehari-hari. Ini adalah salah satu keuntungan menggunakan pengiriman log ...

Jika Anda masih ingin tetap menggunakan verifikasi saja, Anda dapat menyiapkan lingkungan khusus hanya untuk melakukan ini. Ini akan membongkar pekerjaan dari server produksi Anda (mungkin), dan mengurangi waktu kerja.

Akhirnya, sudahkah Anda mempertimbangkan untuk pindah dari rencana perawatan? Skrip seperti skrip Ola kecuali untuk pencadangan dan pemeliharaan: https://ola.hallengren.com/

Secara teknis pemulihan benar-benar seperti melakukan pemulihan, namun tidak ada pemeriksaan yang lebih baik yang benar-benar memulihkan database untuk memeriksa cadangan yang valid. Kami telah memiliki contoh di mana verifikasi hanya berlalu tetapi database tidak akan pulih karena korupsi, maksud saya adalah jangan mengandalkan ini karena verifikasi cadangannya ok. Kami sekarang telah mengembangkan sistem yang mengembalikan semua basis data kami pada contoh terpisah untuk memeriksa validitasnya, jelas itu tidak selalu memungkinkan, jadi cobalah mengambil sampel basis data tertentu seminggu. Panjang dan pendek tidak percaya hanya 100%.