Küçük Siteler İçin Disaster Recovery Planı (DR) Rehberi

Bugün bir küçük site yönetseniz bile, kesinti sadece “site açılmıyor” değildir: e-ticarette sipariş kaybı, WordPress’te veri bozulması, e-posta akışının durması ve SEO sıralamalarında gecikmeli etkiler ortaya çıkabilir. Bu yazıda disaster recovery planı (DR) kavramını, küçük ölçekli siteler için uygulanabilir bir çerçeveye indiriyoruz. Hedeflerinizi netleştirmek için RTO/RPO mantığını kullanacak, yedekleme (backup) ve yeniden ayağa kaldırma akışını somutlaştıracak, en kritik kısım olan DR test adımını kontrol listesiyle vereceğiz.

1) DR planı neyi çözmeli: RTO ve RPO ile hedef koyun

Küçük sitelerde yapılan en yaygın hata, “yedek var” diyerek DR’nin tamamlandığını sanmaktır. Yedek (backup) tek başına çözüm değildir; “ne kadar zamanda geri döneceksiniz?” ve “hangi veri kaybını kabul edersiniz?” sorularına cevap vermelidir.

RTO (Recovery Time Objective) nasıl belirlenir

RTO, hizmeti geri getirmenin maksimum süresidir. - Basit blog: 2-6 saat - Bülten ve müşteri başvuru formu olan site: 1-4 saat - E-ticaret: 30-120 dakika (satış kaybını azaltmak için)

Örnek net karar: - “E-ticaret sitemizde ödeme akışı bozulduğunda en geç 60 dakika içinde checkout tekrar çalışmalı.”

RPO (Recovery Point Objective) nasıl belirlenir

RPO, geri döneceğiniz noktadaki maksimum veri kaybıdır. - Dosya değişimi az olan blog: günlük (24 saat) - WooCommerce siparişleri olan mağaza: 15-60 dakika - Sık güncellenen üyelik/CRM entegrasyonları olan yapılar: 5-15 dakika

Küçük site için pratik hedef seti

Aşağıdaki tablo, karar vermeyi hızlandırır:

2) Senaryoları yazın: “felaket” tek bir şey değildir

DR planı, senaryolara göre farklı adımlar gerektirir. Küçük siteler için 5 senaryoyu yazmak yeterli olur; çünkü çoğu gerçek olay bu kümelere düşer.

Senaryo 1: Sunucu/VM tamamen çöktü

• Sağlayıcı tarafı donanım arızası veya veri merkezi kesintisi
• VDS/VPS’in kapanması (power/host error)

Senaryo 2: Veritabanı bozuldu (DB corruption) veya yanlış işlem

• Yanlış migration
• Disk dolu hatasıyla MySQL/innodb kaynaklı bozulma

Senaryo 3: Dosyalar bozuldu (upload hatası, saldırı, yanlış deploy)

• WordPress çekirdeği/eklenti dosyaları güncelleme ile bozuldu
• Sızma sonrası dosya bütünlüğü kaybı

Senaryo 4: DNS/sertifikalar kaynaklı erişim kesildi

• Yanlış DNS kaydı
• SSL sertifikası yenilenemedi

Senaryo 5: E-posta tarafı etkileniyor

• Domain MX kaydı bozuldu
• Spam/blacklist veya sağlayıcı sorunu

Planın içine mutlaka yazılacak 6 karar

Her senaryonun yanıtı için şu bilgiler net olmalı: - Hangi sistem kritik? (web sunucusu, veritabanı, e-posta, CDN) - Geri dönüş yolu: aynı sağlayıcı mı, farklı bölge mi? - Yedek nerede? (aynı sunucu mu, dış depo mu?) - Güncel olma sıklığı: RPO’yu tutturuyor mu? - Geri dönme testi: son ne zaman denendi? - Sorumlu kişi ve iletişim kanalı: tek kişinin bilgisi mi, dokümante mi?

3) Küçük site için DR mimarisi: temel bileşenler

DR’yi “yapı taşları” olarak düşünün. Küçük sitelerde hedef, maliyeti yönetirken kritik noktaları garanti altına almaktır.

3.1 Yedekleme stratejisi: tek plan değil katmanlı plan

Minimum iki katman hedefleyin: 1) Lokal yedek (backup) — hızlı geri dönüş için 2) Dış yedek (off-site) — sağlayıcı/zon kesintisine karşı

Yedek türleri: - Dosya yedeği: WordPress çekirdeği, tema/eklenti, uploadlar - Veritabanı yedeği: MySQL/MariaDB dump - Konfigürasyon: web sunucusu ayarları, .env/uygulama ayarları

Önemli: Snapshot (anlık görüntü) tek başına gerçek backup değildir; birden fazla hata türünü kapsamayabilir. Yedeklerinizi geri dönüş testinde doğrulayın.

3.2 Yedek saklama (retention) süresi

Küçük siteler için pratik kural: - Haftalık: 4-8 hafta - Aylık: 6-12 ay - Yıllık: 1-3 yıl (içerik arşivi için)

Retentie ayarını RPO ile eşleştirin: - Eğer RPO 60 dakikaysa, en az 48-72 saat arası “noktasal geri dönüş” mantığını desteklemek gerekir.

3.3 İkinci ortam: restore edilebilir “hedef sistem”

DR planında en az şu soru net olmalı: - Sunucu çökünce siteyi nereye kuracağım?

Küçük sitelerde iki yaygın yol: - Aynı sağlayıcı içinde yedeklerden restore (hızlı, genelde en ekonomik) - Farklı sağlayıcıya restore (daha pahalı, daha dirençli)

Hedef, “restore için saatlerce ortam aramak” değil, önceden bir hedef belirlemektir.

4) Uygulama planı: adım adım DR akışı

Aşağıdaki akış, WordPress başta olmak üzere çoğu web uygulamasına uyar.

4.1 Hazırlık (Hazır olma) adımları

1) Kritik envanter çıkarın - Domain, DNS sağlayıcısı - Web barındırma (VDS/VPS/web hosting) - Veritabanı (ör. MySQL) - CDN varsa: Cloudflare/BunnyCDN - E-posta sağlayıcısı 2) Erişimleri dokümante edin - SSH/RDP kullanıcıları - Panel erişimleri (kontrol paneli) - Veritabanı erişimi - Sertifika yönetimi 3) Yedekleme job’larını kontrol edin - Yedek dosyalarının boyutu, üretim zamanı, hata logları - Yedeklerin dış depoda doğrulanması 4) Restore kapasitesini test edin - Test için küçük bir staging (demo) ortamı kurun - Aynı zamanda “prod’a yakın” bir yedek restore akışı hazırlayın

4.2 Olay anında (Incident response) adımları

Olay türüne göre ilk 10 dakikada hedef: - Daha fazla hasarı durdurmak - Doğru geri dönüş yolunu seçmek

Örnek: - Dosya bozulması/sızma şüphesi: 1) Uygulamayı geçici olarak trafik kesmeden “read-only” yapın (varsa) 2) Son güvenilir dosyayı bulun 3) Veritabanı ile eş zamanlı uyumu kontrol edin - Sunucu çökmesi: 1) Yedek restore hedefini seçin 2) Yeni VM/VDS ayağa kaldırın 3) DB restore + dosya restore sırasını uygula

4.3 Restore (yeniden ayağa kaldırma) sırası

En kritik nokta: restore sırasını sabitleyin.

Genel kural: 1) Veritabanını restore edin 2) Uygulama dosyalarını restore edin 3) Konfigürasyonu (DB host, site URL, SMTP) doğrulayın 4) Dosya izinleri ve cron/queue varsa ayarları kontrol edin 5) Son olarak test: ana sayfa + kritik sayfalar + form/checkout

4.4 DNS ve SSL adımları

DR sonrası erişim için sık karşılaşılan problem, “site ayağa geldi ama domain açılmıyor”dur. - DNS TTL değerleri düşükse geçiş daha hızlı olur - SSL sertifikası otomatik yenileniyorsa, DNS doğrulaması için zaman gerekir

Küçük site için pratik checklist: - Domain DNS kayıtlarını doğru görür mü? (A/AAAA/CNAME) - Cloudflare proxy açıksa DR sonrası doğru şekilde çalışıyor mu? - SSL durumu: “valid” mi?

5) DR test planı: doğrulanmamış yedek, güvenli sayılmaz

DR’nin en sık eksik noktası testtir. Yedek alındığını görmek, geri yükleme (restore) başarısını kanıtlamaz.

Minimum test sıklığı

• Aylık: restore testi (staging’e)
• Üç ayda bir: “küçük felaket” testi (veritabanı restore + dosya restore)
• Altı ayda bir: DNS/SSL dahil uçtan uca doğrulama

Testte ölçülecek metrikler

• Restore süresi (dakika)
• RPO uyumu: hangi zaman damgasından restore ettiniz?
• Uygulama doğrulama: kritik sayfalar, form, ödeme (varsa)
• Log doğrulama: hata var mı?

DR test checklist (kopyala-kullan)

• [ ] Son yedek üretildi mi? (dosya zamanı)
• [ ] Yedekten staging restore başarılı mı?
• [ ] DB bağlantısı çalışıyor mu?
• [ ] WordPress admin girişi çalışıyor mu?
• [ ] WP cron/queue işi çalışıyor mu?
• [ ] Site URL ve yönlendirmeler doğru mu?
• [ ] Görsel yüklemeler (uploads) geliyor mu?
• [ ] Form/checkout akışı çalışıyor mu?
• [ ] SSL durumu geçerli mi?
• [ ] Test sonucu dokümana işlendi mi?

6) Net maliyet-kapsam kararı: küçük site için doğru seviyeyi bulun

Küçük sitelerde DR bütçesi sınırlıdır. Bu nedenle “her şeyi iki katına çıkarma” yerine, risk ve hedeflere göre katmanlı yatırım yapın.

Hangi bileşen en çok değer üretir?

• Yedeklerin dış depoya gitmesi: sağlayıcı kaynaklı olaylarda ayakta kalma
• DB + dosya uyumlu geri dönüş prosedürü: bozuk/uyumsuz restore riskini düşürür
• Aylık restore testi: en pahalı hatayı (yedek bozukluğu) erken yakalar
• DNS/SSL hazırlığı: “site ayağa geldi ama domain açılmıyor” süresini azaltır

En yaygın yanlışlar

• Yedek var ama restore hiç denenmemiş
• Yedek dosyaları aynı sunucuda ve sunucu çökünce kayboluyor
• DB yedeği alınmıyor (veya güncel değil)
• RTO/RPO hedefleri tanımsız olduğu için olay anında karar verilemiyor

Hızlı aksiyon planı (bugün başlayın)

1) RTO ve RPO hedeflerinizi tabloya göre yazın 2) En az 3 senaryoyu (sunucu çökmesi, DB bozulması, dosya bozulması) dokümana girin 3) Yedek türlerini ve saklama yerini netleştirin: dosya + DB + config, dış depoda 4) Bu ay içinde bir “restore testi” planlayın

Sonuç olarak, küçük site için DR; pahalı bir altyapı kurmak değil, RTO/RPO ile hedef koyup senaryolara göre geri dönüş akışını yazmak ve düzenli restore testiyle doğrulamak demektir. En yakın aksiyonunuz: RTO/RPO’yu bir sayfaya yazın, yedek stratejinizi katmanlı hale getirin ve bu hafta bir staging restore testi planlayın. Böylece bir olay olduğunda karar vermek değil, önceden belirlenmiş adımları uygulamak kolaylaşır.