Felaket Kurtarma Planı Hazırlama

Felaket kurtarma planı hazırlama işi, çoğu ekipte "bir gün yapılacaklar" listesinde durur ve o gün genellikle bir şeyler kaybolduktan sonra gelir. Oysa planın kendisi karmaşık bir belge değildir: sunucunuz bu gece tamamen kaybolsa hangi sırayla ne yapacağınızı, verinin nereden geleceğini ve bunun ne kadar süreceğini yazıya dökmektir. Asıl zor kısmı yazmak değil, yazdığınızın gerçekten işe yaradığını düzenli olarak kanıtlamaktır.

Bu rehberde kullanılabilir bir felaket kurtarma planını adım adım kuracağız: kararların dayanağı olan RTO ve RPO sayılarını belirlemek, neye sahip olduğunuzu ve neyin neye bağlı olduğunu çıkarmak, 3-2-1 kuralına oturan bir yedekleme stratejisi kurmak, gece yarısı uykulu bir gözle takip edilebilecek bir kurtarma runbook'u yazmak ve bunu tatbikatla doğrulamak. Ayrıca planları işe yaramaz hâle getiren klasik hataları da tek tek ele alacağım.

Felaket Kurtarma Planı Neyi Kapsar#

Öncelikle terimleri yerine oturtalım, çünkü sık karıştırılıyorlar. Yedekleme, verinin ikinci bir kopyasını almaktır. Felaket kurtarma (DR), o kopyadan hizmeti yeniden ayağa kaldırma sürecidir. İş sürekliliği ise hizmet yokken şirketin nasıl çalışmaya devam edeceğidir. Elinizde mükemmel yedekler olabilir ama onları hangi sunucuya, hangi sırayla, hangi parolayla geri yükleyeceğinizi bilmiyorsanız felaket kurtarma planınız yok demektir.

Gerçek bir plan şu sorulara yazılı cevap verir: Hangi olaylar "felaket" sayılır? Kim karar verir ve kim müdahale eder? Hangi sistemler hangi sırayla ayağa kalkar? Veri nereden gelir ve o kaynağa erişim kimde? İşlem ne kadar sürer ve bu süre kabul edilebilir mi? Müşterilere ne zaman ve nasıl bilgi verilir?

Kapsanması gereken felaket türlerini de dar tutmayın. Donanım arızası akla ilk gelenidir ama gerçekte en sık yaşananlar farklıdır: yanlışlıkla silinen veri, hatalı bir dağıtımın (deploy) veritabanını bozması, fidye yazılımı, bir servis sağlayıcısının hesabı askıya alması, alan adının süresinin dolması ve ekipteki tek yetkili kişinin ulaşılamaz olması. RAID ve replikasyon bunların hiçbirine çare değildir; RAID seviyeleri yalnızca disk arızasına karşı korur ve silinen dosyayı sadakatle tüm disklerden siler.

RTO ve RPO: İki Sayıyla Başlayın#

Planın tüm teknik kararları iki sayıdan çıkar ve bu ikisini belirlemeden hiçbir araç seçimi anlamlı değildir.

RTO (Recovery Time Objective), hizmetin ne kadar süre kapalı kalabileceğidir. "En fazla 4 saat" gibi.

RPO (Recovery Point Objective), ne kadarlık veri kaybının kabul edilebileceğidir. "En fazla son 1 saatin verisi" gibi.

Bu iki sayı doğrudan maliyeti belirler. RPO'yu 24 saatten 15 dakikaya indirmek, günlük bir yedekten sürekli replikasyona geçmek demektir ve bu, hem altyapı hem işletme maliyetini katlar. Bu yüzden tüm sistemlere aynı hedefi koymayın; katmanlandırın:

Bu tabloyu doldururken teknik ekibin değil, işin sahibinin cevap vermesi gerekir. "Sipariş sistemi 6 saat kapalı kalırsa ne kaybederiz?" sorusunun karşılığı somut bir rakamsa, o rakam DR bütçesinin gerekçesidir. Yıllık kesinti bütçenizin ne anlama geldiğini görmek için uptime ve SLA hesaplayıcı aracımızı kullanabilirsiniz; %99,9 erişilebilirliğin yılda yaklaşık 8,8 saat kesinti demek olduğunu görmek çoğu tartışmayı hızla netleştirir.

Varlık Envanteri ve Bağımlılık Haritası#

Kurtaramayacağınız tek şey, var olduğunu bilmediğiniz şeydir. Bu yüzden planın ikinci adımı sıkıcı ama vazgeçilmezdir: neyin nerede olduğunu yazın.

Envanterde her sistem için şu alanlar bulunmalı: sistemin adı ve işlevi, çalıştığı sunucu ve IP, hangi veriyi tuttuğu, yedeğinin nerede olduğu, bağımlı olduğu servisler, sorumlu kişi ve kurtarma önceliği.

# dr-envanter.yml — basit ama işe yarar bir başlangıç
sistemler:
  - ad: siparis-veritabani
    sunucu: db1.firmaniz.local (10.0.0.20)
    tur: PostgreSQL 16
    veri: /var/lib/postgresql
    yedek: s3://firmaniz-yedek/pg/  (saatlik WAL, günlük tam)
    bagimlilik: [depolama-agi]
    oncelik: 1
    sorumlu: [email protected]

  - ad: web-uygulama
    sunucu: web1, web2 (10.0.0.11, 10.0.0.12)
    veri: /var/www + kullanıcı yüklemeleri (nesne depolama)
    yedek: git deposu + s3://firmaniz-yedek/uploads/
    bagimlilik: [siparis-veritabani, dns, ssl-sertifika]
    oncelik: 2
    sorumlu: [email protected]

Bağımlılık sütunu, çoğu planın atladığı ve tatbikatta ilk patlayan yerdir. Web uygulamanız veritabanı olmadan açılmaz; veritabanı depolama ağı olmadan bağlanmaz; hiçbiri DNS düzeltilmeden ziyaretçiye ulaşmaz. Kurtarma sırası bu bağımlılıklardan çıkar, sizin sezginizden değil.

Envanterde teknik olmayan üç kalem de mutlaka bulunmalı ve gerçekte en çok bunlar unutulur: alan adı kayıt hesabı (süresi dolan bir alan adı, mükemmel yedeklere rağmen hizmeti bitirir), DNS yönetim erişimi ve SSL sertifikaları ile özel anahtarları. Bir de erişim bilgileri: kurtarmayı yapacak kişi hangi hesaplara nasıl girecek? Parola yöneticisinin kendisi de kurtarma kapsamındadır, çünkü ona erişemiyorsanız diğer hiçbir şeye erişemezsiniz.

Yedekleme Stratejisi: 3-2-1 ve Ötesi#

Klasik 3-2-1 kuralı hâlâ geçerlidir ve ezberlenmesi kolaydır: verinizin 3 kopyası olsun, 2 farklı ortamda tutulsun, 1 tanesi başka bir lokasyonda bulunsun. Modern tehditler karşısında buna iki madde daha eklemek gerekir: 1 kopya değiştirilemez (immutable) olsun ve 0 doğrulanmamış yedek kabul edilmesin.

Değiştirilemez kopya, fidye yazılımına karşı asıl savunmadır. Saldırgan sunucunuza girdiğinde ilk yaptığı iş yedekleri aramak ve silmektir; sunucudan erişilebilen bir yedek deposu, saldırganın da erişebildiği bir depodur. Nesne depolamanın nesne kilidi (object lock) özelliği bu yüzden değerlidir: belirlenen süre boyunca kimse — yönetici bile — o nesneyi silemez. Ayrıntılar için S3 uyumlu nesne depolama yazısına bakabilirsiniz.

Pratik bir yedekleme düzeni şöyle görünür:

#!/usr/bin/env bash
# /usr/local/bin/gunluk-yedek.sh
set -euo pipefail

TARIH=$(date +%F)
HEDEF="s3://firmaniz-yedek"

# 1) Veritabanını tutarlı biçimde al
sudo -u postgres pg_dump -Fc siparis > /tmp/siparis-$TARIH.dump

# 2) Uygulama dosyalarını ve yapılandırmayı arşivle
tar -czf /tmp/config-$TARIH.tar.gz /etc/nginx /etc/postgresql /var/www

# 3) Şifreleyerek uzak depoya gönder
age -r "$(cat /etc/yedek/alici.pub)" -o /tmp/siparis-$TARIH.dump.age /tmp/siparis-$TARIH.dump
aws s3 cp /tmp/siparis-$TARIH.dump.age $HEDEF/pg/
aws s3 cp /tmp/config-$TARIH.tar.gz    $HEDEF/config/

# 4) Yerel geçici dosyaları temizle
rm -f /tmp/siparis-$TARIH.dump /tmp/siparis-$TARIH.dump.age /tmp/config-$TARIH.tar.gz

# 5) Bitişi izleme sistemine bildir — sessiz başarısızlık en tehlikelisidir
curl -fsS "https://izleme.firmaniz.com/ping/gunluk-yedek" > /dev/null

Son adım özellikle önemlidir. Yedekleme işleri sessizce başarısız olur: disk dolar, kimlik bilgisi süresi biter, cron devre dışı kalır ve kimse fark etmez. "Yedek alındı" bildirimi yerine "yedek alınmadı" alarmı kurun; başarı bildirimlerini insanlar bir süre sonra okumaz, eksik kalan bir sinyal ise alarm üretir.

Yedekleme aracı seçimi ikincil bir karardır. Artımlı ve tekilleştirilmiş yedek istiyorsanız Borg ile sunucu yedekleme yazısı iyi bir başlangıç; paylaşımlı hosting kullanıyorsanız cPanel yedekleme rehberi panel üzerinden aynı disiplini kurmanızı sağlar.

Kurtarma Runbook'u Yazmak#

Runbook, felaket anında takip edilecek adım adım talimattır. Yazarken tek bir kriteri gözetin: ekipteki en az deneyimli kişi, gece 03.00'te, stres altında, size ulaşamadan bunu uygulayabilmeli. Bu kriter "veritabanını geri yükleyin" gibi cümleleri otomatik olarak eler.

İyi bir runbook şu bölümlerden oluşur:

1. Tetikleyici ve karar. Bu prosedür hangi durumda başlatılır, kim başlatma kararı verir, kimler haberdar edilir.
2. Ön kontroller. Gerçekten felaket mi, yoksa geçici bir kesinti mi? Yanlış alarmla üretimi yeniden kurmak, felaketin kendisinden pahalıya patlayabilir.
3. Sıralı adımlar. Kopyalanabilir komutlar, tam dosya yolları ve beklenen çıktılar.
4. Doğrulama. Sistem gerçekten çalışıyor mu? Somut kontroller yazın.
5. Geri dönüş. Adım yarıda kalırsa nasıl güvenli bir noktaya dönülür.
6. İletişim. Müşteriye ve ekibe ne zaman, hangi kanaldan ne söylenir.

Örnek bir bölüm şöyle görünmeli:

# ADIM 4: Veritabanını son yedekten geri yükle
# Beklenen süre: ~25 dakika (80 GB dump)

# 4.1 En güncel yedeği bul
aws s3 ls s3://firmaniz-yedek/pg/ | tail -5

# 4.2 İndir ve şifresini çöz
aws s3 cp s3://firmaniz-yedek/pg/siparis-2026-08-25.dump.age /tmp/
age -d -i /etc/yedek/ozel.key -o /tmp/siparis.dump /tmp/siparis-2026-08-25.dump.age

# 4.3 Boş veritabanına geri yükle
sudo -u postgres createdb siparis
sudo -u postgres pg_restore -d siparis -j 4 /tmp/siparis.dump

# 4.4 DOĞRULAMA — bu sorgu dünkü tarihi ve makul bir sayı dönmeli
sudo -u postgres psql -d siparis -c \
  "SELECT max(olusturma_tarihi), count(*) FROM siparisler;"
# Beklenen: max tarih son 1 saat içinde, count > 0

Runbook'u nerede sakladığınız da planın parçasıdır. Yalnızca kurtarmaya çalıştığınız sunucuda duran bir runbook, tam ihtiyacınız olduğu anda erişilemez. Ekibin ulaşabildiği ikinci bir yerde — ve tercihen basılı ya da çevrimdışı erişilebilir bir kopyada — bulundurun.

Tatbikat: Test Edilmeyen Plan Yoktur#

Bu bölüm, yazının en önemli kısmı. Test edilmemiş bir yedek, yedek değil, yedek olduğuna dair bir inançtır. Gerçek kurtarmalarda karşılaşılan sorunlar neredeyse hep aynıdır ve hepsi tatbikatta ucuza yakalanır: dump dosyası bozuk çıkar, şifreleme anahtarı kaybolmuştur, geri yükleme tahmin edilenin üç katı sürer, runbook'taki komut eski sürüme aittir, DNS TTL'i yüzünden geçiş saatler alır.

Üç seviyeli bir tatbikat düzeni kurun:

Haftalık kontrolü otomatikleştirin; insan iradesine bırakılan tekrarlı işler yapılmaz:

#!/usr/bin/env bash
# Yedekten rastgele bir dosyayı geri yükle ve bütünlüğünü doğrula
set -euo pipefail

GECICI=$(mktemp -d)
trap 'rm -rf "$GECICI"' EXIT

aws s3 cp s3://firmaniz-yedek/config/config-$(date +%F).tar.gz "$GECICI/" 
tar -tzf "$GECICI"/config-*.tar.gz > /dev/null   # arşiv okunabiliyor mu
tar -xzf "$GECICI"/config-*.tar.gz -C "$GECICI" etc/nginx/nginx.conf
test -s "$GECICI/etc/nginx/nginx.conf"           # dosya boş değil mi

curl -fsS "https://izleme.firmaniz.com/ping/yedek-dogrulama" > /dev/null

Aylık sistem tatbikatını mümkünse üretimden bağımsız bir sunucuda yapın ve süreyi ölçün. Ölçtüğünüz süre, gerçek RTO'nuzdur; belgeye yazdığınız hedef değil. İkisi arasında büyük fark varsa ya hedefi ya da yöntemi değiştirmeniz gerekir.

Tatbikattan sonra runbook'u mutlaka güncelleyin. Takıldığınız her nokta, planın bir sonraki sürümünde açıklanmış olmalı. Bir tatbikat sonunda hiçbir şey düzeltilmediyse, muhtemelen yeterince gerçekçi değildir.

Sık Yapılan Hatalar ve Tuzaklar#

Yedeği üretim sunucusunda tutmak. Aynı makinenin ikinci diskindeki yedek, sunucu kaybolduğunda ya da fidye yazılımı çalıştığında yok olur. Yedek her zaman ayrı bir hata alanında olmalıdır.

Yedeklerin geri yüklenebildiğini hiç denememek. En yaygın ve en pahalı hata budur. Aylarca alınan yedeklerin bozuk çıktığı ilk kez gerçek felakette anlaşılır.

Şifreleme anahtarını yedeğin yanında saklamak. Anahtar aynı depoda ya da yalnızca kurtarmaya çalıştığınız sunucudaysa, şifreli yedeğiniz kullanılamaz bir dosyadan ibarettir. Anahtarı bağımsız ve erişilebilir bir yerde tutun.

Yalnızca veriyi yedeklemek. Veritabanı dumpı elinizde ama Nginx yapılandırması, cron görevleri, ortam değişkenleri ve SSL anahtarları yoksa kurtarma saatler uzar. Sunucunun "kişiliğini" oluşturan yapılandırmayı da yedekleyin, tercihen bir sürüm kontrol deposunda tutun.

Alan adı ve DNS'i planın dışında bırakmak. Süresi dolan bir alan adı ya da erişilemeyen bir DNS paneli, mükemmel bir teknik kurtarmayı bile görünmez kılar. Alan adı yenilemesini otomatiğe alın ve DNS erişimini en az iki kişiye verin.

Tek kişiye bağımlı olmak. Kurtarmayı yalnızca bir kişi yapabiliyorsa, o kişinin tatilde olması felaketin bir parçasıdır. Runbook'un amacı tam olarak bu bağımlılığı kırmaktır.

RAID ve replikasyonu yedek sanmak. İkisi de kesintisizlik sağlar, geri dönüş sağlamaz. Silinen kayıt tüm kopyalardan silinir.

Sıkça Sorulan Sorular#

RTO ve RPO arasındaki fark nedir#

RTO, hizmetin ne kadar süre kapalı kalabileceğini; RPO ise ne kadarlık veri kaybının kabul edilebileceğini ifade eder. Örneğin RTO'nuz 4 saat, RPO'nuz 1 saat ise sistem en geç 4 saatte ayağa kalkmalı ve en fazla son 1 saatin verisi kaybolmalıdır. RTO altyapı hazırlığını ve kurtarma hızını belirler; RPO ise yedek alma sıklığını ve replikasyon ihtiyacını belirler. İkisi farklı maliyet kalemlerini sürükler, bu yüzden ayrı ayrı konuşulmalıdır.

Yedeklerimi ne sıklıkta test etmeliyim#

Basit dosya geri yükleme testini haftalık ve otomatik yapın; bu, arşivin okunabildiğini ve içeriğin boş olmadığını doğrular. Bir sunucuyu bütünüyle ayrı bir ortamda ayağa kaldırdığınız sistem tatbikatını ayda bir yapmak makul bir hedeftir. Ekibin katıldığı uçtan uca tam tatbikat ise altı ayda bir yeterlidir. Önemli bir mimari değişiklikten sonra sıklıktan bağımsız olarak ek bir test yapın.

Felaket kurtarma planı ne kadar maliyetli olmalı#

Doğru bütçe, kesintinin size maliyetinden hesaplanır. Saatlik kesinti kaybınızı ve kabul ettiğiniz RTO'yu çarpın; DR yatırımı bu rakamın makul bir oranını aşmamalıdır. Küçük bir kurumsal site için günlük şifreli yedek ve yazılı bir runbook neredeyse maliyetsizdir ve büyük fayda sağlar. Sürekli replikasyon ve sıcak yedek sistem ise ciddi maliyet getirir; yalnızca gerçekten kritik sistemler için düşünün ve tüm sistemlere aynı seviyeyi uygulamayın.

Bulut sağlayıcısı zaten yedek alıyor, yeter mi#

Sağlayıcı anlık görüntüleri (snapshot) değerlidir ama tek başına yeterli değildir. Genellikle aynı hesabın içinde ve aynı altyapıda dururlar; hesabınız askıya alınırsa ya da kimlik bilgileriniz ele geçirilirse onlara da erişilemez veya silinebilirler. Ayrıca çoğu snapshot uygulama tutarlılığını garanti etmez; çalışan bir veritabanının ham disk kopyası geri yüklendiğinde onarım gerektirebilir. Sağlayıcı yedeğini birinci katman, kendi aldığınız bağımsız kopyayı ikinci katman olarak konumlandırın.

Fidye yazılımına karşı en etkili koruma nedir#

Değiştirilemez (immutable) yedeklerdir. Saldırganlar sunucuya eriştiklerinde bağlı yedek dizinlerini ve erişebildikleri depoları da şifreler ya da siler; bu yüzden sunucudan silinebilen bir yedek, gerçek bir koruma sağlamaz. Nesne depolamanın nesne kilidi özelliğiyle belirli bir süre boyunca silinemeyen kopyalar tutun ve yedekleme hesabına yalnızca yazma yetkisi verin. Ayrıca yedeklerin bir kopyasının çevrimdışı ya da farklı bir kimlik alanında bulunması riski belirgin şekilde düşürür.

Planı nasıl güncel tutarım#

Planı canlı bir belge gibi ele alın ve güncellemesini bir sürece bağlayın. Her yeni sistem devreye alındığında envantere eklenmesini kontrol listesine koyun, her tatbikattan sonra takıldığınız noktaları runbook'a yazın ve en az altı ayda bir sorumlu kişileri ve erişim bilgilerini gözden geçirin. Planı ekibin günlük kullandığı bir depoda tutmak, ayrı bir belge sisteminde unutulmasından çok daha iyi sonuç verir.

Kapanış#

Felaket kurtarma planı, süslü bir belge değil; sunucunuz kaybolduğunda ne yapacağınızı önceden düşünmüş olmanın yazılı hâlidir. Aklınızda kalması gereken alışkanlıklar şunlar: önce RTO ve RPO'yu belirleyip sistemleri katmanlandırın, yedeklerin en az bir kopyasını ayrı lokasyonda ve değiştirilemez şekilde tutun, kurtarmayı en deneyimsiz kişinin uygulayabileceği bir runbook'a dökün, yedek işlerinin başarısızlığını alarma bağlayın ve en önemlisi düzenli tatbikat yapıp geçen süreyi ölçün. Ölçtüğünüz süre gerçek RTO'nuzdur.

Planın altyapı tarafını kurarken yedeklerinizi üretimden ayrı tutmak için yedekleme çözümlerimize, kurtarma ortamını hızlıca ayağa kaldırmak için bulut sunucu ve VDS paketlerimize göz atabilirsiniz. İzleme, yedek doğrulama ve tatbikat süreçlerini bize bırakmak isterseniz sunucu yönetimi hizmetimiz bu işi üstlenir; taşıma sırasında kesintiyi en aza indirmek için site taşıma hizmetimiz de yanınızda olur.