KOBİ’ler İçin RPO/RTO ve Felaket Kurtarma Planı: Hosting Tarafında Gerçekçi Hedefler

KOBİ’ler İçin RPO/RTO Neden Bu Kadar Kritik?

KOBİ tarafında yaptığımız her toplantıda aynı tabloyu görüyoruz: Web sitesi, e‑ticaret altyapısı veya SaaS ürünü işin merkezinde ama RPO/RTO sorusunu sorduğumuzda odada sessizlik oluyor. Çoğu zaman yedek alınıyor mu sorusuna verilen yanıt net bile değil. Oysa birkaç saatlik kesinti; sipariş kaybı, CRM verisinin bozulması, şube ya da bayilerin sistemlere ulaşamaması gibi çok somut kayıplara dönüşüyor.

Bu yazıda KOBİ’ler için RPO (Recovery Point Objective) ve RTO (Recovery Time Objective) kavramlarını iş tarafından bakarak netleştireceğiz. Ardından bu hedefleri hosting tarafında gerçekten hangi mimari ve yedekleme stratejileriyle tutturabileceğinizi konuşacağız. Yani; paylaşımlı hosting, VPS, dedicated veya colocation kullanıyor olun, hangi senaryoda hangi RPO/RTO aralıkları mantıklı, hangisi bütçeyi gereksiz şişiriyor, bunları somut örneklerle ele alacağız.

DCHost ekibi olarak; e‑ticaret, kurumsal web siteleri ve SaaS projeleri için yüzlerce kez kesinti analizi, yedekleme mimarisi ve felaket kurtarma provası yaptık. Burada paylaşacağımız örnekler ve tavsiyeler, doğrudan bu gerçek deneyimlerin süzgecinden geçmiş durumda. Ayrıca daha önce detaylı anlattığımız RPO/RTO odaklı yedekleme stratejisi rehberi ve felaket kurtarma planı nasıl yazılır yazılarındaki prensipleri, bu kez doğrudan KOBİ perspektifinden, daha pratik bir dille özetleyeceğiz.

RPO ve RTO Nedir? KOBİ Düzeyinde Basit Tanımlar

Önce kavramları sadeleştirelim. Teknik terminolojiyle uğraşmadan, bir işletme yöneticisinin anlayacağı dille düşünelim.

RPO (Recovery Point Objective) nedir?

RPO; felaket yaşandığında en fazla ne kadarlık veri kaybına razı olduğunuzu anlatır. Bunu şu soruyla düşünebilirsiniz:

• ‘Sunucu tamamen çökerse, en fazla kaç dakika/saat önceki yedeğe dönmeyi kabul ediyorum?’

Örnekler:

• Günde bir yedek alan bir sistemde, teorik RPO yaklaşık 24 saattir.
• Her 15 dakikada bir veritabanı replikasyonu ya da log bazlı yedek varsa, RPO 15 dakika civarına iner.

Yani RPO; yedeklerin ne sıklıkla alındığı ve ne kadar güncel olduğu ile ilgilidir.

RTO (Recovery Time Objective) nedir?

RTO ise; felaket anından sistemin tekrar ayağa kalktığı ana kadar geçen kabul edilebilir maksimum süreyi ifade eder. Diğer bir deyişle:

• ‘Sistemim bozulduktan sonra, en geç ne kadar sürede tekrar çalışır hale gelmeli?’

Örnekler:

• Küçük bir blog için 4–8 saatlik RTO hala kabul edilebilir olabilir.
• Yoğun sipariş alan bir e‑ticaret sitesi için RTO çoğu zaman 15–60 dakika arasında olmalıdır.

RTO; sadece yedekle değil, kurtarma senaryosunun ne kadar otomatikleşmiş olduğu, altyapıda hazır bekleyen yedek sistemler bulunup bulunmadığı ve ekibin bu senaryoları ne kadar pratikleştirdiği ile doğrudan ilişkilidir.

Neden sadece teknik ekip değil, iş birimleri de RPO/RTO’ya dahil olmalı?

RPO/RTO teknik metrik gibi görünse de aslında tamamen iş kararıdır. Çünkü:

• 0 dakikalık veri kaybı (RPO=0) ve sıfıra yakın RTO, ciddi altyapı ve operasyon maliyeti gerektirir.
• İş birimleri bu maliyetleri, olası kayıplarla karşılaştırarak onaylamalıdır.

Bu yüzden KOBİ’lerde en sağlıklı yaklaşım; teknik ekip, iş birimleri ve yönetimin birlikte ‘bu sistem en fazla kaç dakika kapalı kalabilir, en fazla ne kadarlık veriyi kaybetmeyi göze alabiliriz’ sorularını netleştirmesidir.

KOBİ’lerde En Sık Görülen RPO/RTO Yanılgıları

Sahada en çok karşılaştığımız problemler, yanlış varsayımlardan kaynaklanıyor. Birkaç tipik senaryoya bakalım.

‘Yedek var, o zaman güvendeyiz’ yanılgısı

Birçok işletmede yedeklerin nerede tutulduğu, ne sıklıkla alındığı, geri yüklenip yüklenemediği net değil. Hatta bazen:

• Yedekler aynı fiziksel sunucuda tek diske tutuluyor.
• FTP ile manuel yedek alınıyor ama son dosya 3 ay öncesine ait.
• Veritabanı yedeği var ancak dosya sistemi (görseller, upload klasörü vb.) yedeklenmemiş.

Sonuç: Felaket anında RPO kağıt üzerinde 24 saat görünse de gerçekte 1 hafta veya daha fazla veri kaybı yaşanabiliyor. Bu da RPO/RTO hedeflerinin kağıt üzerinde kalmasına neden oluyor.

‘%99.9 uptime varsa her şey çözülmüştür’ algısı

Hosting SLA’larında gördüğünüz uptime değerleri; altyapının ne kadar sık erişilebilir olduğunu anlatır, veri kaybı ya da felaket kurtarma süresini garanti etmez. Operatör kaynaklı kısa kesintilerle; yanlış konfigürasyon, ransomware, kritik tablo silinmesi gibi senaryolar tamamen farklı başlıklardır.

Bu nedenle uptime oranı yüksek bir altyapı kullanıyor olmanız; RPO/RTO hedeflerinizi otomatik olarak sağladığınız anlamına gelmez. Ayrı bir felaket kurtarma planı ve test edilmiş yedekleme stratejisine ihtiyaç vardır.

‘Paylaşımlı hosting kullanıyoruz, RTO’muz 10 dakika olsun’ beklentisi

Gerçekçi olalım: Standart bir paylaşımlı hosting hesabında, manuel müdahale gereken bir felaket senaryosunda (örneğin sitenin hacklenmesi veya kullanıcı hatasıyla silinmesi) 10 dakikalık RTO çoğu zaman gerçekçi değildir. Çünkü:

• Önce problemin fark edilmesi gerekir (izleme yoksa bu bile saatler sürebilir).
• Son yedeğin bulunması ve geri yükleme süreci başlar.
• DNS, cache, CDN gibi katmanların etkisi eklenir.

Bu yüzden mimari ve hizmet modeline göre RPO/RTO hedeflerini yeniden kalibre etmek şarttır. DCHost tarafında KOBİ müşterilerimizle yaptığımız çalışmalarda, bu gerçekçilik seviyesini en baştan oturtmaya özellikle dikkat ediyoruz.

Hosting Tarafında RPO/RTO’yu Belirleyen Temel Bileşenler

RPO ve RTO hedeflerinizin sahada gerçekten tutturulup tutturulamayacağını belirleyen birkaç temel teknik unsur var.

1. Yedekleme sıklığı ve türü

RPO’yu doğrudan etkileyen başlık burası:

• Tam (full) yedek: Tüm sistemin tek seferde yedeği alınır. RPO yedek aralığı kadardır; günlük alınıyorsa RPO ~24 saattir.
• Artımlı (incremental) / fark (differential) yedek: Sadece değişen veriler alınır. Daha sık yedek almaya uygun olduğu için RPO’yu düşürmekte kullanılır.
• Anlık görüntü (snapshot): Özellikle VPS/dedicated ortamlarında disk seviyesinde snapshot’lar ile çok düşük RPO değerleri yakalanabilir.

Yedekleme stratejilerini, RPO hedeflerinizi gözeterek tasarlamanız gerekir. Bu konuyu detaylı anlattığımız yedekleme stratejisi planlama rehberine mutlaka göz atmanızı öneririz.

2. Yedeklerin konumu ve dayanıklılığı

Yedeklerin nerede tutulduğu, felaket türüne göre RTO ve hatta RPO’yu doğrudan etkiler:

• Aynı sunucuda tek disk: Donanım arızası veya ransomware durumunda hem sistem hem yedek kaybolabilir.
• Aynı veri merkezinde farklı disk / depolama: Donanım riskleri azalır ama veri merkezi bazlı felaketlere karşı hala savunmasız kalırsınız.
• Farklı veri merkezinde uzak yedek: Hem donanım hem lokasyon bazlı risklere karşı koruma sağlar, fakat geri yükleme süresini (RTO’yu) etkileyebilir.
• S3 uyumlu object storage + immutable (değiştirilemez) yedekler: Fidye yazılımlara karşı ekstra koruma sağlar. Ransomware’a dayanıklı 3‑2‑1 yedekleme stratejisi tam da bu noktada devreye giriyor.

3. Kurtarma sürecinin otomasyon seviyesi

RTO’yu belirleyen kritik faktörlerden biri de geri yükleme sürecinin ne kadar otomatik olduğudur:

• cPanel hesabını tek tıkla tam yedekten geri dönmek ile
• VPS üzerinde manuel dosya kopyalama, veritabanı import etme, konfigürasyon dosyalarını elle düzeltme

arasında ciddi RTO farkı vardır. Benzer şekilde, Terraform/Ansible gibi araçlarla altyapının kodla tekrar kurulabiliyor olması da RTO’yu çarpan etkisiyle düşürür.

4. DNS ve TTL stratejisi

Birçok KOBİ, RTO hesabında DNS yayılım süresini tamamen unutuyor. Oysa bir felaket senaryosunda:

• Origin sunucu değiştiğinde A veya AAAA kaydı güncellenir.
• Eski yüksek TTL değerleri yüzünden, kullanıcıların bir kısmı eski IP’ye gitmeye devam eder.

Bu yüzden felaket senaryosu içeren projelerde, DNS TTL değerlerini baştan stratejik olarak ayarlamak gerekir. Failover kurgusu olan kritik sistemlerde; düşük TTL, çoklu DNS sağlayıcı ve health check mekanizmaları da RTO’yu azaltmakta etkilidir.

5. İzleme, alarm ve olay yönetimi

RTO sadece kurtarma hızına değil, problemi fark etme süresine de bağlıdır. Eğer:

• Uptime, hata oranı, disk doluluk, yedek başarısızlıkları için alarm yoksa,
• Loglar merkezileştirilmemişse,
• Olay müdahale runbook’ları tanımlanmamışsa,

felaket etkisi gereğinden fazla büyür. Bu nedenle; merkezi izleme ve alarm mimarisi ile uptime izleme araçlarını RPO/RTO planınızın ayrılmaz parçası olarak düşünmeniz gerekir.

Farklı KOBİ Senaryoları İçin Gerçekçi RPO/RTO Hedefleri

Şimdi en sık karşılaştığımız üç tip KOBİ senaryosu üzerinden somut hedef aralıkları konuşalım. Buradaki değerler elbette her işletmeye göre uyarlanmalı; ancak iyi bir başlangıç noktası sunar.

1. Kurumsal web sitesi ve blog

Örnekler: Kurumsal tanıtım sitesi, haber/blog yayını yapan orta ölçekli işletmeler, lead toplama amaçlı siteler.

• Önerilen RPO: 12–24 saat
• Önerilen RTO: 2–8 saat

Bu tip siteler için tipik mimari:

• Güçlü bir paylaşımlı hosting ya da giriş seviye VPS
• Günlük tam yedek + kritik günlerde manuel ekstra yedek
• WordPress gibi CMS kullanılıyorsa veritabanı ve dosya yedeklerinin birlikte alınması

Önemli ayrıntı: İçerik üretimi çok sık ise (günde onlarca yazı/sayfa güncellemesi), RPO’yu 6 saate çekmek için daha sık veritabanı yedeği alınabilir. Özellikle WordPress siteler için WordPress yedekleme stratejileri yazımızdaki pratikleri uygulamak büyük fayda sağlar.

2. E‑ticaret siteleri

Örnekler: WooCommerce, Magento, OpenCart gibi platformlarla satış yapan KOBİ e‑ticaret siteleri.

• Önerilen RPO: 5–30 dakika (en azından sipariş ve ödeme verileri için)
• Önerilen RTO: 15–60 dakika (mesai saatleri içinde)

Neden bu kadar sıkı? Çünkü burada kaybettiğiniz şeyler:

• Tamamlanmış sipariş kayıtları,
• Sepetteki ürünler ve müşteri davranış verileri,
• Stok seviyeleri ve muhasebe entegrasyonu.

Bu senaryoda tipik yaklaşım:

• Veritabanı için daha sık (örneğin 5–15 dakikada bir) transaction log ya da replikasyon tabanlı yedekleme.
• Ürün görselleri ve medya için daha seyrek ama güvenli object storage yedeği.
• VPS veya dedicated üzerinde otomatikleştirilmiş geri yükleme betikleri.

Burada hem veritabanı tuning’i hem de yedekleme performansı kritik olduğu için, e‑ticaret müşterilerimizle çalışırken ayrı veritabanı sunucusu ve önbellek mimarisi gibi konuları da mutlaka gözden geçiriyoruz.

3. SaaS ve kritik iş uygulamaları

Örnekler: Müşterilere servis verilen SaaS paneller, CRM, rezervasyon sistemleri, bayi portalları, üretim veya lojistik takip uygulamaları.

• Önerilen RPO: 0–15 dakika aralığı (özellikle ödeme, işlem ve log kayıtları için)
• Önerilen RTO: 5–30 dakika (kritik iş süreçleri için)

Bu hedeflere yaklaşmak için genellikle şu mimariler kullanılır:

• VPS kümeleri veya dedicated + replikasyonlu veritabanı
• Gerçek zamanlı ya da yakın gerçek zamanlı veritabanı replikasyonu
• İkincil bölgede (farklı veri merkezi) hazır bekleyen yedek ortam (warm standby)

Böyle ortamlarda, basit dosya yedeğinin ötesine geçmek ve çok bölgeli mimari ve veritabanı replikasyonu gibi yöntemleri düşünmek gerekiyor. DCHost olarak bu tarz projelerde RPO/RTO hedeflerini en baştan masaya yatırıp, bütçeyle dengelenmiş gerçekçi bir mimari öneriyoruz.

Felaket Kurtarma Planı: KOBİ’ler İçin Adım Adım Yaklaşım

Tek başına yedek yeterli değil; yedeği nasıl, ne zaman, hangi sırayla devreye alacağınızı yazılı bir plana dökmediğiniz sürece, RPO/RTO hedefleri kağıt üzerinde kalır. Peki KOBİ düzeyinde uygulanabilir bir felaket kurtarma planı nasıl hazırlanmalı?

1. Varlık envanteri ve bağımlılıklar

Önce hangi sistemlerin var olduğunu ve birbirlerine nasıl bağlı olduklarını listeleyin:

• Web uygulamaları (site, panel, API vb.)
• Veritabanları
• Dosya depoları (upload klasörü, media, object storage)
• DNS, e‑posta, CDN, ödeme altyapıları gibi dış bağımlılıklar

Daha sonra her varlığın iş açısından önem derecesini iş birimleriyle birlikte belirleyin. Böylece felaket anında hangi sistemi önce ayağa kaldırmanız gerektiği netleşir.

2. Risk analizi ve senaryo seti

Her işletmenin risk profili farklıdır. Yine de çoğu KOBİ için tipik riskler şunlardır:

• Veritabanı tablosunun yanlışlıkla silinmesi
• Ransomware veya web shell ile sitenin şifrelenmesi
• Disk arızası veya dosya sistemi bozulması
• Veri merkezindeki ağ/elektrik kesintileri

Bu riskleri yazılı hale getirip, her biri için ‘tetikleyici olay’, ‘ilk tepki’, ‘kurtarma adımları’ ve ‘iletişim planı’ başlıklarını yazdığınızda, RTO hedefini tutturmak çok daha kolaylaşır. Bu kısmı detaylı ele aldığımız felaket kurtarma planı rehberine göz atabilirsiniz.

3. Sistem bazında RPO/RTO hedeflerini yazılı hale getirme

Her sistem için şu tabloyu doldurmanızı öneririz:

• Uygulama adı
• İş kritikliği (yüksek/orta/düşük)
• Hedef RPO (dakika/saat)
• Hedef RTO (dakika/saat)
• Yedekleme yöntemi (full, incremental, snapshot vb.)
• Kurtarma yöntemi (otomatik restore, script, manuel vb.)

Bu tabloyu teknik ekiple birlikte doldurup gözden geçirdiğinizde, gerçekçi olmayan talepler çok hızlı ortaya çıkar. Örneğin paylaşımlı hosting üzerinde çalışan bir blog için 5 dakikalık RPO yazıldıysa; bunun için gereken ek maliyetler masaya yatırılmalıdır.

4. Runbook ve sorumluluk matrisi

Felaket anında kim, neyi, ne kadar sürede yapacak? Bu soruya net cevap vermeden RTO hedefi koymak anlamlı değildir. Bu nedenle:

• Her senaryo için adım adım yapılacak işleri anlatan runbook’lar hazırlayın.
• Adımların yanına sorumlu kişi/ekipleri ve tahmini süreleri yazın.
• İletişim kanallarını (e‑posta, telefon zinciri, Slack/Teams vb.) belirleyin.

DCHost müşterilerinin önemli bir kısmıyla; özellikle e‑ticaret ve SaaS tarafında, bu runbook’ları birlikte yazarak hem teknik adımları sadeleştiriyoruz hem de iş ekiplerinin hangi durumda kiminle iletişime geçeceğini netleştiriyoruz.

Hosting Tarafında Uygulanabilir Teknik Stratejiler

Teoriden pratiğe geçelim. KOBİ ölçeğinde gerçekten uygulanabilir ve bütçeyi patlatmayan bazı stratejileri özetleyelim.

1. 3‑2‑1 yedekleme kuralını KOBİ seviyesine uyarlamak

3‑2‑1 kuralının özü şudur:

• Verinizin 3 kopyası olsun (1 üretim + 2 yedek)
• En az 2 farklı ortamda tutun (örneğin disk + object storage)
• En az 1 kopya farklı lokasyonda olsun (uzak veri merkezi)

Bunu KOBİ için pratik hale getirmenin yolu:

• Sunucu üzerinde yerel günlük yedek (hızlı geri dönüş için)
• Farklı bir veri merkezindeki object storage’ta şifreli haftalık yedek
• Kritik veritabanları için daha sık incremental veya binlog tabanlı yedekleme

Object storage ve uzak yedekleme tarafını detaylı anlattığımız otomatik S3 uyumlu yedekleme rehberi ve restic/borg ile uzak yedekleme yazılarından da faydalanabilirsiniz.

2. Immutable ve ransomware’a dayanıklı yedekler

Özellikle muhasebe, ERP, CRM gibi verilerin tutulduğu ortamlarda, fidye yazılım riski artık teorik değil, günlük hayatın parçası. Bu nedenle:

• Yedeklerin bir kısmını immutable (değiştirilemez) modda tutmak
• Yedek depolama alanını üretim sunucusundan erişilemez hale getirmek (air‑gap mantığı)

gibi adımlar RPO/RTO hedeflerinizin ‘ransomware senaryolarında’ da geçerli kalmasını sağlar. Detaylar için ransomware’a dayanıklı yedekleme stratejisi yazımızı inceleyebilirsiniz.

3. Felaket kurtarma provasını gerçekten yapmak

Plan ne kadar güzel olursa olsun, en az yılda bir kez test etmiyorsanız, RTO tahminlerinizin çoğu kağıt üzerindedir. KOBİ ölçeğinde pratik yaklaşım:

• Test ortamında en az yılda 1–2 kez tam kurtarma provası yapmak
• cPanel tam yedekten farklı bir sunucuya geri dönüş denemek
• VPS snapshot’larından veya veritabanı yedeklerinden ayağa kalkma sürelerini ölçmek

Bu konuda adım adım örnekleri hosting tarafında felaket kurtarma provası rehberimizde detaylı anlattık. Prova sonucunda gerçek RTO sürelerinizi ölçüp planınızı revize etmeniz, en kritik adımdır.

4. DNS ve çok bölgeli mimari ile RTO’yu kısaltmak

Kritik sistemler için, tek veri merkezine bağımlı kalmamak büyük avantaj sağlar. Örneğin:

• Birincil bölgede çalışan ana VPS kümeleri
• İkincil bölgede daha küçük ama senkronize bir warm standby ortam
• DNS health check ve otomatik failover kuralları

ile veri merkezi kapsamlı kesintilerde bile RTO’yu dakikalar seviyesinde tutabilirsiniz. Bu kurgunun prensiplerini multi‑region DNS ve CDN failover mimarisi yazımızda pratik örneklerle ele aldık.

5. İzleme, loglama ve alarm kültürünü yerleştirmek

RPO/RTO haritası tamamlanırken çoğu KOBİ’nin atladığı nokta; sorunu erken fark etmeyi sağlayacak görünürlük katmanı. En azından:

• HTTP 5xx hatalarına alarm
• Yedek başarısızlıklarına alarm
• Disk doluluk ve yüksek CPU/IO kullanımına alarm

kurulmadığı sürece, RTO hedefleri gerçekçi olmaz. Bu nedenle; DCHost üzerinde çalışan VPS ve dedicated müşterilerimize genellikle Prometheus/Grafana + Uptime Kuma gibi çözümlerle basit ama etkili bir izleme katmanı önermekteyiz.

RPO/RTO Hedeflerini Maliyetle Dengelemek

Her KOBİ’nin bütçesi sınırlı; bu yüzden ‘maksimum güvenlik, minimum kesinti’ isteğini daha rasyonel bir çerçeveye oturtmak gerekiyor.

Hedefler sıkılaştıkça maliyetin nasıl yükseldiğini görmek

Basitleştirilmiş bir örnek düşünelim:

• Senaryo A: RPO 24 saat, RTO 8 saat – Gündelik kurumsal site
• Senaryo B: RPO 1 saat, RTO 1 saat – Orta seviye e‑ticaret
• Senaryo C: RPO 5 dakika, RTO 10 dakika – Kritik SaaS

Senaryo A’dan C’ye geçerken:

• Daha sık yedekleme → daha fazla depolama ve işlem maliyeti
• İkincil ortam ve replikasyon → ek sunucu maliyeti
• Otomasyon, izleme, testler → daha fazla operasyonel zaman

Yani her ‘dakika sıkılaştırması’ bir maliyet çarpanı getiriyor. Bu yüzden önce iş kaybının parasal karşılığını hesaplamadan, RPO/RTO hedeflerini sıkılaştırmak sağlıklı değil.

İş etkisini parasal olarak kabaca hesaplamak

KOBİ’ler için basit bir çerçeve işe yarıyor:

• Saatlik ortalama ciro veya müşteri işlemi değerini çıkarın.
• İtibar, müşteri memnuniyeti, sözleşme cezaları gibi kalemler için bir katsayı ekleyin.
• Diyelim ki 1 saatlik kesintinin işletmenize ortalama X TL maliyeti var.

Ardından altyapınızı bir üst seviyeye taşımak için gereken ek maliyeti hesaplayın. Eğer fazladan yatırdığınız her 1 TL, size olası zarar tarafında 2–3 TL tasarruf olarak dönüyorsa, RPO/RTO’yu sıkılaştırmak rasyonel bir karardır.

Planı Test Etmek ve Sürekli Güncel Tutmak

Felaket kurtarma ve RPO/RTO, ‘bir kere yazıp rafa kaldırdığımız’ dokümanlar değildir. Özellikle KOBİ’lerde;

• Yeni modüller devreye girer,
• Yeni entegrasyonlar eklenir,
• Ekibin bileşimi ve yetkinlikleri değişir.

Bu nedenle yıllar önce yazılmış ve hiç güncellenmemiş bir DR planının, gerçek bir olayda işe yaramasını beklemek hayalcilik olur.

Yıllık minimum bakım takvimi

KOBİ seviyesinde uygulanabilir, basit bir rutin önerebiliriz:

• Yılda en az 1 kez tam DR senaryosu provası (test ortamında)
• Her 6 ayda bir RPO/RTO tablolarının gözden geçirilmesi
• Yeni uygulamalar devreye girdikçe, envanter ve runbook’lara eklenmesi

Bu süreci; küçük işletmeler için yıllık bakım takvimi ile entegre etmek de pratik bir yöntemdir.

Gerçek olaylardan öğrenmek

Ne kadar prova yaparsak yapalım, gerçek bir kesinti veya veri kaybı olayı yaşandığında mutlaka beklenmedik detaylar ortaya çıkar. Her böyle olay sonrası:

• Olay sonrası inceleme (post‑mortem) yapın.
• Hangi adımlar işe yaradı, hangileri tıkandı, bunları not edin.
• RPO/RTO hedeflerini ve runbook’ları bu öğrenimlerle güncelleyin.

DCHost olarak ciddi her vaka sonrasında müşterilerimizle birlikte teknik ve operasyonel dersleri çıkarıp, ilgili dokümanları güncellemek için zaman ayırıyoruz. Uzun vadede en çok faydayı sağlayan adımın bu olduğunu rahatlıkla söyleyebiliriz.

Sonuç: KOBİ’ler İçin Uygulanabilir Bir Yol Haritası

Özetleyelim:

• RPO ve RTO teknik kavramlar gibi görünse de aslında iş kararlarıdır; yönetim ve iş birimleri mutlaka sürece dahil olmalıdır.
• Paylaşımlı hosting, VPS, dedicated veya colocation hangi modeli kullanıyor olursanız olun; her biri için gerçekçi RPO/RTO sınırları vardır.
• 3‑2‑1 kuralı, immutable yedekler, uzak veri merkezi, DNS/TTL stratejisi ve izleme; felaket kurtarma mimarisinin temel taşlarıdır.
• Planın kağıt üzerinde kalmaması için yılda en az bir kez felaket kurtarma provası yapılmalı ve sonuçlara göre güncellenmelidir.

Eğer siz de işletmeniz için ‘Bu sistem en fazla kaç dakika kapalı kalabilir, en fazla ne kadar veri kaybına katlanabiliriz?’ sorularını netleştirmek istiyorsanız, DCHost ekibi olarak RPO/RTO hedeflerinizi birlikte masaya yatırmaktan memnuniyet duyarız. Mevcut altyapınızı, yedekleme düzeninizi ve iş önceliklerinizi inceleyip; bütçenize uygun, gerçekçi ve sürdürülebilir bir felaket kurtarma planını beraber tasarlayabiliriz.

İlk adım olarak, dahili ekibinizle kısa bir oturum yapıp bu yazıda bahsettiğimiz tabloyu doldurun; ardından bizimle paylaştığınızda, DCHost altyapısı üzerinde hangi hosting, yedekleme ve DR mimarisinin sizin için doğru olduğunu somut önerilerle konuşabiliriz.