Yedekleme konusu çoğu işletmede ürün seçimiyle başlar: hangi yazılım, hangi cihaz, hangi bulut. Oysa doğru sıra tersidir. Önce iki soruya net bir yanıt verilmeli, ürün bu yanıtlardan sonra seçilmelidir. Aksi hâlde teknik olarak kusursuz çalışan ama işletmenin gerçek ihtiyacını karşılamayan bir sistem kurulur.
Önce iki soru: RTO ve RPO
Bu iki kısaltma, yedekleme kararının tamamını belirler.
RTO (Recovery Time Objective): Bir kesinti sonrası sistemlerin ne kadar sürede çalışır hâle gelmesi gerektiğidir. "Yarım gün duraksak ne olur?" sorusunun yanıtıdır.
RPO (Recovery Point Objective): Kabul edilebilir azami veri kaybı süresidir. "Son bir saatin verisini kaybetsek işimiz durur mu?" sorusunun yanıtıdır.
Bu iki değer birbirinden bağımsızdır. Muhasebe sunucusu için günde bir yedek yeterli olabilirken, sürekli sipariş alan bir e-ticaret veritabanı için on beş dakikalık kayıp bile kabul edilemez olabilir. Tek bir RTO/RPO değeri tüm sistemlere uygulanmaya çalışıldığında ya gereksiz maliyet ya da yetersiz koruma ortaya çıkar.
Pratik yaklaşım şudur: sistemleri kritiklik düzeyine göre üç gruba ayırın ve her gruba ayrı hedef belirleyin. Kritik sistemler, önemli sistemler, ertelenebilir sistemler.
3-2-1 kuralı ve neden hâlâ geçerli
Yıllardır tekrarlanan bu kural, teknoloji değişmesine rağmen geçerliliğini korur:
- 3 kopya veri bulundurun (asıl veri dahil)
- 2 farklı ortam türünde saklayın (disk ve bulut, disk ve teyp gibi)
- 1 kopya tesis dışında olsun
Kuralın mantığı basittir: aynı odadaki iki kopya, yangın veya hırsızlık karşısında tek kopya sayılır. Aynı diskteki iki kopya ise disk arızasında hiç sayılır.
Son yıllarda bu kurala bir madde daha eklenmeye başlandı: kopyalardan birinin değiştirilemez (immutable) olması. Fidye yazılımlarının artık yedekleri de hedef alması bunu zorunlu kıldı.
Yerel mi, bulut mu, ikisi mi?
İkisinin de kendine göre güçlü ve zayıf yönü vardır; seçim RTO ve RPO hedeflerinize göre yapılmalıdır.
| Kriter | Yerel yedek (NAS, disk) | Bulut yedek |
|---|---|---|
| Geri dönüş hızı | Yüksek — yerel ağ hızında | İnternet hızıyla sınırlı |
| Tesis dışı koruma | Yok | Var |
| Başlangıç maliyeti | Donanım yatırımı | Düşük, abonelik tabanlı |
| Uzun vadeli maliyet | Öngörülebilir | Veri hacmiyle artar |
| Yönetim yükü | Donanım bakımı gerekir | Sağlayıcıda |
| Fidye yazılımı riski | Ağa bağlıysa yüksek | Değiştirilemez kopyayla düşük |
Çoğu kurumsal senaryoda doğru yanıt "ikisi birden" olur: hızlı geri dönüş için yerel kopya, felaket senaryosu için bulut kopyası. Bu yapı 3-2-1 kuralını da doğal olarak karşılar.
Yedekleme türleri arasındaki fark
Seçtiğiniz yöntem hem yedekleme süresini hem de geri dönüş süresini doğrudan etkiler.
- Tam yedek: Her seferinde verinin tamamı kopyalanır. Geri dönüş en hızlı ve en basit olanıdır; ancak depolama ve süre maliyeti yüksektir.
- Artımlı yedek: Yalnızca son yedekten bu yana değişenler alınır. Yedekleme hızlıdır, depolama azdır; ancak geri dönüşte zincirin tamamı gerekir. Zincirin bir halkası bozulursa sonrası kullanılamaz.
- Diferansiyel yedek: Son tam yedekten bu yana değişenler alınır. İkisinin ortasında bir denge sunar.
Uygulamada yaygın kurgu, haftalık tam yedek ile günlük artımlı yedeğin birleşimidir. Kritik veritabanlarında buna gün içi işlem günlüğü yedeği eklenir; böylece RPO dakikalar seviyesine iner.
Fidye yazılımı ve değiştirilemez yedek
Modern fidye yazılımları yalnızca üretim verisini şifrelemez; ağdan erişilebilen yedekleri de arar ve siler. Bu nedenle "ağdaki NAS cihazına yedekliyoruz" cümlesi tek başına yeterli koruma anlamına gelmez.
Korunma için üç yaklaşım öne çıkar:
- Değiştirilemez depolama: Yazıldıktan sonra belirlenen süre boyunca silinemeyen veya değiştirilemeyen yedek katmanı.
- Ayrı kimlik doğrulama: Yedekleme sisteminin, üretim ortamının etki alanı hesaplarından bağımsız kimlik bilgileriyle çalışması.
- Çevrimdışı kopya: Fiziksel olarak ayrılmış, sürekli bağlı olmayan bir kopya.
Test edilmeyen yedek, yedek değildir
Sahada en sık rastlanan durum, yedeklerin düzenli alındığı ama hiç geri dönülmediği senaryodur. Gerçek bir kayıp anında ilk kez denenen geri dönüş, çoğu zaman beklenenden uzun sürer veya hiç çalışmaz.
Düzenli bir test döngüsü şöyle kurulabilir:
- Her ay rastgele bir dosya veya klasörü yedekten geri döndürün. Bu, zincirin sağlam olduğunu doğrular.
- Üç ayda bir tam bir sanal makineyi izole bir test ortamında ayağa kaldırın.
- Geri dönüşün ne kadar sürdüğünü ölçün ve bu süreyi hedeflediğiniz RTO ile karşılaştırın.
- Yılda en az bir kez, kritik bir sistemi baştan sona kurtarma tatbikatı yapın. Sürecin hangi adımında takıldığınızı not edin.
- Her testin sonucunu kayıt altına alın. Altyapıda değişiklik olduğunda testi tekrarlayın.
Bu döngünün amacı yedeklerin çalıştığını kanıtlamak değil, çalışmadığı yerleri felaket anından önce bulmaktır.
Karar verirken sırayla sorun
Özetle, ürün karşılaştırmasına geçmeden önce şu sırayı izleyin: hangi sistemler kritik, her biri için RTO ve RPO ne olmalı, bu hedefler hangi yedekleme türünü gerektiriyor, 3-2-1 nasıl sağlanacak, fidye yazılımına karşı hangi katman eklenecek ve test döngüsü nasıl işleyecek.
Bu soruların yanıtı netleştiğinde ürün seçimi çok daha kolaylaşır; çünkü artık hangi özelliğin gerçekten gerekli olduğu bilinmektedir. Mevcut yedekleme yapınızı gözden geçirmek veya bu hedefleri birlikte belirlemek isterseniz MayraNet ekibine danışabilirsiniz.