Backup Hizmeti, RPO/RTO ve Recovery Sözleşmesi

Ön koşul: workload kritiklik, veri sınıfı, snapshot, replication, HA, failure domain ve temel storage kavramlarını açıklayabilmelisin. Bu dersin sonunda “backup alalım” talebini ölçülebilir bir recovery hizmetine çevirecek; backup, snapshot, replication, HA ve DR sınırlarını ayıracak; iş hizmeti bazında RPO/RTO, tutarlılık ve kapsam sözleşmesi kuracak; kopya oluşturma ile kullanılabilir hizmete dönüş arasındaki zinciri doğrulayacak; Arven için varsayım, risk, TBD, owner ve test kanıtı taşıyan baseline hazırlayabileceksin. Yaklaşık 30 dakika anlatı, 16 dakika vaka/uygulama ve 10 dakika kontrollerdir. Veri yolu, kopya mimarisi, izolasyon, cyber recovery ve kesin sizing sonraki derslerde derinleşir.

Backup, belirli bir zamanda var olan veri ve gerekli metadata’nın üretim sisteminden bağımsız bir recovery amacıyla kopyalanması ve yönetilmesidir. İş sonucu ise dosyanın kopyalanması değil, kabul edilen veri kaybı ve süre içinde doğru hizmetin güvenle geri dönmesidir. Bu nedenle backup işi “job successful” durumu ile kapanmaz. Korunacak iş hizmeti, geri dönülecek nokta, restore kapsamı, bağımlılık sırası, doğrulama ve operasyon sahipliği birlikte tanımlanır. Snapshot bir volume, filesystem, sanal disk veya uygulama durumunun point-in-time görünümünü hızlı oluşturabilir. Aynı yönetim düzlemi, kimlik, cluster ya da storage failure domain’inde kalıyorsa bağımsız backup sayılmaz. Replication güncel veriyi başka hedefe taşıyabilir; kaynakta yetkili silme, mantıksal bozulma veya zararlı şifreleme hedefe de aktarılabilir. HA bileşen arızasında hizmeti sürdürmeyi hedefler; geçmişteki temiz noktaya dönmeyi garanti etmez. DR site veya büyük hizmet kesintisi için daha geniş insan, süreç, tesis ve uygulama orkestrasyonudur. Her mekanizma recovery sözleşmesinde bir rol üstlenebilir, fakat adları birbirinin yerine kullanılmaz. Kapsam application service’den türetilir. Veritabanı dosyaları tek başına yeterli olmayabilir; transaction log, uygulama binary/configuration, VM metadata, network ve DNS bilgisi, identity/authorization, sertifika, encryption key, secret, lisans, automation/IaC ve işletim runbook’u gerekebilir. Backup platformunun kendi catalogue, configuration, credential ve recovery prosedürü de korunur. Hizmet sınıfı iş etkisine göre kurulur. Aynı “kritik” etiketi altındaki ERP transaction, dosya paylaşımı ve arşiv farklı değişim hızı, bağımlılık, retention ve doğrulama ister. Her workload için data owner, application owner, platform/backup owner ve olay anındaki karar yetkisi yazılır. Yasal saklama, silme yükümlülüğü ve gizlilik erişimi ayrıca doğrulanır; uzun retention otomatik olarak daha iyi koruma değildir.

Recovery Point Objective, kesinti anına göre kabul edilebilen en eski veri noktasını tanımlar; zaman cinsinden veri kaybı toleransıdır. Saatlik backup otomatik olarak bir saatlik gerçek RPO kanıtlamaz. İşin başlama zamanı, tamamlanma süresi, tutarlılık, değişim verisinin korunması, başarısız işlerin yeniden denenmesi ve kullanılabilir son kopya yaşı birlikte ölçülür. 10:00 job’ı 10:45’te bitiyor ve 09:50 uygulama durumunu koruyorsa, isimdeki saat gerçek recovery point değildir. Recovery Time Objective, olaydan sonra hedeflenen hizmet geri dönüş süresidir. Saatin nerede başladığı ve nerede durduğu sözleşmede yazılmalıdır: algılama mı, disaster declaration mı, restore emri mi; altyapı açılışı mı, veritabanı consistency kontrolü mü, uygulama işleminin kullanıcı kabulü mü? Download veya volume mount süresi bütün RTO değildir. Queue bekleme, catalogue erişimi, medya/rehydration, compute/network hazırlığı, data transfer, log replay, dependency start, güvenlik taraması ve iş doğrulaması zaman bütçesine dahildir. Tutarlılık recovery point’in kalitesidir. Crash-consistent kopya güç kesintisine benzer durumda filesystem ve uygulama recovery’si isteyebilir. Application-consistent kopya uygulama koordinasyonu, log ve transaction sınırıyla daha güçlü bir geri dönüş noktası sunabilir. Çok bileşenli hizmette ERP database, application tier, message queue, file share ve identity farklı saniyelerden dönerse her biri sağlam olsa bile iş akışı tutarsız olabilir. Consistency group, log koordinasyonu veya belirlenmiş yeniden uzlaştırma adımı gerekir. RPO ve RTO tek kuruluş sayısı yerine hizmet sınıfı ve senaryo matrisidir. Donanım hatası, yanlış silme, veritabanı bozulması, credential compromise, ransomware ve site kaybı aynı kaynakları bırakmaz. Normal restore ile clean-room cyber recovery’nin süreleri farklı olabilir. Hedef, base ve adverse senaryolarla; çalışma saati ve off-hours çağrı zinciriyle ayrı doğrulanır.

Recovery zinciri kaynak workload’dan kabul edilmiş iş hizmetine kadar izlenir. Capture aşaması snapshot, agent, API, database dump veya log ile point üretir. Transfer ve ingest veriyi repository’ye taşır. Catalogue/metadata hangi point’in hangi workload ve bağımlılığa ait olduğunu buldurur. Retention ve lifecycle kopyayı gerekli süre korur. Retrieve veya rehydrate seçilen point’i erişilebilir hale getirir. Restore veriyi hedefe yazar; reconstruct uygulama, configuration, identity ve network’ü kurar. Validate teknik ve iş bütünlüğünü ölçer; authorize kontrollü üretim açılışını yapar. Her adım failure domain ve credential bağımlılığı taşır. Production admin ile backup silme yetkisi aynı hesapta ise bağımsız kopya fiziksel olarak uzak olsa da ortak kimlik riski vardır. Catalogue yalnız korunan workload üzerinde çalışıyorsa üretim kaybında point bulunamayabilir. Encryption key aynı kayıp alanındaysa sağlam medya okunamaz. DNS, NTP, certificate authority, identity provider veya network policy eksikse uygulama restore edilmiş fakat erişilemez olabilir. Recovery architecture bu bileşenlerin bootstrap sırasını içerir. Kopya sağlığı katmanlı doğrulanır. Job completion, okunabilir block/object, checksum veya immutability durumu, catalogue eşleşmesi, uygulama açılışı, consistency check, transaction testi ve iş sahibi kabulü farklı kanıtlardır. NIST storage güvenlik rehberi restore testlerinin RTO’yu doğrulamasını, kopya sağlığının izlenmesini ve data ile application restore’un ayrıştırılmasını önerir. Test yalnız “dosya indirildi” seviyesinde kalırsa hizmet sözleşmesini sınamaz. Restore testinin hedefi üretim felaketi çıkarmadan en riskli varsayımları ölçmektir. İzole ve yetkili bir alanda representative veri seti seçilir; catalogue erişiminden kullanıcı işlemine kadar süre tutulur. Zararlı yazılım veya bozulma şüphesinde point seçimi, tarama ve temiz çalışma alanı devreye girer. Test verisinin gizliliği, erişimi ve test sonunda güvenli silinmesi yönetilir.

Arven’in raporunda yüzde 98 backup success, 30 günlük retention ve “kritik sistemlerde RPO 1 saat/RTO 4 saat” yazılıdır. Fakat oran workload sayısını mı job sayısını mı gösterir bilinmez. ERP database backup’ı vardır; log zinciri, application configuration, identity, encryption key ve backup catalogue kapsamı belli değildir. Dosya paylaşımı snapshot’ları aynı storage yönetim alanındadır. Arşivin üç yıllık saklaması iş gereksinimine bağlanmamıştır. Son tam restore tatbikatı on dört ay önce küçük bir test VM’inde yapılmıştır. Ekip hizmet envanteri çıkarır. ERP order-to-cash, dosya paylaşımı, kimlik servisi, sanallaştırma yönetimi, backup platformu ve arşiv ayrı recovery service olarak kaydedilir. Her biri için business owner, application/technical owner, data class, değişim hızı, normal/adverse RPO-RTO, consistency, scope, dependency, retention gerekçesi ve restore kabul işlemi yazılır. Backup’ın backup’ı ifadesi yerine catalogue, config, key ve credential bootstrap yolu çizilir. Arven ilk tatbikatta ERP’yi seçer. Senaryo yetkili yanlış silme ile başlar; ardından credential compromise şüphesi eklenir. Ekip 15 dakikalık log noktalarından doğru olanı seçer, izole hedefte database ve application katmanını kurar, key/identity/DNS bağımlılığını sağlar, order oluşturma ve raporlama işlemlerini çalıştırır. Her adımın başlangıç-bitişi, hata, manuel müdahale ve owner’ı kaydedilir. Cyber şüphesinde temiz point ve tarama süresi ayrı raporlanır. Çıktı ürün listesi değil recovery sözleşmesi ve kanıt backlog’udur. Koşullu ifade şöyledir: “ERP için 30 dakikalık RPO ve dört saatlik RTO, son tutarlı point’in sürekli izlenmesi ve catalogue’dan iş kabulüne uçtan uca tatbikatın geçmesi halinde kabul edilir.” Risk register ortak credential, aynı failure domain, eksik key/config, test dışı bağımlılık ve çağrı zinciri gecikmesini taşır. TBD kapanmadan daha pahalı repository satın almak belirsizliği çözmüş sayılmaz.