Küçük Siteler için Disaster Recovery Planı: Net Rehber

Bir web sitesinde kesinti; gelir kaybı, itibar zedelenmesi ve SEO etkisi gibi sonuçlara dönüşür. Küçük sitelerde problem genelde “yedek var mı?” kadar basit değildir; yedeğin erişilebilir olması, kurtarmanın ölçülebilir olması ve planın sınanmış olması gerekir. Bu rehberde disaster recovery planını (DR) küçük ölçek için net, uygulanabilir parçalara ayıracağız: hedefler (RPO/RTO), yedekleme ve kopyalama düzeni, olay türlerine göre kurtarma akışı, kontrol listesi ve düzenli test.

1) Disaster recovery planını küçük siteye göre tanımlayın (RPO/RTO)

DR planının ilk çıktısı, “ne olursa ne kadar sürede toparlarız” sorusunun sayısal cevabıdır.

Hedefleri belirleyin: RPO ve RTO

• RPO (Recovery Point Objective): Son veri kaybı kabulünüz. Örnek: “Son 15 dakikadan daha eski bir veri kaybını kabul etmiyorum.”
• RTO (Recovery Time Objective): Hizmeti kaç dakikada/saatte geri getirmek istediğiniz.

Küçük siteler için pratik hedef örnekleri: - Basit WordPress + küçük e-ticaret: RPO 1-6 saat, RTO 1-6 saat - Sık güncellenen içerik/booking: RPO 15-60 dk, RTO 1-3 saat

Kesinti senaryolarını sınıflandırın

Aşağıdaki senaryolara göre farklı kurtarma yolları gerekir: 1. Dosya bozulması / siber saldırı (malware, defacement, şifreleme girişimi) 2. Veritabanı bozulması (MySQL/PostgreSQL çökmesi, yanlış işlem) 3. Sunucu donanım arızası / VM silinmesi 4. Yanlış yapılandırma (kontrol panelinde hatalı değişiklik, Nginx/Apache ayarı) 5. DNS kesintisi / yanlış yönlendirme

DR planınız, bu senaryolardan en az ilk 3’ünü kapsamalı. “Hepsine birden” çalışmak yerine, en olası ve en maliyetli olanı seçin.

2) Yedekleme mimarisi: tek kopya değil, doğrulanabilir sistem kurun

Küçük sitelerde en yaygın hata “yedek alıyoruz” sanıp, yedeğin geri yüklenebilirliğini test etmemektir. DR planı için yedekleme düzeni tek başına değil; saklama ve doğrulama ile birlikte çalışır.

3 katmanlı yedekleme yaklaşımı

Aşağıdaki düzen, çoğu küçük site için mantıklıdır: - Katman A (Hızlı geri dönüş): Güncel yedekler (ör. her 1-6 saatte bir DB snapshot + günlük dosya arşivi) - Katman B (Uzun saklama): Haftalık/aylık kopya (en az 4-8 haftalık) - Katman C (Felaket kopyası): Farklı lokasyon/sağlayıcıda ayrı tutulmuş kopya

Not: Katman C, aynı sağlayıcıda tutulsa bile aynı altyapı arızasında koruma sağlayamayabilir. Uygun olanı seçmek için sağlayıcıların veri merkezi ve kurtarma kabiliyetini inceleyin.

Yedek türlerini net ayırın

• Dosya yedeği: Tema/eklenti, yüklemeler (uploads), config dosyaları
• Veritabanı yedeği: WordPress için wp_posts, wp_options vb.
• Uygulama ayarları: web server (Nginx/Apache), PHP ayarları, environment (varsa)
• DNS kayıtları: A kayıtları, CNAME’ler, TTL değerleri

Doğrulama olmadan yedek DR değildir

Aşağıdaki doğrulamalar planın parçası olmalı: - Yedeğin boyutu ve oluş tarihi kontrolü - En az haftada 1 kez “geri yükleme testi”: örnek bir staging ortamına restore - Parola/erişim anahtarlarının (SSH key, veritabanı user) kurtarma sırasında kullanılabilirliği

3) Kurtarma akışı: senaryoya göre adım adım işletin

DR planında “kim ne yapacak” kadar “sırayı bozmamak” önemlidir. Aşağıdaki akış, küçük ekip (hatta tek kişi) için tasarlanmıştır.

Olay 1: Siber saldırı / dosya bozulması

Amaç: temiz duruma dönmek ve saldırının kalıcı izlerini silmek.

Adımlar (kontrol listesi) 1. Siteyi geçici olarak durdurun: HTTP trafiğini azaltmak için web server’ı maintenance moduna alın. 2. Dosya yedeğinden restore etmeyi hedefleyin: Saldırının başlamasından önceki Katman A veya B yedeğini kullanın. 3. WordPress çekirdek dosyaları ve eklenti/tema listesi üzerinden bütünlük kontrolü yapın. 4. Veritabanında kalıcı değişiklikleri kontrol edin: - wp_options içinde şüpheli siteurl/home değişimleri - admin kullanıcısı oluşturma izleri 5. Parolaları sıfırlayın ve erişim anahtarlarını (SSH/Control Panel) güncelleyin. 6. Yeni bir “temiz” baseline oluşturun: gelecekte karşılaştırmak için dosya hash’leri alın.

Net tercih: Yalnızca “dosyayı temizledik” diyerek devam etmeyin; DB’deki değişiklikler çoğu zaman saldırının kalıcı parçasıdır.

Olay 2: Veritabanı bozulması

Amaç: veriyi mümkün olduğunca geri almak, sonra uygulamayı doğrulamak.

Adımlar 1. En yakın DB yedeğini (RPO hedefiyle uyumlu) alın. 2. Mevcut DB’yi korumak için önce “mevcut hali”nin bir kopyasını saklayın (rollback için). 3. Restore sonrası uygulama testleri: - yönetici paneli giriş denemesi - ana sayfa yükleme - kritik form/ödeme akışı (e-ticaret varsa) 4. Loglarda hata bulunuyorsa (deadlock, izin problemi), web server tarafını değil önce DB şemasını doğrulayın.

Olay 3: Sunucu arızası / VM silinmesi

Amaç: altyapıyı yeniden ayağa kaldırmak (infrastructure restore).

Adımlar 1. Yeni bir VM/VDS hazırlayın (aynı OS sürümü, aynı PHP sürümü, aynı web server) 2. Uygulama dosyalarını geri yükleyin 3. Veritabanını geri yükleyin 4. DNS/Load balancer tarafını doğrulayın 5. İzlemeyi açın (health check + log takibi)

Olay 4: Yanlış yapılandırma

Amaç: “geri al” yaklaşımı. - Önce son 1-2 değişikliği tespit edin (deployer script, kontrol panel ayarı, config değişikliği) - Konfigürasyon dosyalarının sürüm kontrolünü kullanın (en azından basit git veya yedekli kopya) - Geri dönüş mümkün değilse staging üzerinde aynı konfigurasyonu yeniden kurup karşılaştırın

Olay 5: DNS kesintisi

Amaç: domain yönlendirmesini hızlı düzeltmek. - TTL değerini uzun süre yüksek tutmayın: Kurtarma esnasında değişikliklerin yayılması uzar - Domain sağlayıcının panel erişimi ve kayıt e-postaları DR planında listelenmeli

4) Küçük site için maliyet/etki dengesini somutlaştırın

DR planı “en pahalı” değil, “hedeflediğin RPO/RTO’yu karşılayan” sistem olmalı.

Basit kılavuz: hedefe göre pratik seçenekler

Aşağıdaki tablo, hangi parçaları hangi sıklıkla yapmanız gerektiğini netleştirir.

Buradaki değerler “tek doğru” değil; ama seçim mantığını RPO/RTO üzerinden kurarsanız, sağlayıcı/servis seçimi de netleşir.

5) DR planını çalışır hale getiren 10 maddelik kontrol listesi

DR planının “kâğıt üzerinde” kalmaması için uygulamada şu maddeler tamamlanmalı.

Kayıtlar ve erişimler

• İletişim listesi: kim, hangi durumda neye bakacak (e-posta/telefon)
• Kontrol panel erişimleri ve parolalar için güvenli saklama (password manager veya ayrı bir kasada)
• DNS sağlayıcı paneli erişimi

Yedekleme ve kurtarma

• Yedeklerin saklama lokasyonu net (katman A/B/C)
• Yedeklerin geri yükleme komut/iş akışı dokümante (ör. “DB restore adımı”)
• Yedek dosyaları şifreli saklanıyor mu (ihtiyaca göre)
• Loglar tutuluyor: yedek job’ları başarı/başarısızlık en

Test ve güncellik

• En az haftada 1 kez staging ortamında restore testi
• DR testi “tam site geri getirme” değilse bile DB restore + sayfa yükleme testi yapılmalı
• Büyük değişiklik (tema/eklenti yükseltme, sunucu konfigürasyon değişikliği) sonrası otomatik check listesi

Hazırlık: kurtarma sırasında karar vermeyi kolaylaştıran dokümanlar

• Sunucunun mimarisi: OS sürümü, PHP sürümü, web server türü
• Kullanılan eklenti/temaların listesi ve kritik dosyaların konumu
• RTO’ya giden adımların süre tahmini (ör. restore + cache temizleme + CMS ayarları)

Sonuç: 1 haftada uygulamaya alın

DR planını tek günde “tamamlamak” yerine, 1 haftalık bir sprint ile başlatın: 1. Bugün: RPO/RTO hedeflerini ve 3 temel senaryoyu yazın. 2. 3 gün içinde: Katman A/B yedekleme + yedek job doğrulama + dokümante edilmiş restore adımları. 3. 7. gün: Staging’de geri yükleme testi yapın ve başarısız kalan noktaları düzeltin.

NetKıyas’ta sunucu/hosting seçerken sadece fiyat ve kota değil, yedekleme iş akışı, erişilebilirlik ve kurtarma testini destekleyen altyapı da değerlendirilmelidir. Bu rehberi uyguladıktan sonra, hangi yedeğin gerçekten işe yaradığı ortaya çıkacak ve bir kesintide “ne yapacağım?” sorusu yerini net bir akışa bırakacaktır.