Ana içeriğe geç

SecuraWall.com

E-posta güvenliği ve sürekliliği

Keşfedin
Teknik Rehber · Backup & DR

SQL Server Yedekleme Rehberi

SQL Server yedekleme tasarımı; full, differential ve transaction log yedeklerinin birlikte nasıl kullanılacağına ve hedef RPO/RTO değerlerine göre planlanır.

SON TEKNİK GÖZDEN GEÇİRME:
Backup & DR

Bu Konu Neden Önemli?

SQL Server yedekleme tasarımı; full, differential ve transaction log yedeklerinin birlikte nasıl kullanılacağına ve hedef RPO/RTO değerlerine göre planlanır.

Karar Verirken Kontrol Edilecek Noktalar

Recovery model'i iş ihtiyacına göre doğrulayın.

Log backup zincirini düzenli izleyin.

Restore sequence'i test ortamında doğrulayın.

Backup dosyalarını üretim sunucusuyla aynı hata alanında bırakmayın.

Mimari ve çalışma modeli

SQL Server’da full, differential ve transaction log yedekleri recovery modeline göre birlikte tasarlanır. Differential son ilgili full temeline bağlıdır; loglar gerekli sırayla uygulanır. Full recovery modeli seçmek tek başına düzenli log yedeği oluşturmaz. Zincir, LSN ilişkileri ve hedef zaman ürünün restore kurallarıyla doğrulanmalıdır.

  1. 1Full temel
  2. 2Differential varsa uygulama
  3. 3Sıralı transaction loglar
  4. 4Hedef zaman ve recovery
Recovery modelini, log zincirini ve hedef zamandaki uygulama kayıtlarını ayrı doğrulayın.

Tasarım parametreleri

Recovery model
Full recovery ile log backup zincirini birlikte işletin; sadece full yedek almak log büyümesini her durumda çözmez.
Restore sırası
Uygun full, varsa differential ve gerekli logları zincir/LSN uyumuyla sıraya koyun.
Kurtarma birimi
Dosya, uygulama, veritabanı ve tüm sistem için kurtarma gereksinimlerini ayrı ayrı belirleyin. Her birinin bağımlılığı ve test yöntemi farklıdır.
Kopyanın tutarlılığı
Yedekleme işinin başarıyla tamamlanmasıyla yetinmeyin. Uygulama hazırlığı, günlük zinciri ve gerçek geri yükleme sonucu üzerinden tutarlılığı doğrulayın.
Kapasite ve aktarım
Günlük değişim, saklama, tam kopya yöntemi ve ölçülen net hızla hesap yapın. Sıkıştırma veya deduplication oranını varsaymak yerine pilotta ölçün.
Bağımsız kurtarma
Yedek yönetimi, anahtar, katalog ve hedef altyapının üretim kaybından sonra erişilebilirliğini sınayın.

Hesap ve uygulama örneği

Örnek kurtarmada Pazartesi full, Çarşamba differential ve olay öncesine kadar gereken loglar ayrı hedefe uygulanır. Ara restore adımları NORECOVERY ile zinciri açık tutar; son adımda doğru hedef zaman ve recovery işlemi seçilir. Aynı isimli üretim veritabanına deneme restore yapmayın.

Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.

SELECT name, recovery_model_desc FROM sys.databases;

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
Belirli saate dönüş yapılamıyorLog zinciri boşluğu veya seçilen başlangıç yedeği uyumsuz olabilir.Backup metadata ve log aralığını doğrulayıp ayrı hedefte hedef saate restore edin.
Yedekleme başarılı ancak geri yüklenen sistem açılamıyorZincir, şifreleme anahtarı, katalog veya uygulama tutarlılığı sorunu olabilir.Ayrı hedefe küçük bir gerçek kurtarma yapın; ürün loglarını uygulama doğrulamasıyla birlikte inceleyin.
Aktarım süresi hedefi aşıyorKaynak okuma, ağ, hedef yazma veya çok sayıda küçük nesne sınırlayıcı olabilir.Aynı zaman aralığında üç katmanın hız ve gecikmesini ölçün; yalnız hat hızına bakmayın.
Kapasite tahminden hızlı büyüyorDeğişim oranı, tam kopyalar, kilit süreleri veya temizleme beklemeleri hesap dışı kalmış olabilir.Politika bazında gerçek kullanım ve silinmeye uygun noktaları karşılaştırın.

Kabul ve doğrulama kontrolleri

  1. Recovery modelini, log zincirini ve hedef zamandaki uygulama kayıtlarını ayrı doğrulayın.
  2. Seçilen kurtarma noktasını temiz bir hedefe geri yükleyin ve iş verilerini doğrulayın.
  3. Gözlenen veri kaybı penceresini hedef RPO ile karşılaştırın.
  4. Hazırlık, transfer, açılış ve iş onayını ayrı süreler olarak kaydedin.
  5. Üretim yönetim hesabı olmadan gerekli kurtarma erişimini test edin.
  6. Korunan kopyayı kontrollü silme denemesi ve gerçek restore ile sınayın.

İlgili kavramlar

İşlem günlüğü ve recovery zinciri

WAL, redo veya transaction log gibi mekanizmalar, veri değişikliklerinin kalıcılaştırılması ve kurtarılması için sıralı kayıt tutar; ürünler arasında ayrıntılar farklıdır. Veri dosyası kopyası ile işlem günlüklerinin zamanı ve zinciri uyumlu olmalıdır. Günlüklerin bulunması tek başına belirli bir zamana dönülebileceğini kanıtlamaz: başlangıç yedeği ve kesintisiz gerekli günlük aralığı da gerekir. Arşivleme gecikmesini, günlük hacmini ve geri oynatma süresini ölçün. Günlükleri kapasite kazanmak için rastgele silmeyin; saklama ve temizleme ürünün desteklediği yöntemle yapılmalıdır.

Transaction sınırı

Transaction, uygulamanın belirli işlemleri birlikte başarılı veya başarısız kabul ettiği mantıksal birimdir. Veritabanı içindeki atomiklik, e-posta gönderimi veya farklı servislerdeki değişikliklerin otomatik olarak aynı atomik kapsamda olduğu anlamına gelmez. Commit noktası ve hata sonrasında tekrar denemenin davranışı açık olmalıdır. Aynı isteğin iki kez işlenmesini önlemek için idempotency gereksinimini değerlendirin. Testte ağ kesintisi ve bağlantı kopmasını commit öncesi ve sonrasında ayrı uygulayın; istemcinin hata alması işlemin kesinlikle başarısız olduğu anlamına gelmeyebilir.

Uygulama tutarlılığı

Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedekleme ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.

RPO ve gerçek veri kaybı penceresi

RPO, olay sonrasında kabul edilebilecek veri kaybı süresidir. Yedek zamanlaması tek başına RPO kanıtı değildir; işin başarısız olması veya kopyanın karşı merkeze geç ulaşması pencereyi büyütebilir. Olay anı ile kullanılabilir son tutarlı kurtarma noktasının zamanını karşılaştırın. Örneğin olay 14.00'te, doğrulanmış kopya 13.20'deyse o testteki veri kaybı penceresi 40 dakikadır. Hedefi uygulama bazında belirleyin: dosya arşivi ile sürekli sipariş alan veritabanının gereksinimleri aynı olmayabilir.

RTO ve uçtan uca kurtarma süresi

RTO, bir hizmetin olaydan sonra ne kadar sürede kullanılabilir hale gelmesi gerektiğini ifade eder. Yedek dosyasının indirilmesi veya sanal makinenin açılması bu sürenin yalnız bir bölümüdür. Olayı tanıma, onay, altyapı hazırlığı, veri aktarımı, uygulama açılışı ve iş biriminin doğrulaması ayrı zaman kalemleri olarak kaydedilmelidir. Test süresinin hangi olayla başlayıp hangi olayla sona erdiğini açıkça belirtin. Aynı teknik geri dönüş süresi, bağımlılık veya erişim beklenmesi nedeniyle farklı iş süreçlerinde farklı kesinti süresine dönüşebilir.

Şifreleme ve anahtarın yaşam döngüsü

Şifreleme, verinin anahtar olmadan okunmasını zorlaştırır; erişim kontrolü, silinme koruması ve yedekleme farklı ihtiyaçları karşılar. Taşınan veri ile disk üzerindeki veri için hangi katmanın şifreleme sağladığını belirtin. Anahtarların oluşturulması, korunması, döndürülmesi ve acil geri kazanımı tasarımın parçasıdır. Yedeği kurtarmak için gereken anahtar yalnız felaket sırasında kaybedilecek sunucuda bulunmamalıdır. Test ortamında ayrı bir yöneticiyle veriyi açma ve anahtar erişimini geri kazanma adımlarını uygulayın; gerçek anahtarları dokümana veya destek mesajına koymayın.

Birincil teknik dokümantasyon

Who · How · Why

Bu İçerik Nasıl Hazırlandı?

KİM?

Doz Teknoloji Teknik Ekibi

İçerik, Doz Teknoloji’nin kurumsal BT hizmet alanlarında kullandığı teknik değerlendirme yaklaşımı temel alınarak hazırlanmıştır.

NASIL?

Teknik kriterler + birincil kaynaklar

Konu; üretici dokümantasyonu, standart kuruluşları ve ilgili resmî teknik kaynaklarla çapraz kontrol edilmiştir.

NEDEN?

Karar kalitesini artırmak

Amaç, teknik bir terimi yalnız tanımlamak değil; satın alma, tasarım veya işletim kararı verirken hangi kriterlerin birlikte değerlendirilmesi gerektiğini görünür hale getirmektir.

Bu Rehberle İlgili Kurumsal Çözümler

Teknik konuyu uygulamaya dönüştürmek için ilgili hizmet ve çözüm sayfalarına geçebilirsiniz.

Teknik İhtiyacınızı Birlikte Değerlendirelim

Mevcut altyapınızı, kullanıcı sayınızı veya teknik hedefinizi paylaşın; ürün, lisans veya proje kapsamını ihtiyaca göre netleştirelim.

Teknik Talep Oluşturun
Kurumsal IT Ürün Satışı, Lisanslama ve Kurulum
Kurumsal IT Proje & Çözüm Senaryoları
Tüm ilgili içerikleri görüntüleyin
WhatsApp'tan Yazın
Kopyalandı!