CloudRUX Logo
    Datacenter 1
    Datacenter 2
    Datacenter 3
    İş Sürekliliği

    KOBİ'ler İçin Felaket Kurtarma Planı: RPO ve RTO Nasıl Belirlenir?

    CloudRUX Mühendislik Ekibi
    3 dk

    Her sistem için sıfır veri kaybı ve anında dönüş istemek bütçeyi patlatır. İş etki analiziyle sistemleri sınıflandırıp her biri için doğru RPO/RTO hedefini ve teknolojisini seçmenin pratik yolu.

    Felaket kurtarma (DR) planı denince birçok KOBİ'nin aklına "her gece yedek alıyoruz" cevabı gelir. Oysa yedek, verinin bir kopyasıdır; felaket kurtarma ise işin yeniden çalışır hale gelmesidir. Bir yangın, donanım arızası veya fidye yazılımı saldırısından sonra ne kadar veri kaybedebileceğinizi ve ne kadar süre durabileceğinizi önceden bilmiyorsanız, planınız yok demektir. Bu iki soru, RPO ve RTO kavramlarıyla cevaplanır.

    RPO ve RTO Nedir?

    • RPO (Recovery Point Objective — Kurtarma Noktası Hedefi): Kabul edilebilir en fazla veri kaybı süresi. Her gece yedek alıyorsanız RPO'nuz yaklaşık 24 saattir; öğleden sonra yaşanan bir felakette o günün tüm verisi kaybolur.
    • RTO (Recovery Time Objective — Kurtarma Süresi Hedefi): Sistemin yeniden kullanılabilir hale gelmesi için kabul edilebilir en uzun süre.

    İkisi de kısaldıkça maliyet artar. Bu yüzden her sistem için "sıfır kayıp, anında dönüş" hedeflemek yerine, sistemleri iş için önemine göre ayırmak gerekir.

    Adım 1: İş Etki Analizi

    Her sistem için şu soruları sorun:

    • Bu sistem bir saat durursa ne kaybederiz? Satış, üretim, müşteri memnuniyeti, sözleşme cezası?
    • Bu sistemdeki son bir saatlik veri kaybolursa yeniden oluşturabilir miyiz?
    • Yasal veya sözleşmesel bir erişilebilirlik yükümlülüğü var mı?
    • Bu sistem hangi diğer sistemlere bağımlı?

    Bu analizi BT ekibi tek başına değil, iş birimleriyle birlikte yapmalıdır. Hangi sistemin kritik olduğunu en iyi o sistemi kullanan ekip bilir.

    Adım 2: Sistemleri Katmanlara Ayırın

    • Katman 1 — Kritik: ERP, e-ticaret, ödeme ve sipariş sistemleri. Hedef: RPO dakikalar, RTO birkaç saat. Uygun teknoloji: farklı bir veri merkezine sürekli replikasyon.
    • Katman 2 — Önemli: E-posta, dosya sunucusu, CRM. Hedef: RPO 1–4 saat, RTO aynı iş günü. Uygun teknoloji: sık aralıklı replikasyon veya anlık görüntü kopyalama.
    • Katman 3 — Destekleyici: Arşiv, test ve geliştirme ortamları. Hedef: RPO 24 saat, RTO birkaç gün. Uygun teknoloji: lokasyon dışı yedekten geri yükleme.

    Adım 3: Bağımlılıkları ve Sırayı Belirleyin

    Uygulama sunucusunu dakikalar içinde ayağa kaldırmak, kimlik doğrulama (Active Directory) ve DNS çalışmıyorsa işe yaramaz. Geri dönüş sırasını yazılı hale getirin: önce ağ, kimlik ve DNS; sonra veritabanları; en son uygulamalar ve kullanıcı erişimi. DR ortamında IP adreslerinin, DNS kayıtlarının ve VPN bağlantılarının nasıl değişeceği de plana dahil olmalı.

    Adım 4: Felaket Anı İçin Runbook

    • Felaketi kim, hangi kriterlere göre ilan eder?
    • Hangi sistem kim tarafından, hangi sırayla devreye alınır?
    • Çalışanlara, müşterilere ve tedarikçilere hangi kanalla, ne söylenir?
    • Ana veri merkezine dönüş (failback) nasıl ve ne zaman yapılır?

    Adım 5: Tatbikat

    Test edilmemiş bir DR planı, bir varsayımdan ibarettir. Yılda en az iki kez tatbikat yapın ve gerçekleşen RTO'yu ölçün. Modern replikasyon çözümleri, tatbikatları üretim ortamını etkilemeden ayrı bir test ağında yapmanıza izin verir. Her tatbikattan sonra planı güncelleyin.

    Fidye Yazılımı Senaryosunu Unutmayın

    Replikasyon, şifrelenmiş veriyi de birkaç saniye içinde DR tarafına kopyalar. Bu yüzden DR çözümünüz yalnızca "son durumu" değil, geçmişe dönük kurtarma noktalarını da saklamalıdır. Saldırının başladığı andan hemen önceki temiz bir noktaya dönebilmek için replikasyon günlüğünün (journal) saklama süresini ve değiştirilemez yedeklerinizi birlikte planlayın.

    Sık Yapılan Hatalar

    • Yedeği felaket kurtarma planı sanmak
    • DR kopyasını üretimle aynı binada veya aynı veri merkezinde tutmak
    • Ağ, DNS ve kullanıcı erişimi planını atlamak
    • Planı yazıp hiç test etmemek
    • Plan sahibinin ve güncelleme sıklığının belirsiz olması

    CloudRUX DRaaS

    CloudRUX DRaaS, Zerto tabanlı sürekli replikasyonla sanal sunucularınızı Türkiye'deki ayrı bir veri merkezine kopyalar ve tatbikatları üretimi etkilemeden yapmanızı sağlar. ISO 22301 iş sürekliliği yönetim sistemi sertifikamız kapsamında, sistemlerinizi katmanlara ayırıp her biri için doğru RPO/RTO hedefini birlikte belirleyebiliriz. Değerlendirme için info@cloudrux.com adresinden bize ulaşın.

    İşletmeniz İçin Doğru Çözümü Birlikte Bulalım

    KOBİ'lere özel butik mühendislik hizmeti. Ücretsiz ön analiz ile başlayın.

    Ücretsiz Danışmanlık Alın