# 3-2-1 Yedekleme Kuralı ve Modern Backup Stratejileri

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/backup-yedekleme-is-surekliligi/3-2-1-yedekleme-kurali-backup-stratejileri

![3-2-1 Yedekleme Kuralı ve Modern Backup Stratejileri](/images/bilgi-merkezi/covers/cover-backup-02.webp)

Bir kurumun yedeklerinin olması, verilerinin güvende olduğu anlamına gelmez.

Asıl önemli olan yedeklerin **nerede tutulduğu, üretim sistemlerinden ne kadar bağımsız olduğu, saldırgan tarafından değiştirilip değiştirilemediği ve gerektiğinde gerçekten geri yüklenip yüklenemediğidir.**

Bugün birçok kurum düzenli olarak backup almasına rağmen bir fidye yazılımı saldırısından sonra sistemlerini geri getirmekte ciddi sorunlar yaşayabilmektedir.

Bunun temel nedenlerinden biri oldukça basittir:

**Saldırganlar artık yalnızca üretim sistemlerini değil, yedekleme altyapısını da hedeflemektedir.**

Bir saldırgan kurumun Active Directory altyapısında yüksek yetkili bir hesaba eriştiğinde saldırısını hemen başlatmak yerine günlerce hatta daha uzun süre ağ içerisinde hareket edebilir.

Bu süreçte;

backup sunucularını,

yedekleme yazılımlarını,

storage sistemlerini,

hypervisor altyapısını,

backup repository'lerini,

snapshot yapılarını,

bulut depolama hesaplarını

tespit etmeye çalışabilir.

Amaç yalnızca veriyi şifrelemek değildir.

Amaç kurumun **geri dönüş yolunu ortadan kaldırmaktır.**

Bu nedenle modern backup stratejisinin temel prensibi şudur:

Üretim ortamının ele geçirilmesi, yedekleme ortamının da ele geçirilmesi anlamına gelmemelidir.

Bu prensibin en bilinen uygulamalarından biri **3-2-1 Backup Rule**, yani 3-2-1 yedekleme kuralıdır.

Ancak günümüzde klasik 3-2-1 modeli de gelişmiştir.

Artık;

**3-2-1,**

**3-2-1-1-0,**

**immutable backup,**

**air-gap backup,**

**offsite backup**

ve **zero trust backup**

yaklaşımları birlikte değerlendirilmektedir.

### 3-2-1 Backup Kuralı Nedir?

3-2-1 backup kuralı, veri kaybı riskini azaltmak için kullanılan en bilinen yedekleme prensiplerinden biridir.

Kural oldukça basittir:

#### 3 Veri Kopyası

Kritik verinin toplamda en az üç kopyası bulunmalıdır.

Bunlardan biri üretim verisidir.

Diğer ikisi ise backup kopyalarıdır.

Örneğin:

**\1. Kopya:** Üretim sunucusundaki veri

**\2. Kopya:** Lokal backup repository

**\3. Kopya:** Uzak veri merkezi veya bulut backup

Buradaki temel mantık, tek bir kopyanın kaybedilmesinin kurumun verisini tamamen kaybetmesine neden olmamasıdır.

### Neden Üç Kopya?

Tek bir backup kopyası bazı durumlarda yeterli görünür.

Ancak backup'ın kendisi de bozulabilir.

Backup storage arızalanabilir.

Backup dosyası corrupt olabilir.

Yanlış retention politikası nedeniyle gerekli restore point silinmiş olabilir.

Backup sistemi ransomware tarafından şifrelenebilir.

Bir yönetici yanlışlıkla backup repository'yi silebilir.

Bu nedenle üretim verisiyle birlikte en az iki ek kopyanın bulunması veri dayanıklılığını önemli ölçüde artırır.

Buradaki kritik nokta şudur:

**Backup'ın da backup'a ihtiyacı olabilir.**

### 2 Farklı Depolama Ortamı

3-2-1 kuralındaki ikinci rakam **iki farklı depolama ortamını** ifade eder.

Amaç tüm verilerin aynı teknolojiye veya aynı fiziksel altyapıya bağımlı olmamasıdır.

Örneğin kurumun üretim verisi SAN üzerinde bulunuyorsa backup farklı bir disk sistemi üzerinde tutulabilir.

İkinci backup ise;

object storage,

tape,

cloud storage,

ayrı bir backup appliance

gibi farklı bir ortamda saklanabilir.

Bunun nedeni **ortak hata noktalarını azaltmaktır.**

Eğer üretim ve backup aynı storage üzerinde bulunuyorsa storage sisteminin kaybedilmesi hem üretim verisini hem backup'ı etkileyebilir.

### Aynı Storage Üzerindeki Snapshot Backup Sayılır mı?

Bu noktada kritik bir yanlış anlaşılmaya değinmek gerekir.

Birçok altyapıda snapshot teknolojileri kullanılmaktadır.

Snapshot'lar hızlı geri dönüş açısından son derece değerlidir.

Ancak production data ve snapshot aynı storage üzerinde bulunuyorsa fiziksel storage kaybedildiğinde her ikisi de kaybedilebilir.

Bu nedenle:

#### Snapshot ≠ bağımsız backup

Snapshot, backup stratejisinin bir katmanı olabilir.

Ancak tek başına 3-2-1 stratejisinin yerini almamalıdır.

### 1 Kopya Farklı Lokasyonda

3-2-1 kuralının son rakamı, backup kopyalarından en az birinin farklı fiziksel lokasyonda bulunmasını ifade eder.

Buna genellikle:

#### Offsite Backup

adı verilir.

Neden?

Çünkü bazı felaketler yalnızca bir sunucuyu değil, bütün lokasyonu etkileyebilir.

Örneğin;

yangın,

sel,

deprem,

elektrik altyapısı problemi,

fiziksel sabotaj,

veri merkezi arızası,

soğutma sistemi problemi

tüm altyapının kullanılamaz hale gelmesine neden olabilir.

Eğer production ve backup aynı veri merkezindeyse kurum bütün kopyalarını aynı anda kaybedebilir.

Bu nedenle kritik backup'lardan en az biri farklı lokasyonda tutulmalıdır.

### Offsite Backup Nerede Tutulabilir?

Offsite backup için farklı seçenekler bulunmaktadır.

Örneğin;

ikinci veri merkezi,

disaster recovery merkezi,

bulut storage,

uzak backup repository,

co-location veri merkezi,

fiziksel tape arşivi

kullanılabilir.

Burada önemli olan yalnızca kilometre olarak uzaklık değildir.

İki lokasyonun aynı riskleri paylaşmaması gerekir.

Örneğin iki veri merkezinin aynı elektrik altyapısına veya aynı fiziksel binaya bağımlı olması gerçek anlamda coğrafi dayanıklılık sağlamayabilir.

### 3-2-1 Backup Kuralı Neden Ortaya Çıktı?

Klasik backup stratejilerinin temel amacı donanım arızası, yanlışlıkla silme veya fiziksel felaketlere karşı veri korumaktı.

Bu nedenle 3-2-1 modeli uzun yıllar son derece etkili bir yaklaşım oldu.

Ancak tehdit modeli değişti.

Eskiden backup sistemlerinin en büyük düşmanı çoğunlukla:

**donanım arızasıydı.**

Bugün ise denklemde başka bir aktör var:

**Saldırgan.**

Saldırgan backup sisteminin varlığını biliyor.

Hatta bazı saldırılarda backup altyapısının ortadan kaldırılması saldırının temel aşamalarından biri haline geliyor.

Bu nedenle klasik 3-2-1 modeline yeni güvenlik katmanları eklenmeye başladı.

### Ransomware 3-2-1 Backup Stratejisini Nasıl Değiştirdi?

Bir ransomware saldırısında saldırganın doğrudan dosyaları şifrelediğini düşünmek artık eksik bir bakış açısıdır.

Modern saldırı zinciri çok daha uzun olabilir.

Örneğin:

#### \1. Gün – İlk erişim

Phishing, zafiyet veya ele geçirilmiş hesap üzerinden sisteme giriş yapılır.

#### \2. Gün – Credential erişimi

Kullanıcı hesapları ve yüksek yetkili hesaplar hedeflenir.

#### \3. Gün – Lateral Movement

Ağ içerisindeki diğer sistemlere geçilir.

#### \4. Gün – Active Directory

Domain seviyesinde yüksek yetki elde edilmeye çalışılır.

#### \5. Gün – Backup Discovery

Backup sunucuları ve repository'ler keşfedilir.

#### \6. Gün – Backup Sabotajı

Snapshot'lar, restore point'ler veya backup politikaları hedef alınabilir.

#### \7. Gün – Veri Sızıntısı

Kritik veriler kurum dışına çıkarılabilir.

#### \8. Gün – Encryption

Üretim sistemleri şifrelenir.

Bu aşamada kurumun backup altyapısı da kullanılamaz durumdaysa saldırganın fidye talebi çok daha güçlü hale gelir.

İşte bu nedenle modern backup stratejisinin temel sorusu değişmiştir.

Eskiden:

**“Kaç backup kopyamız var?”**

soruluyordu.

Bugün ise:

**“Bu kopyalardan kaçı saldırganın erişemeyeceği durumda?”**

sorusu sorulmalıdır.

### 3-2-1-1-0 Backup Stratejisi Nedir?

Modern yedekleme dünyasında kullanılan gelişmiş yaklaşımlardan biri **3-2-1-1-0 backup kuralıdır.**

Model şu şekilde açıklanabilir:

**3**

Verinin en az üç kopyası bulunur.

**2**

Bu kopyalar en az iki farklı depolama ortamında tutulur.

**1**

Kopyalardan en az biri farklı bir lokasyonda bulunur.

**1**

Kopyalardan en az biri **offline, air-gapped veya immutable** olarak korunur.

**0**

Backup doğrulamalarında **sıfır hata** hedeflenir.

Son iki madde modern tehdit ortamı açısından son derece önemlidir.

### İkinci “1” Neden Kritik?

Klasik 3-2-1 stratejisindeki offsite backup coğrafi felaketlere karşı güçlü koruma sağlar.

Ancak saldırgan ağ üzerinden uzak backup sistemine erişebiliyorsa fiziksel olarak başka şehirde bulunması tek başına yeterli değildir.

Örneğin Ankara'daki üretim sistemi ile İstanbul'daki backup sistemi aynı Active Directory kimlik bilgileriyle yönetiliyorsa saldırgan Ankara ortamını ele geçirdikten sonra İstanbul'daki backup'a da ulaşabilir.

Bu nedenle modern backup mimarisinde **mantıksal izolasyon** da önemlidir.

Backup farklı lokasyonda olabilir.

Ama aynı zamanda farklı bir güvenlik sınırında bulunmalıdır.

### Immutable Backup Nedir?

Immutable backup, belirli bir retention süresi boyunca değiştirilemeyen veya silinemeyen backup kopyasıdır.

“Immutable” kelimesi:

**değiştirilemez**

anlamına gelir.

Örneğin bir backup kopyası 30 günlük immutable retention ile oluşturulduysa bu süre içerisinde backup'ın değiştirilmesi veya silinmesi ciddi şekilde sınırlandırılır.

Bu yaklaşım ransomware savunmasında son derece değerlidir.

Çünkü saldırgan backup yönetim sistemine erişse bile değiştirilemez kopyaları ortadan kaldırması zorlaşır.

### Immutable Backup Neden Ransomware'e Karşı Etkilidir?

Saldırganın amacı kurtarma seçeneklerini yok etmektir.

Eğer kurumun;

7 günlük,

14 günlük,

30 günlük

veya iş ihtiyacına göre daha uzun süre saklanan temiz immutable backup kopyaları varsa saldırgan production ortamını şifrelese bile kurum geçmişteki temiz noktaya geri dönebilir.

Ancak burada kritik bir detay vardır.

Immutable backup yalnızca bir ürün özelliği değildir.

**Bir mimari ve güvenlik yaklaşımıdır.**

Yanlış yapılandırılmış immutable storage beklenen güvenliği sağlamayabilir.

### Immutable Backup Nasıl Korunmalıdır?

Immutable backup mimarisinde özellikle aşağıdaki kontroller değerlendirilmelidir:

- backup administrator hesaplarının ayrılması,
- Multi-Factor Authentication kullanılması,
- minimum yetki prensibi,
- production domain'den bağımsız yönetim,
- ayrı network segmentleri,
- retention lock,
- güvenli object storage,
- kritik işlemlerde ek doğrulama,
- backup loglarının izlenmesi,
- değişikliklerin alarm üretmesi.

Özellikle retention süresinin saldırgan tarafından kolayca değiştirilememesi önemlidir.

### Air-Gap Backup Nedir?

Air-gap backup, backup ortamının üretim sistemlerinden izole edilmesi yaklaşımıdır.

Kelime anlamı olarak iki sistem arasında “hava boşluğu” bulunmasını ifade eder.

Klasik fiziksel air-gap örneği tape backup'tır.

Tape üzerine backup alındığını düşünelim.

İşlem tamamlandıktan sonra tape sürücüden çıkarılır ve güvenli bir fiziksel alanda saklanır.

Bu tape artık network üzerinden erişilebilir değildir.

Dolayısıyla saldırgan bütün ağı ele geçirse bile fiziksel olarak bağlantısı olmayan tape'e doğrudan ulaşamaz.

### Physical Air-Gap ve Logical Air-Gap

Air-gap iki temel biçimde uygulanabilir.

#### Physical Air-Gap

Backup medyasının fiziksel olarak üretim ortamından ayrılmasıdır.

Tape bunun klasik örneğidir.

Avantajı oldukça güçlü izolasyon sağlamasıdır.

Dezavantajı ise operasyonel süreçlerin daha karmaşık olabilmesidir.

#### Logical Air-Gap

Modern veri merkezlerinde fiziksel bağlantının tamamen kesilmesi her zaman pratik olmayabilir.

Bu nedenle mantıksal izolasyon kullanılabilir.

Örneğin;

backup repository'nin sürekli erişilebilir olmaması,

ayrı credential kullanılması,

ayrı network segmentinde tutulması,

erişimin belirli zamanlarda açılması,

immutable object storage kullanılması,

backup sisteminin production domain'e dahil edilmemesi

logical air-gap yaklaşımının parçaları olabilir.

### Offline Backup Nedir?

Offline backup, normal operasyon sırasında network üzerinden erişilebilir olmayan yedek kopyasıdır.

Offline backup ransomware saldırılarına karşı güçlü bir savunma katmanı sağlayabilir.

Çünkü network bağlantısı bulunmayan bir backup'a saldırganın uzaktan erişmesi çok daha zordur.

Ancak offline backup operasyonlarında da;

fiziksel güvenlik,

medya takibi,

şifreleme,

envanter yönetimi,

saklama koşulları,

restore prosedürleri

dikkate alınmalıdır.

### Cloud Backup 3-2-1 Stratejisinde Kullanılabilir mi?

Evet.

Bulut depolama 3-2-1 stratejisindeki offsite kopya için oldukça uygun olabilir.

Örneğin:

#### Production Storage

↓

#### Local Backup Repository

↓

#### Cloud Object Storage

şeklinde bir mimari oluşturulabilir.

Ancak cloud backup'ın güvenliği doğru yapılandırılmalıdır.

Özellikle;

MFA,

IAM politikaları,

object lock,

immutable storage,

encryption,

ayrı hesap veya subscription,

audit logging

gibi kontroller önemlidir.

### Backup'ı Aynı Cloud Hesabında Tutmak Yeterli mi?

Her zaman değil.

Örneğin production workload ve backup storage aynı cloud hesabında ve aynı administrator credential'ları ile yönetiliyorsa yüksek yetkili hesabın ele geçirilmesi iki ortamı da riske atabilir.

Bu nedenle kritik sistemlerde **account separation** değerlendirilebilir.

Örneğin:

#### Production Cloud Account

ve

#### Backup Cloud Account

ayrı güvenlik sınırlarında tutulabilir.

Böylece production hesabının compromise edilmesi backup hesabının otomatik olarak ele geçirilmesine neden olmaz.

### Backup Sistemleri Active Directory'den Ayrılmalı mı?

Kritik yapılarda bu konu mutlaka değerlendirilmelidir.

Backup sunucusunun production Active Directory domain'ine tamamen bağımlı olması saldırı yüzeyini artırabilir.

Saldırgan Domain Admin yetkisi elde ettiğinde backup altyapısına erişebilirse yedekleri silebilir veya değiştirebilir.

Bu nedenle modern backup güvenliği yaklaşımında;

ayrı administrator hesapları,

ayrı authentication mekanizmaları,

MFA,

PAM,

network segmentation

ve gerektiğinde domain bağımsız backup yönetimi

kullanılabilir.

### Zero Trust Backup Yaklaşımı

Zero Trust prensibinin temel mantığı:

#### Never Trust, Always Verify

yaklaşımıdır.

Bu prensip backup altyapısına da uygulanabilir.

Hiçbir kullanıcı veya sistem yalnızca network içerisinde olduğu için güvenilir kabul edilmemelidir.

Backup işlemleri için minimum yetki verilmelidir.

Yönetici işlemleri doğrulanmalıdır.

Kritik değişiklikler loglanmalıdır.

Backup administrator hesapları günlük kullanıcı hesaplarından ayrılmalıdır.

MFA kullanılmalıdır.

Repository erişimleri sınırlandırılmalıdır.

Bu yaklaşım backup sistemini kurumun geri kalan altyapısından bağımsız bir güvenlik bölgesi haline getirir.

**“0” Ne Anlama Geliyor?**

3-2-1-1-0 stratejisindeki son rakam çoğu zaman gözden kaçırılır.

**0 = Backup doğrulamalarında sıfır hata**

anlamına gelir.

Çünkü backup'ın alınmış olması tek başına yeterli değildir.

Backup bozuk olabilir.

Dosya okunamayabilir.

Database restore edilemeyebilir.

Encryption key kaybolmuş olabilir.

Uygulama backup'tan açılmayabilir.

Bu nedenle backup'ların düzenli olarak doğrulanması gerekir.

### Restore Testi Neden Zorunludur?

Bir kurumun backup dashboard'unda her şey yeşil görünebilir.

100 backup job çalışmış olabilir.

100'ü de:

#### SUCCESS

durumunda olabilir.

Ancak gerçek soru şudur:

#### Kaçı gerçekten restore edildi?

Bu soru backup olgunluğunu ölçmek açısından son derece değerlidir.

Restore testlerinde yalnızca bir dosyanın açılması yeterli olmayabilir.

Kritik sistemler için;

virtual machine restore,

database restore,

application restore,

Active Directory recovery,

file-level recovery,

bare-metal recovery

gibi senaryolar test edilmelidir.

### Backup Doğrulaması Otomatik Yapılabilir mi?

Modern backup çözümlerinde belirli doğrulama süreçleri otomatikleştirilebilir.

Örneğin backup'tan sanal makine izole ortamda başlatılabilir.

İşletim sisteminin açılıp açılmadığı kontrol edilebilir.

Uygulama servisleri test edilebilir.

Malware taraması yapılabilir.

Backup integrity kontrol edilebilir.

Ancak otomatik doğrulama insan kontrollü DR tatbikatlarının tamamen yerini almamalıdır.

### Clean Backup Kavramı Neden Önemlidir?

Bir diğer kritik konu backup'ın yalnızca sağlam değil, **temiz** olmasıdır.

Düşünün:

Saldırgan sisteme 1 Haziran'da girdi.

Kurum saldırıyı 20 Haziran'da fark etti.

Bu süre boyunca her gün backup alındı.

Kurumda;

19 Haziran,

18 Haziran,

17 Haziran,

16 Haziran

backup'ları bulunuyor.

Ancak saldırgan 1 Haziran'dan beri sistem içerisindeyse bu backup'ların içerisinde saldırgana ait persistence mekanizmaları bulunabilir.

Bu nedenle incident response sırasında:

**“En yeni backup hangisi?”**

sorusu kadar:

**“Son temiz backup hangisi?”**

sorusu önemlidir.

### Backup Retention Süresi Nasıl Belirlenmeli?

Her backup sonsuza kadar saklanamaz.

Depolama maliyetleri ve veri yaşam döngüsü nedeniyle retention politikası oluşturulmalıdır.

Örneğin bir yapı;

günlük backup'ları 30 gün,

haftalık backup'ları 12 hafta,

aylık backup'ları 12 ay,

yıllık backup'ları daha uzun süre

saklayabilir.

Ancak bunlar evrensel rakamlar değildir.

Retention süresi;

iş gereksinimleri,

RPO,

RTO,

regülasyon,

veri sınıflandırması,

saklama yükümlülükleri,

storage kapasitesi,

ransomware risk modeli

dikkate alınarak belirlenmelidir.

### Backup Encryption Neden Önemlidir?

Backup repository çoğu zaman kurumun bütün kritik verilerini bir arada içerir.

Bu nedenle saldırgan açısından son derece değerli bir hedeftir.

Backup içerisinde;

müşteri kayıtları,

kişisel veriler,

finansal bilgiler,

ERP verileri,

personel bilgileri,

e-posta verileri,

fikri mülkiyet,

ticari sırlar

bulunabilir.

Bu nedenle backup verilerinin şifrelenmesi önemlidir.

İki temel alan değerlendirilmelidir:

#### Encryption at Rest

ve

#### Encryption in Transit

Ancak encryption key'lerin güvenliği de ayrıca yönetilmelidir.

Anahtar kaybedilirse kurum kendi backup'ını açamayabilir.

Anahtar saldırgan tarafından ele geçirilirse şifrelemenin koruma değeri azalabilir.

### Backup Network'ü Ayrılmalı mı?

Kritik yapılarda evet.

Backup trafiğinin production network üzerinde kontrolsüz biçimde dolaşması hem güvenlik hem performans problemi oluşturabilir.

Ayrı;

VLAN,

network segment,

firewall zone

veya fiziksel backup network

kullanılabilir.

Backup sunucularının internete erişimi de ihtiyaç doğrultusunda sınırlandırılmalıdır.

Amaç backup altyapısının saldırı yüzeyini mümkün olduğunca küçültmektir.

### Modern Kurumsal Backup Mimarisi Nasıl Görünebilir?

Örnek bir yapı düşünelim:

#### Katman 1 – Production

Kurumun aktif sistemleri.

#### Katman 2 – Local Backup

Hızlı restore için lokal repository.

#### Katman 3 – Offsite Backup

Farklı veri merkezi veya coğrafi lokasyon.

#### Katman 4 – Immutable Backup

Belirli süre değiştirilemeyen kopya.

#### Katman 5 – Air-Gapped / Offline Backup

Production network'ten izole kurtarma kopyası.

Bu katmanların tamamının her kurumda bulunması zorunlu değildir.

Ancak sistem kritikliği arttıkça koruma katmanlarının da artırılması gerekir.

### Backup Stratejisi RPO ve RTO ile Birlikte Tasarlanmalıdır

3-2-1 veya 3-2-1-1-0 stratejisi tek başına yeterli değildir.

Backup mimarisinin kurumun RPO ve RTO hedeflerini karşılaması gerekir.

Örneğin:

**RPO = 15 dakika**

olan bir sistem için yalnızca gece 02:00'de backup almak yeterli değildir.

Benzer şekilde:

**RTO = 30 dakika**

olan bir sistemin tape backup'tan saatlerce restore edilmesi hedefi karşılamayabilir.

Bu nedenle backup teknolojisi iş gereksinimleriyle birlikte tasarlanmalıdır.

### Her Sistem İçin Aynı Backup Politikası Kullanılmalı mı?

Hayır.

Kurumdaki tüm sistemlerin kritikliği aynı değildir.

Örneğin;

Tier 1 – Kritik sistemler

Tier 2 – Önemli sistemler

Tier 3 – Standart sistemler

şeklinde sınıflandırma yapılabilir.

Tier 1 sistemler için;

daha düşük RPO,

daha düşük RTO,

daha sık backup,

immutable kopya,

offsite backup,

DR replikasyonu

kullanılabilir.

Daha düşük kritik seviyedeki sistemlerde ise daha ekonomik politikalar uygulanabilir.

Bu yaklaşım backup maliyetlerinin optimize edilmesine yardımcı olur.

### En Büyük Backup Hataları Nelerdir?

Kurumsal ortamlarda sık karşılaşılan hatalardan bazıları şunlardır:

- yalnızca tek backup kopyası tutmak,
- backup ile production'ı aynı storage üzerinde tutmak,
- snapshot'ı backup olarak değerlendirmek,
- replikasyonu backup zannetmek,
- backup administrator hesabını production domain hesabıyla yönetmek,
- MFA kullanmamak,
- backup repository'yi network üzerinde gereğinden fazla erişilebilir bırakmak,
- immutable backup kullanmamak,
- offsite kopya oluşturmamak,
- restore testi yapmamak,
- backup loglarını izlememek,
- retention sürelerini iş ihtiyaçlarına göre belirlememek,
- ransomware senaryosunu backup tasarımına dahil etmemek.

Bu hataların bazıları tek başına kritik görünmeyebilir.

Ancak gerçek bir saldırı sırasında birkaçının aynı anda bulunması kurumun bütün kurtarma kabiliyetini ortadan kaldırabilir.

### Backup Başarısı Nasıl Ölçülmeli?

Backup başarısını yalnızca:

#### Backup Success Rate

ile ölçmek yeterli değildir.

Daha olgun bir yaklaşımda;

backup başarı oranı,

restore başarı oranı,

restore süresi,

RPO uyumu,

RTO uyumu,

immutable backup kapsamı,

offsite backup kapsamı,

restore test sıklığı,

kritik sistem coverage oranı,

backup güvenlik olayları

gibi metrikler takip edilebilir.

Çünkü backup sisteminin gerçek görevi veri kopyalamak değil:

**veriyi geri getirmektir.**

### Kurumlar Hangi Backup Modelini Kullanmalı?

Tek bir doğru backup mimarisi yoktur.

Doğru model kurumun;

veri hacmine,

kritik sistemlerine,

iş sürekliliği hedeflerine,

regülasyonlarına,

altyapısına,

bütçesine,

RPO/RTO gereksinimlerine,

ransomware riskine

göre belirlenmelidir.

Ancak günümüz tehdit ortamında yalnızca aynı network üzerinde bulunan tek bir backup repository kullanılması kritik sistemler için yeterli bir strateji olarak görülmemelidir.

Modern yaklaşımın temel amacı:

**yedek oluşturmak değil, kurtarılabilirliği garanti altına almaktır.**

### Sonuç: Backup Stratejisi “Kaç Kopyamız Var?” Sorusundan Daha Fazlasıdır

3-2-1 backup kuralı veri korumanın en güçlü temel prensiplerinden biridir.

Ancak modern siber saldırılar backup dünyasının kurallarını değiştirmiştir.

Bugün saldırgan yalnızca production sistemini hedeflemiyor.

Backup sunucusunu,

snapshot'ları,

storage sistemlerini,

administrator hesaplarını,

cloud backup hesaplarını,

restore point'lerini

de hedefleyebiliyor.

Bu nedenle klasik:

#### 3-2-1

yaklaşımı birçok kritik altyapıda;

#### 3-2-1-1-0

gibi daha dayanıklı modellerle güçlendirilmektedir.

Modern backup stratejisinin temel bileşenleri;

**çoklu kopya,**

**farklı depolama ortamları,**

**offsite backup,**

**immutable backup,**

**air-gap,**

**kimlik izolasyonu,**

**şifreleme,**

**MFA,**

**network segmentasyonu**

ve en önemlisi:

**düzenli restore testidir.**

Çünkü felaket anında kurum için en değerli backup en yeni backup değildir.

**Güvenli, temiz ve gerçekten geri yüklenebilen backup'tır.**