1. Neden yedekleme ve felaket kurtarma?

• Donanım arızası, insan hatası, kötü amaçlı yazılım (ransomware), doğal afet veya veri bozulması gibi olaylar veri ve hizmet kaybına yol açar.
• İş sürekliliğini sağlamak, yasal uyumluluğu korumak ve müşteri güvenini sürdürmek için planlı, test edilmiş yedekleme ve DR stratejileri gereklidir.

2. Temel kavramlar ve yedekleme türleri

• Dosya düzeyinde yedekleme: Bireysel dosya/klasörlerin yedeklenmesi. Hızlı geri dönüş (granüler restore). Dezavantaj: sistem durumunu veya program tutarlılığını tek hamlede geri getirmez.
• Görüntü (imaj) tabanlı yedekleme: Disk/partition tabanlı tam kopya. Hızlı tam sistem geri yükleme sağlar; yapılandırma ve işletim sistemi dahil geri gelir.
• Snapshot (anlık görüntü): Depolama veya hiper yönetici (VMware/Hyper-V) seviyesinde anlık kopya. Hızlı, düşük gecikmeli; genelde kısa süreli koruma ve hızlı rollback için uygundur. Uzun süreli arşivleme için yeterli olmayabilir.
• Veritabanı/transaction-log yedekleri: Veritabanı tutarlılığını korumak için özel yöntemler (logical dump, physical backup, log shipping).
• Sürekli replika (continuous replication): Senkron/aynı zamanlı veya asenkron replikasyon. Düşük RPO için tercih edilir.
• Immutable/Write-Once yedekleme: Değiştirilemeyen yedekler, özellikle ransomware koruması için önemlidir.

3. Snapshot vs İmaj vs Dosya Bazlı: Ne zaman hangi yöntemi?

• Snapshot: Hızlı rollback, kısa dönem koruma, test ortamlarda veya VM’lerde anında geri dönüş gerektiren durumlarda.
• İmaj (disk) yedek: Tam sistem restore gerektiğinde (sunucu kurtarma, donanım değişimi). İmajlar donanım bağımlılıklarını ele alacak şekilde kullanılmalı (sysprep, drivers).
• Dosya düzeyi: Belgeler, home dizinleri, loglar için uygun; granüler kurtarma gerektiğinde tercih edilir.
• Öneri: Önem derecesine göre hibrit yaklaşım (kritik sistemler için imaj + sürekli replika, uygulama verileri için veritabanı log backup + dosya düzeyi yedek).

4. RTO ve RPO: Tanım ve hesaplama

RTO (Recovery Time Objective): Hizmetin yeniden işlevsel olması için kabul edilebilir maksimum süre. Örnek: RTO = 4 saat → restorasyonun 4 saat içinde tamamlanması gerekir.

RPO (Recovery Point Objective): Kabul edilebilir maksimum veri kaybı süresi. Örnek: RPO = 1 saat → en fazla 1 saatlik veri kaybı kabul edilebilir.

Nasıl belirlenir

• İş etki analizleri (BIA) yapın: Hangi sistemler iş süreçlerini nasıl etkiler?
• Hızlı gelir/maliyet/durum analizi: 1 saatlik kesinti maliyeti nedir?
• Hangi RTO/RPO’ları karşılamak için hangi teknoloji gerekli (snapshot, replika, log shipping)?

Örnekler

• Kritik çevrimiçi satış platformu: RTO < 30 dk, RPO < 1 dk → aktif-aktif replikasyon, global yük dengeleyici.
• İç yönetim sunucusu: RTO = 24 saat, RPO = 12 saat → günlük imaj + günlük artımlı yedek.

5. Yedekleme sıklığı ve örnek çizelgeler

Sıklık, RPO gereksinimine göre belirlenir.

Örnek 1 — Kritik uygulama

• Sürekli replika (near-real-time)
• Saatlik transaction log backup
• Günlük tam imaj gece
• Haftalık offsite arşiv

Örnek 2 — Orta öncelikli

• Günlük artımlı yedek (saatlik artımlar mümkünse)
• Haftalık tam yedek
• Aylık arşiv

Örnek 3 — Arşiv / düşük öncelikli

• Haftalık tam yedek
• Aylık arşiv (uzun dönem saklama)

Retention (saklama) önerileri

• Kısa dönem: Günlük yedekler 30 gün
• Orta dönem: Haftalık 3 ay
• Uzun dönem: Aylık/ yıllık 7 yıl (yasal gereksinimlere göre)

6. Offsite yedekleme ve coğrafi dağıtım

Offsite neden gerekli? Aynı fiziksel lokasyon felaketinde yerel yedekler kaybolur.

Yöntemler

• Bulut depolama (S3/Blob/Coldline): Esneklik, ölçek, kopyalama politikaları, çoğu zaman daha kolay otomasyon.
• Taşınabilir medya / Tape (LTO): Maliyet etkin uzun süreli arşiv, fiziki taşıma riski vardır.
• İkinci veri merkezi (DR site): Daha hızlı failover ama maliyet yüksek.
• Hibrid: Kritik veriler için anlık replikasyon + uzun dönem arşiv için bulut/tape.

Offsite Kriterleri

• Veri tutarlılığı ve şifreleme
• Coğrafi mesafe ve yasal uyumluluk
• Erişim süreleri (cold vs hot storage)

7. Güvenlik ve uyumluluk

• Şifreleme: Hem tranist (TLS) hem de at-rest (AES-256) şifreleme uygulayın.
• Anahtar yönetimi: KMS veya sahip olduğunuz HSM kullanarak anahtarları yönetin.
• Erişim kontrolü: Yedek yönetim sistemine sadeleştirilmiş, denetlenebilir, rol tabanlı erişim (RBAC).
• Immutable yedekler ve WORM depolama: Ransomware’e karşı koruma sağlar.
• Loglama ve denetim: Yedekleme/restore işlemlerinin audit kayıtları olmalı.
• Uyumluluk: GDPR, KVKK, HIPAA gibi düzenlemelere uygun retentions ve veri yerleşimi planlayın.

8. Yedekleme doğrulama ve bütünlük kontrolü

• Yedek alma yeterli değildir; doğrulama gereklidir:
• Checksum/hashtag kontrolü
• Otomatik restore doğrulamaları (sandbox ortamda mount edip kontrol)
• Zaman damgası, yedek başarı oranı raporları
• Düzenli test edilmiş geri dönüşler, yedeklerin güvenilirliğini sağlar.

9. Otomasyon ve yedekleme yönetimi

Otomasyo neden? İnsan hatasını azaltmak, tutarlılığı artırmak, tekrarlanabilirlik.

Ne otomatikleştirilmeli?

• Planlı yedek görevleri (tam, fark, artımlı)
• Offsite transfer ve lifecycle yönetimi
• Uyarı ve hata işleme
• Test otomasyonu (restore simülasyonları)

Araçlar / yaklaşımlar

• Kurumsal: Veeam, Commvault, Rubrik, Veritas NetBackup
• Açık kaynak / küçük ölçek: Bacula, Duplicati, Restic, Borg, Borgmatic
• Bulut-native: AWS Backup, Azure Backup, Google Cloud Storage ile snapshot/AMI
• Kubernetes: Velero, Kasten K10

IaC: Infrastructure as Code (Terraform, Ansible, ARM) ile backup politikalarını kodlayın.

Orkestrasyon: On-call bildirimleri, otomatik failover playbook’ları (runbooks + automation triggers).

10. Kurtarma testleri: Türler, planlama ve frekans

Test türleri

• Tabletop (masa başı) tatbikat: Senaryolar üzerinden sorumlularla tartışma.
• Parça testi (component): Tek bir servis veya veri setinin geri yüklenmesi.
• Tam failover testi: DR site’ye geçiş simülasyonu (production etkilenmeden yapılmalı).
• Tatbikat içinde üretim (canary) testi: Sınırlı üretim kesintisi ile küçük kullanıcı grupları üzerinde test.

Frekans önerisi

• Kritik sistemler: Aylık parça test, çeyreklik tam restore testi
• Orta seviye: Çeyrek bazlı parça test, yıllık tam test
• Tabletop: En az yılda bir

Test sonrası: Sonuçların dokümantasyonu, eksikliklerin action-item olarak takip edilmesi.

11. Felaket Kurtarma Planı (DRP) — Adım Adım (Örnek Runbook)

Hazırlık

• Sorumlular listesi (DR Coordinator, IT Lead, DBAs), iletişim kanalları
• DR kriterleri: Bu durumlarda DR uygulanır (ör. veri merkezi çöktü, süre > X)

Olay tespit

• Olayı sınıflandır, RTO/RPO’yu yeniden onayla
• İlk bildirimleri yap (yönetim, müşteri, yasal gereklilikler)

Activate DR

• DR ilanı yap, DR site veya cloud failover tetikle
• DNS, load balancer, IP yönlendirme planını çalıştır
• Öncelikli servislerin sırasını takip et (kritik → kritik olmayan)

Restore adımları (örnek)

1. En son tutarlı imajı belirle
2. İmajı DR hosta aktar ve mount et
3. Veritabanı log replay veya restore
4. Ağ ve güvenlik yapılandırmasını kontrol et
5. Smoke test (sağlık kontrolleri + temel işlevsellik)
6. Kullanıcı kabul testi (UAT) ve üretime kademeli geçiş

Post-incident

• Olay raporu ve root cause analysis (RCA)
• Onarım, iyileştirme ve politika güncellemeleri
• Öğrenilen derslerin uygulanması

12. KPI’lar ve izleme

İzlenecek ana metrikler

• Yedek başarı oranı (%)
• Ortalama restore süresi vs hedef RTO
• Geri yükleme doğrulama süresi
• Yedek büyüme oranı ve depolama maliyeti/GB
• RPO sapmaları (kaç olayda RPO aşıldı)

Uyarılar

• Başarısız yedek bildirimi, tutmayan doğrulama, replication lag yüksekliği

Raporlama: Haftalık/aylık dashboard ve üst yönetime özet.

13. Maliyet ve kapasite planlaması

Maliyet kalemleri: Depolama (hot/cold), network (egress ücretleri), lisans, personel, DR site maliyeti.

Optimizasyon

• Data deduplication ve compression
• Lifecycle policies ile cold storage’a taşıma
• Sık kullanılmayan veriler için daha uzun RTO/RPO kabulü

Örnek hesaplama: Kritik veri 10 TB ise, depolama + egress + yönetim maliyeti yıllık tahmini çıkarılmalı; bulutta cold vs hot arasında seçim.

14. Yaygın hatalar ve nasıl önlenir

• Hata: Yedeklerin restore edilmediği — Çözüm: Düzenli restore testleri ve doğrulama.
• Hata: Tek lokasyonda yedek tutma — Çözüm: En az bir offsite kopya.
• Hata: Yedeklerin güvenli olmaması (şifreleme yok) — Çözüm: Hem transfer hem at-rest şifreleme, anahtar yönetimi.
• Hata: İyi tanımlanmamış RTO/RPO — Çözüm: BIA yap, önceliklendirme ve teknoloji eşleştirmesi.
• Hata: Aşırı manuel süreçler — Çözüm: Otomasyon, orkestrasyon, playbook.
• Hata: Yedeklerin yanlış konfigürasyonu (permissions, retention) — Çözüm: IaC ile versiyon kontrolü ve kod inceleme.

15. Hemen uygulayabileceğiniz 10 adım

1. Tüm sistemlerin envanterini çıkarın ve kritiklik sınıflandırması yapın.
2. BIA ile RTO/RPO hedeflerini belirleyin.
3. Minimum bir yedek stratejisi kurun: günlük tam + artımlı + offsite.
4. Offsite/immutable çözüm seçin (cloud veya tape).
5. Şifreleme ve RBAC kurallarını hemen uygulayın.
6. Otomatik yedek görevleri oluşturun ve uyarılar kurun.
7. Haftalık doğrulama (checksum/mount) otomasyonu kurun.
8. Çeyreklik parça testleri ve yıllık tam failover testi planlayın.
9. DR runbook’larını yazın ve iletişim planını netleştirin.
10. KPI dashboard’u oluşturun ve yönetimle paylaşın.

16. Örnek Restore Runbook (kısa)

Olay: Ana DB sunucusu çöktü

1. DR Coordinator’a bildir
2. En son tutarlı DB backup’ını belirle (tarih/saat)
3. Yedek imajı/backup dosyasını DR host’a transfer et
4. Restore komutunu çalıştır (DB engine’e göre)
5. Log replay/transaction apply
6. Bağlantı testleri, uygulama smoke test
7. Kullanıcı onayı alınıp servisi geri aç
8. Olay raporu oluştur

17. Özel durumlar: Sanallaştırma, konteynerler, veritabanları

• VM: Hypervisor snapshot + imaj yedek kombinasyonu; VMware Tools / VSS kullanarak uygulama tutarlılığı sağlanmalı.
• Kubernetes: Velero ile PV snapshot + namespace backup; persistent volumes için storage provider snapshot’ları.
• Veritabanları: Logical dump (pg_dump, mysqldump) vs physical backup; transaction log/redo/archivelog süreçleri kritik.

18. Sonuç ve takip

Yedekleme ve felaket kurtarma, bir proje değil sürekli bir süreçtir. Teknoloji, veri hacmi ve tehdit ortamı değiştikçe politikalarınızı, test frekansınızı ve otomasyonunuzu güncelleyin. En iyi savunma; iyi tanımlı RTO/RPO, otomatik, doğrulanmış yedekler ve sık test edilmiş bir DR planıdır.

Sık Sorulan Sorular (kısa)

Hangi veriyi yedeklemeliyim?

Kritik iş yüklerini ve kurtarma için gerekli konfigürasyonları önceliklendirin.

Bulut yedekleme güvenli midir?

Evet, uygun şifreleme ve IAM uygulandığında güvenlidir. Egress maliyetlerini göz önünde bulundurun.

Haftalık mı günlük mi yedek?

RPO hedefinize göre; kritik için sürekli veya saatlik, az kritik için günlük/haftalık.

Snapshot yeterli mi?

Kısa süreli rollback için yeterli; uzun dönem arşiv ve tam sistem dönüşleri için imaj/dosya yedeklerini de kullanın.

Ek kaynak ve araç önerileri (başlangıç)

• Veeam, Commvault, Rubrik (kurumsal)
• Restic, Borg, Bacula (açık kaynak)
• AWS Backup, Azure Backup, Google Cloud Storage (bulut-native)
• Velero, Kasten K10 (Kubernetes)
• HashiCorp Vault (anahtar yönetimi)

İhtiyacınız olursa

Kurumunuza özel yedekleme/DR planı oluşturabilirim (envanter, RTO/RPO analizi, örnek yedek çizelgesi, test planı). Mevcut altyapınızı gözden geçirip kısa bir GAP analizi raporu da hazırlayabilirim.

Başlamak için: Bana altyapınızın kısa bir özetini (sunucu sayısı/tipleri, veritabanları, bulut/on-prem karışımı, mevcut yedekleme araçları) gönderin — size uygulanabilir bir yol haritası çıkarayım.