Disaster Recovery (Felaket Kurtarma) Planı Nedir? Sunucu ve Hosting İçin Uygulama Rehberi

Son Güncelleme: Nisan 2026

Disaster Recovery (felaket kurtarma), sunucu, hosting, VPS, VDS ve kurumsal web altyapılarında hizmet kesintisi sonrası sistemleri yeniden ayağa kaldırmak için oluşturulan kritik bir plandır. Doğru hazırlanmış bir felaket kurtarma planı, veri kaybını azaltır, kesinti süresini kısaltır ve işletmelerin operasyonel devamlılığını güvence altına alır.

İçindekiler

• Disaster Recovery Nedir?
• Felaket Kurtarma Planı Neden Önemlidir?
• Temel Kavramlar: RPO ve RTO
• Sunucu Altyapılarında Risk Senaryoları
• Felaket Kurtarma Planı Nasıl Hazırlanır?
• Felaket Kurtarma Mimarileri
• Yedekleme ve Geri Kurtarma Stratejileri
• Test, Dokümantasyon ve Operasyon Süreçleri
• Pratik Senaryolar ve Uygulama Örnekleri
• Sıkça Sorulan Sorular
• Sonuç

Disaster Recovery Nedir?

Disaster Recovery (DR), Türkçesiyle felaket kurtarma, bir bilgi işlem altyapısında yaşanan kritik arıza, veri kaybı, siber saldırı, donanım bozulması, insan hatası veya doğal afet sonrasında sistemlerin tekrar erişilebilir hale getirilmesi için tanımlanan süreçlerin tamamıdır.

Buradaki temel amaç yalnızca sunucuyu yeniden başlatmak değildir. Asıl hedef; uygulamaları, veritabanlarını, dosyaları, ağ servislerini ve kullanıcı erişimini mümkün olan en kısa sürede, kabul edilebilir veri kaybı sınırları içinde geri döndürmektir.

Birçok işletme yedekleme ile felaket kurtarma kavramını aynı şey sanır. Oysa yedek almak, felaket kurtarma planının sadece bir parçasıdır. Eğer hangi sistemin hangi sırayla geri yüklenmesi gerektiği, DNS yönlendirmelerinin nasıl değiştirileceği, uygulama bağımlılıklarının neler olduğu ve kimlerin hangi görevleri üstleneceği belirlenmemişse, tek başına yedek dosyaları yeterli olmaz.

Felaket Kurtarma Planı Neden Önemlidir?

Modern web projeleri artık tek bir web sitesinden ibaret değildir. Arka planda veritabanları, önbellek (cache), dosya depolama, e-posta servisleri, API servisleri, kuyruk sistemleri, güvenlik katmanları ve üçüncü taraf entegrasyonlar birlikte çalışır. Bu nedenle tek bir bileşendeki sorun bile tüm hizmeti etkileyebilir.

Kesinti maliyetini azaltır

Bir e-ticaret sitesi, SaaS uygulaması veya kurumsal portal için birkaç saatlik erişim kesintisi bile satış kaybı, müşteri memnuniyetsizliği ve marka güveninde zedelenme yaratabilir. Hazırlıklı bir DR planı, kesinti süresini azaltarak doğrudan mali kaybın önüne geçer.

Veri kaybını sınırlar

Yanlış silinen veriler, bozulmuş dosya sistemleri, fidye yazılımı (ransomware) saldırıları veya başarısız güncellemeler sonrası geri dönüş için yedeklerin ne kadar güncel olduğu kritik önemdedir. Felaket kurtarma yaklaşımı, yalnızca “yedek var mı?” sorusuna değil, “ne kadar veri kaybetmeyi kabul edebiliriz?” sorusuna da cevap verir.

Operasyonel süreklilik sağlar

Özellikle müşteriye hizmet sunan sistemlerde hizmet sürekliliği (business continuity - iş sürekliliği) kritik bir başlıktır. DR planı, ekiplerin kriz anında panik yerine prosedürlerle hareket etmesini sağlar.

Güvenlik olaylarında toparlanmayı hızlandırır

Sunucu ele geçirilmesi, zararlı yazılım bulaşması veya yetkisiz erişim gibi durumlarda temiz sistemlere dönüş yapabilmek için önceden tanımlı, test edilmiş bir kurtarma planına ihtiyaç vardır.

Temel Kavramlar: RPO ve RTO

Felaket kurtarma planlarının temelinde iki kritik metrik bulunur: RPO ve RTO. Bu iki kavram doğru anlaşılmadan sağlıklı bir DR stratejisi kurulamaz.

RPO nedir?

RPO (Recovery Point Objective), Türkçesiyle hedef kurtarma noktası, kabul edilebilir maksimum veri kaybı süresini ifade eder. Örneğin RPO değeri 15 dakika ise, en kötü senaryoda son 15 dakikalık veri kaybı tolere edilebilir demektir.

Yüksek işlem hacmine sahip bir sipariş sistemi için 24 saatlik RPO genellikle kabul edilemez. Buna karşılık düşük trafik alan tanıtım sitelerinde günlük yedekleme yeterli olabilir.

RTO nedir?

RTO (Recovery Time Objective), Türkçesiyle hedef kurtarma süresi, bir sistemin ne kadar sürede tekrar çalışır hale getirilmesi gerektiğini tanımlar. Örneğin RTO değeri 1 saat olan bir hizmet için felaket sonrası en fazla 1 saat içinde erişim yeniden sağlanmalıdır.

RPO ve RTO birlikte nasıl değerlendirilir?

Bu iki değer doğrudan altyapı yatırımını etkiler. Daha düşük RPO ve daha düşük RTO hedefleri, daha gelişmiş replikasyon (çoğaltma), otomasyon, yedekleme ve yedek altyapı maliyetleri anlamına gelir. Bu nedenle her uygulama için ayrı hedefler belirlenmelidir.

Sunucu Altyapılarında Risk Senaryoları

Felaket kurtarma planı oluştururken önce hangi risklerin sistemleri etkileyebileceğini tanımlamak gerekir. Bu riskler yalnızca fiziksel afetlerden oluşmaz.

Donanım arızaları

• Disk arızası: RAID yapısı olsa bile yanlış yapılandırma veya eşzamanlı disk kaybı veri erişimini bozabilir.
• Anakart veya güç ünitesi arızası: Fiziksel sunucunun tamamen hizmet dışı kalmasına neden olabilir.
• Ağ ekipmanı problemi: Switch, router veya uplink sorunları erişim kesintisi oluşturabilir.

Yazılımsal sorunlar

• Hatalı güncelleme: Kernel, panel, PHP, veritabanı veya uygulama güncellemesi sistemi bozabilir.
• Yanlış konfigürasyon: Nginx, Apache, firewall veya DNS yapılandırma hataları erişim sorunlarına yol açabilir.
• Veritabanı bozulması: Tabloların bozulması veya replikasyon kopması uygulamayı durdurabilir.

Güvenlik olayları

• Ransomware (fidye yazılımı): Verilerin şifrelenmesi ve sistemlerin kullanılamaz hale gelmesiyle sonuçlanabilir.
• Yetkisiz erişim: Root veya yönetici hesabının ele geçirilmesi kritik değişikliklere neden olabilir.
• Silme veya tahrifat: Dosyaların, logların veya veritabanlarının kasıtlı olarak değiştirilmesi mümkündür.

İnsan kaynaklı hatalar

Gerçek hayatta yaşanan kesintilerin önemli bir kısmı yanlış komut çalıştırılması, hatalı deploy (yayınlama), yanlış disk bağlama veya eksik güvenlik kuralı tanımlama gibi insan hatalarından kaynaklanır.

Felaket Kurtarma Planı Nasıl Hazırlanır?

Etkili bir DR planı, belge hazırlamaktan ibaret değildir. Teknik, operasyonel ve yönetsel bileşenleri birlikte ele alan yaşayan bir süreçtir.

1. Kritik varlıkları envanterleyin

İlk adım, korunması gereken tüm sistemleri listelemektir. Buna aşağıdakiler dahil olabilir:

• Web sunucuları: Uygulama veya siteyi yayınlayan sistemler.
• Veritabanları: MySQL, MariaDB, PostgreSQL veya diğer veri katmanları.
• Dosya depoları: Medya dosyaları, kullanıcı yüklemeleri, yedek arşivleri.
• DNS ve ağ servisleri: Erişim için kritik yönlendirme bileşenleri.
• Panel ve yönetim araçları: cPanel, Plesk veya özel yönetim panelleri.

2. İş etki analizi yapın

Her servis aynı önemde değildir. Hangi sistemin durması doğrudan gelir kaybı yaratıyor, hangisi birkaç saat sonra toparlanabilir, bunu belirlemek gerekir. Böylece öncelik sırası çıkarılır.

3. RPO ve RTO hedeflerini belirleyin

Her sistem için ölçülebilir hedefler tanımlayın. Örneğin:

• E-ticaret veritabanı: RPO 5 dakika, RTO 30 dakika.
• Kurumsal web sitesi: RPO 24 saat, RTO 4 saat.
• Log sunucusu: RPO 1 saat, RTO 8 saat.

4. Kurtarma sırasını yazılı hale getirin

Kriz anında hangi servis önce açılacak? Önce veritabanı mı, sonra uygulama mı, yoksa önce ağ mı doğrulanacak? Bu sıra net olarak tanımlanmalıdır.

5. Sorumluluk matrisi oluşturun

Kim yedekleri doğrular, kim DNS değişikliği yapar, kim müşteri iletişimini yönetir, kim güvenlik incelemesini yürütür? Roller açıkça belirtilmelidir.

Felaket Kurtarma Mimarileri

Her işletme için aynı DR mimarisi uygun değildir. Trafik yoğunluğu, bütçe, uygulama yapısı ve tolerans seviyesine göre farklı modeller kullanılabilir.

Cold Site (soğuk yedek ortam)

Bu modelde yedek altyapı hazırdır ancak sürekli aktif değildir. Gerektiğinde sistemler elle veya yarı otomatik şekilde ayağa kaldırılır. Maliyeti daha düşüktür fakat RTO genellikle daha uzundur.

Warm Site (ılık yedek ortam)

Bazı servislerin hazır tutulduğu, ancak tam yük altında sürekli çalışmadığı modeldir. Yedek sunucular ve temel yapılandırmalar hazırlanmıştır. Orta seviye maliyet ve orta seviye toparlanma süresi sunar.

Hot Site (sıcak yedek ortam)

Canlı ortama çok yakın çalışan, replikasyon ve anlık senkronizasyon kullanılan yapıdır. Arıza durumunda hızlı geçiş yapılabilir. Özellikle yüksek erişilebilirlik gerektiren projelerde tercih edilir.

Eğer büyüyen bir projeniz varsa, altyapınızı Sanal Sunucu, Kiralık Sunucu veya Bulut Sunucu çözümleriyle felaket kurtarma senaryolarına daha uygun hale getirebilirsiniz.

Yedekleme ve Geri Kurtarma Stratejileri

Başarılı bir DR stratejisinin omurgasını doğru yedekleme yaklaşımı oluşturur. Ancak burada yalnızca yedek almak değil, yedeğin geri dönebilir olması esastır.

3-2-1 yedekleme yaklaşımı

• 3 kopya veri: Orijinal veri dahil en az üç kopya tutulmalıdır.
• 2 farklı ortam: Örneğin yerel disk ve nesne depolama (object storage - nesne depolama).
• 1 kopya dış lokasyonda: Ana sunucudan bağımsız farklı fiziksel veya mantıksal ortamda saklanmalıdır.

Uygulama tutarlılığı önemlidir

Özellikle veritabanı kullanan sistemlerde sadece dosya kopyalamak yeterli olmayabilir. Veritabanı dump, snapshot veya transaction log tabanlı yöntemlerle tutarlı yedekler alınmalıdır.

İmmutable backup nedir?

Immutable backup (değiştirilemez yedek), belirli bir süre boyunca silinemeyen veya değiştirilemeyen yedek kopyalarını ifade eder. Bu yaklaşım özellikle fidye yazılımına karşı güçlü koruma sağlar.

Versiyonlama kullanın

Tek bir son yedeğe güvenmek risklidir. Bozuk veri de yedeklenmiş olabilir. Bu nedenle saatlik, günlük, haftalık ve aylık versiyonlar tutmak daha güvenlidir.

Kritik verilerinizi korumak için profesyonel bir Yedekleme Hizmeti planı oluşturmak, felaket sonrası toparlanma süresini ciddi ölçüde kısaltabilir.

Test, Dokümantasyon ve Operasyon Süreçleri

Test edilmeyen bir felaket kurtarma planı, gerçek kriz anında çoğu zaman işe yaramaz. Bu nedenle planın belirli aralıklarla sınanması gerekir.

Masa başı tatbikatlar

Ekip üyeleri bir araya gelerek “veritabanı sunucusu çöktü”, “ana lokasyon erişilemez oldu”, “ransomware saldırısı gerçekleşti” gibi senaryolar üzerinden adım adım ilerler. Bu yöntem süreç açıklarını hızlıca görmeyi sağlar.

Teknik geri dönüş testleri

Yedeklerden örnek geri yükleme yapılmalı, uygulama ayağa kaldırılmalı, kullanıcı girişleri, API çağrıları ve veritabanı kontrolleri test edilmelidir.

Dokümantasyon içeriği nasıl olmalı?

• Sistem envanteri: Sunucular, IP adresleri, roller, bağımlılıklar.
• Erişim bilgileri politikası: Parolaların nerede ve nasıl güvenli tutulduğu.
• Kurtarma adımları: Sıralı ve net operasyon prosedürleri.
• İletişim listesi: Teknik ekip, yönetim, servis sağlayıcılar ve kritik paydaşlar.
• Doğrulama checklist'i: Kurtarma sonrası yapılacak kontroller.

Otomasyonun rolü

Tekrarlanan işlemler için otomasyon kullanmak insan hatasını azaltır. Örneğin servis başlatma, yedekten geri dönme, DNS güncelleme veya sağlık kontrolleri scriptlerle standardize edilebilir.

# Örnek servis kontrol komutları
systemctl status nginx
systemctl status mariadb
systemctl status php-fpm

# Örnek veritabanı yedeği geri yükleme
mysql -u root -p veritabani_adi < yedek.sql

# Örnek dosya senkronizasyonu
rsync -avz /backup/app/ /var/www/app/

Komutların gerçek ortama uygulanmadan önce test ortamında doğrulanması gerekir. Özellikle üretim (production - canlı ortam) sistemlerinde otomasyon scriptleri sürüm kontrollü şekilde saklanmalıdır.

Pratik Senaryolar ve Uygulama Örnekleri

Senaryo 1: WordPress tabanlı kurumsal site

Kurumsal bir WordPress sitesinde temel ihtiyaç genellikle düşük veri kaybı değil, hızlı geri dönüş olur. Bu nedenle günlük tam yedek, saatlik veritabanı yedeği ve medya dosyaları için dış lokasyon kopyası yeterli olabilir. Böyle bir yapı için Hosting veya Linux Hosting çözümleri üzerinde planlı yedekleme kurgulanabilir.

Senaryo 2: E-ticaret uygulaması

Sipariş, ödeme ve müşteri verilerinin yoğun işlendiği sistemlerde düşük RPO gerekir. Veritabanı replikasyonu, daha sık snapshot, uygulama dosyaları için sürüm kontrollü dağıtım ve yedek lokasyon devreye alma prosedürü oluşturulmalıdır.

Senaryo 3: API ve mikro servis altyapısı

Birden fazla servis içeren yapılarda sadece ana uygulamayı kurtarmak yetmez. Redis, queue, worker, object storage ve veritabanı gibi bağımlılıkların da sırayla ayağa kaldırılması gerekir. Bu tür projeler için Uygulama Sunucuları çözümleri daha kontrollü bir yapı sunabilir.

Senaryo 4: Fidye yazılımı saldırısı sonrası toparlanma

Bu durumda doğrudan geri yükleme yapmak yerine önce olayın kapsamı analiz edilmelidir. Temiz imajdan yeni sistem kurulmalı, güvenlik açıkları kapatılmalı, ardından saldırı öncesi doğrulanmış yedekler geri yüklenmelidir. SSL, erişim ve güvenlik katmanlarının da yeniden kontrol edilmesi gerekir. Gerekirse SSL Sertifikası ve diğer servis bileşenleri yeniden planlanmalıdır.

Senaryo 5: Bölgesel kesintilere karşı coğrafi yedeklilik

Tek lokasyona bağımlı çalışmak bazı projeler için büyük risktir. Trafiğin ve yedeklerin farklı bölgelerde tutulması, daha dayanıklı bir yapı sağlar. İhtiyaca göre Türkiye Kiralık Sunucu, Almanya Kiralık Sunucu veya Fransa Kiralık Sunucu seçenekleriyle çok bölgeli stratejiler kurulabilir.

Sıkça Sorulan Sorular

Sonuç

Disaster Recovery (felaket kurtarma) planı, yalnızca büyük ölçekli şirketler için değil; web sitesi, e-ticaret altyapısı, kurumsal portal, SaaS uygulaması veya müşteri verisi barındıran her işletme için kritik bir gerekliliktir. Başarılı bir plan; risk analizi, RPO ve RTO hedefleri, doğru yedekleme stratejisi, test süreçleri ve net operasyon adımlarının birleşiminden oluşur.

Eğer altyapınızı daha dayanıklı hale getirmek, farklı lokasyonlarda yedekli yapı kurmak veya projenize uygun hosting, sanal sunucu, kiralık sunucu ve yedekleme çözümlerini değerlendirmek istiyorsanız Corelux’un Sanal Sunucu, Kiralık Sunucu, Hosting ve Yedekleme Hizmeti seçenekleri ile ihtiyaçlarınıza uygun profesyonel bir yapı oluşturabilirsiniz.