Web sunucu kiralama: paylaşımlı hostingden sunucuya geçiş zamanı, aylık TL maliyet ve kesintisiz taşıma

Siteniz paylaşımlı hostingte yavaşlıyor, kampanya günlerinde 503 hatası veriyor ya da panel sürekli "kaynak sınırına ulaşıldı" uyarısı gösteriyorsa web sunucu kiralama zamanı gelmiş olabilir. Bu rehber, sitesini büyüten KOBİ sahipleri ve birden çok müşteri sitesi yöneten ajanslar için hazırlandı. Geçişin gerçekten gerekli olup olmadığını ölçerek anlamayı, aylık TL maliyetin hangi kalemlerden oluştuğunu ve siteyi ziyaretçiye kesinti yaşatmadan nasıl taşıyacağınızı adım adım gösteriyor.

Web sunucu kiralama nedir, paylaşımlı hostingten farkı

Paylaşımlı hostingte siteniz, aynı makinedeki yüzlerce siteyle CPU, bellek ve disk erişimini paylaşır. Sağlayıcı herkesi korumak için her hesaba sınır koyar: CPU yüzdesi, eşzamanlı giriş süreci (entry process), bellek ve dosya sayısı (inode). Bu sınırlar hesabınızı korur ama sitenizin tepe anlarında da devreye girer.

Web sunucu kiralamada ise size ayrılmış bir sanal ya da bulut sunucu alırsınız. vCPU, RAM ve disk sizin içindir; PHP sürümünü, PHP-FPM işçi sayısını, önbelleği ve veritabanı ayarlarını kendiniz belirlersiniz. Karşılığında işletim sistemi güncellemesi, güvenlik ve yedek sorumluluğu da büyük ölçüde size geçer. Bu sorumluluğu bir kontrol paneliyle ya da yönetilen hizmetle hafifletebilirsiniz.

Kısaca karar şu soruya dayanır: Sorununuz yazılımdan mı, yoksa paylaşılan kaynağın sınırından mı geliyor? Optimize edilmemiş bir tema ya da önbelleksiz bir site, sunucuya taşındığında da yavaş kalır.

Geçiş zamanı geldiğini gösteren işaretler

Hissiyat yerine ölçüm kullanın. Aşağıdaki üç işaretten en az ikisi düzenli tekrar ediyorsa geçiş mantıklıdır.

503 ve 508 hataları

cPanel tabanlı paylaşımlı hostinglerde eşzamanlı süreç sınırı dolduğunda ziyaretçi genellikle "503 Service Unavailable" ya da "508 Resource Limit Is Reached" görür. Panelde "Resource Usage" (Kaynak Kullanımı) bölümünü açın ve son 30 günde kaç kez sınıra takıldığınıza bakın. Sınır aşımları yalnız bot taramasıyla aynı saatlere denk geliyorsa önce bot trafiğini ve önbelleği düzeltin. Gerçek ziyaretçi yoğunluğuyla örtüşüyorsa sorun kapasitedir.

CPU, giriş süreci ve inode sınırları

Kaynak kullanım grafiğinde CPU çizgisi sık sık tavana yapışıyorsa, ya da giriş süreci sayısı sınırın yakınında geziyorsa, kodu iyileştirseniz bile pay yetmeyecektir. Inode sınırı ise farklı bir sorundur: önbellek klasörleri ya da eski yedekler binlerce küçük dosya üretir. Bunu temizlik çözer, sunucu değil.

Yavaş ödeme sayfası ve TTFB

E-ticaret sitesinde en kritik ölçü, önbelleğe alınamayan sepet ve ödeme sayfalarının ilk bayta kadar geçen süresidir (TTFB). Ana sayfa önbellekten hızlı gelir ama ödeme sayfası her istekte PHP ve veritabanı çalıştırır.

Aşağıdaki komut bir sayfayı 10 kez çağırıp her isteğin TTFB ve toplam süresini yazar. Herhangi bir Linux ya da macOS terminalinde, curl kurulu sistemler için hazırlandı. Yalnız okuma yapar, geri alınacak bir değişiklik yoktur. https://example.com/odeme yerine kendi sayfanızı yazın.

#!/usr/bin/env bash
# Belirtilen adrese 10 istek atar, TTFB ve toplam süreyi saniye cinsinden yazar.
URL="https://example.com/odeme"   # ölçülecek sayfa
for i in $(seq 1 10); do
  curl -s -o /dev/null \
    -w "istek $i  ttfb=%{time_starttransfer}s  toplam=%{time_total}s  kod=%{http_code}\n" \
    "$URL"
  sleep 2
done

Beklenen çıktı istek 1 ttfb=0.412s toplam=0.455s kod=200 biçimindedir. Ölçümü sakin saatte ve yoğun saatte ayrı ayrı yapın. İki saat arasındaki fark büyükse, yani yoğunlukta TTFB birkaç katına çıkıyorsa, paylaşılan kaynak sınırı ciddi bir adaydır. Sakin saatte de yavaşsa önce eklentileri, sorguları ve önbelleği inceleyin.

Aylık TL maliyet karşılaştırması

Teklifleri yalnız etiket fiyatıyla karşılaştırmak yanıltır. Aşağıdaki kalemleri her seçenek için ayrı ayrı yazın ve aylık toplama çevirin.

Kontrol panelinde iki yol vardır. cPanel ve Plesk gibi ücretli paneller hesap ya da site sayısına göre lisanslanır ve bu ücret sunucu bedelinin üstüne eklenir. CloudPanel ve HestiaCP gibi ücretsiz paneller lisans maliyetini kaldırır ama e-posta gibi bazı özellikleri kapsamayabilir. Ajanssanız site sayısı arttıkça lisans kaleminin nasıl büyüdüğünü mutlaka hesaplayın.

Yönetim ücretini de görünür yapın. Sunucuyu kendiniz yönetecekseniz bu bir para kalemi değil, zaman kalemidir: güncelleme, izleme ve sorun anında müdahale için ayda kaç saat ayıracağınızı yazın ve saat değerinizle çarpın. Bu hesap çoğu zaman "en ucuz VPS" ile "yönetilen sunucu" arasındaki farkı daraltır.

Kur etkisi: dolar endeksli fatura ile TL faturalı sunucu

Bazı hosting ve sunucu teklifleri dolar ya da euro üzerinden fiyatlanır ve her fatura döneminde güncel kurla TL'ye çevrilir. Bu durumda bütçeniz yalnız sağlayıcı zammına değil, kura da bağlıdır. Karşılaştırma yaparken aynı kaynak için 12 aylık toplamı en az iki kur senaryosuyla hesaplayın: kur sabit kalırsa ve kur yükselirse. TL sabit fiyatlı teklifte ise yenileme dönemindeki artış koşulunu sözleşmeden okuyun. Faturadaki kalemleri ayırma ve yenileme zammını değerlendirme konusunu sunucu kiralama yenileme zammı rehberinde ayrıntılı bulabilirsiniz.

Web sitesi için sunucu kaç GB RAM gerektirir?

Tahmin yerine şu mantığı kullanın: PHP sitelerinde belleğin büyük kısmını PHP-FPM işçileri ve veritabanı tüketir. Gereken RAM kabaca, aynı anda çalışması gereken PHP işçi sayısı ile işçi başına ortalama bellek çarpımına veritabanı, işletim sistemi ve önbellek payının eklenmesiyle bulunur.

Paylaşımlı hostingte panelin gösterdiği tepe giriş süreci sayısı, eşzamanlı işçi ihtiyacınız için iyi bir başlangıç verisidir. Yeni sunucuda site çalışmaya başladıktan sonra işçi başına belleği aşağıdaki komutla ölçün. Ubuntu 24.04 ve Debian 12 için hazırlandı, yalnız okuma yapar. Süreç adı dağıtıma ve PHP sürümüne göre php-fpm8.3 gibi değişebilir.

# PHP-FPM işçilerinin sayısını ve ortalama bellek kullanımını (MB) gösterir.
ps -C php-fpm8.3 -o rss= | awk '{t+=$1; n++} END {if (n) printf "islem=%d  ortalama=%.0f MB\n", n, t/n/1024}'

Küçük başlayıp bir hafta ölçmek, büyük paketle başlayıp gereksiz ödemekten ucuzdur. Bellek, CPU steal ve disk gecikmesini bir hafta boyunca kaydeden betik için VPS sunucu kaç GB RAM yeter rehberine bakabilirsiniz. Bulut sunucuda kaynak artırmak genellikle kısa bir yeniden başlatma ile yapılabildiği için ilk boyutta yanılmak kalıcı bir hata değildir.

Kesintisiz taşıma planı

Kesintisiz taşımanın sırrı, eski ve yeni sunucunun bir süre aynı anda çalışması ve DNS değişiminin hızlı yayılmasıdır. Sırayı bozmayın.

1. DNS TTL değerini en az 24 saat önce düşürün

Alan adınızın A kaydı için TTL değeri, dünyadaki çözümleyicilerin kaydı ne kadar süre önbellekte tutacağını belirler. Taşımadan en az bir gün önce, mevcut TTL süresinden daha uzun bir süre önce, A ve AAAA kayıtlarının TTL'ini 300 saniyeye indirin. Değişikliği şöyle doğrulayın:

# A kaydını ve kalan TTL değerini gösterir (dnsutils ya da bind-utils paketi gerekir).
dig +noall +answer example.com A

Beklenen çıktı example.com. 300 IN A 192.0.2.10 gibidir. İkinci sütun 300 ya da altındaysa hazırsınız.

2. Yeni sunucuyu hazırlayın

Yeni sunucuda aynı PHP ana sürümünü, gerekli PHP eklentilerini ve aynı veritabanı motorunu kurun. Eski hostingte panelden PHP sürümünü ve eklenti listesini not edin. Sürüm atlamayı taşımayla aynı güne koymayın; önce birebir taşıyın, sürüm yükseltmesini sonra ayrı yapın.

3. Dosyaları rsync ile aktarın

Paylaşımlı hostingte SSH erişimi varsa rsync en güvenli yoldur, çünkü tekrar çalıştırıldığında yalnız değişen dosyaları aktarır. SSH yoksa panelden tam yedek alıp yeni sunucuya yükleyin.

Aşağıdaki betik yeni sunucuda çalışır ve eski hostingteki site dosyalarını çeker. Ubuntu 24.04 ve Debian 12 için hazırlandı. ORNEK_KULLANICI, eski sunucu adresi ve dizin yollarını kendi değerlerinizle değiştirin. Betik --delete kullanmaz, yani hedefte dosya silmez; tekrar çalıştırmak güvenlidir. Geri almak için hedef dizini yedekleyip yeniden oluşturmanız yeterlidir, eski sunucuda hiçbir değişiklik yapılmaz.

#!/usr/bin/env bash
# Eski hostingteki site dosyalarını yeni sunucuya çeker. Tekrar çalıştırılabilir.
set -euo pipefail

ESKI_SUNUCU="192.0.2.10"              # eski hostingin adresi
ESKI_KULLANICI="ORNEK_KULLANICI"       # eski hosting SSH kullanıcısı
KAYNAK="public_html/"                  # eski sunucudaki site dizini (sondaki / önemli)
HEDEF="/var/www/example.com/htdocs/"   # yeni sunucudaki site dizini

mkdir -p "$HEDEF"

# -a: izinleri ve zamanları korur, -z: sıkıştırır, --partial: kesilen aktarımı sürdürür
rsync -az --partial --info=progress2 \
  --exclude 'wp-content/cache/' \
  "${ESKI_KULLANICI}@${ESKI_SUNUCU}:${KAYNAK}" "$HEDEF"

# Dosya sahibini web sunucusu kullanıcısına ver (dağıtıma ve panele göre değişebilir)
chown -R www-data:www-data "$HEDEF"
echo "Aktarim tamam: $HEDEF"

4. Veritabanını aktarın

Veritabanını tutarlı bir anlık görüntü olarak almak için --single-transaction kullanın; bu seçenek InnoDB tablolarını kilitlemeden döküm alır. Aşağıdaki komutlar yeni sunucuda çalışır, MySQL 8 ve MariaDB 10.11 için hazırlandı. Parolayı komut satırına yazmamak için eski sunucuda ~/.my.cnf dosyası kullanın. ORNEK_DB ve ORNEK_DB_KULLANICI değerlerini değiştirin. Geri almak için yeni sunucudaki veritabanını silip yeniden içe aktarmanız yeterlidir; eski veritabanına yazma yapılmaz.

#!/usr/bin/env bash
# Eski sunucudaki veritabanını döker, yeni sunucuya içe aktarır.
set -euo pipefail

ESKI_SUNUCU="192.0.2.10"
ESKI_KULLANICI="ORNEK_KULLANICI"
DB="ORNEK_DB"
DOKUM="/root/${DB}-$(date +%Y%m%d-%H%M).sql.gz"

# 1) Uzak döküm: tablolar kilitlenmez, büyük tablolar satır satır okunur
ssh "${ESKI_KULLANICI}@${ESKI_SUNUCU}" \
  "mysqldump --single-transaction --quick --no-tablespaces --default-character-set=utf8mb4 ${DB}" \
  | gzip > "$DOKUM"

# 2) Hedef veritabanı yoksa oluştur (varsa dokunmaz)
mysql -e "CREATE DATABASE IF NOT EXISTS \`${DB}\` CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

# 3) İçe aktar
gunzip -c "$DOKUM" | mysql "$DB"
echo "Veritabani aktarildi: $DOKUM"

Ardından site yapılandırma dosyasında (WordPress için wp-config.php) veritabanı adı, kullanıcısı ve sunucu adresinin yeni sunucuya uyduğunu kontrol edin. Alan adı değişmediği için site adresini güncellemeniz gerekmez.

5. DNS'i değiştirmeden test edin

Yeni sunucuyu, DNS'e dokunmadan, alan adınızla test edebilirsiniz. curl'ün --resolve seçeneği isteği belirttiğiniz adrese yönlendirir. 198.51.100.20 yerine yeni sunucunun adresini yazın:

curl -sI --resolve example.com:443:198.51.100.20 https://example.com/ | head -n 5

Henüz sertifika yoksa -k ekleyin ya da önce http ile deneyin. Tarayıcıda gezinmek için bilgisayarınızın hosts dosyasına geçici satır ekleyip giriş, sepet ve ödeme adımlarını uçtan uca deneyin. Testten sonra satırı silmeyi unutmayın.

6. SSL sertifikası

Let's Encrypt HTTP doğrulaması, alan adı yeni sunucuyu göstermeden çalışmaz. İki seçeneğiniz var: DNS doğrulamasıyla sertifikayı önceden almak ya da DNS değişiminden hemen sonra sertifikayı almak. İkinci yolda TTL düşük olduğu için açık kalan süre kısadır. Süreç ayrıntıları için Let's Encrypt doğrulama türleri belgesine bakabilirsiniz.

7. E-posta

Paylaşımlı hostingte e-posta çoğu zaman web ile aynı yerdedir; taşımanın en çok gözden kaçan parçası budur. Önce MX kayıtlarının nereyi gösterdiğini dig example.com MX ile görün. E-postayı web sunucusunda tutmak yerine ayrı bir e-posta hizmetine taşımak, sunucu sorunlarında postanın etkilenmemesini sağlar. Geçmiş kutuları IMAP üzerinden aktarın, MX değişikliğini web taşımasından ayrı bir günde yapın ve eski hostingi kapatmadan önce son bir eşitleme çalıştırın.

8. Son eşitleme ve DNS değişimi

Trafiğin en düşük olduğu saati seçin. E-ticaret ya da üyelik sitesinde siparişin eski veritabanına düşmemesi için eski sitede kısa bir bakım modu açın. Ardından rsync betiğini ve veritabanı aktarımını bir kez daha çalıştırın, A kaydını yeni adrese çevirin. Statik içerikli bir sitede bakım modu gerekmez; birkaç dakika iki sunucunun aynı içeriği sunması sorun değildir.

Taşıma sonrası kontrol listesi ve geri dönüş planı

DNS değişiminden sonraki ilk saatlerde şunları sırayla kontrol edin:

• dig +short example.com A çıktısı yeni adresi gösteriyor mu?
• Ana sayfa, ürün sayfası, sepet ve ödeme 200 dönüyor mu? TTFB ölçüm betiğini yeniden çalıştırıp eski değerlerle karşılaştırın.
• İletişim formu ve sipariş e-postası gidiyor mu? Site e-postası için SPF kaydına yeni sunucu adresi ya da kullandığınız SMTP servisi eklendi mi?
• Zamanlanmış görevler (cron) yeni sunucuda tanımlı mı? WordPress'te wp-cron ya da sistem cron'u çalışıyor mu?
• Yedek planı devrede mi ve ilk yedek alındı mı? Bir dosyayı geri yükleyerek test edin.
• Web sunucusu ve PHP hata günlüklerinde yeni uyarı var mı?

Geri dönüş planı basittir, yeter ki eski hostingi hemen iptal etmeyin. Bir sorun çıkarsa A kaydını eski adrese döndürürsünüz; TTL düşük olduğu için yayılma hızlı olur. Tek dikkat noktası veridir: geri dönüşten önce yeni sunucuda oluşan sipariş ve üyelikleri eski veritabanına aktarmanız gerekir. Bu yüzden ilk günlerde sipariş tablosunu takip edin. Eski hostingi en az bir fatura dönemi daha tutup her şey oturduktan sonra kapatın, TTL'i de normal değerine geri yükseltin.

Sık yapılan hatalar

• TTL'i taşıma günü düşürmek. Eski yüksek TTL önbelleklerde durduğu için değişiklik saatler sonra yayılır. Düşürmeyi en az bir gün önce yapın.
• Sorunu yanlış teşhis etmek. Önbelleksiz ve ağır eklentili bir site, güçlü sunucuda da yavaştır. Önce ölçün, sonra taşıyın.
• Taşıma ile sürüm yükseltmesini birleştirmek. PHP ya da veritabanı sürümünü aynı gün değiştirmek, sorun çıktığında nedenini bulmayı zorlaştırır.
• E-postayı unutmak. MX kaydını kontrol etmeden eski hostingi kapatmak, gelen postaların kaybolmasına yol açar.
• Son eşitlemeyi atlamak. İlk aktarımdan sonra gelen siparişler ve yüklenen görseller yeni sunucuya geçmez.
• Yedeği sonraya bırakmak. Paylaşımlı hostingte otomatik olan yedek, kendi sunucunuzda siz kurmadıkça yoktur.
• Güvenlik ayarlarını atlamak. Yeni sunucuda SSH anahtarı, güncelleme ve erişim kısıtlamalarını taşımadan önce tamamlayın.

Sık sorulan sorular

Paylaşımlı hostingten VPS'e geçince site kesinlikle hızlanır mı?

Hayır, kesin değildir. Yavaşlığın nedeni paylaşılan kaynak sınırıysa belirgin iyileşme görülür. Neden ağır sorgular, önbellek eksikliği ya da büyük görsellerse, sunucu tek başına çözmez. Taşımadan önce sakin ve yoğun saatte TTFB ölçümü yapmak bu ayrımı netleştirir.

Sunucuyu yönetmeyi bilmiyorsam ne yapmalıyım?

Kontrol paneli kurulu bir sunucu ya da yönetilen hizmet seçebilirsiniz. Panel, site ekleme, SSL ve veritabanı gibi günlük işleri kolaylaştırır. Güncelleme, izleme ve yedeğin kimde olduğunu sözleşmede açıkça yazdırın.

Bir sunucuda birden çok site barındırabilir miyim?

Evet. Ajanslar için bu çoğu zaman hosting hesaplarından daha ekonomiktir. Her siteyi ayrı sistem kullanıcısı ve ayrı PHP-FPM havuzuyla çalıştırmak, bir sitedeki güvenlik açığının diğerlerine yayılmasını zorlaştırır.

Taşıma sırasında arama motoru sıralamam etkilenir mi?

Alan adı ve adres yapısı değişmediği sürece taşıma yalnız sunucu değişikliğidir. Önemli olan sitenin kesintisiz yanıt vermesi ve hata sayfası dönmemesidir. Taşımadan sonra Search Console'daki tarama hatalarını birkaç gün izleyin.

Eski hostingi ne zaman iptal etmeliyim?

Web, e-posta ve zamanlanmış görevlerin yeni yerde sorunsuz çalıştığını doğruladıktan ve son e-posta eşitlemesini yaptıktan sonra. Bu, geri dönüş seçeneğini de o süre boyunca açık tutar.

Bu işi hazır yapmak isterseniz hosting taşıma hizmetimizle web sitenizi ve e-postalarınızı yukarıdaki sırayla, ücretsiz olarak taşıyabiliriz. CloudPanel kurulu bir web sitesi sunucusu üzerinde siteleriniz panelden yönetilmeye hazır olarak teslim edilir.

Sonuç

Web sunucu kiralama, paylaşımlı hostingin sınırlarına gerçekten takıldığınızda doğru adımdır; bunu 503 hataları, kaynak grafiği ve TTFB ölçümüyle kanıtlayın. Maliyeti sunucu, panel lisansı, yedek, e-posta, yönetim emeği ve kur riskiyle birlikte 12 aylık toplam olarak karşılaştırın. Taşımada sıra her şeydir: TTL'i önceden düşürün, yeni sunucuyu DNS'e dokunmadan test edin, son eşitlemeyi yapın ve eski hostingi geri dönüş seçeneği olarak bir süre açık tutun.