Yedekleme, Replikasyon ve Kurtarma

Backup as a Service (BaaS), yedekleme, replikasyon ve geri yükleme operasyonunun tek elden bir hizmet sağlayıcıya devredildiği yönetilen yedekleme modelidir. Eclit'te her sistemin koruma politikası bir RPO hedefine bağlanır, yedek deposu değiştirilemez (immutable) saklamayla korunur ve rastgele seçilen bir yedekten düzenli olarak gerçek geri yükleme yapılıp süresi ölçülür. Başarısız yedekleme işi uyarıya döner; kapsam dışında kalan yeni sunucu raporda görünür. Saklama yeri sizinle birlikte belirlenip sözleşmeye yazılır; veri yerelliği gereksiniminiz varsa yedekler Türkiye'deki veri merkezlerinde kalır. Mevcut Veeam, Commvault, NetWorker ya da Rubrik kurulumunuzla da çalışırız.

İş etkisi analiziyle başlıyoruz; hedefler ürünün kapasitesine göre değil işin ihtiyacına göre çıkıyor.

Analiz iki soru soruyor: bu sistem ne kadar süre durabilir (RTO), ve ne kadar veri kaybı kabul edilebilir (RPO). Sorular teknik ekibe değil, o sistemi kullanan iş birimine soruluyor, çünkü ikisinin de cevabı ticari.

Çıkan hedefler sistem sistem yazılıyor, ve burada katmanlama şart: ödeme alan sistemle iç raporlama aracı aynı hedefi taşımak zorunda değil. Hepsini en agresif hedefe çekmek, bütçenin büyük kısmını düşük öncelikli iş yüklerine harcamak oluyor.

Hedefler belirlendikten sonra yöntem seçiliyor: günlük RPO periyodik yedeklemeyle, saatlik RPO sık snapshot ya da günlük tabanlı kurtarmayla, dakikalık RPO çoğaltmayla karşılanıyor. Her adımın maliyeti farklı ve karar o maliyet görünürken veriliyor.

Düzenli kurtarma tatbikatlarıyla. Yedeğin alınmış olması geri dönebileceği anlamına gelmiyor.

Bir yedek işi "başarılı" raporu verirken de bozuk olabiliyor: eksik bir veritabanı dosyası, tutarsız bir snapshot, kurtarma sırasında gereken ama yedeklenmemiş bir yapılandırma dosyası. Bunlar ancak geri dönmeyi deneyince görülüyor.

Tatbikatta izole bir ortama gerçekten geri dönülüyor: veri açılıyor, uygulama başlatılıyor, bütünlük kontrol ediliyor, geçen süre ölçülüyor. Ölçülen süre hedefle karşılaştırılıyor ve fark rapora yazılıyor.

Rapor sizde kalıyor, ve iki işe yarıyor: denetimde kurtarmanın test edildiğinin kanıtı oluyor, ve bir sonraki tatbikatın gündemini belirliyor. Zaman içinde biriken raporlar ayrıca bir eğilim gösteriyor; kurtarma süresi uzuyorsa ortam plandan uzaklaşıyor demektir.

İki mekanizma birlikte çalışıyor, ve tek başına hiçbiri yeterli değil.

Değiştirilemez (immutable) saklama. Yazıldıktan sonra belirlenen süre boyunca hiçbir hesabın (yönetici hesabı dahil) silemediği ya da değiştiremediği kopya. Süre, bir saldırının fark edilmesi için gereken süreden uzun seçiliyor.

Kimlik ayrıştırması. Yedekleme altyapısının kimlik doğrulaması üretim dizin hizmetinden bağımsız yapılıyor. Bu olmadığında, üretimde ele geçirilen bir yönetici hesabı doğrudan yedeklere de erişiyor; ve saldırganın ilk yaptığı iş bu.

Bugünkü fidye yazılımı ortama girdiği anda şifrelemiyor; haftalarca sessiz kalıp önce yedekleme altyapısını arıyor. Bu yüzden kurtarma noktası da farklı seçiliyor: saldırının tespit edildiği ana göre değil, bulaşmanın başladığı ana göre. Aradaki fark genellikle günlerdir ve bu, temiz bir noktaya dönebilmek için yeterli geçmişin saklanması gerektiği anlamına geliyor.

Saklama yeri sizinle birlikte belirleniyor ve sözleşmede yazılı hâle geliyor.

Veri yerelliği gereksiniminiz varsa yedekler Türkiye'deki veri merkezlerinde kalıyor; ikincil kopyanın konumu da aynı şekilde tanımlanıyor. Gereksinim yoksa konum, kurtarma hızı ve maliyet dengesine göre seçiliyor.

Burada sorulması gereken ve çoğu zaman atlanan bir ayrıntı var: yedeğin kendisi kadar, yedekleme sisteminin ÜST VERİSİ de bir konumda duruyor: hangi dosya ne zaman yedeklendi, hangi sunucu hangi işe ait. Bazı bulut tabanlı yedekleme ürünlerinde bu üst veri sağlayıcının merkezî sisteminde tutuluyor.

Ayrıca en az iki farklı konumda kopya tutuluyor: aynı tesiste duran iki kopya, o tesisi etkileyen bir olayda tek kopyadır.

Evet. Veeam, Commvault, NetWorker, Rubrik ve yerleşik hypervisor araçlarıyla çalışıyoruz.

Ürün değişikliği ancak mevcut ürün hedeflerinizi karşılayamıyorsa gündeme geliyor, o zaman da gerekçesiyle birlikte. Bir yedekleme ürününü değiştirmek, yalnızca yazılımı değiştirmek değil: eski yedeklerin saklama süresi boyunca eski ürünün de ayakta tutulması gerekiyor, yani bir süre iki sistem birden işletiliyor. Bu maliyet baştan hesaba katılmadığında geçiş beklenenden pahalı çıkıyor.

Devralma sırasında önce mevcut kurulumun ne yaptığı çıkarılıyor: hangi işler hangi sıklıkla çalışıyor, hangi sistemler kapsam dışı kalmış, saklama süreleri ne. Kapsam dışında kalmış bir sistem bulmak, devralmaların neredeyse tamamında karşılaşılan bir durum.

Temeli geçerli, ama fidye yazılımı çağında eksik kalıyor.

Klasik kural şunu söylüyor: verinin üç kopyası, iki farklı ortamda, biri saha dışında. Amacı donanım arızası ve fiziksel felaket. Bu iki riske karşı hâlâ doğru.

Eksik kalan yer, saldırganın kopyaların hepsine erişebilmesi durumu. Üç kopya da aynı ağdan ulaşılabiliyorsa ve aynı kimlik altyapısıyla yetkilendiriliyorsa, saldırgan için tek kopya demektir.

Bu yüzden kural genellikle şöyle genişletiliyor: kopyalardan biri değiştirilemez olmalı, ve biri çevrimdışı ya da mantıksal olarak ayrık olmalı. Yani üç kopya, iki ortam, biri saha dışı, biri değiştirilemez, sıfır doğrulanmamış geri dönüş.

Son madde en çok atlanan: doğrulanmamış bir yedek, sayılmayan bir kopyadır.

Yanlış yapılandırılmışsa evet, ve bu genellikle pencere sorunudur.

Yedekleme, diskten okuma ve ağdan gönderme demek; ikisi de üretim iş yüküyle aynı kaynakları kullanıyor. Yedekleme penceresi iş saatlerine taştığında ya da veri hacmi pencereye sığmayacak kadar büyüdüğünde etki hissediliyor.

Çözüm sırası şu. Önce artımlı yedekleme: her seferinde tam kopya değil, yalnızca değişen bloklar. Sonra snapshot tabanlı yöntem: kopyalama, üretimin devam ettiği bir görüntü üzerinden yapılıyor. Sonra bant genişliği sınırlama: yedekleme trafiğine tavan konuyor. En son, gerçekten gerekiyorsa, ayrı bir yedekleme ağı.

İzlenmesi gereken sayı yedekleme süresi değil, sürenin pencereye oranı. Süre penceresinin %80'ini geçtiğinde bu bir uyarı: veri büyümeye devam ediyor ve birkaç ay içinde pencere taşacak.

Üç ayrı gereksinim aynı anda cevaplanıyor ve en uzunu belirleyici oluyor.

Operasyonel gereksinim: yanlışlıkla silinen bir dosyayı geri getirmek için genellikle birkaç hafta yetiyor. Silmenin fark edilme süresi bunu belirliyor.

Fidye yazılımı gereksinimi: bulaşmanın başlangıcına dönebilmek için daha uzun geçmiş gerekiyor, çünkü tespit haftalar sonra oluyor.

Yasal ve sözleşmesel gereksinim: mevzuatın ya da müşteri sözleşmelerinin öngördüğü saklama süresi. Bu genellikle en uzunu ve tartışmaya kapalı olanı.

Bunlar tek bir saklama politikasına dönüşüyor: günlük yedekler kısa süre, haftalık ve aylık kopyalar daha uzun, yıllık arşiv en uzun. Buna kademeli saklama deniyor ve maliyeti kontrol altında tutan şey bu; her günlük yedeği yedi yıl saklamak hem gereksiz hem pahalı.

Saklama süresinin bir de ters yüzü var: KVKK kapsamında gereğinden uzun tutulan kişisel veri, kendisi bir bulguya dönüşüyor.

Veri hacmine değil, yönteme ve hazırlığa bağlı; ve bu ayrım tahminlerin çoğunun neden tutmadığını açıklıyor.

Klasik yedekten geri dönmede veri ağ üzerinden hedef sisteme kopyalanıyor; süre doğrudan hacimle ve bant genişliğiyle orantılı. Terabaytlar mertebesinde bu saatler demek.

Anlık kurtarma yönteminde ise sanal makine doğrudan yedekleme deposu üzerinden başlatılıyor ve veri arka planda taşınıyor. Sistem dakikalar içinde ayakta oluyor, performansı bir süre düşük kalıyor. Kritik sistemlerde tercih edilen yöntem bu.

Ama asıl süreyi belirleyen genellikle kopyalama değil, hazırlık: hedef ortamın var olması, ağın hazır olması, kimin ne zaman onay vereceğinin bilinmesi. Hazırlık yapılmamışsa "iki saatlik kurtarma" gerçekte yarım gün sürüyor, ve o farkı ancak tatbikat gösteriyor.