Fiziksel sunucu kiralama: bulut faturası büyüyen VPS'ten dedicated sunucuya kesintisiz geçiş ve aylık TL maliyet eşiği

Birden çok VPS'e ya da büyük bir bulut sunucuya her ay ödenen tutar bir noktada tek bir fiziksel makinenin kirasını geçer. Fiziksel sunucu kiralama bu noktadan sonra mantıklı hale gelir. Ama yalnız fiyata bakarak geçiş yapmak, RAID, yedek ve donanım arızası gibi kalemleri gözden kaçırmak demektir. Bu rehber, birden çok VPS yöneten sistem yöneticileri ve KOBİ sahipleri için. Önce eşiği ölçümle hesaplıyoruz, sonra geçişi kesintisiz yapmanın adımlarını sırayla veriyoruz.

Fiziksel sunucu kiralama ne zaman bulut sunucudan ucuza gelir

Kararın temeli tahmin değil ölçümdür. Fiziksel sunucu, kaynakları sürekli ve öngörülebilir biçimde kullanan iş yüklerinde avantajlıdır. Yük gün içinde çok dalgalanıyorsa, birkaç haftalık kampanya dönemleri varsa ya da iş yükü henüz netleşmediyse bulutun esnekliği genellikle daha değerlidir.

Şu dört soruya ölçümle yanıt verin:

1. Toplam kaynak: Bütün VPS'lerin vCPU, RAM ve disk toplamı ne kadar?
2. Gerçek kullanım: Bu kaynakların ne kadarı gerçekten kullanılıyor, yoksa boş mu bekliyor?
3. CPU steal: Sanal makineler fiziksel çekirdek için başka müşterilerle yarışıyor mu? st değeri sürekli yüksekse, aldığınız vCPU'nun tamamını kullanamıyorsunuz demektir.
4. Disk bekleme: wa değeri yüksekse darboğaz CPU değil disktir. Fiziksel sunucudaki yerel NVMe bu tabloyu değiştirebilir.

Her VPS'te kaynak özeti alma

Aşağıdaki betik Ubuntu 24.04 ve Debian 12 için hazırlandı. Yalnız okuma yapar, sonucu /tmp altında bir dosyaya yazar. Geri almak için oluşan dosyayı silmeniz yeterli.

#!/usr/bin/env bash
# kaynak-ozeti.sh: Sunucunun anlık kaynak durumunu salt okunur biçimde raporlar.
set -euo pipefail

CIKTI="/tmp/kaynak-ozeti-$(hostname)-$(date +%F).txt"

{
  echo "== Sunucu: $(hostname)"
  echo "== vCPU sayisi: $(nproc)"
  echo "== Load average (1/5/15 dk): $(cut -d' ' -f1-3 /proc/loadavg)"
  echo "== Bellek (MiB)"
  free -m
  echo "== Disk kullanimi"
  df -hT -x tmpfs -x devtmpfs
  echo "== vmstat: 5 sn arayla 12 ornek (us sy id wa st sutunlarina bakin)"
  vmstat 5 12
} > "$CIKTI"

echo "Rapor yazildi: $CIKTI"

Tek bir anlık görüntü yanıltıcıdır. En az bir haftalık veri için sysstat paketini kurup toplamayı açın:

# sysstat kurulumu ve periyodik toplamayi acma (Ubuntu 24.04, Debian 12)
sudo apt-get install -y sysstat
sudo systemctl enable --now sysstat
# Ertesi gun CPU (steal dahil) ve bellek ozetini gorme:
sar -u
sar -r

sar -u çıktısında %steal ve %iowait sütunlarına, sar -r çıktısında %memused sütununa bakın. Geri almak için sudo systemctl disable --now sysstat ve sudo apt-get remove sysstat yeterli. Linux tarafında ayrıntılı ölçüm yöntemi için RAM ve CPU steal ölçüm rehberindeki mantık aynıdır.

Karar ölçütü: Bir hafta boyunca toplam kullanım istikrarlıysa ve VPS'lerin toplamı tek bir fiziksel makinenin kapasitesine büyüme payıyla birlikte sığıyorsa, fiziksel sunucu ciddi bir seçenektir. Kullanım ani tepeler yapıyor ve çoğu zaman boşta duruyorsa, önce VPS'leri küçültmek daha ucuz olabilir.

Aylık TL maliyet eşiği: bütün kalemleri toplama

Eşiği bulmak için iki tarafın bütün kalemlerini aynı tabloya koyun. Yalnız sunucu kirasını karşılaştırmak en sık yapılan hatadır.

Bulut ya da VPS tarafı (aylık):

• Her VPS'in kira bedeli (VPS sayısı kadar satır)
• Ek blok disk ve snapshot ücretleri
• Yedekleme hizmeti
• Trafik kotası aşımı ve ek IP adresleri
• Lisanslar (Windows, kontrol paneli, veritabanı)
• KDV ve dövizle faturalanıyorsa kur farkı

Fiziksel sunucu tarafı (aylık):

• Sunucu kira bedeli
• Kurulum ücreti varsa, taahhüt süresine bölünmüş hali
• Ek disk (RAID için ikinci disk dahil)
• Ayrı bir yere alınan yedek alanı (aynı makinedeki disk yedek sayılmaz)
• Ek IP adresleri, trafik ya da bant genişliği yükseltmesi
• Çekirdek başına lisanslanan yazılımlar (aşağıda ayrıca anlatılıyor)
• Proxmox gibi bir sanallaştırma katmanı kullanacaksanız destek aboneliği (isteğe bağlı)
• İşletim zamanı: donanım izleme, RAID kontrolü, güncelleme için harcanacak saatler

Eşik formülü sade:

Eşik koşulu:
  (Bulut toplamı) > (Fiziksel kira + Yedek alanı + Ek IP + Lisans farkı + İşletim zamanı farkı)

Formülde iki kalem sık unutulur. Birincisi, buluttaki snapshot ve yedek çoğu zaman sağlayıcının altyapısında ayrı tutulur. Fiziksel sunucuda bu güvenceyi ayrıca satın almanız gerekir. İkincisi, kur riski. Dövizle faturalanan bir hizmetin TL karşılığı her ay değişir. Teklifleri 12 aylık bir kur senaryosuyla karşılaştırın ve sözleşmede fiyatın TL sabit mi döviz endeksli mi olduğunu yazılı görün.

Güncel kalemleri tek sayfada görmek için fiyat listesindeki bulut, yedekleme ve fiziksel sunucu satırlarını aynı tabloya aktarabilirsiniz.

Büyüme payını hesaba katın

Fiziksel sunucuyu bugünkü toplam kullanıma tam oturacak şekilde seçmeyin. Bulutta bir VPS'i büyütmek dakikalar alır. Fiziksel sunucuda RAM ya da disk eklemek donanım müdahalesi, bazen de makine değişimi demektir. Önümüzdeki 12 ile 24 ay için beklediğiniz büyümeyi ölçümünüze ekleyin.

Fiziksel sunucuda dikkat: RAID, yedekli güç, arıza müdahale süresi

Bulut sunucuda alttaki donanım arızalanırsa sanal makine genellikle başka bir hosta alınır. Fiziksel sunucuda böyle bir katman yoktur: makine tek arıza noktasıdır. Bu farkı dürüstçe hesaba katmak gerekir.

Teklifte sorulacaklar:

• RAID: Kaç disk var, hangi RAID düzeyi kurulu (RAID 1, RAID 10), donanım RAID kartı mı yazılım RAID mi? İki disk RAID 1 ile tek disk arasındaki fiyat farkı, tek bir disk arızasında yaşanacak veri kaybının yanında küçüktür.
• Yedekli güç kaynağı: Sunucuda iki güç kaynağı var mı, ve bunlar ayrı güç hatlarına bağlı mı?
• Donanım arızasında müdahale süresi: Disk, RAM ya da anakart arızasında değişim kaç saat içinde yapılıyor? Bu süre sözleşmede yazılı mı?
• Uzaktan konsol: IPMI, iDRAC ya da iLO gibi bir yönetim arayüzü var mı? İşletim sistemi açılmadığında tek erişim yolu budur. Bu arayüz internete açık olmamalı, yalnız VPN ya da IP kısıtlamasıyla erişilmelidir.
• Lokasyon ve stok: Hangi veri merkezinde olacağını ve teslim süresini netleştirin.

Teslim aldıktan sonra RAID ve disk sağlığını kontrol etme

Yazılım RAID (mdadm) kullanılan bir sunucuda ilk iş durumu doğrulamaktır. Komutlar Ubuntu 24.04 ve Debian 12 için hazırlandı, salt okunurdur:

# Yazilim RAID durumunu goster
cat /proc/mdstat

# Disk saglik ozeti (smartmontools paketi gerekir)
sudo apt-get install -y smartmontools
sudo smartctl -H /dev/sda

/proc/mdstat çıktısında dizinin yanında [UU] görmelisiniz. [U_] bir diskin düştüğünü gösterir. smartctl -H çıktısında PASSED beklenir. NVMe disklerde aygıt adı /dev/nvme0n1 gibi olur. Donanım RAID kartında durumu kartın kendi aracıyla ya da IPMI arayüzünden kontrol edin.

Unutmayın: RAID yedek değildir. Yanlışlıkla silinen bir dosya ya da fidye yazılımı her iki diske de aynı anda yazılır.

Geçiş öncesi hazırlık: envanter, DNS TTL, yedek ve geri dönüş planı

Envanter çıkarma

Her VPS'te nelerin çalıştığını yazılı hale getirmeden taşıma yapmayın. Aşağıdaki betik Ubuntu 24.04 ve Debian 12 için hazırlandı, salt okunurdur ve çıktıyı /tmp altına yazar. Geri almak için dosyayı silin.

#!/usr/bin/env bash
# envanter.sh: Dinleyen portlar, calisan servisler ve zamanlanmis gorevler
set -euo pipefail

CIKTI="/tmp/envanter-$(hostname)-$(date +%F).txt"

{
  echo "== Dinleyen TCP portlari"
  sudo ss -tlnp
  echo "== Calisan servisler"
  systemctl list-units --type=service --state=running --no-pager
  echo "== Kullanici crontab'lari"
  for u in $(cut -d: -f1 /etc/passwd); do
    if sudo crontab -l -u "$u" >/dev/null 2>&1; then
      echo "-- $u"
      sudo crontab -l -u "$u"
    fi
  done
  echo "== /etc/cron.d icerigi"
  ls -l /etc/cron.d
  echo "== systemd zamanlayicilari"
  systemctl list-timers --all --no-pager
} > "$CIKTI"

echo "Envanter yazildi: $CIKTI"

Bu listeye ek olarak SSL sertifikalarının nasıl yenilendiğini, e-postanın nereden gönderildiğini ve dış servislerin (ödeme, API) hangi IP'ye izin verdiğini not edin. IP izin listesi olan dış servisleri yeni IP için önceden güncellemeniz gerekir.

DNS TTL düşürme

Geçişten en az 24 ile 48 saat önce ilgili kayıtların TTL değerini 300 saniyeye düşürün. Böylece geçiş günü kayıt değiştiğinde önbellekler kısa sürede yenilenir. Doğrulama:

dig +noall +answer example.com A

Beklenen çıktı şuna benzer:

example.com.   300   IN   A   192.0.2.10

İkinci sütun TTL'dir. Eski değeri görüyorsanız, eski TTL süresi dolana kadar bekleyin.

Yedek ve geri dönüş planı

Taşımaya başlamadan önce her VPS'in tam yedeğini alın ve bir dosyayı geri yükleyerek yedeğin çalıştığını doğrulayın. Geri dönüş planı tek cümleyle yazılmalıdır: "Sorun çıkarsa DNS kaydını eski IP'ye geri alırız, eski VPS'ler bu süre boyunca açık kalır." Eski VPS'leri en az bir fatura dönemi boyunca kapatmayın.

Adım adım taşıma: rsync, veritabanı replikasyonu ve son senkronizasyon

1. Yeni sunucuyu hazırlama

İşletim sistemini kurun, kullanıcıları, SSH anahtarlarını ve gerekli paketleri aynı sürümlerle yükleyin. PHP, Node.js ya da veritabanı sürümlerinin kaynakla aynı olması sürpriz hata riskini azaltır.

2. İlk dosya senkronizasyonu

İlk kopya, kaynak sunucu çalışırken yapılır. Komut yeni sunucuda çalıştırılır ve Ubuntu 24.04 ile Debian 12 için hazırlandı. ORNEK_KULLANICI ve IP adresini kendi değerlerinizle değiştirin. Önce --dry-run ile neyin kopyalanacağını görün:

KAYNAK="ORNEK_KULLANICI@192.0.2.10"

# Deneme: hicbir sey yazmaz, yalnizca listeler
rsync -aHAX --numeric-ids --dry-run "$KAYNAK:/var/www/" /var/www/

# Gercek kopya
rsync -aHAX --numeric-ids --info=progress2 "$KAYNAK:/var/www/" /var/www/

Kaynak yolun sonundaki / önemlidir: dizinin içeriğini kopyalar, dizinin kendisini değil. Bu komut tekrar çalıştırılabilir; ikinci çalıştırmada yalnız değişen dosyalar aktarılır. Geri almak gerekirse hedef sunucudaki /var/www/ içeriği kaynakta hâlâ durduğu için kaynak etkilenmez.

3. Veritabanını canlı tutma

Küçük veritabanlarında son senkronizasyon sırasında döküm alıp geri yüklemek yeterlidir. Büyük ya da sürekli yazılan veritabanlarında replikasyon kurmak kesintiyi kısaltır:

• MySQL ve MariaDB: Kaynakta ikili günlüğü (binlog) açın, mysqldump --single-transaction ile tutarlı bir döküm alın ve dökümün içine binlog konumunu yazdırın. Yeni sunucuda dökümü yükleyip kaynağı replika kaynağı olarak tanımlayın. Replika gecikmesi sıfıra yaklaştığında geçiş anına hazırsınız demektir.
• PostgreSQL: pg_basebackup ile temel kopyayı alıp akış replikasyonu kurabilir, geçiş anında replikayı birincil yapabilirsiniz.

Hangi yöntemi seçerseniz seçin, replikasyon bağlantısını yalnız iki sunucunun IP'leri arasında açın ve şifreli bağlantı kullanın.

4. Son senkronizasyon ve geçiş

1. Uygulamayı bakım moduna alın ya da yazmaları durdurun.
2. Dosyalarda son farkı aktarın. Bu adımda kaynakta silinen dosyaların hedefte de silinmesi için --delete kullanılır. Yalnız açık ve dar bir yol verin, önce --dry-run ile listeyi kontrol edin:

KAYNAK="ORNEK_KULLANICI@192.0.2.10"
rsync -aHAX --numeric-ids --delete --dry-run "$KAYNAK:/var/www/" /var/www/
# Liste dogruysa --dry-run olmadan tekrar calistirin

3. Veritabanında replikasyonu durdurun ve yeni sunucuyu birincil yapın ya da son dökümü yükleyin.
4. DNS kaydını yeni IP'ye çevirin.
5. Eski sunucuda uygulamayı salt okunur bırakın ya da yeni sunucuya yönlendirin. Böylece eski IP'ye düşen istekler kaybolmaz.

Doğrulama: DNS değişmeden yeni sunucuyu test etme

DNS'i değiştirmeden önce yeni sunucuyu kendi alan adınızla test edin. curl --resolve isteği belirttiğiniz IP'ye gönderir:

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

Beklenen çıktı HTTP/2 200 ya da uygulamanıza göre bir yönlendirme kodudur. Sertifika hatası alıyorsanız sertifikanın yeni sunucuya taşınmadığını gösterir.

Geçişten sonra şunları kontrol edin:

• dig +short example.com A yeni IP'yi gösteriyor mu?
• Uygulama ve web sunucusu hata günlüklerinde yeni hata var mı?
• Zamanlanmış görevler yeni sunucuda çalışıyor mu, eski sunucuda kapatıldı mı? İki sunucuda aynı cron'un çalışması çift e-posta ya da çift işlem üretir.
• Yedekleme yeni sunucudan alınıyor ve geri yüklenebiliyor mu?

Fiziksel sunucuda sanallaştırma: Proxmox ile birden çok VPS'i tek makinede toplama

Birden çok VPS'i tek makineye taşırken servisleri aynı işletim sistemine yığmak zorunda değilsiniz. Proxmox VE gibi bir sanallaştırma platformuyla her eski VPS'i ayrı bir sanal makine ya da LXC konteyneri olarak koruyabilirsiniz.

Artıları: Servisler birbirinden yalıtılır, her biri ayrı güncellenip yeniden başlatılabilir, snapshot alma imkânı geri gelir. Bir müşterinin ya da projenin sunucusu diğerini etkilemez.

Eksileri: Sanallaştırma katmanını sizin yönetmeniz gerekir. Kaynakları aşırı dağıtırsanız (her sanal makineye fiziksel kapasitenin üstünde RAM verirseniz) bellek baskısı tüm sanal makineleri etkiler. Yedekleri aynı makinedeki diske değil ayrı bir depolamaya alın; Proxmox'un yerleşik yedekleme aracı uzak bir hedefe yazacak şekilde ayarlanabilir.

Karar ölçütü basit: Servisleriniz farklı işletim sistemi sürümleri, farklı ekipler ya da farklı müşteriler içinse sanallaştırın. Tek bir uygulama yığını çalıştırıyorsanız doğrudan işletim sistemi kurulumu daha az bakım ister.

Sık yapılan hatalar

• Çekirdek başına lisanslanan yazılımları unutmak. Windows Server Standard ve Datacenter, sunucudaki fiziksel çekirdek sayısına göre lisanslanır ve sunucu başına bir alt sınır vardır. SQL Server'ın çekirdek lisansı da benzer mantıkla çalışır. Çok çekirdekli bir fiziksel sunucu, küçük VPS'lerde ödediğiniz lisans tutarını beklenmedik biçimde artırabilir. Teklifi alırken lisansın nasıl hesaplandığını yazılı isteyin.
• Yedeksiz tek diskle başlamak. RAID olmayan tek diskli bir sunucu, ilk disk arızasında hem kesinti hem veri kaybı demektir.
• RAID'i yedek sanmak. Silme, bozulma ve fidye yazılımına karşı ayrı bir yerde, mümkünse değiştirilemez bir yedek gerekir.
• TTL'i geçiş günü düşürmek. Eski TTL süresi dolmadan yapılan değişiklik, bazı kullanıcıların saatlerce eski sunucuya gitmesine yol açar.
• Eski VPS'leri hemen kapatmak. Geri dönüş yolunu ortadan kaldırır.
• IPMI arayüzünü internete açık bırakmak. Uzaktan yönetim arayüzü sunucunun tam denetimini verir.
• Bant genişliğini kontrol etmemek. Bazı fiziksel sunucu tekliflerinde port hızı ve trafik kotası VPS'lerden farklı tanımlanır.

Sık sorulan sorular

Fiziksel sunucu kiralama her zaman bulut sunucudan ucuz mu?

Hayır. Kaynakları sürekli ve yüksek kullanan iş yüklerinde genellikle avantajlıdır. Yükü dalgalı olan, kısa süreli projeler yürüten ya da hızlı ölçeklenmesi gereken işlerde bulut daha uygun olabilir. Kararı bir haftalık ölçüm ve kalem kalem maliyet tablosuyla verin.

Geçiş sırasında site kaç dakika kapalı kalır?

Kesinti, son senkronizasyon ve DNS değişimi arasındaki süreye bağlıdır. TTL önceden düşürülmüş, dosyalar rsync ile önceden kopyalanmış ve veritabanı replikasyonla güncel tutulmuşsa kesinti yalnız son farkın aktarılması kadar sürer. Kesin bir süre, veri boyutunuz ve yazma yoğunluğunuzla belirlenir.

Fiziksel sunucuda donanım arızalanırsa ne olur?

Arızalı parçanın değişimi sağlayıcının sözleşmedeki müdahale süresine bağlıdır. Bu süre boyunca hizmetin ayakta kalması için RAID, yedekli güç kaynağı ve ayrı bir yerde tutulan yedek gerekir. Kesintiye hiç tahammülü olmayan sistemlerde ikinci bir sunucu ya da bulutta yedek ortam düşünülmelidir.

Tüm VPS'leri tek fiziksel sunucuya toplamak riskli değil mi?

Tek makine tek arıza noktasıdır, bu doğru. Riski RAID, ayrı yedek ve hızlı geri yükleme planıyla azaltırsınız. Kritik bir servisi bulut sunucu üzerinde bırakıp geri kalanını fiziksel sunucuya taşımak da dengeli bir seçenektir.

Bu işi hazır yapmak isterseniz

Ölçüm, sunucu seçimi ve taşıma adımlarını kendiniz yürütmek yerine hazır bir fiziksel sunucuyla başlamak isterseniz dedicated sunucu sayfasındaki lokasyon seçeneklerine bakabilirsiniz: İstanbul'da stok sınırlıdır, stok yoksa teklif hazırlanır; Almanya, Fransa, ABD ve Singapur da seçenekler arasındadır. Taşıma sürecini devretmek isterseniz taşıma hizmetinin koşullarını inceleyebilirsiniz.

Sonuç

Fiziksel sunucu kiralama, sürekli yük taşıyan ve birden çok VPS'e dağılmış iş yükleri için bulut faturasını kontrol altına almanın somut bir yoludur. Doğru sıra şudur: bir hafta ölçün, bütün kalemleri aynı tabloda toplayın, RAID, yedekli güç ve arıza müdahale süresini yazılı alın, ardından TTL düşürme, rsync ve replikasyonla kademeli taşıyın. Eski sunucuları geri dönüş yolu olarak bir süre açık tutun ve yedeğinizi geri yükleyerek doğrulamadan geçişi tamamlanmış saymayın.