Sanal sunucu için doğru yedekleme yöntemi, yalnızca ne kadar veri saklandığına göre seçilmez. Önce kabul edilebilir veri kaybını ve hizmetin ne kadar sürede geri dönmesi gerektiğini belirleyin. Anlık görüntü hızlı geri dönüş sağlayabilir; ancak tek başına bağımsız bir yedek değildir. Kritik veriler için farklı bir depolama alanına kopya ve düzenli geri yükleme testi gerekir.
İki temel hedefi birbirinden ayırmak gerekir. RPO, son yedekten sonra oluşan ve kaybedilmesi kabul edilen veri aralığıdır. Örneğin RPO bir saat ise, son bir saat içindeki siparişlerin kaybolması işletme açısından kabul edilebilir mi sorusuna yanıt verilmiş olur. RTO ise hizmetin yeniden çalışır duruma gelmesi için tanınan süredir. Bu süre yalnızca dosyaların kopyalanmasını değil, uygulamanın açılması, veritabanının tutarlı olması ve alan adının doğru hedefe yönelmesi gibi işlemleri de kapsayabilir.
Veri kaybı bir saatten fazla sorun yaratıyorsa günlük yedekleme yeterli olmayabilir; daha sık çalışan bir yedekleme düzeni veya uygulama seviyesinde çoğaltma düşünülmelidir. Buna karşılık birkaç saatlik kayıp kabul edilebiliyor ve asıl öncelik hızlı geri dönüşse, düzenli sanal makine yedekleri ile kısa süreli anlık görüntüler birlikte kullanılabilir. Buradaki seçim doğrudan iş yüküne bağlıdır; tüm siteler için aynı sıklık veya yöntem uygun değildir.
Anlık görüntü, sanal sunucunun belirli bir andaki disk durumunu koruyan, genellikle aynı sanallaştırma altyapısında tutulan bir geri dönüş noktasıdır. Bir yapılandırma değişikliğinden önce kısa süreli güvenlik ağı olarak işe yarar. Örneğin işletim sistemi güncellemesinden sonra uygulama açılmazsa önceki duruma daha hızlı dönmeyi sağlayabilir. Ancak anlık görüntünün saklama süresi, depolama alanı ve geri yükleme davranışı sağlayıcının altyapısına göre değişir.
Bağımsız yedek ise verilerin ayrı bir depolama alanına veya farklı bir altyapıya kopyalanmasıdır. Kaynak sunucunun diski, sanal makinesi veya bulunduğu fiziksel sistem kullanılamaz hale geldiğinde bu ayrım önem kazanır. Aynı altyapıdaki anlık görüntü, altyapı arızasına karşı ayrı bir kurtarma ortamı sunmayabilir. Bu nedenle anlık görüntüyü uzun süreli arşiv, tek kurtarma yöntemi veya fidye yazılımına karşı yeterli koruma gibi değerlendirmemek gerekir.
Bir sanal sunucu yalnızca değişimi az olan bir tanıtım sitesi barındırıyorsa, günlük veya daha seyrek bağımsız yedek ve değişikliklerden önce alınan geçici anlık görüntü yeterli olabilir. Yedek geri yüklenemediğinde yeni bir sunucuya alınabilmesi için dosyaların, veritabanının ve gerekli yapılandırma bilgilerinin birlikte korunması gerekir. Sadece web dosyalarını saklamak, veritabanı içeren bir uygulamayı eksiksiz kurtarmaya yetmez.
Veritabanına sürekli kayıt alan bir mağaza veya rezervasyon uygulamasında karar farklılaşır. Kayıtlar sık değişiyor ve birkaç saatlik kayıp kabul edilmiyorsa, sanal sunucunun periyodik imaj yedeğine ek olarak veritabanı için uygulamayla uyumlu dışa aktarma ya da günlükleme mekanizması gerekir. Yedekleme sırasında veritabanının tutarlı bir kopyasının alındığı doğrulanamıyorsa, yalnızca disk kopyasına güvenmek risklidir. İşlem hacmi büyüdükçe yedek sıklığı kadar yedekleme süresinin üretim trafiğini etkileyip etkilemediği de izlenmelidir.
Diyelim ki bir e-ticaret uygulaması günde birkaç kez sipariş alıyor ve işletme en fazla iki saatlik veri kaybını kabul ediyor; ancak hizmetin dört saat içinde yeniden açılması gerekiyor. Bu durumda yalnızca haftalık anlık görüntü uygun değildir. Daha sık alınan veritabanı kopyaları, ayrı depolanan sunucu yedeği ve geri yükleme sırasında alan adı ile uygulama ayarlarının nasıl taşınacağını açıklayan bir prosedür gerekir. Buna karşılık düşük değişim oranlı bir portföy sitesi için aynı yoğunlukta yedekleme, gereksiz depolama ve işlem maliyeti yaratabilir.
Önce sağlayıcının panelinde veya sunucu yönetim aracında yedeklerin saklama süresini, depolama konumunu, otomatik çalışma zamanını ve geri yükleme kapsamını bulun. Yalnızca “başarılı” durumunu görmek yeterli değildir; yedek içeriğinde uygulama dosyalarının, veritabanı dökümünün ve gerekli yapılandırma bilgilerinin bulunduğunu kontrol edin. Sağlayıcıya bağlı özelliklerde, yeni bir sunucuya geri yükleme veya dosya düzeyinde kurtarma seçeneklerinin ayrıca sunulup sunulmadığını doğrulayın.
İlk gerçek sınama üretim sunucusunun üzerine yapılmamalıdır. Mümkünse ayrı bir test sunucusuna veya izole bir çalışma alanına geri yükleme başlatın. Uygulamanın açıldığını, örnek bir veritabanı kaydının okunabildiğini, dosya izinlerinin beklenen davranışı gösterdiğini ve bağlantı ayarlarının üretim verilerine yanlışlıkla yönelmediğini kontrol edin. Bu test başarılı olsa bile sağlayıcının kurtarma süresi, ağ erişimi ve lisans bağımlılıkları üretim anında farklılık gösterebilir.
Yedekleme planını değiştirirken önce mevcut saklama süresini, son başarılı kopyanın tarihini ve geri dönüş yönergelerini kaydedin. Tek seferde yedek sıklığını, depolama konumunu ve geri yükleme yöntemini birlikte değiştirmeyin; aksi halde sorun çıktığında hangi değişikliğin etkili olduğunu ayırt etmek zorlaşır. Bir geri yükleme testi başarısız olursa eski planı hemen silmek yerine önceki çalışan ayarı koruyun, hatanın hangi aşamada oluştuğunu sağlayıcının kayıtlarından belirleyin ve yeni planı üretim verileri üzerinde kullanmadan düzeltin.
İş yükünüz için sağlayıcı seçeneklerini karşılaştırırken önce bu RPO, RTO ve geri yükleme koşullarını yazılı hale getirin; ardından Türkiye VDS sunucu paketleri gibi seçenekleri, yalnız kaynak miktarına değil yedekleme ve kurtarma modeline göre değerlendirin. İlk somut adım, mevcut yedeğinizi ayrı bir test ortamına geri yükleyip uygulamanın gerçekten açıldığını kanıtlamaktır.
Copyright © 2026 Tüm Hakları Saklıdır.
