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

Disaster recovery planı (DRP) küçük sitelerde neden kritiktir?

Küçük sitelerde arıza anında genellikle sorun şu olur: Yedek alınır ama geri yükleme (restore) denenmez, erişimler dağınıktır ve “ne yapacağız?” sorusuna tek bir cevap yoktur. Disaster recovery planı (DRP), olası kesintilerde hedeflenen toparlanma süresini (RTO) ve veri kaybı miktarını (RPO) belirleyerek, adım adım uygulanabilir bir süreç kurar. Bu rehberde; WordPress olmayan siteler dahil küçük altyapılar için DRP’yi pratik ve ölçülebilir şekilde nasıl kuracağınızı öğreneceksiniz.

DRP’nin 2 ölçütü: RTO ve RPO’yu netleştirin

DRP dokümanı üretmeden önce iki sayıyı belirlemek gerekir. Bu sayılar, hangi yedekleme yaklaşımının “yeterli” olduğunu belirler.

RTO (Recovery Time Objective) nedir?

RTO, sistemin tekrar çalışır hale gelmesi için kabul edilen maksimum süredir. Örnek: - E-ticaret dışı küçük site: RTO 4 saat - İçerik blogu: RTO 8 saat - Müşteri formu veya kritik entegrasyon varsa: RTO 2 saat

RPO (Recovery Point Objective) nedir?

RPO, kaybedilmesine izin verilen maksimum veri güncelliği farkıdır. Örnek: - RPO 1 saat: 1 saatlik yedek aralığı gerekir - RPO 24 saat: günlük yedek çoğu senaryoda yeterlidir

Küçük sitelerde tipik hedefler şöyle netleşir: - RTO: 4-8 saat - RPO: 1-24 saat (site değişim sıklığına göre)

Küçük siteler için DRP mimarisi: 3 katmanlı model

Küçük siteler için en doğru DRP, “her şeyi yedekleyeyim” yaklaşımı değil, katmanlı ve test edilebilir bir yaklaşımdır. Aşağıdaki model pratikte en çok işe yarayan kurgu olur.

1) Veri katmanı: yedek (backup) ve sürümleme

Yedek türleri genelde 3 parçadır: - Uygulama kodu (web sitesi dosyaları) - Veritabanı (database) - Kritik ayarlar (DNS/SSL dışında iç ayarlar)

Kritik nokta: Yedek alındığını değil, geri yükleme süresi ölçüldüğünü garanti altına almaktır.

Önerilen minimum kurulum (WordPress için de geçerlidir, WordPress dışı sitelerde de mantık aynıdır): - Dosyalar: haftalık tam paket + günlük değişen dosyalar (tercihe göre) - Veritabanı: günde en az 1 kez, mümkünse saatlik - Yedek saklama: en az 14 gün (RPO ve içerik kaybı toleransına göre 30 güne kadar)

2) Ortam katmanı: geri döneceğiniz hedef

Sadece “yedek var” yeterli değildir. Yedek nerede ve nasıl tekrar ayağa kalkacak sorusunun cevabı hazır olmalıdır.

Küçük siteler için iki yaygın hedef: - Aynı sağlayıcı içinde farklı konum: Aynı servis sağlayıcı ama farklı lokasyon/cluster - Farklı sunucu: Örneğin VDS sunucunuzda, felaket anında yedekleri yeni bir VM’e restore edeceğiniz senaryo

Eğer tek bir sunucu kullanıyorsanız, DRP’nizi “sunucu ölürse” varsayımıyla test etmeniz gerekir. Disk bozulması, dosya sistemi hatası veya yanlış güncelleme DRP kapsamına girer.

3) İşletme katmanı: runbook ve yetkiler

DRP’nin yüzde 50’si dokümandır. - Runbook: Felaket anında kim ne yapar? - Erişim listesi: Panel erişimleri, veritabanı bilgileri, SSH anahtarları, DNS sağlayıcı erişimi - İletişim planı: Ekip varsa; yoksa “kim duyurur, kim karar verir?”

Küçük sitelerde genellikle tek kişi olduğundan, erişimlerin tek bir şifre kasasında ve tek bir “acil durum” dokümanında toplanması gerekir.

Küçük siteler için DRP senaryoları: neyi planlamalısınız?

DRP’yi her felakete göre yazmak yerine, en sık yaşanan 6 senaryoyu kapsatın. Aşağıdaki liste, küçük sitelerde gerçekçi bir kapsam verir.

Yanlış güncelleme veya hatalı kod dağıtımı
Veritabanı bozulması (disk hatası, yanlış sorgu)
Dosya sistemi bozulması veya yetkisiz değişiklik
DDoS veya bant genişliği tıkanması
SSL sertifikası/ara sertifika zinciri problemi
DNS kesintisi veya yanlış DNS kaydı

Senaryo bazında karar kuralı

Aşağıdaki gibi basit karar kuralları DRP’yi hızlandırır: - Kod bozulduysa: Son sağlam sürüme dön - Veritabanı bozulduysa: DB restore + dosya doğrulama - DNS hatası varsa: Yetkili DNS sağlayıcıda düzeltme + TTL düşürme - SSL sorunu varsa: Sertifika zincir kontrolü + yenileme akışı

Yedekleme stratejisini “test” ile tamamlayın

DRP’nin en sık başarısız olduğu yer: Yedek alınıyor ama hiç restore edilmiyor. Restore testleri, planın doğruluğunu kanıtlar.

Yedek doğrulama: 10 dakikalık kontrol

Her yedek döngüsünde otomatik doğrulama yapmak ideal olsa da küçük sitelerde en azından manuel doğrulama uygulanmalıdır. - Dosya yedekleri: Arşivin açılabildiğini ve boyutunun beklenen aralıkta olduğunu kontrol edin - Veritabanı yedekleri: “import edilebilir” durumda mı test edin

Restore testi: ayda 1 kez (minimum)

Ayda 1 kez, prod ortamdan bağımsız bir test ortamında restore yapın. - Aynı sunucuda ayrı bir klasör ve ayrı veritabanı kullanın - WordPress ise yeni bir database + yeni kullanıcıyla restore edin - Dosya izinleri (permission) ve config ayarlarını kontrol edin

Bu testte ölçmeniz gerekenler: - Restore süresi (dakika) - Uygulamanın açılma süresi - Hata varsa kök neden analizi

DRP runbook şablonu: olay anında adım adım ilerleme

Aşağıda küçük siteler için uygulanabilir, kısa ve net bir runbook şablonu var. Bunu kendi altyapınıza göre isimlendirin.

0) Bildirim ve durum tespiti (ilk 15 dk)

Site ulaşıyor mu? (HTTP 200 mi, 5xx mi, zaman aşımı mı?)
Sunucu erişimi var mı? (SSH erişimi)
Panel erişimi var mı? (kontrol paneli)
Son değişiklik zamanı nedir? (son deploy / eklenti güncellemesi)

1) Hasar tipini sınıflandır (15-30 dk)

Kod hatası mı, veritabanı mı, altyapı mı?
SSL mi, DNS mi?
Disk bozulması veya sistem servis çökmesi var mı?

2) Hedefi seç (RTO’ya göre)

Hızlı toparlanma: En son “sağlam” yedeği kullan
Tam toparlanma: Son yedek dışında bir önceki sürümü de değerlendirme

3) Restore adımları (30-180 dk)

Veritabanını restore et
Dosyaları restore et
Config ayarlarını doğrula (DB host, kullanıcı, şema)
Dosya izinlerini kontrol et
Uygulamayı test ortamında aç

4) DNS/SSL geçişi (gerekliyse)

DNS kayıtlarını doğru hedefe yönlendir
SSL sertifikasını kontrol et (zincir, ara sertifika)

5) Post-mortem (olayın tamamlanmasından sonra)

Ne yanlış gitti?
Yedek doğru mu açıldı?
Restore süresi hedef RTO içinde mi?
“Bir sonraki sefere” aksiyon maddeleri

Küçük siteler için doğru yedek lokasyonu: tek nokta hatasını azaltın

Küçük sitelerde en yaygın hata, yedeği aynı sunucuda tutmaktır. Sunucu çökerse yedek de zarar görebilir. Bu nedenle yedek lokasyonunu en az ikiye bölün.

Uygulanabilir seçenekler

Aynı sağlayıcı içinde farklı depolama (ör. nesne depolama)
Farklı sağlayıcıda depolama (S3 uyumlu farklı lokasyon)
İkinci bir sunucuda sadece yedek deposu (daha maliyetli ama basit)

Net hedef: Yedeği, felaket anında erişilemez hale gelmeyecek şekilde saklayın.

DRP’de DNS ve TTL yönetimi: beklenmedik kesinti riskini azaltır

DNS kaynaklı kesinti genellikle iki sebepten olur: yanlış kayıt ve hızlı yayılmayan değişiklik.

DNS sağlayıcı erişimini DRP dokümanına koyun
TTL (Time To Live) değerini kritik alanlar için düşürün (ör. 300-900 saniye aralığı)
Planlı bakım öncesinde TTL düşürme rutini tanımlayın

Bu yaklaşım, sunucu değişikliği veya IP değişikliği gerektiren durumlarda toparlanmayı hızlandırır.

VDS/VPS kullanan küçük sitelerde pratik ayarlar

Küçük siteler çoğunlukla VDS veya VPS ile çalışır. DRP’yi hızlandıran ayarlar şunlardır:

Otomasyon: yedek üretimini düzenli ve kesintisiz tutun

Yedek işlerini cron ile çalıştırın
İş başarısız olursa e-posta veya bildirim üretin
Yedek günlüklerini (log) saklayın

Ayrı oturum: yönetim erişimini güvenli tutun

SSH anahtarı kullanın
Parola tabanlı girişleri kısıtlayın
Güncelleme sırasında erişim kaybı yaşamamak için plan yapın

Güncelleme disiplini

Eklenti/tema güncellemesini önce staging’de deneyin
Üretime dağıtmadan önce değişiklik listesini kaydedin

DRP’yi ölçün: hedefin tuttuğunu nasıl anlarsınız?

DRP bir kez kurulur, sonra testlerle doğrulanır. Küçük sitelerde takip edilecek metrikler:

Haftalık: Yedek başarısı var mı? (başarısız job sayısı)
Aylık: Restore testi süresi (dakika) ve hata sayısı
Olay sonrası: RTO hedefi tutuyor mu?

Aşağıdaki kontrol listesi pratik bir değerlendirme sağlar:

[ ] RTO ve RPO sayıları dokümanda yazıyor
[ ] Yedekler farklı lokasyonda saklanıyor
[ ] En az ayda 1 restore testi yapılıyor
[ ] DNS/SSL erişimleri DRP dokümanında bulunuyor
[ ] Runbook tek sayfalık, adım sıralı ve uygulanabilir
[ ] Güncel iletişim ve erişim bilgileri erişilebilir

Sonuç: 1 gün içinde başlayabileceğiniz net aksiyon planı

Küçük bir site için DRP’yi “karmaşık bir proje” gibi görmek gerekmez. Bugün yapılacak en etkili 3 adım: (1) RTO/RPO hedeflerinizi yazın, (2) en az bir restore testini bağımsız ortamda planlayın, (3) DNS/SSL erişimlerini ve runbook’unuzu tek dokümanda toplayın. Bu üç madde tamamlandığında, kesinti anında karar vermek yerine uygulamaya geçersiniz ve toparlanma süresi ölçülebilir hale gelir.