Küçük Siteler İçin Disaster Recovery Planı: 30-60-90 Gün Planı

Küçük bir sitenin altyapısı büyüğüne göre daha sade olabilir; ancak bu, hiç durmayacağı anlamına gelmez. Disk arızası, yanlış konfigürasyon, fidye yazılımı (ransomware) ya da sağlayıcı kesintisi gibi senaryolarda hedef, “her şeyi kurtarmak”tan önce hizmeti belirlenen sürede geri almak olur. Bu rehberde, küçük siteler için uygulanabilir bir disaster recovery (DR) planını netleştireceksiniz: önce RTO/RPO hedefleri, sonra yedekleme ve doğrulama, ardından ayağa kaldırma adımları ve 30-60-90 gün yol haritası.

Disaster recovery ile business impact’ı netleştirin (RTO/RPO)

DR planının ilk çıktısı doküman değil, sayılardır. “Ne kadar sürede geri dönmeliyiz?” ve “Veri ne kadar kaybolabilir?” sorularını belirlemeden yapılacak her çalışma dağınık kalır.

RTO (Recovery Time Objective) ve RPO (Recovery Point Objective)

• RTO: Hizmetin (web sitesi, uygulama, e-posta gibi) tekrar çalışır hale gelmesi için hedef süre.
• RPO: En fazla kaybetmeyi kabul ettiğiniz veri kaybı (ör. son 15 dakika, son 1 saat).

Küçük siteler için pratik başlangıç değerleri: - Basit web sitesi (içerik ağırlıklı): RTO 2-4 saat, RPO 24 saat - Admin paneli olan, sık içerik güncellenen site: RTO 1-2 saat, RPO 1-4 saat - E-ticaret / sipariş akışı olan site: RTO 1-2 saat, RPO 15-60 dakika

Not: RTO/RPO hedeflerini “tek bir sayı” gibi düşünmeyin. İlk sürüm plan için hedefleri koyun; sonra yedekleme sıklığı ve test süreçleriyle gerçekçi hale getirin.

Senaryoları sınıflandırın: aynı plan her şeye yetmez

Küçük sitelerde DR çalışması genelde “sunucu bozuldu” varsayımıyla başlar. Oysa pratikte daha sık karşılaşılan senaryolar farklı yaklaşım ister.

Aşağıdaki sınıflandırma, hangi aksiyonların otomatik olması gerektiğini belirler:

1) Yazılım / konfigürasyon hatası

• CMS güncelleme sonrası bozukluk
• Yanlış Nginx/Apache kuralı
• Bozuk migrasyon (migration) dosyası

İlk hedef: hızlı geri alma (rollback). Yedekten ayağa kaldırma kadar, uygulama sürüm geri dönüşü de önemlidir.

2) Veri kaybı (DB/Storage)

• Veritabanı bozulması
• Yanlış silme
• Disk dolması nedeniyle servis çökmesi

İlk hedef: DB restore (geri yükleme) ve uygulama ile uyum.

3) Güvenlik olayı (ransomware / web defacement)

• Dosya bütünlüğü bozulması
• Şifrelenmiş klasörler
• Yetkisiz admin hesabı

İlk hedef: “hızlı açalım”dan önce temizliği doğrulamak. Aksi halde geri yüklediğiniz yedek de enfekte olabilir.

4) Sağlayıcı kesintisi / fiziksel arıza

• Hosting/VPS durması
• Donanım arızası

İlk hedef: alternatif lokasyonda ayağa kaldırma ve DNS geçişi.

5) İnsan hatası

• Yanlış dosya izinleri
• Yanlış yedekleme klasörü
• Parola kaybı

İlk hedef: kontrol paneli erişimi, kimlik bilgisi saklama ve kurtarma prosedürü.

Yedekleme stratejisi: “var” değil “geri yüklenebilir” olmalı

DR planının en sık başarısız noktası, yedeğin “alınması” değil “restore edilmesi”dir. Bu bölümde, küçük site için uygulanabilir bir yedekleme bileşimi veriyorum.

Minimum yedekleme bileşenleri

Küçük bir site için tipik olarak şunlar yeterlidir: - Dosya yedekleri: Web kökü, uygulama dosyaları, yüklemeler (uploads) - Veritabanı yedekleri: MySQL/MariaDB, PostgreSQL - Konfigürasyon yedekleri: Nginx/Apache vhost ayarları, .env (dosyalarda hassas veriyi dikkatle ele alın), cron işleri - TLS/sertifika takibi: Sadece sertifika değil, yenileme mekanizması (ör. Let’s Encrypt) ve kayıtlı hesap bilgisi - Erişim bilgileri: Kontrol paneli, veritabanı kullanıcıları, SSH anahtarları

Yedek saklama ve sıklık (pratik öneri)

Aşağıdaki tablo, küçük siteler için uygulanabilir bir başlangıç setidir:

Yedek doğrulama: 1 saatlik test her şeyi değiştirir

DR planınızı güçlendiren kritik adım: periyodik restore testi.

Uygulanacak test türleri: - Tam restore testi (ayda 1): Yedeği ayrı bir ortamda (test sunucusu/VPS) ayağa kaldırın. - Dosya restore testi (haftada 1): Tek tek kritik dosyaların (konfigürasyonlar, yüklemeler) geri geldiğini doğrulayın. - DB restore testi (haftada 1): Son yedekten DB’nin ayağa kalktığını ve uygulamanın bağlandığını kontrol edin.

Bu testlerde ölçün: - Restore süresi (RTO’ya etki) - Restore sonrası hata sayısı - Veri tutarlılığı (ör. sipariş tablosu, kullanıcılar, içerik)

Ayağa kaldırma (restore/runbook): “kim ne yapacak?”

DR planı bir kontrol listesi olmalıdır. Aşağıdaki runbook şablonu, küçük ekiplerde (hatta tek kişi) işe yarar.

Hızlı durum değerlendirmesi

1. Olay türünü sınıflandırın: hatalı deploy mi, veri kaybı mı, güvenlik olayı mı, sağlayıcı mı?
2. Etkiyi ölçün: web mi, uygulama mı, e-posta mı?
3. Logları toplayın: son 24 saat olay özetini alın.

Kurtarma akışı (örnek)

• Aşama 1: Kaynak/erişim
• Kontrol paneli (hosting/VPS), SSH erişimi, veritabanı erişimi

• En güncel yedeğin bulunup bulunmadığı

• Aşama 2: Temiz ortam hazırlığı

• Aynı işletim sistemi sürümünde yeni sunucu (mümkünse)

• Gerekli paketlerin kontrolü

• Aşama 3: Restore

• Konfigürasyonları geri yükleyin
• DB restore edin

• Uygulama dosyalarını yerleştirin

• Aşama 4: Test

• Sağlık kontrolü: web sayfası, kritik sayfalar

• DB tutarlılığı: uygulama logları ve temel sorgular

• Aşama 5: DNS geçişi (failover)

• DNS TTL planı ile yönlendirin

• Kullanıcı trafiği kademeli mi yoksa anlık mı yönlendirilecek belirleyin

• Aşama 6: İyileştirme

• Kök neden analizi (post-incident)
• Yedek doğrulama ve izleme için aksiyon ekleyin

DNS geçiş planı: küçük site için “DNS TTL” farkı

Birçok DR senaryosunda gerçek zaman problemi DNS’tir. Sunucuyu ayağa kaldırmak mümkün olsa bile kullanıcıların ne zaman yönlendirileceği TTL ile belirlenir.

TTL hedefi nasıl seçilir?

• Olağan çalışma: TTL 3600-86400 aralığında tutulabilir.
• DR hazırlık modu: kritik dönemlerde TTL 300-900 saniye seviyesine indirilir.

Öneri: “Her zaman düşük TTL” pahalı görünebilir. Küçük sitelerde pratik yaklaşım, TTL’i kritik değişiklikler öncesi düşürmek ve olay anında yükseltmektir.

Failover için yönlendirme seçenekleri

• A kaydı / AAAA kaydı güncelleme
• Sağlayıcı kontrol paneli üzerinden IP yönlendirme
• Bazı durumlarda CDN origin değiştirme

DNS planında net yazın: - “Hangi kaydı değiştiriyoruz?” - “DNS değişikliği kimin onayıyla yapılıyor?” - “TTL kaç saniye?”

Güvenlik olayı için özel kural: geri yüklemeden önce temizliği doğrula

Ransomware senaryosunda DR’nin en büyük hatası, enfekte yedeği “kurtarma” sanmaktır.

Kontrol listesi (güvenlik olayında)

• Dosya bütünlüğü: web root altında şüpheli dosyalar (ör. rastgele isimli PHP dosyaları)
• Yetkisiz kullanıcı/şifre: admin panel kullanıcılarını kontrol edin
• DB’de şüpheli kayıtlar: beklenmeyen admin yetkileri, kimlik tablosu değişiklikleri
• Web uygulama logları: anormal istek paterni

Özel kural: - Enfeksiyon şüphesi varsa “yedeği restore etmeden” önce temizleme/inceleme adımını koşula bağlayın.

30-60-90 gün yol haritası (küçük ekipler için)

DR’yi bir günde kurmak yerine adım adım ilerleyin. Aşağıdaki plan, pratik ve ölçülebilir bir başlangıçtır.

İlk 30 gün: temel kurulum + ölçüm

• RTO/RPO değerlerini yazılı hale getirin
• Yedekleme kapsamını netleştirin (dosya + DB + konfig)
• En güncel yedekten ilk restore testini yapın (test ortamı şart)
• DNS TTL stratejisini belirleyin

60 gün: restore başarımını hızlandırma

• Ayda 1 tam restore yerine ilk dönemde daha sık denemelerle (ör. 2 haftada 1) süre ölçün
• Runbook’u güncelleyin: “restore şu adımda şu hatayı veriyor” gibi
• İzleme/uyarı ekleyin (disk doluluğu, yedek başarısızlığı gibi)

90 gün: güvenlik + failover prova

• Güvenlik senaryosu için kontrol listesi tamamlayın
• Failover provası yapın (DNS değişikliği ile ayağa kaldırma süresi ölçümü)
• Dokümantasyonu “tek kişi kullanabilir” hale getirin

NetKıyas bakış açısıyla karar noktaları: hangi bileşen pahalı olmadan güçlenir?

Küçük sitelerde DR maliyeti genelde “fazla sunucu” sanılır. Oysa asıl değer, geri yüklenebilir yedek ve ölçümlenebilir restore süresindedir.

Aşağıdaki karar çerçevesi, hangi altyapı unsurunun öncelikli olacağını belirler:

• Yedekleme otomasyonu ve yedek doğrulama: elle alınan yedek DR’yi zayıflatır. Otomasyon sağlayın.
• DB yedeğinin tutarlılığı: uygulama ile aynı anlık veri seti hedeflenir.
• Test ortamı: aynı sağlayıcı içinde küçük bir VPS/VM ile aylık restore testi yapılabilir.
• DNS planı: TTL ve kayıt tipi net değilse RTO bozulur.

Sonuç: bugün tek bir aksiyon seçin

Bugün yapabileceğiniz en etkili aksiyon, “yedek alındı” demek yerine en güncel yedeği bir test ortamında restore etmek ve restore süresini ölçmektir. Bu ölçüm, RTO/RPO hedeflerinizi gerçekçi hale getirir ve DR planınızın sonraki adımlarını netleştirir. Runbook’u oluşturup DNS TTL stratejinizi yazılı hale getirdiğinizde, olay anında panik yerine kontrollü ilerlersiniz.