🧭 RPO / RTO 🗓 Saklama Süresi 🧪 Test Edilmiş Geri Dönüş 📋 Kontrol Listesi 🧭 RPO / RTO 🗓 Saklama Süresi 🧪 Test Edilmiş Geri Dönüş 📋 Kontrol Listesi
Felaket Kurtarma

Felaket Kurtarma Planınızın Temeli: Yedekleme
RPO · RTO · Saklama Süresi · Test Edilmiş Geri Dönüş

Felaket kurtarma planı, kötü gün geldiğinde ne kadar veri kaybedeceğinizi ve ne kadar sürede ayağa kalkacağınızı önceden belirlemektir. Bu iki sayı (RPO ve RTO) doğrudan yedekleme düzeninizden çıkar. Aşağıda ikisini nasıl belirleyeceğinizi ve yedeklemenin bu planın neresinde durduğunu anlatıyoruz.

Kredi kartı gerekmez · 14 gün ücretsiz deneme

Temel Kavramlar

RPO ve RTO Nedir?

Bu iki sayıyı belirlemeden yedekleme sıklığınıza doğru karar veremezsiniz.

RPO — Kabul Edilen Veri Kaybı

"En fazla kaç saatlik veriyi kaybedebilirim?" Yedekleme sıklığınızı doğrudan bu belirler. Saatlik yedek = 1 saat RPO.

RTO — Ayağa Kalkma Süresi

"Sistem ne kadar sürede geri gelmeli?" Geri yükleme hızınızı ve hazırlık seviyenizi belirler.

🗓

Saklama Süresi

Ne kadar geriye dönebilmelisiniz? Sorunu geç fark etme ihtimali bu süreyi belirler.

🧪

Test Sıklığı

Plan ne sıklıkla denenecek? Test edilmemiş plan, plan değil temennidir.

Uygulama

RPO Hedefine Göre Yedekleme Sıklığı

Aşağıdaki eşleştirme çoğu işletme için pratik bir başlangıç noktasıdır.

📄

Tanıtım Sitesi

İçerik nadiren değişir. Haftalık ya da günlük yedek yeterlidir; RPO birkaç gün olabilir.

📰

Blog / Haber

Günlük yedek makuldür; en fazla bir günlük içerik kaybedersiniz.

🛒

E-ticaret

Günlük yedek pahalıya patlar. Saatlik yedekle RPO bir saate iner.

🏪

Yoğun Mağaza

Saatlikten daha sık yedekleme gerekebilir; sipariş yoğunluğu belirleyicidir.

🗄

Bileşen Ayrımı

Dosyalar nadiren, veritabanı sürekli değişir. İkisine ayrı sıklık vermek hem korur hem ucuzlatır.

Artımlı ile Ucuzlatın

Artımlı yedek sık yedeklemeyi ekonomik hâle getirir. Ayrıntı.

Kontrol Listesi

Planınızda Bunlar Yazılı mı?

Kriz anında hatırlanacak değil, okunacak bir belgeye ihtiyacınız var.

1️⃣

Kritik Sistemler

Hangi sistemler önce ayağa kalkacak? Öncelik sırası yazılı mı?

2️⃣

RPO / RTO Hedefleri

Her sistem için kabul edilen kayıp ve süre belirlenmiş mi?

3️⃣

Yedeklerin Konumu

Yedek nerede? Kim erişebiliyor? Şifreleme anahtarı nerede saklanıyor?

4️⃣

Geri Yükleme Adımları

Adımlar yazılı mı, yoksa tek bir kişinin aklında mı?

5️⃣

Haberleşme

Kim, ne zaman, kimi haberdar edecek? Müşteri bilgilendirmesi kimde?

6️⃣

Test Takvimi

Plan en son ne zaman denendi? Sonuçları kayıt altına alındı mı?

Yedekleme planın temelidir ama tek başına plan değildir

Yedek olmadan kurtarma mümkün değildir; ancak yedeğin varlığı tek başına yeterli değildir. Kriz anında kaybedilen zamanın büyük kısmı "yedek var mıydı?" sorusuna değil, "kim, nereden, nasıl geri yükleyecek?" sorusuna gider.

Bu yüzden yedekleme kurarken şu üçünü de hazırlayın: geri yükleme adımlarının yazılı olması, yetkili kişilerin önceden tanımlanmış olması ve şifreleme anahtarınızın sunucudan bağımsız bir yerde saklanması. Anahtar yalnızca kaybedilen sunucudaysa şifreli yedeğiniz de kaybolmuş demektir.

Merak Edilenler

Felaket Kurtarma ve RPO/RTO Hakkında Sıkça Sorulan Sorular

RPO (Recovery Point Objective), kabul edebileceğiniz azami veri kaybı süresidir: "en fazla kaç saatlik veriyi kaybedebilirim?" sorusunun cevabıdır ve doğrudan yedekleme sıklığınızı belirler. RTO (Recovery Time Objective) ise sistemin ne kadar sürede tekrar ayağa kalkması gerektiğidir. Saatlik yedek alan bir sitenin RPO değeri bir saattir; günlük yedek alanın RPO değeri 24 saattir.
RPO hedefinizden geriye doğru gidin. Bir günlük sipariş kaybını göze alamıyorsanız günlük yedek yetersizdir. Pratik yaklaşım şudur: tanıtım siteleri için haftalık veya günlük, blog ve haber siteleri için günlük, e-ticaret için saatlik, yoğun mağazalar için saatlikten daha sık. Dosyalar nadiren değiştiği için veritabanına dosyalardan daha sık plan vermek hem korumayı artırır hem maliyeti düşürür.
KVKK tek bir süre belirlemez; ilkesi kişisel verinin işleme amacı için gerekli olan süreden fazla saklanmamasıdır. Süreyi veri sorumlusu olarak siz, saklama ve imha politikanızda belirlersiniz. Yedekleme tarafındaki karşılığı, her yedek türü için kaç kopya tutulacağını tanımlamak ve fazlasının otomatik silinmesini sağlamaktır.
En azından şunları: hangi sistemlerin kritik olduğu ve öncelik sırası, her sistem için RPO ve RTO hedefleri, yedeklerin nerede durduğu ve kimin erişebildiği, geri yükleme adımlarının yazılı olması, kimin ne zaman haberdar edileceği ve planın ne sıklıkta test edileceği. Test edilmemiş bir plan, plan değil temennidir.
Hayır. İş sürekliliği, olay sırasında işin nasıl devam edeceğini kapsayan geniş bir çerçevedir; felaket kurtarma ise teknik sistemlerin nasıl geri getirileceğine odaklanır. Yedekleme, felaket kurtarmanın temel yapı taşıdır ama tek başına bir plan değildir.
Hayır. Yedek olmadan kurtarma mümkün değildir, ama yedeğin varlığı tek başına yeterli de değildir. Geri yükleme adımlarının yazılı olması, erişim yetkilerinin önceden tanımlanmış olması, şifreleme anahtarının ulaşılabilir bir yerde saklanması ve planın düzenli test edilmesi gerekir.
Devamı

İlgili Çözümler

Aradığınızı bulamadıysanız tüm yedekleme çözümleri sayfasında platform ve senaryo bazlı sayfaların tam listesi var; tutarlar için yedekleme fiyatları sayfasına bakabilirsiniz.

Yedek Doğrulama

Yedeğinizin gerçekten geri yüklenebildiğini bilin.

🔒

Silinemez Yedek (WORM)

Fidye yazılımının silemediği değiştirilemez kopya.

🔏

KVKK Teknik Tedbirler

Şifreleme, erişim denetimi, saklama süresi, kayıtlar.

🔐

Şifreli Yedekleme

AES-256, kendi anahtarınızla (BYOK).

RPO Hedefinize Uygun Bir Plan Kurun

Bileşen bazında sıklık, saklama sayısı ve doğrulama — hepsi tek panelde. 14 gün ücretsiz.

Ücretsiz Hesap Oluştur

3-2-1 yedekleme kuralını okuyun →