Hosting yenileme zamanı: 2026’da nelere dikkat etmeli?

Hosting yenileme zamanı geldiğinde karar vermenizi zorlaştıran şey genellikle fiyat farkı değil; ileride maliyet, performans ve güvenlikte sürpriz çıkaran detayların kaçmasıdır. Bu rehberde, hosting veya sunucu kiralama yenilemesi yapmadan önce SLA, kaynak limitleri, yedekleme (backup), veri merkezi ve destek süreçlerini net şekilde nasıl kontrol edeceğinizi adım adım anlatıyorum. Ayrıca sağlayıcı değişmeden bile olası sorunları azaltacak somut kontrol maddeleri paylaşıyorum.

1) Yenileme öncesi sözleşme ve SLA kontrolü

Hosting yenilemesinde ilk bakılacak yer “fiyat” değil, sağlayıcının hangi koşullarda sorumluluk aldığını yazdığı bölümlerdir. Özellikle yenileme tarihinden önce bilmediğiniz bir madde, yıl içinde beklenmedik kesintilere veya ek ücretlere yol açabilir.

SLA (Service Level Agreement) ve kesinti tanımı

SLA’da şu bilgileri arayın:

• Uptime garantisi: Örn. aylık %99.9 gibi. Daha önemlisi, garanti hesaplamasının kesinti tanımına nasıl bağlandığıdır.
• Planlı kesinti: Bakım için bildirimin süresi (kaç saat/kaç gün önce) ve bildirimin kanalı (mail, panel, bülten) net mi?
• SLA dışı durumlar: DDoS, üçüncü taraf ağ sorunları, yanlış kullanım vb. hangi başlıklarla hariç tutuluyor?
• Telafi mekanizması: SLA tutmazsa kredi (credit) mi veriliyor yoksa fatura indirimi mi? Oran ve ödeme şekli yazıyor mu?

Fiyat artışı ve ödeme şartları

Yenilemede sık görülen sorun, ilk yıl “tanıtım fiyatı” ile devam edip sonraki yılın artışa gitmesidir. Şunları netleştirin:

• Yenileme bedelinin dayandığı fiyat politikası: “Ücretler her dönem güncellenebilir” gibi muğlak ifadeler yerine değişim aralığı/hesap mantığı var mı?
• Ödeme yöntemi ve para birimi: TL tahsil edilip edilmeyeceği, kur farkı yansıtılması.
• Otomatik yenileme iptali: İptal yöntemi ve son tarih. Panik yaşanmasın diye son gün yerine 30 gün önce aksiyon alın.

2) Kaynak limitleri: CPU/RAM, disk, IOPS ve “adil kullanım”

Paylaşımlı hosting, VDS/VPS ve dedicated fark etmeksizin “adil kullanım” (fair use) veya kaynak aşımı politikaları yenilemede kritikleşir. Çünkü kullanımınız büyüdükçe limitlere takılmanız hız düşüşü ve hatalarla sonuçlanır.

Paylaşımlı hostingte bakılacaklar

• Disk alanı: Sadece toplam kapasite değil, e-posta kutuları ve log dosyaları için ek limit var mı?
• İnce ayar limitleri: CPU kullanım sınırı, süreç sayısı (process limit), eş zamanlı bağlantı sayısı.
• MySQL/PostgreSQL limitleri: max bağlantı (connections) ve sorgu süresi sınırları.

VPS/VDS/dedicatedta bakılacaklar

• vCPU ve CPU paylaşımı: vCPU sayısı kadar, ne tür CPU tahsisi olduğu (paylaşımlı/garantili) önemlidir.
• RAM garantisi: Oversell (aşırı tahsis) olup olmadığı.
• Depolama tipi: SSD/NVMe. Sadece “SSD” yazması tek başına yeterli değildir; NVMe ve IOPS değerleri belirtiliyor mu?
• Ağ bant genişliği: “Unlimited” deniyorsa hız çekme/limit sonu var mı?

Kontrol listesi (hızlı)

Aşağıdaki tablo, yenilemeden önce sağlayıcıdan yanıt almanız gereken başlıkları özetler:

3) Yedekleme stratejisi: Sağlayıcı backup mı, sizin kontrolünüz mü?

Hosting yenilemesinde en kritik konu yedekleme değilse bile “restore edilebilirlik”tir. Bir backup dosyasının var olması tek başına güvenli değildir; gerektiğinde geri yüklenebilir olmalıdır.

Sağlayıcı yedeklemeyi test edin

Şunları doğrulayın:

• Yedekleme sıklığı: Günlük mü, saatlik mi? Log dosyaları için ayrı yaklaşım var mı?
• Saklama süresi: 7 gün mü 30 gün mü? Ransomware senaryosunda gecikme önemlidir.
• Restore süresi: Beklenen geri dönüş süresi var mı?
• Restore yöntemi: Panelden mi, destek talebiyle mi? Otomasyon var mı?

Sizin tarafınızdan alınan yedek (ikincil kopya)

En sağlıklı yaklaşım, sağlayıcının backup’ını “tek kopya” olarak görmemektir. Yenileme öncesinde şu iki şeyi yapın:

• Dosyalar için arşiv yedek: tar/rsync mantığıyla belirli aralıklarla.
• Veritabanı yedek: MySQL/PostgreSQL için düzenli dump veya anlık yedek mantığı.

Örnek (mantıksal) periyot önerisi: - Kritik verilerde: Günlük sağlayıcı backup + haftalık manuel arşiv. - E-ticaret/üretim sistemlerinde: Her deploy öncesi veritabanı dump + dosya arşivi.

4) Veri merkezi, routing ve gecikme (latency) beklentisi

Yenileme kararında veri merkezi seçimi, sadece “lokasyon” değildir; Türkiye kullanıcılarını etkileyen şey gecikme (latency), paket kaybı ve rota istikrarıdır.

Planlı test: Yenilemeden önce performans ölçümü

• Mevcut site hızlarını kaydedin: Lighthouse skorları (mobil/desktop), TTFB, sayfa yükleme süresi.
• 7 gün boyunca trend bakın: Özellikle aynı saat dilimlerinde ölçün.
• CDN kullanıyorsanız: CDN’in hangi POP noktasından hizmet verdiğini ve origin (kök sunucu) yanıt süresini kontrol edin.

Routing değişimi riskini yönetin

Yenileme sırasında sağlayıcının veri merkezi tarafında altyapı güncellemesi yapma ihtimali vardır. Şu soruları sorun:

• Yenileme döneminde node/vlan değişikliği veya bakım planı var mı?
• Veri merkezi değişirse bildirim süreci nedir?
• IP adresi aynı kalacak mı? (SEO ve cache davranışı açısından önemlidir.)

5) Güvenlik: Güncelleme, izolasyon, erişim ve olay müdahalesi

Hosting yenilemesi, güvenlik bakım planını da yenileme anlamına gelir. Burada kontrol edeceğiniz noktalar “hangi ürün var” değil, “kim neyi yönetiyor” sorusunun cevabıdır.

Güncellemeler: OS, kontrol paneli, eklentiler

Şunları netleştirin:

• OS güncellemeleri (Linux security patches) otomatik mi?
• Web sunucusu (Apache/Nginx/Caddy/LiteSpeed) güncellemeleri ne sıklıkla uygulanıyor?
• Kontrol paneli (cPanel/Hestia vb.) ve eklentiler için güncelleme penceresi var mı?

Erişim yönetimi ve loglar

• SSH erişimi hangi yöntemle sağlanıyor? (Kilit tabanlı erişim, parola kapatma politikası.)
• Log erişimi: Panel logları ve sistem logları ne kadar süre saklanıyor?
• Fail2ban/WAF gibi katmanlar var mı? Varsa kapsamı nedir?

Olay müdahalesi (incident response)

Şu maddeleri sorarak riski azaltın:

• Güvenlik ihlali tespitinde sağlayıcı kullanıcıya nasıl geri dönüş yapar?
• DDoS durumunda varsayılan aksiyon: trafik temizleme mi, yönlendirme mi?
• Sızma sonrası çalışma: Forensics desteği var mı, ek ücret mi?

6) Uygulama uyumu: Kontrol paneli, PHP sürümü ve SSL yenileme planı

Hosting yenilemesinde “sistemin çalışıyor olması” yetmez; yenileme sonrası sürüm uyumsuzluğu yaşanmaması gerekir. Özellikle PHP sürümü, Node/Java süreçleri ve SSL süreçleri kritikleşir.

PHP ve uygulama bağımlılıkları

• Hangi PHP sürümleri mevcut? Sürüm düşmesi veya kaldırılması planlanıyor mu?
• Otomatik geçiş var mı? Yoksa yenileme sonrası manuel güncelleme mi gerekecek?
• Gerekli uzantılar (ext) var mı? Örn. mbstring, curl, gd, imagick gibi.

SSL (TLS) yenileme operasyonu

SSL ücretsiz de olsa ücretli de olsa operasyonel süreç yenileme sırasında belirleyicidir:

• Sertifikanın türü: DV/OV/EV ayrımı ve doğrulama süresi.
• Sertifika yenileme mekanizması: Panel otomatik mi, destek müdahalesi mi gerekiyor?
• Sertifika süresi ve hata senaryosu: Yenileme başarısız olursa ne olur, kim uyarılır?

Kontrol paneli ve taşınabilirlik

• Panel değişirse (örn. farklı paket/altyapı) eklentiler etkilenir mi?
• Yönetim arayüzü değişecek mi? Dosya yöneticisi, cron yönetimi, mail yönetimi aynı mı?

Hosting yenileme kararı için pratik senaryolar

Aşağıdaki senaryolardan hanginize daha yakın olduğunuzu düşünün. Her biri için net kontrol aksiyonları var.

• Fiyat artışı görüyorum ama performansım aynı
• Yenileme öncesi 7 günlük hız trendini çıkarın.
• SLA/backup frekansı değişiyor mu kontrol edin.

• Kaynak limitleri güncellendi mi (disk/CPU throttling) öğrenin.

• Kullandığım kaynak arttı, site yavaşladı

• CPU/RAM kullanım grafiğini sağlayıcı panelinden inceleyin.
• Disk doluluk oranını ve MySQL tablolarının büyümesini kontrol edin.

• VDS/VPS’e geçiş gerekiyorsa “maliyet/performans farkını” netleştirin:

  • Paylaşımlı pakette throttling var mı?
  • VPS’te NVMe ve IOPS değerleri nasıl?

• Güvenlik olayından sonra yeniliyorum

• Sağlayıcının incident response adımlarını isteyin (yazılı).
• Restore testini mutlaka yapın: Son backup’tan staging ortamına geri dönüş.

Sonuç: Yenilemeyi “ödeme” değil “kontrol” olarak planlayın

Hosting yenilemesini son haftaya bırakmadan, önce SLA + kaynak limitleri + yedekleme/restore kabiliyeti + veri merkezi/latency beklentisi + güvenlik güncelleme kapsamını netleştirin. Eğer sağlayıcı bu başlıklarda yazılı ve ölçülebilir bilgi vermiyorsa, bu durum ileride maliyet ve kesinti riskini büyütür.

Aksiyon önerisi: Yenileme tarihinden 30 gün önce (1) mevcut performans trendinizi çıkarın, (2) sağlayıcıdan SLA/backup/restore bilgilerini yazılı alın, (3) en az bir restore testini planlayın. Sonrasında ya mevcut pakette kalın ya da VDS/VPS tarafına geçiş için kaynak ve depolama değerleriyle birlikte yeni paketi kıyaslayın.