Bir işletme için en değerli dijital varlık çoğu zaman yazılım değil, yazılımın içindeki veridir: müşteri kayıtları, satış geçmişi, stok hareketleri, faturalar. Donanım arızası, yanlışlıkla silinen bir tablo veya fidye yazılımı saldırısı, düzenli ve test edilmiş bir yedek yoksa telafisi zor kayıplara yol açabilir.
Önce iki kavram: RPO ve RTO
- RPO (Recovery Point Objective): En fazla ne kadarlık veri kaybını kabul edebilirsiniz? "Son 24 saat" mi, "son 15 dakika" mı?
- RTO (Recovery Time Objective): Bir felaketten sonra sistemin en geç ne kadar sürede tekrar çalışması gerekir?
Yedekleme stratejisi bu iki soruya verilen cevaplara göre kurulur. Gün içinde yoğun satış yapan bir işletme için birkaç saatlik veri kaybı bile ciddi olabilir.
Yedek türleri
SQL Server özelinde üç temel yedek türü vardır; diğer veritabanlarında da benzer kavramlar bulunur.
Tam yedek (full)
Veritabanının o anki tamamının kopyasıdır. Geri yükleme için temel noktadır.
Fark yedeği (differential)
Son tam yedekten bu yana değişen verileri içerir. Tam yedekten daha küçük ve hızlıdır.
İşlem günlüğü yedeği (transaction log)
Son günlük yedeğinden bu yana yapılan tüm işlemleri içerir. Tam kurtarma modelinde, belirli bir ana (örneğin silme işleminden bir dakika öncesine) dönmeyi mümkün kılar.
Örnek plan: Haftada bir tam yedek, her gece fark yedeği, mesai saatlerinde 15–30 dakikada bir işlem günlüğü yedeği.
3-2-1 kuralı
- 3 kopya veri (canlı veri + 2 yedek)
- 2 farklı depolama ortamı (örneğin yerel disk ve harici depolama)
- 1 kopya farklı bir lokasyonda (örneğin bulut depolama)
Aynı bilgisayardaki ikinci bir diske alınan yedek, o bilgisayar çalındığında veya fidye yazılımı bulaştığında işe yaramaz.
Fidye yazılımına karşı önlemler
- Yedeklerden en az birini değiştirilemez (immutable) veya ağdan ayrılmış (offline) şekilde saklayın.
- Yedekleme hesabının yetkilerini sınırlayın; üretim sunucusu yedekleri silebilecek yetkiye sahip olmamalı.
- Yedek dosyalarını şifreleyin ve şifreleme anahtarını ayrı bir yerde saklayın.
- İşletim sistemi ve veritabanı güncellemelerini düzenli yapın. Genel güvenlik için OWASP Top 10 yazımıza bakabilirsiniz.
En çok atlanan adım: geri yükleme testi
Test edilmemiş bir yedek, var olduğunu umduğunuz bir yedektir. Düzenli aralıklarla:
- Yedeği ayrı bir test sunucusuna geri yükleyin.
- Veritabanı bütünlük kontrolü çalıştırın.
- Uygulamanın geri yüklenen veriyle açıldığını doğrulayın.
- Geri yüklemenin ne kadar sürdüğünü ölçün ve RTO hedefinizle karşılaştırın.
Otomasyon ve izleme
Elle alınan yedekler bir gün mutlaka unutulur. Yedekleri zamanlanmış görevlerle otomatik alın ve şunları izleyin:
- Yedek başarıyla tamamlandı mı?
- Yedek dosyası beklenen boyutta mı?
- Bulut veya harici kopyaya aktarım yapıldı mı?
Başarısız yedeklerde e-posta veya mesaj bildirimi gönderen küçük bir konsol uygulaması, büyük felaketleri önleyebilir.
Saklama süresi ve KVKK
Yedekler de kişisel veri içerir. Ne kadar süre saklanacakları, kimlerin erişebileceği ve imha süreçleri kişisel veri saklama politikanızla uyumlu olmalıdır. Bkz. KVKK uyumlu web sitesi.
Sık sorulan sorular
Bulut veritabanı kullanıyorsam yedek almam gerekir mi?
Yönetilen hizmetler genellikle otomatik yedek sunar; ancak saklama süresini, geri yükleme sürecini ve gerekirse hizmet dışı ek bir kopyayı kontrol etmek yine sizin sorumluluğunuzdadır.
RAID yedek yerine geçer mi?
Hayır. RAID disk arızasına karşı süreklilik sağlar ama silinen veya şifrelenen veriyi geri getirmez.
Sonuç
Sağlam bir yedekleme stratejisi; iş ihtiyacına göre belirlenmiş RPO/RTO hedefleri, 3-2-1 kuralı, otomasyon ve düzenli geri yükleme testinden oluşur. Bir gün ihtiyaç duyacağınız yedeği bugünden test edin. Altyapı tercihleri için bulut mu, yerel sunucu mu yazımızı okuyabilir, yedekleme otomasyonu için iletişime geçebilirsiniz.