SQL DB'yi daha sık yedekleme

Şu anda her gece 2 am SQLCMD.exe çağıran ve yedekleme için çalıştırmak için bir .sql komut dosyası geçirir (aşağıda gösterilen) zamanlanmış bir görev var. Biz iş dünyasındaki büyük büyüme nedeniyle büyüyen ihtiyaçları olan oldukça küçük bir şirketiz. Bu noktada 1 günlük veri kaybı, geçen yıl bu sefer on yüz dolara karşılık on binlerce dolara mal olacak. Bu DB platformunu SQL Azure gibi büyük fazlalık ile veri yansıtmanın gerçekleştiği farklı bir çözüme geçirene kadar, daha sık yedekleme almak için yapabileceğim en iyi şey nedir? Aşağıdaki bu komut dosyası DB'yi çevrimdışı olmaya zorlar mı? Bu komut dosyasını DB ile etkileşime giren kullanıcılarla çalıştırabilir miyim?

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

Güncelleme

Vay canına, burada SO'dan çok daha özel bir DBA topluluğu var. Şimdiye kadarki geri dönüşler için teşekkürler. Eksik olan tek şey "nasıl". Günlük yedekleme yapmak için kullandığım yukarıdaki SQL komutunu gösterdim, ancak artımlı günlük yedekleme örnekleri MIA. Bu büyük bir DB değil, şu anda SQLExpress üzerinde çalışıyor. HA veya SQL Azure dediğimde, özellikle küçük bir işletme olarak sahip olmadığımız mimariyi kastediyorum. Bu örnek şu anda SADECE sunucumuzda çalışıyor. Bu sunucu çökerse, kurtarma zamanımız bir yapışma noktası haline gelir. Bu nedenle SQL Azure çekici hale gelir.

Güncellemenizden EDIT

Eğer 1 gün değerinde veri kaybedebilirsiniz dediğim gibi o zaman ben sadece basit kurtarma veritabanları koymak istiyorum. Daha sonra her sabah ve / veya akşam bir TAM yapabilirsiniz. Gün içinde kendinizi kapsamak istiyorsanız, veritabanının farklı bir yedeğinden geçebilirsiniz, durumlardan biri. Bu, tam yedeklemeden bu yana yapılan değişiklikleri yakalayacaktır. Çok fazla girişin gerçekleştiği bir zaman dilimi biliyorsanız, bu tür bir yedekleme tamamlandıktan sonra oraya atabilirim. Kurtarma işlemi sırasında insanlara zaman kazandırabilir, böylece ekstra veri girişi yapmak zorunda kalmazlar.

Bu tek sunucunuz olduğundan veritabanlarına karşı DBCC CHECKDB çalıştırdığınızdan emin olabilirsiniz. Yedeklemeler, bozuk olduklarını öğrendiğinizde iyi bir sonuç vermiyor (bence bu da birinden bahsetti). Herhangi bir hatayı yakalamak için DBCC iletisinin SQL ERRORLOG'unu denetlemek üzere zamanlanmış bir görev ayarlamak için orada birkaç komut dosyası bulabilirsiniz. SQL Server, DBCC iletilerinden döndürülen hatalar konusunda yerel olarak sizi uyarmaz; bu nedenle, bunu yapan bir komut dosyasının her seferinde el ile kontrol edilmezse yardımcı olabilir.

Diferansiyel yedekleme komutu:

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 

• SQL Server'daki yedeklemeler kesintiye uğramaz. Yani veritabanı çalışır durumda. Dokümanları okuyun.
• Her gün tam bir yedekleme yapın, ardından gönderilen (kopyalanan) LOG yedeklerini (tekrar, belgeler ... belgeler) daha düzenli olarak yapın - her 15 dakikada bir gibi.

Yapmanız gereken ilk şey, ne kadar veri kaybetmeyi göze alabileceğinizi bulmaktır. O zamana kadar veritabanını ne sıklıkta yedekleyeceğiniz konusunda hiçbir fikriniz olmayacak. Bu, bulmanız gereken bir sayı değil. Bu, işletmenin (veya daha küçük bir şirketteki CEO'nun) karar vermesi gereken bir şeydir. Geri gelecekleri ilk sayı 0 dakikadır. Hangi yapılabilir, ama yapmak çok pahalı olacak. Gerçekte yedek alabileceğiniz en az miktarda veri yaklaşık 2 dakikada birdir. Sistemde değişen veri miktarı yeterince küçükse, her dakika yedekleme yapabilirsiniz.

İşlem günlüğü yedeklemeleri yapmak için yapmanız gereken şey, veritabanını TAM kurtarma moduna geçirmeniz gerekir.

5 dakika değerinde veri kaybetmeyi göze alabiliyorsanız, muhtemelen günlük olarak tam yedeklemeler ve her 5 dakikada bir işlem günlüğü yedeklemeleri yapmak isteyeceksiniz. 15 dakika değerinde veri kaybederseniz, her 15 dakikada bir tam yedekleme ve işlem günlüğü yedeklemesi yapmak istersiniz.

Başka bir seçenek, yukarıda bahsettiğim gibi, her x dakikada bir haftalık tam yedeklemeler, günlük diferansiyel yedeklemeler ve işlem günlüğü yedeklemeleri yapmak olacaktır .

Daha sık yedekleme yapmanız gerektiğini, bir veritabanı hatası veya veri silme durumunda geri yüklemek için daha fazla dosya gerektiğini unutmayın. Veritabanını geri yüklemek için gereken süreyi kısaltmak için gün boyunca farklı yedeklemeler yapmak mantıklı olabilir.

BACKUP veritabanı ve BACKUP LOG deyimini kullanan tüm yedeklemeler çevrimiçi olarak yapılır ve kullanıcıların veritabanına erişmesini engellemez.

En yoğun zamanınız olan ortak bir iş senaryosuna sahip olduğunuzu varsayalım: Pazartesi-Cuma 09: 00-17: 00. Sonra öneririm: Pazar gecesi tam yedekleme. 08:00, 18:00 ve 01:00 saatleri arasında diferansiyel yedekleme (kurtarma süresini azaltmak için). Günlük yedeklemeleri her saatte veya işletmenizin gerektirdiğine bağlı olarak.

Saklama sürenize bağlı olarak, eski yedekleme dosyalarını temizlemek için otomatik bir temizleme işiniz olmalıdır. Tüm bunlar SQL bakım planları kullanılarak oluşturulabilir. SQL 2005 için bu bağlantıyı kontrol edin .

Yedeklerinizi bir çeşit yedek diskte (yansıtılmış) saklamanız veya tesis dışı depolama için bantlar kullanmanız gerekir. Yedeklemeler çalışırken kullanıcılar sistem üzerinde çalışmaya devam edebilir.

Her gece tam bir yedekleme yapmazdım. Büyük bir veritabanı ise, o zaman çok uzun zaman alabilir, bahsetmiyorum bile medyada çok yer kaplıyor. Her hafta sonu tam yedekleme ve her gece diferansiyel yedekleme yapın. Daha sonra her saat veya yarım saatte bir (günlük veritabanınızın tam kurtarma durumunda olduğu varsayılarak) bir işlem günlüğü yedeği yapın, ancak disk hatası durumunda bu .bak ve .trn dosyalarının ayrı bir diskte bulunduğundan emin olun.

Site dışı depolama alanı almak için gece yedekleme klasörünüzü bulutla senkronize edebilir misiniz? Bunun bir sağlık şirketi için olduğundan emin olduğumdan, HiPA uyumluluğu için yeterince güvenli olan var mı? Ya da belki sadece onları şifrelemek mi?

Komut dosyası en azından yedeklemenin bir kopyasını ağ paylaşımına yerleştiriyor mu? Bu şekilde fiziksel kutu patlarsa ...