Küçük Siteler İçin Disaster Recovery Planı: Hazır Yol Haritası

Disaster recovery (DR) planı, siteniz için “kötü senaryo olursa ne yaparım?” sorusuna net yanıt verir. Trafiği yüksek olmayan küçük sitelerde bile yanlış bir adım, saatlerce erişim kaybı veya veri kaybı yaratabilir. Bu rehberde küçük ölçekli ekipler için uygulanabilir bir DR planı kurmayı; hedefleri (RTO/RPO), yedekleme stratejisini, barındırma katmanlarını ve düzenli testi tek bir yol haritasında anlatıyorum. Amaç; planı kâğıt üzerinde bırakmamak, ölçülebilir hale getirmek.

1) Hedefleri Sayıyla Belirleyin: RTO ve RPO

DR planının ilk aşaması, “ne kadar hızlı geri döneceksin” ve “ne kadar veri kaybı kabul edebilirsin” sorularını metrikleştirmektir.

RTO (Recovery Time Objective): Hizmetin kesintiden sonra ne kadar sürede geri dönmesi gerektiği.
RPO (Recovery Point Objective): Kesinti anına göre ne kadar veri kaybını kabul edebileceğiniz (yedek aralığı ve tutarlılığı buna doğrudan etki eder).

Küçük siteler için pratik hedef örnekleri:

Statik ağırlıklı site (blog, rehber):
RTO: 1-4 saat
RPO: 24 saat (içerik güncellemesi sık değilse)
WordPress / küçük e-ticaret:
RTO: 2-6 saat
RPO: 1-6 saat (sipariş/üye veri kaybını minimize etmek için)
Kullanıcı formu / kayıt alan uygulama:
RTO: 2-8 saat
RPO: 1-12 saat

Hedefler neden kritik?

Yedekleme sıklığı, yedekten geri dönüş (restore) adımının süresi ve altyapının yeniden ayağa kalkma şekli RTO/RPO’ya göre seçilir. Hedefi yazmadan teknoloji seçmek, “yanlış ölçekte” yatırım yapmaya yol açar.

2) DR Mimarisi: Tek Noktayı Kaldırın

Küçük sitelerde en sık hata; her şeyin aynı yerde tutulmasıdır. Örneğin hem web uygulaması hem veritabanı hem de yedek aynı sağlayıcı/aynı hesap içinde duruyorsa, bir kimlik doğrulama problemi ya da silme hatası “tek hamlede” her şeyi etkileyebilir.

Minimum DR seti (küçük site için uygulanabilir)

Aşağıdaki bileşenleri düşünün:

Uygulama katmanı: web dosyaları / uygulama imajı / CMS içerikleri
Veri katmanı: veritabanı (DB), kullanıcı tabloları, siparişler
Yedekleme katmanı: yedeklerin kopyası ve saklama politikası
Geri dönüş planı: yedeği geri alıp hizmeti ayağa kaldırma prosedürü
Kimlik ve erişim: admin erişimi, SSH/RDP, kontrol paneli yetkileri
İzleme ve uyarı: kesintiyi erken yakalama

Tek sağlayıcı riskini azaltan yöntemler

Küçük ölçekte bile şu yaklaşımlar fark yaratır:

Yedekleri aynı fiziksel veri merkezine koymamak: aynı sağlayıcının farklı lokasyon seçenekleri varsa kullanın.
Yedekleri “salt okunur” mantığıyla saklamak: silme/şifre bozulması gibi senaryolarda geri dönüş ihtimalini artırır.
Yedekleri ayrı bir hesaba taşımak: uygulama hesabı kilitlenirse yedek erişimi aynı sorunda çakışmaz.

3) Yedekleme Stratejisini RTO/RPO’ya Göre Kurun

Yedekleme DR’nin omurgasıdır. Ancak “yedek alıyorum” demek yetmez; yedeklerin erişilebilir ve restore edilebilir olması gerekir.

3-2-1 yaklaşımı (kayıtlı pratik)

3 kopya: üretim + en az iki yedek kopyası
2 farklı medya/tür: örn. sunucu diski + bulut object storage
1 kopya farklı lokasyon/erişim alanı: örn. farklı hesap / farklı veri merkezi

Küçük siteler için net yedekleme planı örneği

Veritabanı (DB):
Saatlik (RPO 1-6 saat hedefi için)
Günlük tam (24 saat hedefi için)
Uygulama dosyaları / içerik:
İçerik güncellemesi sık değilse 6-24 saat arası
Güncellemeler sık ise saatlik
Yedek saklama süresi:
Son 7 gün: saatlik yedekler
Son 30 gün: günlük yedekler
30+ gün: aylık yedek (gerekiyorsa)

Yedek türü seçimi: Tam mı, incremental mı?

Tam yedek (full backup): restore daha anlaşılır; veri miktarı küçükse ideal.
Artımlı yedek (incremental): depolama/transfer maliyeti düşer; restore süreci zincir mantığı gerektirebilir.

Küçük sitelerde çoğu ekip, DB boyutu ve restore süresini ölçerek tam + günlük planı tercih eder. Buradaki karar “teoride doğru” değil, “sizin restore süreniz” ile ilgilidir.

4) Geri Dönüş Prosedürü: Sihir Değil, Sıralı Adımlar

DR planının en değerli kısmı, kriz anında takip edeceğiniz restore adımlarının yazılı olmasıdır. Bu adımlar, sunucu türünüz (VPS/VDS/dedicated, managed hosting) ne olursa olsun mantık olarak aynıdır.

Restore runbook şablonu

Aşağıdaki başlıklarla kısa ama net bir doküman hazırlayın:

Hızlı değerlendirme

Kesinti türü nedir? (DNS mi, web mi, DB mi?)
En son çalıştığı tarih/saat nedir?
Yedekler erişilebilir mi?

Kapat ve güvenliği sağla

Zararlı süreç/erişim şüphesi varsa uygulamayı geçici durdurun.
Admin kullanıcılarına erişim varsa yetkileri gözden geçirin.

DB restore

Hedef timestamp/yedek seçin.
DB restore etmeden önce şema uyumluluğunu kontrol edin.
Uygulama ile DB bağlantı ayarlarını doğrulayın.

Uygulama dosyaları restore

İçerik/yüklemeler klasörlerini geri alın.
Uygulama konfigürasyon dosyalarını (env/ayarlar) doğru hale getirin.

Yayına alma ve doğrulama

Health check (ör. ana sayfa, login, ödeme/ürün akışı)
Log inceleme
Gerekirse kademeli trafiğe alma

Dokümanı neden test etmelisiniz?

Bir doküman ne kadar iyi yazılırsa yazılsın, restore sırasında sürprizler çıkar: sürüm uyumsuzluğu, parola/env eksikliği, yedek format farkı, eski şema.

5) Test ve Tatbikat: DR Planının Gerçek Ölçümü

DR planı ancak test edildiğinde “gerçek” olur. Küçük sitelerde test sıklığı ekip zamanına göre ayarlanmalıdır.

Test türleri

Restore testi (zorunlu): Aylık bir yedekten, staging ortamında geri dönüş yapın.
Failover tatbikatı (tercihen): Kritik durumda canlıya geçiş adımlarını tatbik edin.
Kimlik/erişim testi: Admin paneli, kontrol paneli, depolama hesabı ve şifrelerin erişilebilir olduğunu kontrol edin.

Minimum kontrol listesi (canlıya çıkmadan önce)

[ ] En az 1 yedek seti, staging’de restore edilebilir
[ ] Yedekler güncel ve erişilebilir (erişim anahtarı çalışıyor)
[ ] Uygulama konfigürasyonları restore sonrası eksiksiz
[ ] DB şema uyumu restore edilen sürümle sağlanıyor
[ ] DNS/HTTP yönlendirme mantığı planlanmış

Ölçüm metrikleri

Her restore testinden sonra şunları not edin:

Restore süresi (dakika)
Veri doğruluğu (en az 3 kritik kontrol: login, form gönderimi, içerik görüntüleme)
Hata noktaları (hangi adımda zaman kaybı oldu?)

Bu verilerle sonraki ay iyileştirme yaparsınız: yedek sıklığını, saklama süresini veya restore adımını güncellersiniz.

6) Küçük Siteler İçin Pratik Donanım/Kurgu Seçenekleri

DR planı, “hangi altyapıda barındırıyorum?” sorusuna göre farklılaşır. Aşağıdaki seçenekler, küçük sitelerin tipik ihtiyaçlarına karşılık gelir.

Senaryo A: Shared hosting / yönetilen hosting

Sağlayıcının yedekleme politikası varsa DR planınızın merkezine restore erişimi koyun.
Şu soruları cevaplayın:
Yedek geri dönüş talebi ne kadar sürer?
Yedekler kaç gün saklanır?
Tüm veri mi yoksa dosya/DB mi ayrı geri döndürülür?

Senaryo B: VPS/VDS (kendi yönetiminizin olduğu kurulumlar)

DB için ayrı yedekleme (ve mümkünse farklı konumda saklama)
Uygulama dosyaları için yedek + düzenli kontrol
Restore runbook + staging testi

Küçük ekipler için iyi bir yaklaşım, sistemleri “tek komutla ayağa kaldırılabilir” hale getirmeye çalışmaktır. Örneğin:

Dosyalar ve config net klasörlerde
DB şema değişiklikleri izleniyor
Ortam değişkenleri (environment variables) yazılı ve versiyonlanmış

Senaryo C: CDN/WAF ve DR’nin ilişkisi

CDN ve WAF, erişilebilirliği artırır; ancak DR planının yerini almaz. WAF, saldırı anında trafiği filtreleyebilir; DR ise saldırıdan sonra veriyi geri getirme planıdır. Bu yüzden DR runbook’ta şu adım net olmalı:

Şüpheli olay sonrası: uygulama dondurma → log inceleme → yedekten geri dönüş (gerekirse) → güvenlik düzeltmesi (parola/anahtar/ayar)

Sonuç: 24 Saatte Başlayan DR Planı

Bugün başlayabileceğiniz en pratik aksiyon, RTO/RPO hedeflerinizi yazıp buna göre yedekleme + restore runbook + ilk restore testi düzenlemektir. Öncelik sırası şu olsun: (1) RTO/RPO belirle, (2) yedekleri 3-2-1 mantığıyla konumlandır, (3) DB ve dosya restore adımlarını dokümante et, (4) staging’de ilk kez geri dönmeyi test et, (5) test sonucuna göre planı güncelle.

NetKıyas gibi karşılaştırma platformlarında sağlayıcı seçerken de DR etkisini gözünüzde canlandırın: yedek saklama süresi, restore süresi, yedek lokasyonu ve erişim kolaylığı, kriz anında “ne kadar bekleyeceğinizi” doğrudan belirler.