Sunucu yedeği seçerken yalnız “kaç GB alan alacağım?” sorusu yeterli değildir. Önce kaybetmeyi göze alabileceğiniz veri aralığını (RPO), hizmetin yeniden çalışması için hedeflediğiniz süreyi (RTO) ve geçmişe ne kadar dönebilmeniz gerektiğini belirleyin. Bu rehberdeki rakamlar yöntemi göstermek için kullanılan varsayımsal örneklerdir; Hedef Hosting paketlerine ait kapasite veya kurtarma süresi garantisi değildir.
RPO, RTO ve saklama süresi üç farklı karardır
- RPO: Olay anından ne kadar önceki veriye dönmek kabul edilebilir? İki saatlik kayıt kaybı kabul edilemiyorsa günde bir yedekleme tek başına bu hedefi karşılamaz.
- RTO: Uygulama ne kadar süre içinde yeniden kullanılabilir olmalıdır? Yedeği indirmek, sunucuyu açmak ve iş akışını doğrulamak aynı aşama değildir.
- Saklama süresi: Hata geç fark edilirse geçmişteki hangi noktalara dönmek gerekir? Daha uzun saklama, yedeklerin daha sık alındığı anlamına gelmez.
Örneğin her gece 02.00’de başarıyla tamamlanan günlük yedeği olan bir sistem 18.00’de veri kaybederse son kullanılabilir nokta yaklaşık 16 saat öncesine ait olabilir. Yedek görevi başarısız olduysa aralık daha da uzar. “30 gün saklama” bu zaman boşluğunu kapatmaz.
Her uygulama için kurtarma hedefi yazın
Tek sunucuda bir tanıtım sitesi, sipariş veritabanı ve dosya arşivi bulunabilir. Bunların iş etkisi farklıdır. Aşağıdaki listeyi uygulama başına doldurmak, teknik teklifi somutlaştırır:
| Bilgi | Kaydedilecek karar |
|---|---|
| Korunacak bileşenler | VM, dosya, veritabanı, sertifika ve gerekli yapılandırmalar |
| Kabul edilebilir veri kaybı | İşletmenin onayladığı süre; yalnız teknik ekibin tahmini değil |
| Hedef geri dönüş süresi | Uygulamanın kullanıcıya yeniden hizmet vereceği an |
| Kurtarma sırası | DNS, kimlik doğrulama, veritabanı ve uygulama bağımlılıkları |
| Geri yükleme onayı | Kararı kimin vereceği ve hangi verilerin üzerine yazılabileceği |
| Başarı ölçütü | Uygulama açılışı, kayıt bütünlüğü, dosya erişimi ve temel iş akışları |
WordPress veya cPanel hesabını koruyorsanız dosya ve veritabanının tutarlılığına odaklanın. cPanel ve Plesk yedekleme rehberi hesap yedeği ile geri yükleme yetkisinin farkını açıklar. VM düzeyindeki korumada ise sanallaştırma uyumluluğu, erişim ve lisans koşulları ayrıca kontrol edilir.
Yedek alanı için örnek kapasite hesabı
Başlangıç hesabında ayrılmış disk boyutu yerine gerçekten korunan veriyi kullanın. Örnek bir sistemde 300 GB korunan veri, günde 10 GB değişen veri ve 14 günlük pencere olsun. Bir tam yedek ile 13 artımlı noktanın tutulduğu basitleştirilmiş varsayımda 300 + (13 × 10) = 430 GB ham veri hesabı çıkar.
Bu sonuç satın alınacak alanı belirlemek için tek başına yeterli değildir. Sıkıştırma ve tekilleştirme alanı azaltabilir; ek tam yedekler, zincir bakımı, metadata, bekleyen silmeler ve büyüme alanı artırabilir. Sıkıştırılmış veya şifrelenmiş kaynak veri daha az küçülebilir. Değişim miktarı da günlük yeni dosya boyutuyla aynı olmayabilir.
- İlk başarılı tam yedeğin gerçek boyutunu ölçün.
- Normal günler ve yoğun günlerdeki artımlı yedek boyutlarını izleyin.
- Gerçek saklama ve tam yedek politikasını hesaba ekleyin.
- Geri yükleme için hedef depolama alanını yedek deposundan ayrı planlayın.
- İş büyümesini ve kapasite uyarı eşiğini belirleyin; eşik aşıldığında kimin işlem yapacağını yazın.
Kapasite planlama aracı
Yedekler için ne kadar alan gerekir?
Koruyacağınız veriyi, günlük değişimi ve saklama politikanızı girerek tam ve artımlı yedeklerin alan ihtiyacını hesaplayın. Saklama süresinin dışında kalan ancak geri yükleme için gereken önceki tam yedek ve artımlı zincir de hesaba katılır.
Bütün alanlar gereklidir. Ondalık için virgül veya nokta kullanabilirsiniz; binlik ayırıcı kullanmayın. GB değerlerini aynı birimle girin.
Hesabın yöntemi ve sınırları
Ham alan = tam yedek sayısı × veri boyutu + artımlı yedek sayısı × günlük değişen veri.
Planlanan alan = ham alan × (1 + emniyet payı / 100).
Hesaplayıcı, tam yedek döngüsündeki bütün günleri inceler ve en fazla alan gerektiren durumu kullanır. En eski saklanan kurtarma noktasının dayandığı tam yedek ile aradaki artımlılar silinmiş kabul edilmez. Tam yedek alınan gün ayrıca artımlı yedek sayılmaz.
Varsayımsal örnek: 100 GB veri, günde 10 GB değişim, 30 günlük saklama ve 7 günde bir tam yedek için en yüksek ihtiyaç 6 tam + 30 artımlı yedek, yani 900 GB olur. %20 emniyet payıyla 1.080 GB planlanır. Bu örnek herhangi bir Hedef Hosting paketinin yedekleme politikası veya kapasite vaadi değildir.
Tek kopya, sabit veri boyutu ve sıkıştırmasız artımlı yedek varsayılır. Sıkıştırma, tekilleştirme, sentetik tam yedek, yazılım metadatası, geçici çalışma alanı ve başka lokasyondaki kopyalar hesaplanmaz. Yeni yedek tamamlanmadan eskisini silmeyen sistemlerde ek geçici alan gerekebilir. Günlük kurtarma noktaları kesinti öncesindeki son günün verisini kaybetme ihtimalini ortadan kaldırmaz; RPO gerçek çalışma sıklığı ve başarılı yedeklerle, RTO ise geri yükleme testiyle doğrulanmalıdır.
Sonucu, bu rehberdeki saklama ve geri yükleme kontrol listesiyle birlikte kullanın. Sunucunun ana diski ile yedek kopyasının farklı arıza alanlarında bulunmasını ayrıca planlayın.
Snapshot, RAID ve yedek kopya ayrımı
RAID, bazı disk arızalarında sürekliliğe yardımcı olur; yanlış silinmiş veya şifrelenmiş verinin geçmiş halini geri getirmez. Aynı depolama sistemine bağımlı snapshot da o sistem kaybedilirse yeterli olmayabilir. Yedeklerin erişimini canlı sistemden ayırın; ayrı lokasyon, değiştirilemez depo veya çevrimdışı kopya gereksinimini olay senaryosuna göre belirleyin. Bu özelliklerin her pakete otomatik dahil olduğunu varsaymayın.
Geri yükleme denemesinde ne ölçülmeli?
Denemeyi üretim verisinin üzerine yazmadan, erişimi sınırlı ve mümkünse ağ açısından yalıtılmış bir test ortamında planlayın. Kurtarılan sistemin canlı sistemle aynı IP, zamanlanmış görev, e-posta gönderimi veya dış entegrasyonları çalıştırması ek sorun oluşturabilir.
- Geri dönüş noktasının tarihini, yedek görevinin başarısını ve varsa şifre çözme anahtarına erişimi doğrulayın.
- Talep/onay zamanı, veri aktarımı, sistem açılışı ve uygulama doğrulaması sürelerini ayrı kaydedin.
- Dosyaları ve veritabanını uygulamayla birlikte kontrol edin; yalnız VM’in açılması başarı ölçütü olmasın.
- Eksik bağımlılıkları, ağ ayarlarını ve erişim sorunlarını kurtarma planına işleyin.
- Ölçülen süre hedefi aşıyorsa yöntem, bant genişliği, hedef depolama veya öncelik sırasını yeniden değerlendirin.
Veeam yedekleme hizmeti için teklif bilgileri
Veeam yedekleme hizmetini değerlendirirken VM sayısını, kullanılan disk alanını, günlük değişimi, saklama hedefini ve geri yükleme önceliklerini birlikte iletin. Standart yaklaşım günlük planlı yedeklemedir; daha sık yedek veya özel RPO/RTO hedefleri ayrıca teknik değerlendirme gerektirir. 500 GB, 1 TB ve 2 TB gibi alan seçeneklerini yalnız sunucu diskinizin etiketiyle eşleştirmeyin.
Yedekleme politikası hizmetin kendi kapsamına bağlıdır. Premium Hosting’in haftalık, bir ay saklanan ve ücretli geri yüklemeli hesabı ile Veeam VM yedekleme hizmeti aynı ürün değildir. Sunucu satın alırken VDS kaynak seçimini ve yedekleme planını birlikte değerlendirin; yedekleme lisansı veya ek koruma katmanlarını otomatik dahil kabul etmeyin.
Teknik kaynak
Veeam Backup & Replication saklama politikası belgeleri, geri dönüş noktalarının ve yedek zincirinin nasıl yönetildiğini açıklar. Uygulamada kullanılan sürüm ve yedekleme yöntemi için ilgili belgelere başvurun.
Konuyu farklı yönleriyle ele alan diğer rehberlere göz atın.
