Backup Veri Yolu, Kopya Mimarisi ve Saklama

Ön koşul: backup hizmeti, RPO/RTO, consistency, snapshot, replication, block/file/object erişimi ve temel network/storage performans kavramlarını açıklayabilmelisin. Bu dersin sonunda workload’dan repository’ye capture, change tracking, transport, ingest, catalogue ve lifecycle yolunu çizecek; full, incremental, differential, log ve synthetic yöntemlerinin bağımlılıklarını ayıracak; kopyaları gerçek failure ve trust domain’lerine yerleştirecek; retention, change rate, reduction, concurrency ve restore hızından kapasite/throughput zarfı kuracak; Arven için kaynak, ölçüm, risk, TBD ve test kapısı taşıyan kopya mimarisi hazırlayabileceksin. Cyber isolation ve clean recovery bir sonraki derste derinleşir.

Backup veri yolu uygulama state’ini recovery point’e çevirdiği anda başlar. Agent, hypervisor/storage API’si, filesystem snapshot’ı, database native dump veya transaction log farklı capture noktalarıdır. Seçim; uygulama tutarlılığı, destek, değişim görünürlüğü, source overhead’i ve restore granularity’sini etkiler. Snapshot çoğu tasarımda kısa bir consistency/staging adımıdır; bağımsız repository’ye veri taşınmadan kaynak failure domain’i ve retention riski devam eder. Full backup seçilen kapsamın tamamını point’e taşır. Incremental son ilgili backup’tan beri değişen veriyi, differential son full’dan beri değişen veriyi taşır. Incremental zincir ingest’i azaltabilir fakat restore sırasında base ve ardışık noktaların okunmasını gerektirebilir. Synthetic full, repository’deki önceki full ve değişimleri birleştirerek source’tan yeniden tam okuma ihtiyacını azaltabilir; metadata, repository işlem gücü ve zincir bütünlüğüne bağımlıdır. Ürünlerin semantiği değişebilir; chain, merge, active-full ve forever-incremental davranışı resmî doküman ve restore testiyle doğrulanır. Change block tracking veya benzeri mekanizma “değişti” bilgisini sağlar; doğru ve tutarlı veri kopyalandığını tek başına kanıtlamaz. Reset, snapshot consolidation, migration veya API hatası change map’i geçersizleştirebilir. Database log zincirindeki gap ya da yanlış truncation point-in-time recovery’yi bozabilir. Transport yolu source CPU/memory, proxy/media server, NIC, switch/WAN, encryption/compression ve repository ingest katmanlarını içerir. Okuma MB/s’si ile ağ payload’ı aynı olmayabilir; compression ve dedupe nerede çalışıyorsa CPU ve trafik sonucu değişir. Window hesabı ortalama veri bölü nominal link değildir. Eşzamanlı workload, retry, snapshot stun, proxy queue, TLS, küçük dosya/metadata ve repository commit davranışı ölçülür. Backup tamamlanma süresi source etkisi ve son kullanılabilir point yaşıyla birlikte izlenir.

Repository yalnız kapasite havuzu değildir; data, metadata/index, catalogue, retention state, checksum ve encryption bilgisini recovery süresince koruyan hizmettir. “Ucuz TB” restore concurrency, saklama, API, egress ve support etkisi görülmeden karşılaştırma ölçüsü değildir. Kopya topolojisi logical copy ile gerçek failure domain’i ayırır. Bir primary repository ve aynı storage cluster’daki ikinci bucket iki isimdir; controller, fabric, identity, management plane ve site ortaksa bağımsız olay koruması sınırlıdır. Tape farklı media ve offline süreç sağlayabilir; robot, catalogue ve offsite lojistiği bağımlılıktır. Cloud object farklı tesis sunabilir; tenant/root identity, region, network, key ve provider control plane ortak nedenleri ayrıca değerlendirilir. “3-2-1” gibi sayısal kurallar faydalı bir başlangıç kontrolüdür; tek başına recovery mimarisi değildir. Hangi üç instance’ın gerçekten ayrı olduğu, iki media/teknoloji sınıfının hangi olaya farklı davrandığı ve offsite/offline kopyanın hangi credential ile erişildiği kanıtlanır. Kopya sayısı tutarlılık, currency, isolation veya restore hızını göstermez. Her copy set için amaç, point aralığı, retention, konum, failure/trust domain, health check ve restore rolü kaydedilir. Catalogue ve index ayrı korunur. Data block’ları sağlamken chain haritası, workload kimliği, key veya media location kaybolursa recovery süresi ağırlaşabilir. Catalogue backup’ı üretim ve ana backup platformu kaybında bağımsız bootstrap yoluyla bulunur. Encryption at rest ve in transit gizliliği destekler; key retention kopyanın en uzun yaşamından kısa olamaz. Key rotation, escrow/recovery, yetkili roller ve key manager kaybı tatbikata eklenir. Dedupe ve compression fiziksel tüketimi azaltabilir; oran workload, scope, işlem sırası ve retention karışımına bağlıdır. Global dedupe index bağımlılığını büyütebilir. Satış oranı yerine representative pilot aralığı, base/adverse kapasite ve metadata recovery testi kullanılır.

Retention “30 gün” gibi tek sayı değildir. NIST SP 800-209 veri sınıfı başına tier, frequency, copy type, media, encryption, location, lifecycle ve restore prosedürünün birlikte tanımlanmasını ister. Saatlik, günlük, aylık ve yıllık point’ler farklı recovery ve denetim amaçları taşır. Retention iş, hukuk, güvenlik ve maliyet sahipleriyle gerekçelendirilir. Legal hold normal expiration’ı durdurabilir; privacy veya sözleşme belirli sürede silmeyi gerektirebilir. “Sonsuza kadar sakla” risk ve maliyeti büyütür. Expire edilen catalogue kaydının data block, replica, object version, tape ve key üzerindeki gerçek silme davranışı doğrulanır. Clock, timezone ve policy değişikliklerinin lock süresine etkisi kaydedilir. Bu ders retention mimarisini kurar; immutability ve privileged-delete saldırı testini sonraki ders derinleştirir. Logical protected data kapasite hesabının başlangıcıdır. Full sayısı, günlük change rate, incremental/differential büyüme, log üretimi, retention tier’ları, metadata/index, catalogue, copy sayısı, staging, synthetic merge workspace ve sistem rezervi ayrı satırlardır. Dedupe/compression tahmini workload sınıfı ve güven aralığıyla uygulanır. Source data artışı, change rate sıçraması, reduction düşüşü, legal hold ve başarısız expiration adverse senaryolarıdır. Repository doluluk üst sınırı operasyon ve yeniden düzenleme için headroom bırakır. Throughput iki yönde hesaplanır. Ingest window içinde source okuma, proxy, network ve repository write/merge akışlarını; restore ise catalogue lookup, media mount/rehydration, repository read, network, target write ve application replay’i içerir. Backup MB/s yüksek olup restore yavaş olabilir: dedupe rehydration, çoklu chain, tape mount, cloud retrieval tier veya target write sınırı sonucu değiştirebilir. RTO için restore concurrency, öncelik ve diğer işlerle çakışma ayrı test edilir.

Arven’in mevcut taslağı 420 TB protected data, gece 22:00–06:00 pencere, yüzde 12 günlük değişim, 30 günlük retention, primary disk repository ve cloud copy bilgilerini içerir. Ancak 420 TB’nin kapsamı, change dağılımı, chain, log üretimi, copy lag, reduction, catalogue/key ve restore throughput’u yoktur. Cloud copy farklı tesis olsa da aynı yönetim hesabıyla silinebilir. Ekip üç workload profili çıkarır. ERP için application-consistent snapshot, log backup ve point-in-time chain; dosya paylaşımı için küçük dosya/metadata yoğun incremental; arşiv için düşük değişim fakat uzun retention ve silme/hold kuralı tanımlanır. Her akış source read, proxy, network, repository ingest/index, copy ve catalogue adımlarıyla çizilir. Normal gün, ay sonu, retry/backlog ve aynı anda kritik restore senaryoları ölçülür. Kopya matrisi production, source snapshot, primary disk, secondary cloud/object ve seçilecek offline/offsite seçeneği data/media, site, network, identity, management, key ve catalogue domain’lerinde karşılaştırır. Amaç sayısal etiketi işaretlemek değil, yanlış silme, storage kaybı, site kesintisi ve credential compromise olaylarında hangi point’in kaldığını göstermektir. Cyber izolasyon ve clean-room kabulü üçüncü derse açık girdi olarak aktarılır. Kapasite waterfall’ı source büyümesi, change/log, tier point’leri, metadata, copy, staging, base/adverse reduction ve headroom’u gösterir. Throughput tablosu backup window, copy ve iki eşzamanlı restore’u aynı kaynak takviminde sınar. Nominal link ve vendor reduction değeri Fact değildir; ölçüm ve güven aralığı taşır. Çıktı koşullu mimaridir: “ERP chain’i ay sonu change rate’inde hedef point yaşını korur, primary kaybında offsite copy ayrı credential ve catalogue/key ile bulunur ve restore zarfı dört saatlik bütçeye sığarsa önerilir.” Riskler chain corruption, ortak identity, reduction düşüşü, doluluk, WAN backlog ve catalogue/key kaybıdır.