Cadangan sekecil mungkin ... dengan SQL Server

37

Setiap hari kami mengirimkan cadangan SQL Server kami di WAN. Kita perlu memperkecil ukuran cadangan ini sehingga tidak perlu selamanya.

Kami tidak keberatan jika proses pencadangan kami membutuhkan waktu lebih lama; seperti berdiri kita perlu memindahkan 30 gram cadangan terkompresi di WAN yang membutuhkan waktu lebih dari 10 jam.

Ada 2 opsi yang kami miliki untuk mendapatkan cadangan harian yang lebih kecil.

  1. Log pengiriman, yang berarti kita harus merestrukturisasi proses DR.
  2. Keluarkan informasi dari db dan bangun kembali di sisi lain (jatuhkan indeks yang tidak berkerumun, pak indeks berkerumun di 100% - bangun kembali di sisi lain)

Keduanya akan melibatkan cukup banyak pekerjaan dari pihak kami. Kami menggunakan SQL Server 2008 pro, semua cadangan dikompresi.

Apakah ada produk komersial yang dapat memberi kita ukuran cadangan yang sama dengan opsi (2)?

Apakah ada skrip yang komprehensif di luar sana yang akan memungkinkan kita untuk menyelesaikan (2)? (menangani tampilan yang diindeks, indeks yang difilter, kunci asing, dan sebagainya)

sql-server  sql-server-2008  backup 
— Sam Saffron
sumber
2
Apa rincian dan frekuensi cadangan Anda saat ini (cadangan log reguler? Harian penuh?) Apakah Anda menggunakan edisi standar atau Enterprise? Pembaruan: apakah Anda DR perusahaan kecil di situs sewaan atau perusahaan besar dengan situs DR permanen? Jika yang pertama, apakah Anda memiliki server file atau SQL Server yang menjalankan situs
— gbn
@ GBN, kita perlu mengoptimalkan untuk harian penuh, kita menggunakan perusahaan, DR semua lokal dengan orang-orang mengambil barang-barang di luar kantor. Cadangan kecil diperlukan untuk devs dan offsite kedua yang kami miliki. perhatikan ... pengembang di luar negeri, di negara lain dengan bandwidth terbatas, kami memerlukan ukuran transfer minimal dari server di NY ke (misalnya) Australia. Kami melakukan sinkronisasi setiap beberapa bulan.
— Sam Saffron
1
Bagi siapa pun yang tidak menyadari hal ini, ini untuk tim SO yang tepat;)
— jcolebrand
1
@ Sam Saffron: ada umpan balik, tolong apakah Anda mengadopsi sesuatu seperti saran saya?
— gbn
@ GBN ... masih memutuskan apa yang harus dilakukan, saya pikir "reguler" - kembali ke pekerjaan Oregon layak dengan solusi yang Anda sarankan. Namun, "Sam perlu mengunduh SO db masalah sebulan sekali masih sangat sangat menyakitkan karena saya perlu memindahkan 22 gigs ke Australia - ketika kenyataannya adalah bahwa" nyata "informasi dapat dengan mudah masuk dalam 10 gigs."
— Sam Saffron

Jawaban:

22

Pikiran pertama berdasarkan komentar ...

Gunakan cadangan diferensial setiap, katakanlah, 6 jam, untuk mengurangi ukuran / waktu cadangan + FTP. Kemudian kurangi cadangan lengkap + FTP Anda menjadi akhir pekan saja. Ini menghindari kompleksitas pengiriman log, mudah dilakukan, dan hanya menambah sedikit kompleksitas pada DR

Saya merasa bahwa cadangan diferensial diabaikan ... Saya telah menyarankan untuk menggunakannya sebelumnya:

Sunting: setelah komentar jcolebrand saya akan mencoba menjelaskan lebih lanjut

Cadangan diferensial hanya membutuhkan halaman yang telah berubah. Di luar pemeliharaan indeks apa pun (yang dapat memengaruhi banyak basis data), hanya beberapa% halaman yang akan berubah selama sehari. Jadi cadangan diferensial jauh lebih kecil daripada cadangan lengkap sebelum kompresi apa pun.

Jika Anda memiliki cadangan lengkap, katakan setiap minggu, Anda kemudian dapat melakukan perbedaan harian dan mengirimkannya ke luar situs. Cadangan penuh harian dengan diferensial masih akan membutuhkan kedua file di luar situs.

Ini harus menyelesaikan masalah mendapatkan data dari A ke B, C dan D dengan cepat.

Anda mungkin perlu memulihkan diferensial penuh dan terbaru untuk mendapatkan data terbaru, tetapi Anda mungkin dapat mengatasinya dengan NORECOVERY dan file STANDBY (Saya belum mencobanya dengan pemulihan berbeda selama bertahun-tahun sejak saya terakhir menggunakan DBA murni pekerjaan).

Bonus tambahan adalah bahwa cadangan diff tidak terkait dengan cadangan log yang sedang berlangsung sehingga Anda dapat memisahkan persyaratan Ketersediaan Tinggi / DR dari persyaratan "dapatkan data ke kode monyet".

Saya melihat beberapa masalah jika Anda memiliki cadangan lengkap harian berdasarkan kebijakan atau audit, tetapi pemulihan diff dapat diterapkan sebelum log apa pun dipulihkan untuk mempersingkat waktu pemulihan. Tidak seperti cadangan, pemulihan diff dan log memang berinteraksi.

Semoga saya sudah membahas sebagian besar pangkalan ...

— gbn
sumber
Hyperbac adalah alat kompresi yang sangat cerdas, yang memungkinkan seseorang untuk mengompres cadangan dan membiarkan semua rencana pemeliharaan dan pekerjaan tidak berubah, karena menangani file pada level OS. Jika mereka tidak ingin mengubah apa pun, tetapi hanya menambahkan alat baru ke kotak, mereka pasti harus mencobanya. Saya tahu saya telah menggunakannya dan menyukainya untuk SQL 2005. Tetapi untuk kompresi lebih lanjut mereka masih harus melakukan beberapa pekerjaan manual ...
— Marian
@Marian saya ... cukup yakin Brent O hanya seorang konsultan yang membutuhkan.
— jcolebrand
@ Maria: ada batas untuk kompresi dan lebih banyak kompresi = lebih banyak CPU / waktu. Cadangan terkecil akan menjadi yang paling sedikit input = diferensial, terlepas dari alat kompresi / format. Tautan tentang waktu / rasio Satu : Anda dapat memberikan kompresi ekstrem tetapi membutuhkan waktu lebih lama dan untuk file terkompresi 30 GB, ini bisa lebih lama dari FTP ...
— gbn
Saya setuju dengan Anda mengenai hal itu, masalahnya adalah alat komersial memiliki tingkat kompresi yang lebih baik daripada MS satu dan mereka dapat dikonfigurasi (dengan tidak ada CPU yang dialokasikan untuk operasi), mereka menawarkan enkripsi .. dan fitur lainnya. Saya tidak perlu memuji mereka (mereka tidak terlalu murah), saya hanya mengatakan bahwa beberapa dari mereka dapat digunakan bersama dengan cadangan saat ini dari SQL Server (penuh, diff, log) tanpa mengubah lingkungan, yang tampaknya orang-orang butuh / inginkan. @ jcolebrand: mengerti, terima kasih!
— Marian
13

Ada produk komersial yang dapat membantu Anda mengompres cadangan Anda lebih baik daripada kompresi asli 2008. Contohnya adalah RedGate Backup , Hyperbac , Idera SQL Backup , Litespeed Backup .

Mereka datang dengan biaya tambahan CPU tinggi dan jenis file yang perlu ditangani dengan alat di luar yang dikirimkan MS. Ini dengan pengecualian kompresi Hyperbac (sekarang diakuisisi oleh Redgate), yang menangani file secara transparan dan memungkinkan seseorang untuk membuat file yang kompatibel dengan zip (dan juga tidak memerlukan alat pihak ketiga).

Tetapi tidak ada alat yang akan menawarkan Anda file dengan ukuran yang akan Anda peroleh dengan melakukan pembersihan manual. Silakan melihat-lihat artikel Brent Ozar: Cara benar-benar memampatkan cadangan SQL Server Anda , ia akan menyarankan melakukan langkah-langkah yang sama yang Anda miliki di titik no. 2.

— Marian
sumber
RedGate FTW !!!!
— Hogan
@Hogan: jika Anda tidak bisa mengalahkan mereka, beli mereka. Ini contoh yang sangat bagus :-). Bagaimanapun, kedua produk yang sekarang menjadi bagian dari Redgate dan menangani kompresi basis data dapat hidup berdampingan dengan sukses.
— Marian
12

Pertanyaan 1: Apakah ada produk cadangan komersial yang akan memberikan ukuran cadangan yang sama dengan membuang data yang tidak penting seperti indeks dari database?

Tidak. Ada banyak produk kompresi cadangan di luar sana (Quest LiteSpeed, Red Gate SQL Backup, Idera SQLSafe, Hyperbac, dll) tetapi semuanya berfungsi dengan hanya mengompresi output dari proses pencadangan reguler SQL Server. Beberapa dari mereka melakukannya dengan cara yang rumit - Opsi HyperBac dan LiteSpeed's Engine adalah driver filter sistem file, yang berarti mereka mencegat output dalam perjalanan ke disk - tetapi hasil akhir dari semua produk ini hanyalah output backup yang terkompresi.

Pertanyaan 2. Apakah ada skrip komprehensif di luar sana untuk membuang semua data tambahan ini?

Seiring waktu, saat Anda menyimpan lebih banyak riwayat dalam basis data (4, 5, 8, 10 tahun), Anda tidak akan ingin mencabut semua data indeks dan membangunnya kembali di sisi lain WAN. Sebagai gantinya, Anda hanya ingin mentransfer data yang dimodifikasi, dan di situlah pengiriman log masuk.

Anda seharusnya tidak melakukan ini.

Tetapi jika Anda benar-benar ingin melakukan ini (dan tidak, saya tidak akan membantu Anda), Anda dapat melakukannya dengan cadangan filegroup. Siapkan filegroup basis data Anda seperti ini:

  • Filegroup utama (wajib, tapi biarkan kosong)
  • ClusteredIndex filegroup (letakkan indeks berkerumun Anda di sini)
  • Filegroup ExtraneousCrap (letakkan semuanya di sini)

Mulai lakukan pencadangan filegroup terkompresi hanya dari dua yang pertama, dan salin yang lebih kecil ke server DR Anda. Anda dapat menggunakan cadangan dan memulihkan kemampuan filegroup SQL Server 2008 untuk hanya memulihkan filegroup Primer dan ClusteredIndex, dan kemudian mereka akan segera tersedia untuk query. Mereka tidak benar-benar akan berfungsi sampai Anda mendapatkan filegroup ExtraneousCrap online, tetapi ada trik jahat untuk itu juga - dalam buku MVP Deep Dives , ada bab tentang mengedit tabel sistem untuk membuat filegroup ExtraneousCrap dan semua dari indeks terkait menghilang. Trik ini berbahaya, sama sekali tidak didukung, dan ide yang buruk - tapi hei, Anda memintanya.

— Brent Ozar
sumber
10

Saya sarankan beralih ke sesuatu seperti pengiriman log. Pada dasarnya jika Anda memiliki pilihan untuk mengirim 30 Gigs lebih dari 24 jam vs mengirim pada akhir hari dalam rentang waktu yang lebih pendek, kecepatan jaringan akan lebih sedikit menjadi masalah bagi Anda.

Pengembang Anda di jaringan lambat juga akan dapat mengunduh file berukuran lebih nyaman, melalui FTP atau proses apa pun yang Anda miliki. Mereka juga dapat mengatur pekerjaan yang diunduh sepanjang hari.

Selain kompresi server sql, Anda bisa mengimplementasikan alat pihak ke-3 yang memiliki kompresi lebih tinggi seperti litespeed atau redgate sqlbackup.

Selanjutnya pada sisi jaringan Anda dapat menginstal perangkat jaringan yang dapat mengoptimalkan throughput Anda ke situs DR. Di masa lalu saya berhasil menggunakan Riverbed Appliance untuk berhasil mendapatkan cadangan 90GB dari FL ke VA dalam waktu kurang dari 3 jam.

Pilihan lain adalah membuat cadangan grup file tertentu, mengecualikan indeks, dll, tetapi Anda masih terjebak dengan indeks berkerumun dan tergantung pada struktur db Anda, Anda mungkin mendapatkan lebih banyak biaya / kerumitan daripada manfaat dari pendekatan itu.

Terima kasih

— johndacostaa
sumber
7

Jika Anda punya uang untuk itu, dan arsitektur Anda memungkinkan, periksa sesuatu seperti teknologi Riverbed (http://www.riverbed.com/us/). Alat seperti ini bersamaan dengan skenario replikasi atau pengiriman log mungkin merupakan pilihan terbaik Anda.

Jika tidak maka beberapa pertanyaan. Jika Anda hanya perlu melakukan refresh setiap beberapa bulan, mengapa harus khawatir tentang bandwidth? Satu-satunya waktu Anda harus khawatir tentang transfer adalah sekali, mendapatkan cadangan lengkap di sana untuk melakukan pengembalian secara lokal, atau apakah saya salah bahwa itu pengaturan Anda?

Kemungkinan lain adalah bukannya khawatir tentang mendapatkan semua data itu kepada mereka, mengatur lingkungan Citrix dan membuatnya jauh ke Anda. Dengan Citrix Anda memiliki persyaratan bandwidth minimal antara klien / host dan Anda memiliki kemampuan untuk melakukan apa yang Anda butuhkan secara lokal dan tidak khawatir harus mereplikasi perubahan itu di tempat lain. Hanya $ 0,02 saya

— SQLCtebal
sumber
Bisakah Anda menjelaskan hal ini lagi? Saya tahu bahwa ini untuk tim StackExchange yang tepat, jadi saya yakin mereka akan menyukai langkah-langkah yang lebih mendalam;)
— jcolebrand
Haha ada banyak yang perlu dipertimbangkan di sini. Pada titik mana tepatnya Anda ingin saya jelaskan?
— SQLChicken
Replikasi / pengiriman log adalah apa yang ada dalam pikiran saya, tapi itu seperti dua minggu yang lalu, jadi saya ragu itu sama pentingnya sekarang. Juga, saya baru membaca kembali dan melihat bagian tentang Citrix, dan saya bisa memberi tahu Anda saat itu (seperti sekarang) bahwa mereka tidak melakukan itu. Mereka hanya melakukan pengembangan lokal menggunakan infrastruktur DVCS dan hanya ingin data untuk pengujian / bermain dengan / konfirmasi. Mungkin juga untuk kesedihan data.
— jcolebrand
Gotcha. Kemudian seperti yang telah dikatakan orang lain, vendor pihak ke-3 seperti Redgate dan Quest memiliki alat kompresi cadangan yang sangat baik untuk membantu Anda memenuhi kebutuhan mereka. Solusi potensial lainnya adalah SQL Azure. Saat ini batas ukuran database adalah 50GB tetapi mereka telah mengangkat biaya untuk data apa pun yang dimuat sehingga mungkin menjadi solusi yang hemat biaya.
— SQLChicken
4

Saya akan menggunakan replikasi transaksional SQL. Muatan awal Anda akan memakan waktu tetapi setelah Anda bangun dan berlari, Anda hanya dapat mengirim informasi apa yang Anda inginkan. Misalnya, jika Anda hanya memiliki 3 atau 4 tabel yang diperbarui, Anda hanya dapat mengirim 3 atau 4 tabel tersebut.

Anda juga dapat memilih apa yang ingin Anda kirim. Indeks FK, clustered / non-clustered, skema partisi tabel, procs tersimpan, dan TON lainnya.

http://www.sql-server-performance.com/2010/transactional-replication-2008-r2/

Jika ini bukan opsi, Anda bisa menggunakan REDGATE SQL BACKUP - http://www.red-gate.com/products/dba/sql-backup/ . Saya menggunakan ini sebelumnya dan mendapat tingkat kompresi hingga 90%. Jauh lebih kecil dari SQL.

— SqlSandwich
sumber
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.