Web Sitelerinde Yedek Geri Yükleme Testi: RPO, RTO ve Kurtarma Planı

Son Güncelleme: Eylül 2026

Bir web sitesi için yedek almak önemlidir; ancak asıl güvence, bu yedeğin gerektiğinde çalışır bir hizmete dönüştürülebilmesidir. Bu rehberde yedek geri yükleme testi, RPO ve RTO kavramlarını; hosting, VPS ve VDS ortamlarında uygulanabilecek bir kurtarma planıyla birlikte ele alacağız.

İçindekiler

• Yedek Geri Yükleme Testi Nedir?
• RPO ve RTO Nedir?
• Nelerin Yedeklenmesi Gerekir?
• Güvenli Test Ortamı Nasıl Hazırlanır?
• Adım Adım Geri Yükleme Testi
• Geri Yükleme Nasıl Doğrulanır?
• Hosting, VPS ve VDS Senaryoları
• Yaygın Hatalar ve Önlemler
• Test Takvimi ve Kurtarma Planı
• Sıkça Sorulan Sorular
• Sonuç

Yedek Geri Yükleme Testi Nedir?

Yedek geri yükleme testi, saklanan verilerin ayrı bir ortama geri alınması ve ortaya çıkan uygulamanın gerçekten kullanılabilir olduğunun kontrol edilmesidir. Yedekleme panelinde görünen başarılı durum bilgisi, dosyanın oluşturulduğunu gösterebilir; fakat veritabanının açıldığını, uygulamanın oturum başlatabildiğini veya doğru içerikleri sunduğunu tek başına kanıtlamaz. Düzenli kurtarma denemeleri, hem yedeğin bütünlüğünü hem de izlenen işlemlerin hedeflenen kurtarma sürelerine uygunluğunu sınamaya yarar.

Örneğin bir e-ticaret sitesinde ürün görselleri ve veritabanı ayrı zamanlarda yedeklenmiş olabilir. Her iki arşiv de açılabilir durumda olsa bile veritabanındaki yeni ürün kayıtlarının görselleri eksik kalabilir. Başka bir durumda dosyalar ve veritabanı sağlamdır, ancak uygulamanın ihtiyaç duyduğu yapılandırma veya şifreleme anahtarı yedeğe dahil edilmemiştir. Bu nedenle testin hedefi yalnızca verileri çıkarmak değil, işlevsel bir web hizmetini yeniden kurmaktır.

Yedek varlığı ile kurtarılabilirlik arasındaki fark

Yedek varlığı, belirli bir tarihe ait kopyanın bulunduğu anlamına gelir. Kurtarılabilirlik ise bu kopyadan, yetkili kişilerce kabul edilebilir sürede, doğru veriyle ve güvenli biçimde çalışan bir sistem kurulabilmesidir. İkincisi ancak uygulamalı testle değerlendirilebilir. Test sırasında karşılaşılan eksik erişim izinleri, unutulmuş bağımlılıklar veya yavaş veri aktarımı, gerçek bir kesintiden önce giderilebilir.

RPO ve RTO Nedir?

RPO (Recovery Point Objective; kurtarma noktası hedefi), bir olaydan sonra kabul edilebilir en fazla veri kaybı aralığını tanımlar. RTO (Recovery Time Objective; kurtarma süresi hedefi) ise kesinti ile hizmetin yeniden kullanılabilir hâle gelmesi arasında kabul edilebilir en uzun süreyi ifade eder. Bunlar yedekleme yazılımının otomatik olarak sağladığı garantiler değil, iş gereksinimlerine göre belirlenen ve testlerle ölçülen hedeflerdir.

Örneğin saat 14.00'te başlayan bir kesintide son kullanılabilir yedek 13.30'a aitse gerçekleşen veri kaybı aralığı 30 dakikadır. Site 16.00'da yeniden sipariş alabiliyorsa ölçülen kurtarma süresi iki saattir. Bu sonuçlar, sırasıyla bir saatlik RPO ve dört saatlik RTO hedefleri içinde kalır. Ancak veritabanının açılması tek başına RTO'nun karşılandığı anlamına gelmez; müşterilerin sipariş oluşturabildiği an esas alınmalıdır.

Yedeklerin 15 dakikada bir başlatılması, tek başına 15 dakikalık RPO güvencesi vermez. İşlemin tamamlanma süresi, başarısız görevler ve başka bir konuma kopyalama gecikmesi de son kullanılabilir kurtarma noktasını etkiler. Benzer biçimde daha sık yedek almak RTO'yu otomatik olarak düşürmez: Büyük arşivlerin indirilmesi, sunucunun hazırlanması ve uygulama testleri ayrıca zaman gerektirir.

Nelerin Yedeklenmesi Gerekir?

İyi bir geri yükleme testi, önce hizmetin hangi bileşenlerden oluştuğunu ortaya çıkarır. Bir web uygulaması yalnızca yayın dizinindeki dosyalardan ibaret olmayabilir. Veritabanı, kullanıcı yüklemeleri ve sunucu yapılandırması birbirinden farklı konumlarda tutulabilir. Kurtarma planında bileşenlerin sırası ve sorumlu kişiler de belirtilmelidir; yalnızca yedek medyasını tanımlayan bir liste operasyon sırasında yeterli olmayabilir.

• Uygulama dosyaları: Kaynak kod, temalar, eklentiler, statik varlıklar ve yayına alınmış sürüm bilgisi belirlenmelidir.
• Veritabanı: Uygulamaya ait tabloların yanı sıra gerekli kullanıcılar, izinler ve uyumlu veritabanı sürümü kaydedilmelidir.
• Kullanıcı verileri: Yüklenen belgeler, görseller ve uygulamanın ürettiği dosyalar ayrı bir depoda bulunuyorsa plana dahil edilmelidir.
• Yapılandırma: Web sunucusu ayarları, zamanlanmış görevler, alan adı yönlendirmeleri ve uygulama değişkenleri belgelenmelidir.
• Gizli bilgiler: Şifreleme anahtarları ve erişim bilgileri güvenli bir sır yönetimi sürecinde tutulmalı; test ortamına yalnızca gerekli olanlar kontrollü biçimde aktarılmalıdır.
• Harici bağımlılıklar: Ödeme, e-posta ve dosya depolama hizmetlerinin geri yükleme sonrasında nasıl doğrulanacağı önceden tanımlanmalıdır.

Her dosyanın aynı sıklıkla yedeklenmesi gerekmez. Nadir değişen uygulama kodu yeniden dağıtılabilirken, sipariş kayıtları çok daha kısa aralıklarla korunmayı gerektirebilir. Bununla birlikte yeniden dağıtılabilir görünen bir bileşenin sürümü bilinmiyorsa kurtarma uzar. Bu nedenle yedek kapsamı, sürüm kaydı ve kurulum yönergesi birlikte düşünülmelidir.

Güvenli Test Ortamı Nasıl Hazırlanır?

İlk kapsamlı denemeyi canlı sitenin üzerine geri yükleme yaparak gerçekleştirmeyin. Ayrı bir test alanı, farklı bir sanal sunucu veya erişimi kısıtlanmış geçici bir ortam hazırlayın. Ortamın işlemci, bellek, depolama ve yazılım sürümleri üretim ortamıyla karşılaştırılabilir olmalıdır; çok farklı bir test makinesinde ölçülen süre, gerçek olay anındaki RTO hakkında yanıltıcı olabilir.

• Erişimi sınırlandırın: Test sitesini yalnızca görevli ekibin erişebileceği biçimde yapılandırın ve arama motorlarına açık bir kopya oluşturmayın.
• Dış işlemleri durdurun: Gerçek müşterilere e-posta gönderimini, ödeme çekimini, webhook (web kancası) çağrılarını ve harici sistemlere veri aktarımını kapatın.
• Veriyi koruyun: Kişisel veriler içeren kopyaları yalnızca yetkili kişilere açın; uygulanabiliyorsa test için maskeleme kullanın.
• Ayrı kimlik bilgileri kullanın: Test ortamındaki hesapları ve erişim anahtarlarını canlı sistemden ayırın.
• Temizliği planlayın: Test tamamlandığında geçici kopyaların ne zaman ve kim tarafından kaldırılacağını belirleyin.

Bir kurtarma testinin amacı riskleri azaltmaktır; yanlışlıkla gerçek sipariş, e-posta veya bildirim üretmek değildir. Bu nedenle test başlamadan önce yapılacak kısa bir izolasyon kontrolü, teknik doğrulama kadar önemlidir. Uygulamanın dış hizmetleri test modunda çalıştırması mümkün değilse ilgili bağlantıları tamamen devre dışı bırakın ve bunu test raporunda belirtin.

Adım Adım Geri Yükleme Testi

Tekrarlanabilir bir süreç, yalnızca deneyimli bir yöneticinin hafızasına dayanmaz. Başlangıç zamanını kaydedin, kullanılacak kurtarma noktasını seçin ve her önemli adımın bitişini not edin. Böylece sonraki denemelerde yavaşlayan aşamaları karşılaştırabilirsiniz.

1. Hedefi yazın: Test edilen siteyi, seçilen yedeğin zamanını, RPO ve RTO hedeflerini ve başarı ölçütlerini kaydedin.
2. Yedeğe erişimi sınayın: Arşivin bulunduğu depoya yetkili hesapla ulaşın; gereken çözme anahtarlarının erişilebilir olduğunu doğrulayın.
3. Boş ortamı hazırlayın: Uyumlu çalışma zamanı, veritabanı ve depolama alanını kurun; canlı ortamdan ayrı bir ağ düzeni kullanın.
4. Verileri sırayla geri yükleyin: Veritabanı, uygulama dosyaları ve kullanıcı yüklemelerini uygulamanın bağımlılıklarına uygun sırada taşıyın.
5. Yapılandırmayı uyarlayın: Test adreslerini ve test veritabanı erişimini tanımlayın; dış dünyaya veri gönderen entegrasyonları kapalı tutun.
6. İşlevleri sınayın: Ana sayfayı açmakla yetinmeyin; giriş, arama, içerik görüntüleme ve iş açısından kritik işlemleri kontrol edin.
7. Süreleri kaydedin: Yedeğe erişim, altyapı hazırlığı, veri aktarımı ve uygulama doğrulaması için harcanan zamanı ayrı ayrı yazın.
8. Sonucu değerlendirip temizleyin: Hedefler karşılandı mı belirleyin, eksikleri görev olarak atayın ve geçici test kaynaklarını güvenli biçimde kaldırın.

İlk denemede geri yükleme başarısız olursa aynı arşivi tekrar tekrar denemeden önce hatanın hangi aşamada oluştuğunu belirleyin. Depolama erişimi, bozuk arşiv, uyumsuz sürüm ve eksik yapılandırma farklı çözümler gerektirir. Ayrıca yalnızca en yeni kopyayı değil, belirli aralıklarla daha eski bir kurtarma noktasını da deneyin. Bu yaklaşım, fark edilmesi gecikmiş veri bozulmalarında seçeneklerinizi görmenizi sağlar.

Geri Yükleme Nasıl Doğrulanır?

Arşivin açılması, testin ilk aşamasıdır. Kurtarmanın tamamlandığını söyleyebilmek için veri bütünlüğü ve uygulama işlevleri birlikte incelenmelidir. Kurtarılan bir kaynağın var olması yeterli değildir; özgün veriye erişilebildiği ve ilgili işlevlerin kullanılabildiği doğrulanmalıdır.

Bir içerik sitesi için başarı ölçütü, son yayınlanan yazıların ve görsellerin erişilebilir olması olabilir. Bir sipariş uygulamasında ise sepet, oturum ve sipariş geçmişi daha önemlidir. Test edilen işlemleri işletmenin önceliğine göre seçin; her kontrolün sonucunu başarılı, başarısız veya test edilmedi biçiminde açıkça kaydedin. Test edilmemiş bir entegrasyonu başarılı saymayın.

Hosting, VPS ve VDS Senaryoları

Paylaşımlı hosting üzerindeki kurumsal site

Bir kurumsal sitenin dosyaları ve veritabanı hosting hesabından alınan yedekte bulunabilir. Test için ayrı bir hesap veya izole bir alan oluşturulur; site dosyaları ile veritabanı geri alınır. Sonrasında iletişim formunun gerçek alıcılara mesaj göndermediği, görsellerin açıldığı ve yönetim paneline erişilebildiği kontrol edilir. Hesap yedeğinin hangi bileşenleri içerdiğini varsaymak yerine içerik listesiyle doğrulamak gerekir.

VPS veya VDS üzerindeki e-ticaret uygulaması

Sanal sunucuda işletim sistemi ayarları, uygulama ve veritabanı farklı katmanlarda bulunabilir. Yönetici önce temiz bir test sunucusu hazırlar; ardından veritabanını ve dosyaları geri yükleyip gerekli servisleri yapılandırır. Ödeme altyapısı test moduna alınmadan satın alma akışı denenmez. Bu senaryoda veri indirme süresi ile uygulama yapılandırma süresi ayrı kaydedilirse sonraki denemelerde hangi adımın darboğaz oluşturduğu daha net görülür.

Sunucunun tamamının kullanılamadığı durum

Yedekler yalnızca kaybedilen sunucunun kendi diskinde tutuluyorsa geri yükleme yapılamayabilir. Ayrı bir depolama konumundaki kopyadan yeni sunucu kurma denemesi, tek dosya geri yükleme testinden farklıdır: Ağ erişimi, uygulama bağımlılıkları ve operasyon sırası da sınanır. Kurumların kesinti planlarında alternatif ekipman veya alternatif konum üzerinden hizmeti yeniden kurma seçeneklerini değerlendirmesi, kurtarma hazırlığının bir parçasıdır.

Yaygın Hatalar ve Önlemler

• Yalnızca başarılı görev bildirimine güvenmek: Zamanlanmış yedeğin tamamlanması, içeriğin kullanılabilir olduğunu kanıtlamaz; uygulamalı geri yükleme yapın.
• Tek kopyayı aynı sunucuda tutmak: Disk arızası veya yetkisiz erişim, canlı veriyi ve yedeği birlikte etkileyebilir; bağımsız bir saklama konumu planlayın.
• Şifreleme anahtarını unutmak: Yedek sağlam olsa bile anahtar yoksa veriye erişilemeyebilir; güvenli ve yetkilendirilmiş anahtar erişimini sınayın.
• Veritabanını dosyalardan ayrı düşünmek: Farklı zamanlara ait bileşenler tutarsız içerik üretebilir; ilişkili kurtarma noktalarını belgeleyin.
• Test ortamını canlı hizmete bağlamak: Gerçek müşterilere bildirim gitmesini veya canlı verinin değişmesini önlemek için entegrasyonları izole edin.
• RTO'yu yalnızca aktarım süresi sanmak: Sunucu hazırlığı, izinler, doğrulama ve gerektiğinde trafik yönlendirme de toplam süreye dahildir.
• Hiç kayıt tutmamak: Ölçülmeyen bir deneme gelecekteki planı iyileştirmez; süreleri, hataları ve düzeltici görevleri saklayın.

Özellikle fidye yazılımı veya yetkisiz erişim şüphesinde, geri yüklenecek noktanın da etkilenmiş olabileceğini hesaba katın. Böyle bir olayda yalnızca en yeni kopyayı seçmek yerine olayın başlangıcını araştırın ve geri yüklenen sistemi yeniden hizmete açmadan önce güvenlik kontrollerini tamamlayın. Temiz bir kurtarma noktası seçimi, hızlı geri dönmek kadar önemlidir.

Test Takvimi ve Kurtarma Planı

Her işletmeye uyan tek bir test aralığı yoktur. Sık güncellenen ve kesintiden büyük ölçüde etkilenen bir uygulama, seyrek değişen tanıtım sitesinden daha kapsamlı ve daha sık deneme gerektirir. Kurulum değişiklikleri, önemli sürüm geçişleri ve yedekleme yöntemindeki değişiklikler de takvim dışı test gerekçesidir. Periyodik kurtarma denemeleri, kâğıt üzerindeki RPO ve RTO hedeflerinin uygulamada karşılanıp karşılanmadığını göstermelidir.

Örnek bir yaklaşım olarak kritik veriler için aylık örnek geri yükleme, üç ayda bir uygulama düzeyinde test ve yılda bir kez yeni ortama tam kurtarma tatbikatı planlanabilir. Bu aralıklar evrensel zorunluluk değildir; iş etkisi, veri değişim hızı ve test sonuçlarına göre ayarlanmalıdır. Sık test yapmak da tek başına yeterli değildir: Başarısız denemeler için sorumlu ve tamamlanma tarihi belirlenmelidir.

• Sorumluluk: Yedeğe kimin erişeceğini, altyapıyı kimin kuracağını ve işlevleri kimin onaylayacağını yazın.
• Öncelik: Önce hangi sitenin, veritabanının veya müşteri işlevinin geri getirileceğini sıralayın.
• Bağımlılıklar: Gerekli lisansları, hesapları, anahtarları ve kurulum yönergelerini güvenli biçimde kaydedin.
• İletişim: Kesintide müşterilere ve ekip üyelerine durum bilgisinin kim tarafından verileceğini belirleyin.
• Ölçüm: Her tatbikatta gerçekleşen veri kaybı aralığını ve hizmete dönüş süresini hedeflerle karşılaştırın.
• İyileştirme: Darboğazları gidermek için yapılacak işlemleri sonraki testten önce tamamlayın.

Planın erişilebilirliği de test edilmelidir. Gerekli yönergeler yalnızca arızalanan sunucuda duruyorsa ekip olay anında onlara ulaşamayabilir. Buna karşılık kurtarma belgeleri erişim kontrollü ayrı bir yerde tutulursa ekip, hangi adımı kimin üstleneceğini daha hızlı görebilir.

Sıkça Sorulan Sorular

Sonuç

Yedekleme, veri koruma sürecinin başlangıcıdır; güvenilir bir kurtarma planı ise kopyaların ayrı ortamda geri yüklenmesini, uygulamanın doğrulanmasını ve sonuçların RPO ile RTO hedeflerine göre ölçülmesini gerektirir. Dosyaları, veritabanını, yapılandırmayı ve dış bağımlılıkları birlikte ele alan düzenli testler, kesinti anındaki belirsizliği azaltır.

Web sitenizin ihtiyaçlarına uygun altyapıyı değerlendirirken Corelux Hosting ve Sanal Sunucu seçeneklerini inceleyebilirsiniz. Yedeklerin ayrı bir çözümle korunması için Yedekleme Hizmeti sayfasına göz atın; hangi hizmeti seçerseniz seçin, kurtarma sürecinizi kendi uygulamanız üzerinde düzenli olarak test etmeyi unutmayın.