Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
Felaket kurtarma (disaster recovery) planı, bir sunucu arızası, fidye yazılımı saldırısı veya veri merkezi kesintisi sonrasında sistemlerinizi öngörülebilir bir sürede ve kabul edilebilir veri kaybıyla yeniden ayağa kaldırmanızı sağlayan yazılı bir stratejidir. Bu rehber RTO ve RPO kavramlarını açıklar, doğru DR stratejisini seçme sürecini adım adım anlatır ve planınızı gerçek bir tatbikatla nasıl test edeceğinizi gösterir.
Bir DR planını anlamlı kılan, birbirini tamamlayan dört kavramı doğru ayırt etmektir.
Bir kesintiden sonra sistemin yeniden hizmet verir hale gelmesi için kabul edilen azami süredir; iş süreci ne kadar kritikse RTO o kadar kısa tutulmalıdır.
Kesinti anına kadar kabul edilebilecek azami veri kaybı aralığıdır ve doğrudan yedekleme/replikasyon sıklığını belirler.
Failover, birincil sistem devre dışı kaldığında trafiğin yedek sisteme yönlendirilmesidir; standby site sıcak (hot), ılık (warm) veya soğuk (cold) olarak hazırlanabilir, her biri farklı maliyet ve hazır olma süresi sunar.
Yedekleme yalnızca verinin bir kopyasını saklar; felaket kurtarma ise o veriyi kullanarak tüm sistemi, ağı ve erişimi belirli bir sürede yeniden ayağa kaldıracak süreci, altyapıyı ve sorumlulukları kapsar.
Yedek almak yeterli değildir; planlanmamış bir kesinti sırasında kimin ne yapacağını önceden bilmemek, kurtarma süresini saatlerden günlere çıkarabilir.
Planlanmamış kesinti süresince kaybedilen gelir, işlenemeyen siparişler ve müdahale için harcanan mesai, çoğu işletme için hızla büyüyen bir maliyettir.
Disk arızası, veri merkezi kesintisi veya fidye yazılımı saldırısı gibi senaryolarda, önceden test edilmiş bir DR planı olmadan kurtarma süresi öngörülemez hale gelir.
ISO 27001, KVKK ve GDPR gibi çerçeveler, kritik sistemler için belgelenmiş bir iş sürekliliği ve felaket kurtarma sürecini beklemekte veya doğrudan zorunlu kılmaktadır.
Uzun süren veya kötü yönetilen bir kesinti, müşteri güvenini yedeklerden çok daha yavaş şekilde geri kazandırır.
Etkili bir DR planı tek seferlik bir belge değil; düzenli olarak test edilen ve güncellenen yaşayan bir süreçtir.
Hangi sistemlerin durması işi en çok etkiler, hangi tehditler (donanım arızası, fidye yazılımı, insan hatası, doğal afet) gerçekçidir, önce bunu belirleyin.
Her uygulama ve veritabanı için ayrı ayrı kabul edilebilir kesinti süresi ve veri kaybı aralığı tanımlayın; tüm sistemlere aynı hedefi uygulamak genellikle gereksiz maliyet yaratır.
Backup/restore, pilot light, warm standby veya çok siteli active-active mimarilerinden, belirlenen RTO/RPO hedeflerine ve bütçeye uygun olanı seçin.
Kimin, hangi sırayla, hangi komutları çalıştıracağını; DNS, veritabanı ve uygulama katmanının nasıl devreye alınacağını adım adım yazılı hale getirin.
Alınan yedeklerin gerçekten geri yüklenebildiğini düzenli bir restore testiyle kanıtlayın; test edilmemiş yedek, yedek değildir.
Yılda en az bir veya iki kez, canlı sisteme en yakın koşullarda tam bir failover tatbikatı yaparak planın kağıt üzerinde değil pratikte de çalıştığını doğrulayın.
Sistem: E-ticaret veritabanı RTO: 1 saat RPO: 15 dakika Sistem: Kurumsal e-posta RTO: 4 saat RPO: 1 saat Sistem: Dahili wiki/dokümantasyon RTO: 24 saat RPO: 24 saat
rsync -avz --dry-run /var/www/ backup@dr-site:/var/www/
mysql -u restore_test -p dr_test_db < /backups/latest/dump.sql mysqlcheck -u restore_test -p --check dr_test_db
mysql -e "SHOW SLAVE STATUS\G" | grep Seconds_Behind_Master
Türkiye (Türkçe)
Almanya (German)
Worldwide (English)
./failover-test.sh --target=dr-site --dry-run
curl -s -o /dev/null -w "%{http_code}\n" https://dr.example.com/healthfind /backups -maxdepth 1 -type f -mtime +1 -name "*.sql.gz" # 24 saatten eski yedek listelenirse alarm üretir
Yedekleme, verinin bir kopyasını güvenli bir yerde saklamaktır. Felaket kurtarma ise o yedeği kullanarak sunucuları, ağı, DNS ayarlarını ve uygulamaları belirli bir RTO içinde yeniden çalışır hale getirecek süreci, altyapıyı ve ekip sorumluluklarını kapsayan çok daha geniş bir stratejidir.
Kritik sistemler için yılda en az bir veya iki kez tam kapsamlı bir failover tatbikatı, ayrıca yedek geri yükleme testleri aylık olarak yapılmalıdır. Altyapıda büyük bir değişiklik olduğunda (yeni sunucu, yeni veritabanı sürümü) plan yeniden gözden geçirilmelidir.
Çoğu küçük işletme için kritik sistemlerde birkaç saatlik RTO ve 15 dakika ile 1 saat arası bir RPO makul bir başlangıç noktasıdır; daha sıkı hedefler genellikle daha yüksek maliyet ve karmaşıklık getirir.
Zorunlu değildir. Küçük ölçekli işletmeler için düzenli, doğrulanmış off-site yedekler ve hızlıca yeni bir sunucu kurabilme yeteneği yeterli olabilir; yüksek erişilebilirlik gerektiren büyük sistemlerde ikinci bir bölge veya veri merkezi önerilir.
Maliyet seçilen stratejiye göre büyük ölçüde değişir: basit bir backup/restore yaklaşımı yalnızca depolama maliyeti getirirken, sıcak standby veya çok siteli active-active mimariler ikinci bir altyapının sürekli çalıştırılmasını gerektirdiği için önemli ölçüde daha pahalıdır.
Hayır. İş sürekliliği planı (BCP) tüm işletmenin bir kriz sırasında nasıl çalışmaya devam edeceğini (personel, iletişim, tedarik zinciri dahil) kapsar; felaket kurtarma planı ise BCP'nin BT altyapısı ve verilerle ilgili teknik alt kümesidir.
Olağanüstü durum ve felaket kurtarma planlaması için ABD federal referans standardı.
İş sürekliliği yönetim sistemleri için uluslararası standart ve gereksinimler.
Bulut altyapısında dayanıklılık, yedeklilik ve felaket kurtarma tasarımı için referans mimari rehberi.
NVMe disk, otomatik yedekleme seçenekleri ve tam root erişimiyle DR stratejinize uygun Linux VPS paketlerimizi inceleyin.