Yedekten geri yükleme süresi: RPO ve RTO rehberi

Yedekten geri yükleme süresi, VDS/VPS ve dedicated sunucularda sadece “yedek var mı?” sorusundan ibaret değildir. Asıl kritik olan, veri kaybını ne kadar tolere edebildiğiniz ( RPO ) ve sisteminizi ne kadar hızlı ayağa kaldırmanız gerektiği ( RTO )dir. Bu iki ölçütü doğru tanımladığınızda; yedek (backup) türü, yedekleme sıklığı, saklama süresi ve geri yükleme prosedürü netleşir. Bu rehberde RPO/RTO kavramlarını pratik ölçümlerle ele alacak, farklı senaryolar için hedef örnekleri verecek ve “yedekten geri yükleme süresi”ni gerçekçi planlamayı göstereceksiniz.

RPO (Recovery Point Objective): Veri kaybı hedefi

RPO, arızanın gerçekleştiği andan geriye doğru “maksimum kaç veri kaybını kabul edebileceğinizi” gösteren hedeftir. Saat birimiyle konuşmak yaygındır ama bazı sistemlerde dakika ya da saniye daha doğru olur.

RPO nasıl ölçülür?

RPO’yu iki farklı yolla düşünebilirsiniz: - Yedekleme sıklığına göre: Örneğin her 15 dakikada bir yedek alıyorsanız RPO hedefiniz pratikte 15 dakikadır. - Uygulama/iş seviyesiyle: Sadece veritabanını değil uygulama işlemlerini de düşünürsünüz. Örneğin ödeme kaydı gibi “kritik transaction”lar için RPO 5 dakika bile yetersiz olabilir.

Önemli nokta: RPO, “yedek ne kadar hızlı alınır” değil, arıza anına göre “ne kadar eski duruma döneceğinizi” söyler.

RPO’yu hangi faktörler etkiler?

• Yedekleme aralığı: 1 saat vs 15 dakika farkı doğrudan RPO’yu değiştirir.
• Log ve incremental stratejisi: Tam yedek + değişiklik (incremental) + log (transaction log) zinciri RPO’yu düşürür.
• İş yükü ve performans: Çok sık yedek almak, yoğun disk/IO kullanan veritabanlarında performansı etkileyebilir. Bu etkiyi planlamazsanız yedek başarısızlıkları artar.

RTO (Recovery Time Objective): Geri dönüş süresi hedefi

RTO, arıza sonrası hizmeti (service) geri yükleyip kullanıcılara tekrar sunana kadar geçmesi gereken maksimum süredir. RTO; yedekten geri yükleme (restore), konfigürasyon adımları, uygulamanın ayağa kalkması ve gerekiyorsa yeni sunucu hazırlığı gibi tüm süreçlerin toplamını içerir.

RTO’nun kapsamı: Sadece “restore” değil

RTO’yu hesaplarken şu adımları aynı süreç gibi düşünün: - Dosya/veri restore (backup restore) - Veritabanı ayağa kaldırma (database recovery) - Uygulama ayarlarının tekrar kurulması (environment/config) - Ağ katmanı / domain / SSL (gerekiyorsa) - İzleme ve doğrulama (monitoring + smoke test)

Örneğin “restore 10 dakika sürüyor” demek tek başına yeterli değildir. Eğer uygulamayı ayağa kaldırmak 25 dakika sürüyorsa gerçek RTO 35 dakikadır.

RTO nasıl ölçülür?

RTO hedefi koymadan önce en az bir kez gerçek geri yükleme testi yapın. En iyi yaklaşım: - Aynı yedek setini alın - Staging benzeri bir ortamda geri yükleyin - Otomasyon varsa süreyi ölçün (ortalama + en kötü durum) - Restore bitse bile “hizmet çalışıyor mu?” doğrulamasını (health check) dahil edin

Bu sayede “teorik süre” yerine ölçülmüş RTO elde edersiniz.

RPO ve RTO birlikte nasıl planlanır?

RPO ve RTO birbirini destekleyen iki farklı boyuttur: - RPO düşükse: daha sık yedek + log zinciri gibi yöntemler gerekir. - RTO düşükse: geri yükleme otomasyonu, hazır imajlar ve ölçeklenebilir restore planı gerekir.

Aşağıdaki tablo, tipik bir karar çerçevesi sağlar:

Bu hedefler sabit bir “tek doğru” değildir; sitenizin iş etkisine göre belirlenir. NetKıyas’ta en sık görülen hata, RPO hedefi yokken “RTO’yu düşük tutalım” demektir. RPO yüksek kaldığında, restore sonrası kullanıcıya eski veriyle hizmet sunulur; bu da iş kaybını büyütür.

Yedekten geri yükleme süresini pratikte düşüren yöntemler

RTO’yu iyileştirmenin yolu genellikle yedek “dosyalarını” küçültmek ve geri yükleme adımlarını standartlaştırmaktır. Aşağıdaki başlıklar, VDS/VPS ve dedicated sunucularda doğrudan etkisi görülen uygulamalardır.

1) Yedek türü: Tam (full) vs incremental vs log

• Tam yedek (full): Restore için basit olabilir ama sık yapıldığında süre ve disk/transfer maliyeti artar.
• Artımlı yedek (incremental): RPO’yu düşürür; fakat restore zinciri uzarsa RTO yükseltebilir.
• Log yedekleme: Veritabanında transaction log saklanıyorsa, RPO ciddi biçimde düşer. Restore karmaşıklığı artar; bu yüzden otomasyon gerekir.

En sağlıklı yaklaşım, RPO/RTO hedeflerinize göre bir kombinasyon seçip “restor testinde” gerçek süreyi ölçmektir.

2) Yedek saklama konumu: Aynı sunucu mu, ayrı lokasyon mu?

Yedek dosyasını aynı fiziksel sunucu üzerinde tutmak; arıza türüne göre RTO’yu düşürür ama riskleri artırır. Örneğin disk arızasında hem üretim hem yedek aynı cihazda kaybolabilir.

Net planlama için iki katman düşünün: - Hızlı geri yükleme için: aynı veri merkezinde/ayrı depoda erişilebilir yedek - Afet senaryosu için: farklı lokasyonda tutulan yedek (offsite)

3) Geri yükleme prosedürünü dokümante edin ve otomatikleştirin

RTO’yu en çok yükselten şey “restore komutunu hatırlamamak” veya farklı kişilerin farklı yöntemler kullanmasıdır. Bu nedenle restore adımlarını bir prosedür haline getirin.

Örnek kontrol listesi: - Restore edilecek yedek setini adlandırma standardı (tarih/epoch + servis adı) - Veritabanı için: stop-start sırası - Konfigürasyonlar: .env, config dosyaları ve secret yönetimi - Domain/DNS/SSL: değişiklik gerekecekse adım listesi - Health check: örnek endpoint çağrısı veya basit kullanıcı akışı

4) Restore testini “sadece bir kez” değil düzenli yapın

Yedek alındı diye güvenmek yanıltıcıdır. Dosya bozuk olabilir, şifre yanlış olabilir, incremental zincir kopmuş olabilir. Restore testinde beklenen fayda: - Gerçek restore süresini ölçmek - Başarı/başarısızlık oranını görmek - Güncelleme sonrası geri yükleme uyumsuzluklarını tespit etmek

5) Konfigürasyonun geri yüklenmesi: Infrastructure as Code mantığı

Uygulama ve altyapı ayarlarını manuel kuruyorsanız RTO uzar. Bu yüzden: - Uygulama konfigürasyonlarını (config) sürümleyin - Otomasyonla sunucuyu ayağa kaldırın - En azından restore sonrası “hangi dosya nerede, hangi ayarlar hangi değerle” bilgisini standardize edin

RPO ve RTO hedeflerini net sayılara çevirme yöntemi

Hedef koymak için şu pratik adımları uygulayın:

Adım 1: Hizmet kapsamını tanımlayın

“Geri geldi” ne demek? - Web erişilebilir mi? - API endpoint’leri çalışıyor mu? - Veritabanı tutarlı mı? - Ödeme gibi kritik modüller doğrulandı mı?

Bu tanım RTO’nun ölçümünü belirler.

Adım 2: Veri kaybını iş etkisine göre sınıflandırın

• Bir kullanıcının 10 dakika önce oluşturduğu kayıt geri gelmeyebilir ama sipariş geri gelmezse sorun büyür.
• Bu sınıflandırma RPO’yu düşürmek için neden sunar.

Adım 3: Geri yükleme süresini ölçün

Bir kez restore testi yapıp “genelde 20 dakika” demeyin. En az şunları raporlayın: - Normal restore süresi (ortalama) - En kötü durum restore süresi (yavaş disk, ağ darboğazı) - İnsan müdahalesi gereken adımların dakika cinsinden toplamı

Adım 4: Yedek stratejisini ve saklama planını hedefe göre revize edin

RPO hedefi tutmuyor (ör. 30 dk isteniyor ama yedek 2 saatte bir alınıyor) ise: - yedek sıklığını artırın - incremental/log stratejisini devreye alın - başarısız yedekleri tespit ve alarm sistemini kurun

RTO hedefi tutmuyor ise: - restore zincirini sadeleştirin - otomasyon ekleyin - yedeklerin bulunduğu depoyu iyileştirin - en sık kullanılan restore senaryolarını önceliklendirin

Sık yapılan hatalar ve net düzeltmeler

Aşağıdaki hatalar, yedekten geri yükleme süresini beklenenden çok daha kötü hale getirir.

Hata 1: RPO/RTO hedefi olmadan sadece “yedek var” kontrolü

Düzeltme: - Hedef RPO: “Arıza anına göre en fazla X dakika eski veri” - Hedef RTO: “restore + ayağa kalkma + health check toplamı en fazla Y dakika/saat”

Hata 2: Yedek alınıyor ama restore hiç denenmiyor

Düzeltme: - Restore testini takvime bağlayın (ör. her ay) - Testte “şu adım başarısız olursa ne yapacağım” aksiyonunu yazın

Hata 3: Incremental yedek çok ama restore yavaş

Düzeltme: - Belirli aralıklarla “restore’ı hızlandıracak” ara snapshot/temel yedek planı kurgulayın - Restore zincirini test edin, uzun zincirde performans hedefini revize edin

Hata 4: Aynı sunucu kaynağında hem üretim hem yedek

Düzeltme: - Disk/VM ölümü senaryosunda yedek erişilebilir olmalı - Offsite katman ekleyin

Sonuç: Aksiyon planı (hemen uygulanabilir)

26.08.2026 itibarıyla pratik yaklaşım şu: Önce hizmetiniz için RPO ve RTO hedefini yazılı hale getirin; ardından elinizdeki mevcut yedek stratejisiyle en az bir restore testi yapın ve gerçek süreleri ölçün. RPO yüksek çıkarsa yedekleme sıklığını ve log/incremental planını güncelleyin; RTO yüksek çıkarsa restore adımlarını otomatikleştirin ve yedek saklama/erişim modelini iyileştirin. Eğer şu an hedef ve test yoksa, ilk aksiyon olarak “restore testi + hedef yazımı” planını bugün başlatın; NetKıyas’ta doğru barındırma/altyapı seçimini de bu ölçümlere göre yaparsınız.