Felaket kurtarma planı: RTO ve RPO

Felaket Kurtarma; Bir Seçenek Değil, Bir Zorunluluk

Saat sabah 3'ü hayal edin ve ana veritabanındaki bir insan hatası bugünün sipariş tablosunu silmiş olsun. Ya da bir fidye yazılımı saldırısı sunucunuzdaki tüm dosyaları şifrelemiş olsun. Bu anda önemli olan tek şey şudur: Sistemin geri dönmesi ne kadar sürer ve ne kadar veri kaybettiniz? Bu iki sorunun cevabı, teknoloji dünyasında tam olarak RTO ve RPO olarak bilinen ve her felaket kurtarma planının temelini oluşturan kavramlardır.

Birçok kuruluş haftalık bir yedeklemenin yeterli olduğunu düşünür, ancak gerçek bir kriz meydana geldiğinde, bu iki göstergeyi tanımlamamanın, kurtarma süreci üzerindeki kontrolü tamamen kaybetmek anlamına geldiğini fark ederler. Bu makalede, basit ama teknik bir dille, RTO ve RPO'nun ne olduğunu, nasıl hesaplanacağını ve bunlara dayalı gerçek ve uygulanabilir bir felaket kurtarma planının nasıl oluşturulacağını öğreneceksiniz.

RTO ve RPO Nedir? İki Kritik Kavramın Kesin Tanımı

Bu iki terim ilk bakışta benzer görünse de, kurtarmanın tamamen farklı iki yönünü ifade eder. Bunları karıştırmak, pratikte işe yaramayan bir planın tasarlanmasına yol açabilir.

RTO (Recovery Time Objective); Geri Dönüşe Kadar Geçen Süre

RTO, kuruluşunuzun kritik sistemleri olmadan dayanabileceği maksimum süredir. Bu sayı, felaketin ilan edildiği andan hizmetin normale döndüğü ana kadar hesaplanır. RTO'nuz 4 saat ise, sunucuları, ağı ve uygulamaları 4 saat içinde tekrar ayağa kaldırabilmeniz gerekir.

Örneğin, saatte 50 milyon TL satış yapan bir e-ticaret sitesi 8 saat erişilemez durumda kalırsa, 400 milyon TL gelir kaybeder. Bu nedenle, bu işletmenin RTO'su açıkça 8 saatten az olmalıdır.

RPO (Recovery Point Objective); Kabul Edilebilir Maksimum Veri Kaybı

RPO, verileri kurtarabileceğiniz en geri noktayı ifade eder. Başka bir deyişle, bir felaket durumunda kaybetmeyi kabul edebileceğiniz maksimum veri miktarıdır. RPO'nuz 24 saat ise, en kötü durumda bir günlük veriyi kaybedersiniz.

Her saat birkaç makale yayınlayan bir haber sitesine sahip olduğunuzu varsayalım. RPO'nuz 6 saat ise, yayınlanan 6 saatlik haberi kaybedebilirsiniz ki bu bir medya kuruluşu için itibar ve izleyici kaybı anlamına gelir.

İşletmeniz için RTO ve RPO Nasıl Belirlenir?

Bu sayıları belirlemek yalnızca teknik bir karar değildir; bu bir iş kararıdır. Doğru hesaplama için aşağıdaki üç adımı izlemelisiniz.

Birinci Adım: Kritik Sistemlerin Belirlenmesi

Tüm sistemler aynı öneme sahip değildir. Çevrimiçi ödeme veritabanı ile dahili bülten e-posta gönderme sistemi arasında büyük fark vardır. Her sistem için bir iş etkisi analizi (BIA) yapın ve bunları üç kategoriye ayırın:

• Kritik: Durdurulmaları işin tamamen durması anlamına gelir (örneğin ödeme ağ geçidi, ana veritabanı)
• Önemli: Durdurulmaları ciddi aksaklıklara neden olur ancak iş tamamen durmaz (örneğin içerik yönetim sistemi)
• Kritik Olmayan: Durdurulmalarının etkisi azdır ve günlerce bekleyebilir (örneğin dahili raporlama sistemi)

İkinci Adım: Duruş Maliyeti ve Veri Kaybı Maliyetinin Hesaplanması

Her kritik sistem için iki sayı hesaplayın:

1. Saatlik duruş maliyeti: Kaybedilen gelir, boşta kalan çalışan maaşları, sözleşme cezaları ve marka itibarı maliyetinin toplamı
2. Kaybedilen her veri biriminin maliyeti: Veri yeniden oluşturma maliyeti, kaçırılan fırsat maliyeti ve yasal riskler

Ardından RTO'yu kurtarma altyapısı için ayırdığınız bütçeye ve RPO'yu kaybetmeyi göze alabileceğiniz miktara göre ayarlayın. Genel bir kural olarak, daha küçük RTO ve RPO, daha yüksek altyapı maliyeti anlamına gelir.

Üçüncü Adım: Belgeleme ve Onay

Elde edilen sayıları resmi bir belgeye kaydedin ve üst düzey yöneticilerin onayına sunun. Bu belge, altyapı tasarımının ve yedekleme araçlarının seçiminin temelini oluşturacaktır. Bu anlaşma olmadan, altyapıdaki herhangi bir değişiklik istemeden RTO veya RPO'yu ihlal edebilir.

RTO ve RPO'ya Dayalı Felaket Kurtarma Planı Tasarımı

Artık sayılara sahip olduğunuza göre, teknik mimariyi tasarlama zamanı geldi. Çözüm seçimi doğrudan RTO ve RPO değerlerinize bağlıdır.

Yedekleme ve Kurtarma Stratejileri

Her biri farklı bir RTO ve RPO kombinasyonu sunan dört ana strateji vardır:

• Geleneksel Yedekleme (Backup): Birkaç saatlik RPO ve birkaç saatlik RTO için uygundur. Veriler periyodik olarak (örneğin her 6 saatte bir) ayrı bir depolama alanına kopyalanır. Kurtarma, işletim sistemi kurulumu, veri kurtarma ve test gerektirir.
• Pilot Light: Yaklaşık 15 dakikalık RPO ve yaklaşık 1 saatlik RTO için uygundur. Altyapının minimum bir kopyası (örneğin küçük bir veritabanı) her zaman ikinci bölgede çalışır durumda tutulur ve veriler sürekli olarak çoğaltılır. Felaket anında ana hizmetleri ayağa kaldırırsınız.
• Sıcak Bekleme (Warm Standby): Yaklaşık 5 dakikalık RPO ve yaklaşık 15 dakikalık RTO için uygundur. Altyapının tam bir kopyası bekleme modundadır, ancak trafik ona yönlendirilmez. Sadece DNS'i değiştirmeniz yeterlidir.
• Aktif-Aktif (Çoklu Site): Sıfıra yakın RPO ve sıfıra yakın RTO için uygundur. İki site aynı anda aktiftir ve trafik aralarında yük dengelemesi yapılır. Biri çökerse, diğeri tek başına devam eder.

Pratik Örnek: Bir E-Ticaret Sitesi için Tasarım

Günlük 1000 siparişi olan bir e-ticaret siteniz olduğunu varsayalım. Analiziniz şunları gösteriyor:

• Saatlik duruş maliyeti: 20 milyon TL
• Kabul edilebilir maksimum veri kaybı: 30 dakika (yani RPO = 30 dakika)
• İzin verilen maksimum duruş süresi: 2 saat (yani RTO = 2 saat)

Bu sayılara dayanarak, Sıcak Bekleme (Warm Standby) stratejisi uygun bir seçimdir. Uygulama için şunları yapmalısınız:

1. Başka bir veri merkezinde (veya farklı bir bulut bölgesinde) ikinci bir sunucu kurun.
2. Veritabanını sürekli çoğaltma (örneğin MySQL Replication veya PostgreSQL Streaming Replication) kullanarak senkronize tutun.
3. Statik dosyaları (ürün görselleri) rsync gibi araçlarla her 5 dakikada bir senkronize edin.
4. IP veya DNS'i otomatik olarak ikinci sunucuya değiştiren hazır bir failover betiğiniz olsun.

API kullanarak DNS değiştirmek için basit bir failover betiği örneği şu şekilde olabilir:

#!/bin/bash
# Basit failover betiği - DNS kaydını değiştirir
# Bu kavramsal bir örnektir, üretim için hazır değildir

PRIMARY_IP="192.168.1.10"
SECONDARY_IP="192.168.2.10"
DOMAIN="shop.example.com"

# Birincil sunucunun erişilebilir olup olmadığını kontrol et
if ! ping -c 3 -W 2 $PRIMARY_IP > /dev/null 2>&1; then
    echo "Birincil sunucu çevrimdışı. DNS ikincil sunucuya değiştiriliyor..."
    # A kaydını güncellemek için DNS sağlayıcı API'sini çağır
    curl -X POST "https://api.dnsprovider.com/v1/update" \
        -H "Authorization: Bearer YOUR_API_KEY" \
        -d "domain=$DOMAIN&ip=$SECONDARY_IP"
    echo "Failover $(date) tarihinde tamamlandı"
fi

Felaket Kurtarma Planında Sık Yapılan Hatalar

Birçok kuruluş, bir plana sahip olmasına rağmen kriz anında başarısız olur. En yaygın hatalar şunlardır:

Birinci Hata: Planı Test Etmemek

Hiç test edilmemiş bir felaket kurtarma planı, işe yaramaz bir belgedir. En az 6 ayda bir tam bir tatbikat yapın. Bunu, üretim verilerine zarar vermemek için izole bir ortamda gerçekleştirin. Test sırasında gerçek kurtarma süresini ölçün ve belirlenen RTO ile karşılaştırın.

İkinci Hata: Bağımlılıkları Göz Ardı Etmek

Uygulama sunucusunu kurtarmadan veritabanını kurtarmak işe yaramaz. Hizmetler arasındaki bağımlılıkları belirleyin ve kurtarma sırasını planda belirtin. Örneğin, önce veritabanı, sonra API ve en sonunda ön yüz.

Üçüncü Hata: Veritabanı Dışındaki Verileri Unutmak

Birçok plan yalnızca veritabanına odaklanır ve kullanıcı tarafından yüklenen dosyaları, günlükleri ve yapılandırma dosyalarını unutur. Bu dosyaları da RPO'nuza dahil edin ve yedekleme stratejinize ekleyin.

Uygulama Araçları ve Teknikleri

Felaket kurtarma planını uygulamak için çeşitli araçlar mevcuttur. Araç seçimi bütçenize, ekibinizin uzmanlığına ve mevcut altyapınıza bağlıdır.

Açık Kaynak ve Ücretsiz Araçlar

• Bacula veya Amanda: Gelişmiş zamanlama özelliklerine sahip geleneksel yedekleme için
• Rsync: İki sunucu arasında dosya senkronizasyonu için
• MySQL Replication / PostgreSQL Streaming Replication: Veritabanının sürekli çoğaltılması için
• Keepalived: Sanal IP yönetimi ve otomatik failover için

Ticari ve Bulut Araçları

Bulut altyapısı kullanıyorsanız, birçok sağlayıcı felaket kurtarma yönetim araçlarını entegre olarak sunar. Örneğin, ServerNet bulut hizmetleri, farklı bölgeler arasında snapshot ve çoğaltma tanımlama imkanı sunar; bu da Pilot Light veya Sıcak Bekleme stratejilerinin uygulanması için temel oluşturabilir. Hizmet seçerken, sağlayıcının teknik dokümantasyonuna ve SLA'sına mutlaka dikkat edin.

Özet ve Sonraki Adımlar

Belirli sayılar olmadan felaket kurtarma planı bir slogandır, bir plan değildir. RTO ve RPO'yu doğru belirleyerek, kriz anında tam olarak beklediğiniz davranışı sergileyen bir altyapı tasarlayabilirsiniz. Unutmayın:

• RTO ve RPO'yu tahminlere değil, iş etkisi analizine dayanarak belirleyin
• Teknik stratejiyi zevke göre değil, bu sayılara göre seçin
• Planı düzenli olarak test edin ve güncelleyin

Bugün başlayın: Kritik sistemlerinizin bir listesini çıkarın, her biri için tahmini RTO ve RPO yazın ve ardından teknik ekibinizle bir toplantı yapın. Bu, gerçek ve uygulanabilir bir felaket kurtarma planı oluşturmanın ilk adımıdır.