Dedicated Sunucu Kiralarken Kontrol Listesi (2026)

Dedicated sunucu (dedicated server) kiralarken doğru kararı vermek, sadece “daha güçlü donanım” seçmekten ibaret değildir. Ağ performansı, depolama tipi, bakım/kurulum süreçleri ve servis seviyesi (SLA) gibi unsurlar birlikte çalışır. Bu rehberde 11.08.2026 itibarıyla uygulamada sık yaşanan hataları kullanarak, dedicated sunucu kiralamadan önce hangi teknik maddeleri kontrol etmeniz gerektiğini net bir liste halinde derliyoruz.

1) İhtiyacın teknik tanımını yap: CPU, RAM ve I/O gerçek darboğazdır

Dedicated sunucuda en pahalı hata, kapasiteyi yanlış tanımlamaktır. “Kimin ne kadar disk ister” sorusu kadar, “hangi I/O deseni var” sorusu da kritiktir.

Hangi metrikleri istemeden karar vermeyin?

CPU kullanımı: Sadece toplam yüzde değil, saatlik zirveler ve çekirdek bazlı yük (vCPU değil; dedicated’da çekirdek gerçek.)
RAM: Uygulamanın büyümesiyle birlikte memory leak (sızıntı) varsa buna alan bırakın.
Disk I/O (IOPS): Özellikle veritabanı (MySQL/PostgreSQL), ElasticSearch/OpenSearch, yoğun log yazımı ve yoğun arama senaryolarında belirleyicidir.
Network throughput: “Trafik” tek başına yetmez; paket başına (pps) veya bant genişliği + gecikme (latency) önemlidir.

Net şartlar: tekliften talep edin

Teklif/konfigürasyon ekranında şu ifadeleri görmeyi hedefleyin: - Disk tipi: NVMe SSD (veya SATA/SAS), kapasite ve RAID seviyesi - RAID: RAID0/1/5/6/10 ve “kullanılabilir kapasite” - İşletim sistemi: lisanslı mı ücretsiz mi (Windows/Linux) - Ağ: Gbps tanımı, port hızı ve “burst” davranışı

2) Konum ve ağ kalitesi: ülke dışına çıkınca gecikme ve route değişir

Dedicated sunucunun konumu, performansın yarısıdır. Türkiye’den erişen bir sistem için, veri yolunun (route) kalitesi günlük deneyimi belirler.

Kontrol edeceğiniz 3 ağ parametresi

TTFB/latency: Gerçek ölçüm isteyin. Sağlayıcı “hızlı” demek yerine hedef ölçüm değerlerini paylaşmalıdır.
Packet loss: Paket kaybı varsa web/API gecikir, hata oranı artar.
Transit/peering: Sağlayıcı mutlaka transit sağlayıcılarını belirtmese bile, en azından “günlük performans şikayeti olur mu” kısmına açıklık getirmelidir.

Uygulama örneği

Türkiye’den kullanıcıya servis veren bir uygulamada; içerik tek ülkede kalmıyorsa CDN düşünün.
Kurumsal VPN/VoIP gibi gecikmeye hassas işlerde, sadece bant genişliği yetmez; latency ve jitter kritik olur.

3) Depolama seçimi: NVMe, RAID ve “rebuild” süresi

Dedicated sunucuda en büyük maliyet kalemi depolama ve yedeklemedir; ayrıca arıza senaryosunda nasıl kurtarıldığı da belirleyicidir.

NVMe SSD vs SATA SSD (pratik ayrım)

NVMe SSD: Çok daha yüksek IOPS ve düşük gecikme hedefler.
SATA SSD: Birçok web senaryosunda yeterli olabilir; fakat veritabanı/arama yoğunluğu arttıkça fark netleşir.

Net kural: Veritabanı ve arama (ElasticSearch/OpenSearch) yoğun çalışacaksa NVMe istemeniz gerekir. Sadece “dosya depolama” yapıyorsanız SATA SSD ekonomik ve yeterli olabilir.

RAID konusunda teklifin açık olması gerekir

RAID seviyesi performans ve kurtarma şeklini etkiler: - RAID0: En yüksek performans, tek disk arızasında veri kaybı riski. - RAID10: Genelde güven + performans dengesi (maliyet artar). - RAID5/6: Alan verimliliği iyi olabilir; rebuild sırasında yük artar.

Teklifte şu bilgileri görün: - RAID seviyesi - “Hot spare” olup olmadığı (varsa) - Donanım arızası durumunda rebuild davranışı

4) Yedekleme ve kurtarma (backup & restore): RAID yedek değildir

Dedicated sunucuda RAID, fiziksel disk arızasını korur. Ancak yanlış dosya silme, şifre sızması, hatalı güncelleme gibi senaryolarda RAID tek başına çözüm değildir.

İstenen yedekleme modeli

Şunlardan en az birini net talep edin: - Otomatik günlük snapshot (snapshot) + geri dönüş imkanı - Uzak hedefe (external storage) kopyalanan yedek (yedek kopyası aynı sunucu üzerinde olmamalı)

3-2-1 kuralını teklif kapsamına bağlayın

3 kopya (primary + en az 2 yedek)
2 farklı ortam (ör. sunucu diski + harici storage)
1 kopya harici lokasyon/ayrı sistem

Aşağıdaki tablo, “teklifte neyi sormalıyım”a hızlı rehber olur:

İhtiyaç	Soru	Net beklenen yanıt
Hızlı geri yükleme	Restore işlemi kaç saat sürer?	ROI/plan + örnek süre
Yedek saklama	Yedek kaç gün/hafta saklanır?	7/14/30 gün gibi net süre
Yedek lokasyonu	Yedek aynı rack’te mi?	Harici/ayrı sistem
Snapshot mı full backup mı?	Ne saklanıyor?	Snapshot + dosya düzeyi geri yükleme mümkün mü
Yedek doğrulama	Restore test ediliyor mu?	“restore doğrulama” süreci

5) Ağ limitleri, port politikası ve “sınırsız” ifadesinin gerçek anlamı

Dedicated sunucularda bant genişliği çoğu zaman satış metninde yer alır; ama kullanıcı deneyimini ağ politikaları belirler.

“Sınırsız” bant genişliğiyle ilgili net kontrol

Sağlayıcılar sıklıkla FUP (Fair Use Policy) uygular. Bu yüzden teklif/SoP (service policy) talep edin.

Şu ifadeleri metinden çıkarıp netleştirin: - Aylık limit var mı? (ör. 1 TB/5 TB) - Gün içinde aşımda throttling var mı? - Aşımda “otomatik kısma” mı var, yoksa ek ücret mi? - Hangi ölçüm birimi kullanılıyor? (transfer vs average throughput)

Ek IP ve yönlendirme gereksinimi

Bazı kurulumlarda ek IP işe yarar: - Birden fazla hizmet için farklı IP segmenti - Güvenlik politikaları ve firewall kuralları (IP bazlı)

Net karar ölçütü: - Birden fazla domain farklı servis/sertifika/ACL ile çalışacaksa ek IP planlayın. - Yalnızca tek web hizmeti varsa çoğu senaryoda ek IP zorunlu değildir; yine de sağlayıcının otomasyonuyla (reverse proxy, load balancer) gerekebilir.

6) Yönetim, erişim ve güvenlik: iLO/kVM ve erişim süresi

Dedicated sunucuda kritik olaylar anlık yaşanır. Bu nedenle kontrol paneli değil; donanım yönetim (iLO/iDRAC/kVM) erişimi ve destek yanıt süresi önem kazanır.

Sormanız gereken erişim başlıkları

KVM/iLO erişimi var mı? (uzaktan konsol)
Reboot/BIOS düzeyi müdahale destekleniyor mu?
Acil durumda destek SLA süresi ne? (ör. 15 dk/1 saat)
Kurulum süresi: OS kurulum ve hazır olma süresi

Güvenlik: temel hardening beklentisi

Teklifte şu konuların kapsamına bakın: - Firewall varsayılanı - DDoS koruması: “var” demek yetmez; hangi seviye (L3/L4/L7) ve kapasite - Log saklama: sistem logları ne kadar tutuluyor

7) Performans ve maliyet dengesi: teklifleri aynı kriterle kıyaslayın

Dedicated sunucularda fiyatlar benzer görünse bile fark; disk, RAID, ağ politikası ve bakım süreçlerinde oluşur.

Kıyas tablosu: teklifleri bu şablonla değerlendirin

Aşağıdaki maddelerle her sağlayıcının teklifini aynı sırayla puanlayın:

CPU/RAM net modeli: İşlemci jenerasyonu ve RAM tipi
Disk: NVMe mi? Kapasite + RAID seviyesi
Ağ: Gbps, FUP ve throttling koşulları
Yedek: snapshot var mı, uzak hedef var mı, saklama süresi
SLA: arıza/anlık servis yanıt süreleri
Yönetim: iLO/KVM ve uzaktan erişim
Kurulum: teslim süresi ve OS/driver kapsamı

Tipik “gizli maliyet” kaynakları

Ek ücretli yedekleme (sadece günlük değil; saklama süresi de ücretli olabilir)
DDoS korumanın “limit aşımında kesilmesi”
RAID0 seçilip “performans iyi” denmesi, sonra veri kaybı maliyetinin büyümesi

Sonuç: Dedicated sunucu kararını teknik şartnameyle netleştirin

Dedicated sunucu kiralarken en iyi sonuç, sağlayıcıdan “genel açıklama” değil; disk (NVMe/RAID), ağ (FUP/throttling), yedekleme (snapshot + saklama + uzak kopya), yönetim erişimi (iLO/KVM) ve SLA bilgilerini şartnameye bağlayınca çıkar. Aksiyon olarak: 1) I/O ve ağ senaryonuza göre NVMe/RAID ve bant genişliği politikasını netleştirin, 2) RAID’in yedek olmadığını kabul ederek 3-2-1 mantığını talebe çevirin, 3) teklifleri yukarıdaki kıyas tablosuyla aynı sırada değerlendirin. Bu üç adımı uyguladığınızda yanlış kapasite ve sürpriz maliyet riski belirgin şekilde düşer.