Mencadangkan SQL DB lebih sering


10

Saat ini saya memiliki tugas yang dijadwalkan yang padam setiap malam pukul 2 pagi yang memanggil SQLCMD.exe dan meneruskannya .sql script untuk dijalankan untuk cadangan (ditunjukkan di bawah). Kami adalah perusahaan yang cukup kecil dengan kebutuhan yang terus meningkat karena pertumbuhan besar di sisi bisnis. Kehilangan 1 hari data pada saat ini akan menelan biaya puluhan ribu dolar vs beberapa ratus kali ini tahun lalu. Sampai saya dapat memigrasikan platform DB ini ke solusi berbeda di mana mirroring data terjadi dengan redundansi besar seperti SQL Azure, apa hal terbaik yang bisa saya lakukan untuk mendapatkan backup yang lebih sering? Apakah skrip di bawah ini memaksa DB menjadi offline? Bisakah saya menjalankan skrip ini dengan pengguna yang berinteraksi dengan DB?

USE CompanyCRM;
GO
BACKUP DATABASE CompanyCRM
TO DISK = 'D:\CRMBackups\CompanyCRMCRM.Bak'
   WITH FORMAT,
      MEDIANAME = 'CompanyCRM_Backup',
      NAME = 'Full Backup of CompanyCRM';
GO

Memperbarui

Wow, jelas komunitas DBA yang jauh lebih berdedikasi di sini daripada di SO. Terima kasih atas responnya sejauh ini. Satu-satunya hal yang hilang adalah "bagaimana." Saya telah menunjukkan perintah SQL di atas yang saya gunakan untuk melakukan backup harian, tetapi contoh cadangan log tambahan adalah MIA. Ini bukan DB besar, saat ini berjalan di SQLExpress. Ketika saya mengatakan HA atau SQL Azure, saya secara khusus merujuk pada arsitektur di tempat yang tidak kita miliki sebagai bisnis kecil. Contoh ini sedang berjalan di server ONLY kami. Jika server itu crash, waktu kita untuk memulihkan menjadi titik yang sulit. Inilah sebabnya mengapa SQL Azure menjadi menarik.


edit jawaban saya untuk pembaruan Anda, semoga membantu

Jawaban:


5

EDIT, dari pembaruan Anda

Seperti yang Anda katakan bahwa Anda dapat kehilangan data senilai 1 hari maka saya hanya akan menempatkan database dalam mode pemulihan SEDERHANA. Anda kemudian dapat melakukan PENUH setiap pagi dan / atau malam hari. Jika Anda ingin melindungi diri Anda pada siang hari, Anda mungkin dapat melakukan backup diferensial dari database, salah satunya hanya dalam situasi berjaga-jaga. Ini akan menangkap setiap perubahan yang dibuat sejak pencadangan penuh. Jika saya tahu kerangka waktu di mana banyak input terjadi, saya mungkin akan membuang jenis cadangan ini di sana setelah selesai. Ini dapat menghemat waktu orang dalam pemulihan sehingga mereka tidak perlu melakukan entri data tambahan.

Karena ini adalah satu-satunya server Anda, saya akan memastikan Anda menjalankan DBCC CHECKDB terhadap database. Backup tidak ada gunanya ketika Anda mengetahui mereka korup (saya pikir seseorang menyebutkan ini juga). Anda dapat dengan mudah menemukan beberapa skrip di luar sana untuk mengatur tugas yang dijadwalkan untuk memeriksa ERRORLOG SQL untuk pesan DBCC untuk menangkap kesalahan. SQL Server tidak akan secara asli memperingatkan Anda tentang kesalahan yang dikembalikan dari pesan DBCC, jadi kecuali Anda secara manual memeriksa setiap kali skrip yang melakukannya dapat membantu.

Perintah cadangan diferensial:


USE CompanyCRM; 
GO 
BACKUP DATABASE CompanyCRM 
   TO DISK = 'D:\CRMBackups\CompanyCRMCRM_diff.Bak'    
WITH FORMAT, DIFFERENTIAL,
MEDIANAME = 'CompanyCRM_Backup',       
NAME = 'Full Backup of CompanyCRM'; 
GO 

1
@Shawn: OP mengatakan bahwa "Kehilangan 1 hari data pada saat ini akan menelan biaya puluhan ribu dolar vs beberapa ratus kali ini tahun lalu", di mana dia mengatakan bahwa dia dapat kehilangan data senilai 1 hari ?!
Marian

8
  • Cadangan di SQL Server tidak mengganggu. Yaitu database tetap operasional. Baca dokumentasinya.
  • Lakukan pencadangan penuh setiap hari, diikuti dengan pengiriman (disalin) LOG cadangan (sekali lagi, dokumentasi tersebut memiliki ... dokumentasi) lebih teratur - seperti setiap 15 menit atau lebih.

4
Saya pikir cadangan adalah sesuatu yang Anda tidak memerlukannya, tetapi membaca dokumentasi secara lengkap - ini penting untuk bisnis DAN itu - serius - penting. Bukan gaya memasak telur. Pekerjakan seorang profesional.
TomTom

2
Sayang sekali saya tidak dapat memilih jawaban di situs ini ...
RSolberg

1
@RSolberg: Jawaban TomTom valid, bersama dengan saran lain yang sudah Anda dapatkan. Saya menyarankan agar Anda tidak mengharapkan responden untuk menunjukkan kepada Anda benar-benar sintaks dasar pencadangan. Meskipun aku melihat Shawn cukup baik untuk melakukan itu. Untuk merancang strategi CADANGAN tidak cukup. Anda harus memasangkannya dengan strategi KEMBALIKAN sehingga semuanya akan valid saat Anda membutuhkannya.
Marian

2
@RSolberg: maaf membuatmu kesal. Ini tidak dimaksudkan. Tetapi bagaimana komunitas ini tidak membantu? Anda memiliki jawaban (dan komentar) yang baik dan valid. Pesan Anda sendiri adalah: "Kehilangan 1 hari data pada saat ini akan menelan biaya puluhan ribu dolar vs beberapa ratus kali ini tahun lalu." Jadi Anda memerlukan strategi cadangan & pemulihan yang solid sehingga Anda tidak sampai di sana. Strategi yang solid datang dari mengetahui dengan sangat baik dasar-dasarnya Yang datang dari membaca dan memahami manual. Maaf jika Anda mengerti hal lain!
Marian

2
Saya setuju dengan @RSolberg bahwa sebagian besar jawaban di sini tidak menunjukkan "bagaimana" untuk melakukannya, tetapi itu juga karena pertanyaannya kurang detail "apa" yang Anda tidak mengerti Russell. Anda harus memberi tahu kami lebih banyak tentang apa yang Anda butuhkan, tetapi saya setuju dengan Anda bahwa situs di sini tidak seharusnya tentang "RTFM n00b". Juga, seperti yang Anda tunjukkan, Anda memiliki 10rb di Stack Overflow , jadi Anda pasti memahami komentar yang menandai yang kasar atau mengganggu. Di masa depan, Anda harus melakukannya lebih cepat, daripada mendidih karena frustrasi.
jcolebrand

6

Hal pertama yang perlu Anda lakukan adalah mencari tahu berapa banyak data yang Anda bisa kehilangan. Sampai saat itu, Anda tidak akan tahu seberapa sering membuat cadangan basis data. Ini bukan nomor yang harus Anda cari. Ini adalah sesuatu yang perlu diputuskan oleh bisnis (atau CEO di perusahaan yang lebih kecil). Nomor pertama yang akan mereka kembalikan adalah 0 menit. Yang bisa dilakukan, tetapi akan sangat mahal untuk dilakukan. Pada kenyataannya, jumlah data terkecil yang dapat Anda ambil cadangannya adalah setiap 2 menit. Jika jumlah perubahan data dalam sistem cukup kecil, Anda dapat melakukan pencadangan setiap menit.

Untuk melakukan pencadangan log transaksi, yang harus Anda lakukan, Anda harus meletakkan basis data ke mode pemulihan LENGKAP.

Jika Anda mampu kehilangan data senilai 5 menit maka Anda mungkin ingin melakukan backup penuh setiap hari, dan backup log transaksi setiap 5 menit. Jika Anda dapat kehilangan data senilai 15 menit maka Anda ingin melakukan pencadangan penuh dan pencadangan log transaksi setiap 15 menit.

Pilihan lain adalah melakukan backup penuh mingguan, backup diferensial harian dan backup log transaksi setiap x menit seperti yang saya bicarakan di atas.

Ingatlah bahwa semakin sering Anda perlu membuat cadangan, semakin banyak file yang perlu Anda pulihkan jika terjadi kegagalan basis data atau penghapusan data. Mungkin masuk akal untuk melakukan backup diferensial sepanjang hari untuk mempersingkat jumlah waktu yang diperlukan untuk mengembalikan database.

Semua cadangan yang menggunakan database CADANGAN dan pernyataan LOG CADANGAN dilakukan secara online dan tidak menghentikan pengguna mengakses database.


Saya sebenarnya cukup bisa menilai berapa banyak data yang bisa kita hilangkan. Bisnis kecil mengharuskan orang untuk memakai banyak topi, karena CIO saya cenderung terlibat dengan serangkaian keputusan bisnis setiap hari.
RSolberg

1
Itu akan membuat diskusi jauh lebih pendek.
mrdenny

3

Katakanlah Anda memiliki skenario bisnis yang sama dengan waktu tersibuk Anda: 9 pagi - 5 sore Senin-Jumat. Maka saya akan menyarankan: Backup penuh pada hari Minggu malam. Pencadangan diferensial pada pukul 8 pagi, 6 sore, dan 1 pagi (untuk mengurangi waktu pemulihan). Catat cadangan setiap jam atau tergantung pada apa yang dibutuhkan bisnis Anda.

Tergantung pada periode penyimpanan Anda, Anda harus memiliki pekerjaan pembersihan otomatis untuk menghapus file cadangan yang lama. Semua ini dapat dibuat menggunakan paket pemeliharaan SQL. Lihat tautan ini untuk SQL 2005 .

Anda harus menyimpan cadangan Anda pada beberapa bentuk disk yang berlebihan (dicerminkan), atau Anda dapat menggunakan kaset untuk penyimpanan di luar kantor. Pengguna dapat terus bekerja pada sistem saat cadangan berjalan.


2

Saya tidak akan melakukan backup penuh setiap malam. Jika itu adalah database besar maka itu bisa memakan waktu yang sangat lama, belum lagi memakan banyak ruang di media. Lakukan pencadangan penuh setiap akhir pekan dan pencadangan diferensial setiap malam. Kemudian lakukan pencadangan log transaksi (dengan asumsi database Anda dalam pemulihan penuh) setiap jam, atau setiap setengah jam, tetapi pastikan file .bak dan .trn ini berada di disk terpisah jika terjadi kegagalan disk.


Tag hilang, ini bukan basis data besar. Saat ini sedang berjalan pada instance SQLExpress.
RSolberg

1
Puluhan ribu dolar, berjalan pada Express? Menarik!
Andrei Rînea

Tidak juga. Bergantung apa yang Anda simpan (tanpa teks, tanpa binari) - yaitu 10 gigabyte data. Anda dapat menjalankan sistem akuntansi untuk perusahaan besar - perusahaan besar SERIUS - dalam 10 gigabyte. Sebuah toko online dengan 100.000 pesanan per hari dapat dengan mudah melakukan sisi toko dalam 10 gigabyte.
TomTom

1

Bisakah Anda menyinkronkan folder cadangan Anda di malam hari untuk mendapatkan penyimpanan di luar situs? Karena saya cukup yakin ini untuk perusahaan perawatan kesehatan, apakah ada yang cukup aman untuk kepatuhan HiPA? Atau mungkin superkripsinya saja?

Apakah skrip setidaknya meletakkan salinan cadangan pada jaringan berbagi? Dengan begitu jika kotak fisik meledak ...


Ya untuk semua hal di atas. Kami sebenarnya mencadangkan ke drive jaringan yang dicerminkan dan kami menyalin data dari lingkungan itu ke pusat data yang aman.
RSolberg
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.