Hosting yedeği ile uygulama felaket kurtarma aynı şey değildir. Bu rehber RPO ve RTO’yu işletme diline çevirir; hangi varlıkların korunacağını, nasıl yedekleneceğini ve nasıl test edileceğini adım adım netleştirir.
Birçok işletme sunucu yedeği alındığında her şeyin güvende olduğunu varsayar. Oysa kesinti, bozulan veri veya yanlış silinen kritik kayıt geldiğinde asıl ihtiyaç bir yazılım felaket kurtarma planıdır. Bu plan hangi bilginin ne kadar kaybedilebileceğini, sistemin ne kadar sürede ayağa kalkacağını ve kimin ne yapacağını önceden netleştirir.
Bu rehberde hosting yedeği ile uygulama felaket kurtarmayı ayırıyor, RPO ve RTO’yu işletme diline çeviriyor ve test edilebilir bir çerçeve sunuyoruz. Amaç korkutmak değil; ölçülebilir bir yol çizmek.
Hosting Yedeği ile Yazılım Felaket Kurtarma Planı Farkı
Hosting yedeği çoğunlukla sunucu disk görüntüsü, veritabanı dökümü veya dosya kopyasıdır. Faydalıdır; fakat tek başına “işin devam etmesi” anlamına gelmez. Felaket kurtarma, yedekten daha geniş bir operasyonel çerçevedir.
Yedek sorar: “Veri bir yerde duruyor mu?” Kurtarma planı sorar: “Bu veriyi hangi sırayla, hangi ortamda, kimin onayıyla ve hangi iş akışlarıyla tekrar çalışır hale getireceğiz?”
- Kapsam farkı: Yedek dosya ve veritabanına bakar. Plan; yapılandırma, entegrasyon, kimlik bilgileri, DNS, ödeme ve kargo bağlantıları, kuyruklar ve zamanlanmış işleri de kapsar.
- Zaman farkı: Yedek “geri yüklenebilirlik” sağlar. Plan “ne kadar süre iş durabilir” sorusuna cevap verir.
- Sorumluluk farkı: Yedek teknik bir görevdir. Plan; iş sahibi, destek, geliştirme ve operasyon rollerini bir araya getirir.
Kısaca: yedek bir araçtır. Yazılım felaket kurtarma planı ise o aracı iş sürekliliğine bağlayan karar setidir.
RPO ve RTO’yu İşletme Dilinde Anlamak
Teknik jargon planı boğmamalı. İki kavramı sade tutun.
RPO (Recovery Point Objective) ne kadar veri kaybını tolere edebileceğinizi anlatır. “Son yedek ile olay anı arasında ne kadar iş kaybolabilir?” sorusudur. Sipariş, stok hareketi veya fatura kaydı yoğun bir sistemde RPO kısa tutulmak ister; arşiv nitelikli içerikte daha esnek olabilir.
RTO (Recovery Time Objective) sistemin ne kadar sürede yeniden kullanılabilir olacağını hedefler. “Müşteri sipariş veremeden, ekip işlem yapamadan en fazla ne kadar bekleyebiliriz?” sorusudur.
Bu hedefleri her modül için aynı yazmak zorunda değilsiniz. Sipariş ve ödeme akışı ile içerik yönetim paneli farklı tolere edebilir. Hedefi “her şey sıfır kayıp, sıfır süre” diye abartmak planı kâğıt üzerinde bırakır; gerçekçi ve önceliklendirilmiş hedefler yazın.
Pratik çeviri örneği
- RPO 15 dakika: “En fazla son 15 dakikalık sipariş veya stok hareketini yeniden girmek zorunda kalabiliriz.”
- RTO 4 saat: “Kritik satış ve destek ekranları en geç 4 saatte erişilebilir olmalı; raporlama ertesi güne kalabilir.”
Hedefler belirlendikten sonra yedek sıklığı, yedek tipi ve yedekleme mimarisi bu sayılara göre seçilir. Tersi yapılmaz.
Önce Korunacak Varlıkları Listeleyin
Plan, “her şeyi yedekleyelim” cümlesiyle başlamamalı. Önce neyin iş değerini taşıdığını yazın.
- İşlem verisi: sipariş, müşteri, stok, fatura, randevu, talep kayıtları
- Uygulama kodu ve sürümleri: canlıda çalışan sürüm, migration’lar, yapılandırma şablonları
- Ortam bilgisi: ortam değişkenleri, API anahtarlarının güvenli referansları, domain ve DNS kayıtları
- Entegrasyonlar: ödeme, kargo, e-posta, SMS, ERP, muhasebe köprüleri
- Dosya ve medya: fatura PDF’leri, ürün görselleri, sözleşme ekleri
- Operasyon bilgisi: kim erişir, kim onaylar, hangi runbook kullanılır
Bu envanter, yazılım yol haritası çalışması gibi öncelik verir: her varlık aynı kritiklikte değildir. “Kesilirse ciro durur”, “manuel devam eder”, “ertelenebilir” diye üç kova açmak yeterlidir.
Yedekleme Stratejisini RPO’ya Göre Kurun
Yedek, felaket kurtarmanın omurgasıdır; fakat tek tip yedek her senaryoyu çözmez.
Ne yedeklenecek, nasıl yedeklenecek?
- Veritabanı: düzenli full + artımlı veya sürekli log tabanlı yaklaşımlar; tutarlılık ve geri yükleme testi şarttır.
- Dosya depoları: medya ve belge alanları ayrı sürüme alınmalı; yalnızca sunucu imajına güvenmeyin.
- Kod ve yapılandırma: kaynak kod depoda, dağıtım betikleri ve ortam şablonları erişilebilir olmalı.
- Gizli bilgiler: anahtarları yedek dosyasına düz metin koymayın; erişim kontrollü gizli deposu kullanın.
3-2-1 prensibini işletme diline çevirin
En az üç kopya, iki farklı ortam/medya, bir kopya da birincil lokasyondan ayrı tutulur. Amaç tek bir sağlayıcı, tek bir disk veya tek bir yanlış silme ile her şeyin gitmesini engellemektir.
Ayrıca yedeklerin değiştirilemez veya yanlışlıkla silinmeye karşı korumalı bir kopyası planı güçlendirir. Fidye yazılımı veya hatalı script senaryosunda “yedek de silindi” riski gerçek bir iş riskidir.
| Konu | Hosting / sunucu yedeği | Uygulama felaket kurtarma |
|---|---|---|
| Odak | Dosya ve sunucu geri yükleme | İşin kabul edilebilir sürede devam etmesi |
| Başarı ölçütü | Yedek dosyası mevcut mu? | RPO/RTO hedefleri karşılandı mı? |
| Kapsam | Disk, veritabanı dökümü | Veri + entegrasyon + roller + runbook + test |
| Sıklık | Genelde takvimli yedek | İş kritikliği ve olay senaryolarına göre |
| Sahiplik | Çoğunlukla altyapı/hosting | İş + ürün + teknik birlikte |
Felaket Senaryolarını ve Runbook’u Yazın
Plan genel cümlelerle kalırsa kriz anında işe yaramaz. Birkaç somut senaryo seçin ve her biri için adım sırası yazın.
- Veritabanı bozulması veya yanlış toplu güncelleme
- Yanlışlıkla silinen kritik kayıtlar
- Uygulama sürümünün hatalı yayınlanması
- Üçüncü parti ödeme veya kargo entegrasyonunun çökmesi
- Sağlayıcı kesintisi veya erişilemeyen birincil ortam
- Yetkisiz erişim şüphesi ve acil parola/anahtar rotasyonu
Her senaryoda şu başlıklar net olsun:
- Kim ilk haberi alır ve kim karar verir?
- Hangi metrik veya alarm “olay” sayılır?
- İlk 15 dakikada hangi kontroller yapılır?
- Hangi yedekten, hangi noktaya dönüş yapılır?
- Entegrasyonlar hangi sırayla doğrulanır?
- Müşteri ve iç ekibe ne zaman, nasıl bilgi verilir?
- Ne zaman “kısmi hizmet” ile devam edilir, ne zaman tam geri dönüş hedeflenir?
Runbook’u wiki’de unutulmuş bir PDF gibi bırakmayın. Erişilebilir, sade ve güncel tutun. Kritik adımlarda ekran görüntüsü yerine komut/checklist ve sorumlu rol yazmak daha kullanışlıdır.
Test Etmeden Plan Yoktur
Hiç denenmemiş yedek, yedek değil varsayımdır. Testi yılda bir “büyük tatbikat”a sıkıştırmak da risklidir. Küçük ve sık kontroller daha değerlidir.
Minimum test seti
- Geri yükleme duman testi: yedekten ayrı bir ortamda veritabanı ve dosyaları ayağa kaldırın.
- Uçtan uca iş akışı: sipariş oluşturma, ödeme simülasyonu, stok düşümü, bildirim gibi kritik yolu çalıştırın.
- Süre ölçümü: gerçek RTO’ya yaklaşmak için adımların ne kadar sürdüğünü kaydedin.
- Erişim ve sırlar: anahtarlar, sertifikalar ve yetkiler felaket ortamında da çalışıyor mu bakın.
Test sırasında performans darboğazı da ortaya çıkabilir. Yedekten dönen sistem açılıyor ama yoğunlukta kilitleniyorsa plan yarım kalır; bu noktada yazılım performans testi ile kurtarma sonrası yük davranışını da değerlendirmek gerekir.
Bulguları “düzeltme işi” olarak yol haritasına geri yazın. Aksi halde test raporu raflarda kalır.
Küçük Ekipler İçin Uygulanabilir Kurulum Adımları
Büyük bir kriz masası kurmak zorunda değilsiniz. KOBİ ölçeğinde sade bir iskelet yeterlidir.
- Kritik iş akışlarını seçin: en fazla 3–5 akış (ör. sipariş alma, stok, faturalama, destek kaydı).
- Her akış için RPO/RTO yazın: ideal değil, tolere edilebilir değerler.
- Yedek envanterini çıkarın: ne, nerede, ne sıklıkla, kim erişir, son başarılı test tarihi.
- İkincil erişim yolunu tanımlayın: birincil bulut paneli kapalıysa kim, hangi yöntemle devreye girer?
- Tek sayfalık runbook hazırlayın: arama, karar, geri yükleme, doğrulama, iletişim.
- Aylık mini test koyun: her ay bir parçayı deneyin; üç ayda bir daha geniş senaryo çalıştırın.
- Değişiklik sonrası kontrol ekleyin: büyük sürüm, altyapı taşıma veya entegrasyon değişiminde yedek ve geri dönüş yolunu yeniden doğrulayın.
Yeni bir özel yazılım veya büyük bir mimari değişiklik planlıyorsanız, felaket kurtarma varsayımlarını baştan proof of concept aşamasında sınamak sonradan pahalı sürprizleri azaltır.
İzleme, Sahiplik ve Sürekli İyileştirme
Planı yazmak yetmez; yaşayan bir sistem haline getirmek gerekir.
- Sahiplik: teknik yürütücü ile iş onayı ayrı roller olsun. “Herkes sorumlu” fiilen “kimse sorumlu değil” demektir.
- Alarmlar: yalnızca sunucu down değil; yedek başarısızlığı, yedek yaşı, disk doluluğu ve başarısız senkron da izlensin.
- Değişiklik kaydı: hangi sürüm canlıda, hangi migration uygulandı, hangi anahtar döndürüldü bilinmeli.
- Tedarikçi bağımlılığı: hosting, e-posta, ödeme ve depolama sağlayıcılarının kendi kesinti bildirim kanalları takip edilsin.
- Gözden geçirme ritmi: çeyreklik kısa bir oturumda RPO/RTO hâlâ gerçekçi mi, runbook güncel mi bakın.
KepezWeb olarak özel yazılım ve bakım süreçlerinde bu başlıkları “sonradan eklenen güvenlik maddesi” gibi değil, ürünün işletilebilirliğinin parçası olarak ele alıyoruz. Plan ne kadar sade yazılırsa ekip o kadar hızlı uygular.
Sıkça Sorulan Sorular
Hosting yedeği yazılım felaket kurtarma planı yerine geçer mi?
Hayır. Hosting yedeği gerekli bir bileşendir; fakat rol dağılımı, entegrasyon sırası, RPO/RTO hedefleri ve test edilmiş geri dönüş adımları olmadan iş sürekliliği planı sayılmaz.
RPO ve RTO’yu nasıl seçmeliyiz?
Teknik ekibin “mümkün olan en iyisi” cümlesinden değil, işin tolere edebileceği kayıp ve kesinti süresinden yola çıkın. Kritik akışlar için daha sıkı, destekleyici akışlar için daha esnek hedefler yazın.
Yedekleri ne sıklıkla test etmeliyiz?
En azından düzenli geri yükleme doğrulaması yapın. Her yedekleme işinin “başarılı” logu yetmez; ayrı bir ortamda ayağa kalkıp kritik iş akışının çalıştığını görmek gerekir. Büyük sürümlerden sonra da kısa kontrol ekleyin.
Küçük bir ekiple bu planı yürütmek mümkün mü?
Evet. Tüm senaryoları aynı anda mükemmelleştirmek yerine önce ciroyu durduran 2–3 akışa odaklanın. Tek sayfalık runbook, net sahiplik ve aylık mini test çoğu KOBİ için güçlü bir başlangıçtır.
Felaket kurtarma ile yüksek erişilebilirlik aynı şey midir?
Değildir. Yüksek erişilebilirlik kesintiyi azaltmaya çalışır; felaket kurtarma ise ciddi bir olay sonrası kabul edilebilir kayıp ve süreyle geri dönüşü yönetir. İkisi birbirini tamamlar, birbirinin yerine geçmez.
Uygulamanızın yedek, geri dönüş ve süreklilik ihtiyaçlarını netleştirmek istiyorsanız KepezWeb ekibiyle kapsamı birlikte sadeleştirebilirsiniz. Mevcut yazılımınız veya yeni projeniz için uygun yaklaşımı konuşmak üzere teklif al sayfasından bize ulaşabilirsiniz. İhtiyaca göre yazılım geliştirme sürecine felaket kurtarma varsayımlarını da en baştan dahil edebiliriz.
