Sunucu yedekleme fiyat rehberi: snapshot, imaj yedeği ve FTP yedek alanı arasında TL maliyet ve neyin dahil olduğu

Sunucu yedekleme fiyat teklifleri ilk bakışta birbirine benzer: "100 GB yedek alanı", "günlük snapshot", "imaj yedeği dahil". Ama bu üç ürün aynı işi yapmaz ve aynı riski kapatmaz. Bu rehber, bulut ya da fiziksel sunucusu için teklif toplayan KOBİ sahibi ve sistem yöneticisi için hazırlandı. Amaç, teklifleri TL bazında aynı ölçütle karşılaştırmanız ve fidye yazılımı gibi gerçek bir olayda işe yarayacak yedeğe para ödemenizdir.

Rakam vermek yerine maliyeti nasıl hesaplayacağınızı gösteriyoruz. Fiyatlar sağlayıcıya, kura ve saklama süresine göre değişir; hesap yöntemi değişmez.

Sunucu yedekleme fiyatını belirleyen kalemler

Bir yedekleme teklifinin faturası genellikle şu kalemlerden oluşur. Teklif aldığınızda her birini ayrı satırda görmek isteyin.

• Depolanan veri (GB ya da TB): Yedeklenen verinin kendisi değil, saklama süresi boyunca biriken tüm kopyaların kapladığı alan. En büyük kalem çoğu zaman budur.
• Korunan sunucu sayısı ya da ajan lisansı: İmaj yedeği yazılımları genellikle sunucu başına ücretlendirilir. Fiziksel sunucu ile sanal sunucu lisansı farklı fiyatlanabilir.
• Saklama süresi: 7 gün ile 90 gün arasındaki fark depolanan GB'yi doğrudan büyütür.
• Yedek sıklığı: Günde bir yerine saatlik yedek, artımlı kopya sayısını artırır.
• Geri yükleme ve trafik: Bazı hizmetlerde yedeği geri indirmek, dışarı veri çıkışı ya da destek ekibinin geri yüklemeyi yapması ayrıca ücretlenir.
• Ek kopya ve koruma: Şirket dışı ikinci kopya, değiştirilemez (immutable) saklama, şifreleme.
• Kur ve vergi: Dolar ya da euro fiyatlı paketlerde aylık TL tutarı değişir; KDV'nin fiyata dahil olup olmadığını teyit edin.

Kaba bir aylık maliyet formülü şöyle yazılabilir:

Aylık maliyet ≈ (depolanan GB × GB birim fiyatı) + (sunucu sayısı × ajan ücreti) + ek kopya ücreti + beklenen geri yükleme ve trafik ücreti

Depolanan GB ise kabaca şöyle tahmin edilir:

Depolanan GB ≈ ilk tam yedek + (günlük değişen veri × saklanan gün sayısı)

Örneğin yalnız hesap yöntemini göstermek için: 200 GB verisi olan ve günde ölçülmüş olarak 4 GB değişen bir sunucuda 30 günlük saklama, sıkıştırma öncesi yaklaşık 200 + 30 × 4 = 320 GB alan demektir. Sıkıştırma ve tekilleştirme (deduplication) bu sayıyı düşürebilir; ne kadar düşüreceği verinin türüne bağlıdır, teklifte bu konuda iddia varsa deneme süresinde kendi verinizle doğrulayın.

Snapshot, ajanlı imaj yedeği ve FTP/S3 yedek alanı: hangisi gerçek yedek?

Üç ürünün farkını anlamadan fiyat karşılaştırması yapmak yanıltır. Kısa karşılaştırma:

Snapshot

Snapshot, sunucunun diskini belirli bir andaki haliyle dondurur. Riskli bir güncellemeden önce geri dönüş noktası almak için idealdir. Zayıf yanı, çoğu altyapıda asıl diskle aynı depolama kümesinde durmasıdır. Depolama katmanında sorun olursa ya da panel hesabınız ele geçirilip snapshot'lar silinirse yedeğiniz de gider. Bu yüzden snapshot'ı yedek değil, "hızlı geri alma" aracı olarak görün. Fiyatlandırma genellikle snapshot başına ya da kapladığı GB'ye göredir.

Ajanlı imaj yedeği

Sunucuya kurulan bir ajan, işletim sistemi dahil diskin tamamını ya da seçtiğiniz bölümleri ayrı bir yedek deposuna taşır. Windows'ta VSS sayesinde SQL Server açıkken tutarlı yedek alınabilir. Hem tek dosya geri yükleme hem de sunucuyu sıfırdan ayağa kaldırma (bare metal) mümkündür. Maliyeti sunucu başı lisans ile depolama toplamıdır. Logo, Mikro, Netsis gibi programları çalıştıran Windows sunucular için çoğu zaman en dengeli seçenektir.

FTP ya da S3 yedek alanı

Burada satın aldığınız şey yalnız bir depolama alanıdır. Yedeği alan yazılımı (restic, rclone, Plesk yedekleme, SQL Server bakım planı vb.) siz kurar, zamanlar ve izlersiniz. GB başı en ucuz görünen seçenek budur ama emek ve sorumluluk sizdedir. FTP'nin önemli bir zayıflığı var: kullanıcı adı ve parola sunucuda durduğu için sunucuyu ele geçiren saldırgan FTP'deki yedekleri de silebilir. S3 uyumlu depolamada object lock kullanılırsa bu risk büyük ölçüde kapanır. Kurulum için S3 yedekleme rehberi restic ve rclone adımlarını anlatıyor.

Yedek boyutunu tahmin etme: Windows ve Linux sunucu

Teklif isterken "ne kadar alan lazım" sorusuna tahminle değil ölçümle cevap verin. Aşağıdaki iki sorgu yalnız okur, sistemde değişiklik yapmaz; geri alınacak bir şey yoktur.

Windows: Logo, Mikro ve SQL Server

Logo, Mikro, Netsis gibi programlarda verinin büyük kısmı SQL Server veritabanlarındadır. Aşağıdaki sorgu SQL Server 2016 ve sonrası için hazırlandı; SQL Server Management Studio'da çalıştırın. Her veritabanının veri (ROWS) ve günlük (LOG) dosyası boyutunu MB olarak listeler.

-- Yalnız okur: veritabanı dosya boyutlarını MB olarak listeler
SELECT
    DB_NAME(database_id)                          AS veritabani,
    type_desc                                     AS dosya_tipi,
    CAST(SUM(size) * 8.0 / 1024 AS DECIMAL(12,1)) AS boyut_mb
FROM sys.master_files
GROUP BY database_id, type_desc
ORDER BY boyut_mb DESC;

Beklenen çıktı, her firma veritabanı için bir ROWS ve bir LOG satırıdır. Yorumlarken şunlara dikkat edin:

• LOG dosyası veriden büyükse kurtarma modeli FULL olup günlük yedeği alınmıyor olabilir. Bu, yedek boyutunu gereksiz şişirir; önce bunu düzeltin.
• SQL veritabanlarına ek olarak program klasörü, e-defter ve e-fatura arşivleri, tasarım dosyaları ve kullanıcı belgelerinin boyutunu da ekleyin.
• İmaj yedeği alacaksanız işletim sistemi bölümünün kullanılan alanını da hesaba katın.

Linux: web, uygulama ve veritabanı sunucusu

Aşağıdaki bash betiği Ubuntu 24.04 ve Debian 12 için hazırlandı. Seçtiğiniz dizinlerin toplam boyutunu ve son 24 saatte değişen dosyaların boyutunu verir. Yalnız okur; geri almak için bir şey yapmanız gerekmez. DIZINLER satırını kendi yapınıza göre değiştirin.

#!/usr/bin/env bash
# Yedek boyutu tahmini: yalnız okur, dosya değiştirmez.
# DIZINLER değişkenini kendi sunucunuza göre düzenleyin.
DIZINLER="/etc /home /var/www /opt"

echo "== Dizin boyutları =="
for d in $DIZINLER; do
  # Dizin yoksa atla
  [ -d "$d" ] && du -sh "$d" 2>/dev/null
done

echo "== Son 24 saatte değişen dosyalar (yaklaşık günlük değişim) =="
find $DIZINLER -xdev -type f -mtime -1 -printf '%s\n' 2>/dev/null \
  | awk '{t+=$1} END {printf "%.2f GB\n", t/1024/1024/1024}'

Bu betiği birkaç gün aynı saatte çalıştırıp günlük değişimin ortalamasını alın. Veritabanı dizinini (/var/lib/mysql gibi) doğrudan ölçmek yanıltıcıdır, çünkü büyük veri dosyaları her gün "değişmiş" görünür. Veritabanı için dump dosyasının boyutunu esas alın. Ayrıca değişen dosya boyutu, blok düzeyinde çalışan imaj yedeğinin gerçek artımından genellikle büyük çıkar; yani bu ölçüm sizi temkinli tarafta tutar.

Değiştirilemez yedek ve şirket dışı kopya: fidye yazılımı fiyatı neden etkiler?

Fidye yazılımı saldırılarında saldırgan genellikle önce yedeklere ulaşmaya çalışır. Sunucudan erişilebilen her yedek (bağlı disk, ağ paylaşımı, parolası sunucuda duran FTP) risk altındadır. Bu yüzden fidye yazılımına karşı korunan bir yedek iki şeye ihtiyaç duyar:

1. Şirket dışı kopya: Yedeğin, korunan sunucudan ve aynı yönetim hesabından ayrı bir yerde durması.
2. Değiştirilemez saklama: Belirlenen süre dolmadan yedeğin silinememesi ya da üzerine yazılamaması. S3 tarafında bu özellik object lock adıyla bilinir.

Bu iki özellik maliyeti üç yoldan artırır. Birincisi, ikinci kopya ek depolama demektir. İkincisi, değiştirilemez süre boyunca eski yedekleri silip yer açamazsınız, yani saklama süresi kadar alanı peşin kabul edersiniz. Üçüncüsü, bazı yazılımlarda bu özellik üst paket lisansında yer alır.

Karar ölçütü basit: fidye yazılımı riskini kapatmak istiyorsanız teklifte "değiştirilemez kopya var mı, kaç gün, kim silebilir?" sorusunun yazılı cevabını isteyin. "Yöneticimiz bile silemez" cevabı alınamıyorsa o yedek bu risk için tam koruma sayılmaz. Konunun sözleşme tarafını KOBİ yedekleme hizmeti seçimi rehberinde ayrıntılı ele aldık.

Teklif karşılaştırma tablosu: TL ve dolar fiyatlı paketlerde gizli kalemler

Topladığınız teklifleri aşağıdaki gibi bir tabloya dökün. Boş kalan her hücre, sağlayıcıya sormanız gereken bir sorudur.

En sık gözden kaçan kalemler şunlardır:

• Korunan ve depolanan veri farkı: "100 GB'lık paket" korunan veriyi mi, saklanan tüm kopyaları mı kapsıyor? İkincisiyse 100 GB'lık sunucu bu pakete sığmaz.
• Kota aşımı: Bazı hizmetlerde kota dolunca yedek sessizce durur. Bunu ancak geri yüklemeye ihtiyaç duyduğunuzda fark edersiniz.
• Dışarı veri çıkışı: Felaket anında birkaç yüz GB'ı indirmek trafik ücreti doğurabilir.
• Kur riski: Dolar fiyatlı paketin aylık TL karşılığı değişir; 12 aylık bütçe yaparken birkaç kur senaryosuyla hesaplayın.

Türkiye'de saklanan yedek ve KVKK açısından konum sorusu

Yedek, kaynak verinin bir kopyasıdır. Sunucunuzda müşteri, çalışan ya da cari bilgisi gibi kişisel veri varsa yedekte de vardır. Yedeğin yurt dışında saklanması, KVKK'nın 9. maddesi kapsamında yurt dışına aktarım sayılabilir ve ek yükümlülükler doğurabilir. Bu yüzden teklifte yalnız "bulutta" yazması yetmez; yedeğin hangi ülkede, hangi veri merkezinde durduğunu ve ikinci kopyanın nereye gittiğini yazılı isteyin.

Pratik karar ölçütü: ana sunucunuz Türkiye'deyse ve kişisel veri işliyorsanız, yedeğin de Türkiye'de kalması uyum işini sadeleştirir. Örneğin S3 uyumlu Object Storage hizmetimiz İstanbul'dadır ve veri ile kopyaları Türkiye dışına çıkmaz. Hukuki değerlendirme için kendi danışmanınızdan görüş almanız gerekir; bu bölüm yalnız sorulacak soruyu gösterir.

Geri dönüş testi: fiyata dahil mi, nasıl istenir?

Geri yüklenemeyen yedek, ödenmiş bir faturadan ibarettir. Geri dönüş testi, yedeğin gerçekten açılıp çalıştığını ayrı bir ortamda doğrulamaktır. Teklif aşamasında şunları sorun:

• Test fiyata dahil mi, yılda ya da ayda kaç kez?
• Test sırasında hangi ortam kullanılıyor: geçici bir sunucu mu, sizin sunucunuzun yanında bir kopya mı?
• Test sonunda yazılı rapor veriliyor mu: hangi tarihli yedek, ne kadar sürede, hangi kontrollerle?

Kendi testinizi de yapabilirsiniz. Asgari kontrol listesi:

1. Rastgele seçtiğiniz eski tarihli bir yedeği geçici bir sunucuya geri yükleyin.
2. Windows'ta SQL Server servisinin açıldığını ve Logo ya da Mikro'nun firma listesini getirdiğini görün; son kayıt tarihini kontrol edin.
3. Linux'ta web sitesinin açıldığını, veritabanı bağlantısının kurulduğunu ve son yüklenen dosyaların yerinde olduğunu doğrulayın.
4. Geri yüklemenin başından sonuna kadar geçen süreyi not edin. Bu süre, işinizin kabul edebileceği kesinti süresinden uzunsa yedek yönteminiz değişmelidir.
5. Sonucu tarih ve sorumlu adıyla kayda geçirin.

Sık yapılan hatalar

• Yedeği aynı diskte ya da aynı sunucuda tutmak: Disk bozulursa ya da fidye yazılımı şifrelerse yedek de gider.
• Tek kopyaya güvenmek: Yalnız snapshot ya da yalnız tek bir FTP alanı, tek hata noktasıdır. En az bir kopya şirket dışında ve değiştirilemez olmalı.
• Hiç test edilmemiş geri yükleme: Yedek görevinin "başarılı" görünmesi, verinin açılacağı anlamına gelmez.
• Yalnız GB fiyatına bakmak: Ajan lisansı, geri yükleme ücreti ve kota aşımı toplam maliyeti değiştirir.
• Veritabanını dosya olarak kopyalamak: SQL Server ya da MySQL açıkken veri dosyalarını kopyalamak tutarsız yedek üretebilir. Uygulama tutarlı imaj ya da dump kullanın.
• Yedek parolasını ve şifreleme anahtarını yedeğin yanında saklamak: Anahtar kaybolursa yedek açılmaz; sunucuyla birlikte ele geçerse koruma anlamını yitirir.

Sık sorulan sorular

Snapshot tek başına yedek sayılır mı?

Çoğu durumda hayır. Snapshot genellikle asıl diskle aynı depolama altyapısında durur ve aynı panel hesabından silinebilir. Güncelleme öncesi hızlı geri dönüş için çok kullanışlıdır, ama şirket dışı ve değiştirilemez bir kopyanın yerini tutmaz.

FTP yedek alanı mı, S3 uyumlu depolama mı daha uygun?

İkisi de yalnız depolama sunar ve yedek yazılımını sizin kurmanızı gerektirir. S3 uyumlu depolama, object lock ile değiştirilemez saklamaya izin verdiği ve modern yedek araçlarıyla doğrudan çalıştığı için fidye yazılımına karşı daha güçlü bir seçenektir. FTP'de parola sunucuda durduğu için saldırgan yedeklere ulaşabilir.

Logo ya da Mikro sunucusu için hangi yedek türünü seçmeliyim?

Pratikte iki katmanlı bir yapı uygundur: SQL Server veritabanlarının düzenli yedeği ve sunucunun ajanlı imaj yedeği, bunlardan en az birinin şirket dışında değiştirilemez kopyası. Böylece hem tek firma veritabanını hem de sunucunun tamamını geri alabilirsiniz.

Saklama süresi ne kadar olmalı?

Kısa saklama ucuzdur ama fidye yazılımı ya da fark edilmeyen veri bozulması günler sonra ortaya çıkabilir. Mali kayıtlar gibi verilerde yasal saklama yükümlülüklerini de göz önüne alın. Günlük yedekleri birkaç hafta, aylık yedekleri daha uzun tutan katmanlı bir politika, maliyet ile güvenlik arasında dengeli bir başlangıçtır.

Yedek fiyatı neden sunucu fiyatından ayrı veriliyor?

Çünkü yedek, sunucudan bağımsız bir depolama ve yazılım hizmetidir ve boyutu verinize, saklama sürenize ve kopya sayınıza göre değişir. Sunucuya "yedek dahil" yazan tekliflerde bunun snapshot mı, şirket dışı kopya mı olduğunu mutlaka sorun.

Bu işi hazır yapmak isterseniz bulut yedekleme hizmetimizde sunucu ve program yedeğinin kurulumunu, saklama politikasını ve geri dönüş kontrolünü birlikte planlayabiliriz. Verinizin boyutunu yukarıdaki ölçümlerle çıkardıysanız teklif daha hızlı ve net hazırlanır.

Sonuç

Sunucu yedekleme fiyatını karşılaştırırken önce ürün türünü netleştirin: snapshot hızlı geri dönüş aracıdır, ajanlı imaj yedeği tam sistemi korur, FTP ya da S3 alanı ise yalnız depolamadır. Ardından verinizi ölçün, depolanan GB'yi saklama süresiyle hesaplayın ve teklifleri aynı tabloda karşılaştırın. Son olarak şirket dışı ve değiştirilemez kopyayı, yedeğin konumunu ve geri dönüş testini yazılı hale getirin. En ucuz teklif değil, geri yüklendiği kanıtlanmış yedek doğru tercihtir.