VDS Sanal Sunucu Nedir? Mimari, Hipervizör ve

VDS (Virtual Dedicated Server, yani sanal adanmış sunucu) terimi son yıllarda hosting pazarında yaygınlaştıkça kafa karıştıran bir kavrama dönüştü. Bir taraftan sanal server diye konuşulan VPS ile çoğu zaman yan yana, hatta eşanlamlı kullanılıyor; diğer taraftan fiziksel sunucu ile karıştırılıp gereksiz yere abartılı bir ürün gibi pazarlanıyor. Bu rehber konuya teknik temelden başlayarak, hipervizör mimarisinden gerçek virsh komutlarına kadar uzanan eksiksiz bir resim çiziyor.

Yazıyı bitirdiğinizde şu sorulara net cevap verebileceksiniz: VDS bir hipervizör katmanında nasıl izolasyon sağlar, KVM ile VMware ESXi arasındaki seçim hangi yük tipinde hangi tarafa kaymalıdır, neden tek başına "4 vCPU 8 GB RAM" satırı bir VDS performansını anlatmaya yetmez ve hangi noktada VDS yerine bare-metal bir sunucuya geçmek mantıklıdır. Bütün örnekler 2026 sürüm araçlarıyla, gerçek üretim ortamlarından sadeleştirilerek alınmıştır.

İlgili rehberler: VPS ile VDS farkı ve VPS kiralama rehberi · Hosting türleri ve seçim rehberi · Linux sunucu yönetimi temelleri · VPS güvenlik sertleştirme · Nginx yapılandırma rehberi · DNS ayarları rehberi

VDS Sanal Sunucu Nedir? Sade Bir Tanım

VDS, fiziksel bir sunucunun donanım kaynaklarını sanallaştırma teknolojisi ile birden fazla bağımsız sanal makineye bölen ve bu sanal makinelerin her birine — paylaşımsız biçimde — sabit miktarda CPU, RAM, disk ve ağ kapasitesi tahsis eden bir hosting modelidir. Diğer adlandırmasıyla sanal server, virtual dedicated server ya da Türkçe literatürdeki bazı kaynakların kullandığı şekliyle sanal ithaflı sunucu, hepsi aynı kavrama atıfta bulunur.

Burada altı çizilmesi gereken kelime "paylaşımsız"dır. VDS'in pazarlama açısından VPS'ten ayrıştırılma çabası, kaynakların oversubscribe edilip edilmediği üzerinden kurulur. VPS sağlayıcılarının önemli bir kısmı, fiziksel sunucudaki toplam vCPU sayısını fiziksel core sayısının 3-5 katına satar; VDS ise teorik olarak 1:1 ya da 1:1.5 gibi düşük oranlarla, kaynağın belirli bir kısmının her zaman müşteriye ait olacağını taahhüt eder. Pratikte tüm sağlayıcılar bu kuralı aynı sıklıkla uygulamaz, bu yüzden satın alma sürecinde sözleşmedeki kaynak garantisi maddesi her zaman okunmalıdır.

Donanım perspektifinden bakıldığında bir VDS, üzerinde Linux KVM, VMware ESXi, Microsoft Hyper-V veya Xen gibi bir hipervizör çalışan fiziksel sunucu üzerindeki sanal makinelerden biridir. Sanal makinenin işletim sistemi (Debian, Ubuntu, AlmaLinux, Rocky, Windows Server, FreeBSD, vb.) tıpkı fiziksel bir sunucudaymış gibi kurulur ve yönetilir. Kullanıcı root/Administrator yetkisine sahiptir; kernel modülü yükleyebilir, iptables/nftables kuralları yazabilir, Docker veya Kubernetes kurabilir.

Sanallaştırmanın Tarihsel Kısa Hikayesi

Sanallaştırma fikri 1960'larda IBM'in CP-40 ve CP-67 sistemlerinde mainframe'leri çoklu kullanıcılara bölmek için doğdu. x86 mimarisi sanallaştırmayı uzun süre desteklemedi; 2003'te VMware ESX Server ile binary translation, 2005-2006'da Intel VT-x ve AMD-V ile donanım destekli sanallaştırma yaygınlaştı. KVM 2007'de Linux 2.6.20 kerneline girerek açık kaynak dünyasında sanallaştırmanın yapı taşlarından biri haline geldi.

VDS'in bugünkü ekonomisini mümkün kılan iki teknolojik kırılma noktası vardır: birincisi donanım destekli sanallaştırma (Intel VT-x, EPT; AMD-V, NPT), ikincisi SR-IOV ve virtio sayesinde paravirtualized I/O ile çıkartılan ağ ve disk overhead'i. Bu iki gelişme olmasaydı, VDS'in fiziksel sunucuya kıyasla taşıdığı performans cezası %30-50 mertebesinde kalır ve fiyat avantajı anlamını yitirirdi.

Hipervizör: VDS'in Kalbi

Hipervizör (hypervisor / VMM, Virtual Machine Monitor), bir fiziksel sunucu üzerinde birden fazla işletim sistemini eşzamanlı çalıştırmayı sağlayan yazılım katmanıdır. İki ana sınıfı vardır.

Type 1 (bare-metal): Doğrudan donanım üzerinde çalışır, host işletim sistemine ihtiyaç duymaz. VMware ESXi, Microsoft Hyper-V Server, Xen, Proxmox VE (KVM tabanlı) bu sınıfa girer. Production VDS sağlayıcılarının neredeyse tamamı Type 1 kullanır.
Type 2 (hosted): Mevcut bir işletim sistemi üzerinde uygulama olarak çalışır. VMware Workstation, Oracle VirtualBox, Parallels Desktop bu kategoridedir. Geliştirici ortamı için uygundur, üretimde tercih edilmez.

Linux dünyasında KVM (Kernel-based Virtual Machine) hibrit bir yapıya sahiptir: kernel modülü olarak yüklenir, ana sistem geleneksel anlamda host olarak kalır ama hipervizör sorumlulukları kernel'in kendisine düşer; bu sayede de facto Type 1 davranır. Çoğu Avrupa'lı VDS sağlayıcısı (Hetzner, OVH gibi) ile Türkiye'deki yerel sağlayıcıların büyük kısmı KVM tercih eder. Resmi belge için linux-kvm.org.

Hipervizör Tipleri Karşılaştırması

KVM + QEMU + libvirt: Açık kaynak, lisans yok, en geniş Linux ekosistem desteği. virtio sürücüleriyle near-native I/O performansı. Yönetim için libvirt, virsh, virt-manager, Cockpit, Proxmox.
VMware ESXi: Olgun, kararlı, vSphere ekosistemi içinde DRS, vMotion, FT gibi enterprise özellikler. Lisans maliyeti yüksektir, 2024 sonrası fiyatlama değişiklikleriyle pek çok sağlayıcı KVM'ye geçmektedir.
Microsoft Hyper-V: Windows Server'a entegre, Active Directory entegrasyonu, Live Migration, Replica. Windows ağırlıklı kurumsal ortamlar için doğal seçim.
Xen: Tarihsel olarak AWS EC2'nin temelini oluşturdu (2017'den itibaren AWS Nitro/KVM'ye geçti). Citrix Hypervisor ürününde hâlâ kullanılır.
Proxmox VE: Debian üzerinde KVM + LXC kombinasyonu sunan açık kaynak yönetim platformu. Web UI, küme yönetimi, Ceph entegrasyonu, ZFS desteği. Küçük/orta sağlayıcıların favorisi.

VDS Mimarisinin İçi: Kaynak İzolasyonu Nasıl Sağlanır?

VDS'in temel iddiası kaynak izolasyonudur. Bu izolasyon dört eksende çalışır: CPU, bellek, depolama ve ağ. Her bir eksenin altında farklı çekirdek/sanallaştırma mekanizmaları görev yapar.

CPU İzolasyonu ve vCPU Pinning

Hipervizör, fiziksel CPU çekirdeklerini sanal makinelere vCPU olarak sunar. KVM'de her vCPU, host kernel'inde bir thread olarak temsil edilir; Linux scheduler bu thread'leri fiziksel core'lara dağıtır. Düşük gecikmeli iş yükleri için CPU pinning uygulanır: belirli bir vCPU sabit bir fiziksel core'a bağlanır.

# libvirt domain XML üzerinden CPU pinning
virsh edit web-vds-01

# <vcpu placement='static'>4</vcpu>
# <cputune>
# <vcpupin vcpu='0' cpuset='2'/>
# <vcpupin vcpu='1' cpuset='3'/>
# <vcpupin vcpu='2' cpuset='4'/>
# <vcpupin vcpu='3' cpuset='5'/>
# <emulatorpin cpuset='2-5'/>
# </cputune>

# Çalışan VM'de pinning sorgulama
virsh vcpupin web-vds-01

# Numa topology gör
virsh capabilities | grep -A 30 '<topology'

NUMA (Non-Uniform Memory Access) farkındalığı yüksek yoğunluklu sunucularda kritiktir: vCPU'nun kullandığı fiziksel core ile RAM'in bulunduğu node aynı NUMA bölgesinde değilse, bellek erişimi 2-3x yavaşlar. Sağlayıcı tarafında bu, müşterinin göremediği ama performansı doğrudan etkileyen bir tuning katmanıdır.

Bellek İzolasyonu, EPT/NPT ve Ballooning

Donanım destekli sanallaştırmada Intel EPT (Extended Page Tables) ve AMD NPT (Nested Page Tables) sayesinde her sanal makine kendi sayfa tablosuna sahip olur ve memory translation overhead'i kabul edilebilir bir seviyede tutulur. Ballooning, host'un belleği kıt olduğunda guest'ten geri talep etmesine olanak tanır; ancak kararlı bir VDS profili için ballooning'in devre dışı bırakılması önerilir, çünkü beklenmedik bellek geri çağırma latency'leri uygulamayı kilitleyebilir.

<!-- libvirt domain XML — memory locking + ballooning kapatma -->
<memory unit='KiB'>16777216</memory>
<currentMemory unit='KiB'>16777216</currentMemory>
<memoryBacking>
 <hugepages/>
 <locked/>
 <nosharepages/>
</memoryBacking>
<devices>
 <memballoon model='none'/>
</devices>

Depolama: virtio-blk, virtio-scsi ve I/O Throttling

VDS sağlayıcıları depolama için iki ana yaklaşım kullanır: lokal NVMe (her hypervisor host'un kendi diskleri) veya merkezi depolama (Ceph, NetApp, EMC). Lokal NVMe daha düşük latency sağlar (50-150 µs) ama hipervizör arızasında iş sürekliliği zorlaşır; Ceph gibi distributed storage daha yüksek latency (1-3 ms) getirir ama live migration ve daha güçlü dayanıklılık sunar.

Performansı belirleyen ikinci ayar I/O throttling'dir. Sağlayıcı, bir VDS'in komşu sanal makineleri açlık çektirmemesi için IOPS ve bant genişliği sınırı koyar. Tipik ürün katalogu değerleri: 1.000-3.000 IOPS read/write per VDS, 100-300 MB/s throughput. Yüksek I/O gerektiren veritabanı yükleri için bu değerler dikkatle gözden geçirilmelidir.

# VDS içinden anlık IOPS ve latency ölçümü — fio
fio --name=randread --ioengine=libaio --iodepth=32 \
 --rw=randread --bs=4k --direct=1 --size=4G \
 --numjobs=4 --runtime=60 --group_reporting

# Sequential write — hugefile
fio --name=seqwrite --ioengine=libaio --iodepth=16 \
 --rw=write --bs=1M --direct=1 --size=8G \
 --runtime=60 --group_reporting

# Latency dağılımı
fio --name=latprofile --ioengine=libaio --iodepth=1 \
 --rw=randread --bs=4k --direct=1 --size=2G \
 --runtime=30 --percentile_list=50:90:95:99:99.9

Ağ: virtio-net, OVS ve SR-IOV

Sanal makinenin ağ adaptörü genellikle virtio-net ile sunulur — paravirtualized bir sürücü, Linux'da virtio_net modülü olarak bilinir. Hipervizör tarafında bridge (Linux bridge, macvtap) veya Open vSwitch ile fiziksel arabirimlere bağlanır. Yüksek paket-per-saniye gerektiren senaryolarda SR-IOV kullanılır: fiziksel NIC'in donanımsal olarak alt arabirimlere bölünmesi sayesinde guest, hypervisor'u atlar ve neredeyse bare-metal performansı yakalar.

Modern VDS sağlayıcılarında özel ağ tarafında da iki katman vardır: birincisi public IP ve internet bağlantısı (genellikle 100 Mbps - 10 Gbps arası bir port), ikincisi private VLAN/VXLAN ile aynı müşterinin diğer sunucularına özel ağ ("vRack", "private network" gibi adlarla anılır).

VDS, VPS ve Dedicated Server: Net Karşılaştırma

Türkiye pazarında bu üç ürün arasındaki sınırlar zaman zaman bulanıklaşır. Aşağıdaki ayrımı pazarlama söyleminden bağımsız, teknik gerçek üzerinden okuyun. Ek detay için VPS Nedir? VPS ile VDS Farkı yazımıza ve Hosting Türleri rehberine göz atabilirsiniz.

Shared Hosting: Tek bir Linux/Windows üzerinde yüzlerce müşterinin aynı kernel'i ve aynı web sunucusunu paylaşması. cPanel/Plesk panel ile yönetilir, root yok. Aylık 30-150 TL bandında, statik veya küçük WordPress siteleri için yeterli.
VPS (Virtual Private Server): Hipervizör tabanlı sanal makine. Genellikle kaynak overcommit'i ile, vCPU/RAM birden fazla müşteriye "paylaşılarak" satılır. Gerçek tüketim sınırlı kalırsa kimse fark etmez; tepe yüklerde "noisy neighbor" etkisi gözlenir.
VDS (Virtual Dedicated Server): Hipervizör tabanlı sanal makine. Kaynaklar iddia edilen düzeyde overcommit edilmez; vCPU bir fiziksel core'a sıkça pin edilir, RAM ballooning kapalıdır. "VPS gibi sanal, ama dedicated hissi veren" konumlandırma.
Dedicated Server (bare-metal): Tüm fiziksel sunucu tek müşteriye ait. Hipervizör katmanı yok ya da müşteri kendi kuruyor. Maximum performans, maximum sorumluluk. Aylık ~50-300 € bandında entry-level Avrupa'da, 10K-50K TL bandında Türkiye'de yerel veri merkezlerinde.

Maliyet Modeli: VDS Aylık Ne Kadar Tutar?

VDS fiyatlandırması donanım, lokasyon ve sağlayıcı operasyon modeline göre büyük dalgalanma gösterir. Aşağıdaki rakamlar 2026 ortalamalarıdır, yaklaşık ve sağlayıcıya göre değişir. KDV ve trafik aşımı ücretleri hariçtir.

Entry (2 vCPU, 4 GB RAM, 50-80 GB NVMe): Yurtdışı 4-8 € / ay, Türkiye 200-400 TL / ay. Küçük WordPress, blog, CRM, dev/test ortamı.
Standard (4 vCPU, 8 GB RAM, 160-240 GB NVMe): Yurtdışı 12-20 € / ay, Türkiye 500-900 TL / ay. Orta ölçek e-ticaret, çok siteli kurumsal, geliştirme + staging.
Performance (8 vCPU, 16-32 GB RAM, 320-500 GB NVMe): Yurtdışı 30-50 € / ay, Türkiye 1.500-3.500 TL / ay. Yüksek trafikli e-ticaret, oyun sunucusu, yoğun PostgreSQL/MySQL.
Enterprise (16+ vCPU, 64+ GB RAM, 1 TB+ NVMe): Yurtdışı 80-200 € / ay, Türkiye 4.000-12.000 TL / ay. SaaS uygulama backend'i, kümeleme, mikroservis cluster head node, video transkode.

Bu rakamların üstüne eklenmesi muhtemel kalemler: yedekleme (R1 snapshot 1-3 € / ay; harici backup 0,01-0,03 € / GB), ek IPv4 (giderek artıyor — 2026 başında 1-3 € / ay başına IP), DDoS koruma (basic genelde dahil; advanced 5-30 € / ay), yönetilen hizmet (managed VDS sertleştirme + güncelleme + monitoring 20-100 € / ay arası, sağlayıcıya göre).

VDS ile Neler Yapılabilir? Gerçek Senaryolar

VDS, root/Administrator yetkisi sayesinde lisanslı yazılım ihtiyacı olmayan hemen her sunucu yükünü karşılayabilir. Aşağıda en sık karşılaştığımız 12 senaryoyu, gereksinim profilleriyle birlikte sıraladık.

1. Web Sitesi ve E-Ticaret Sunucusu

WordPress, Magento, OpenCart, PrestaShop, WooCommerce gibi platformlar için VDS ideal başlangıç noktasıdır. Tipik bir orta ölçek WooCommerce sitesi için 4 vCPU + 8 GB RAM + 80 GB NVMe profili çoğu zaman yeterlidir. Üzerine LSCache veya Nginx FastCGI cache, MariaDB tuning ve PHP opcache kombinasyonuyla saniyede 50-100 dinamik istek rahatça karşılanır.

2. Veritabanı Sunucusu

PostgreSQL, MySQL/MariaDB, MongoDB, Redis için ayrılmış bir VDS, web sunucusunu rahatlatmanın en etkili yoludur. Veritabanı VDS'inde RAM önceliklendirilir; shared_buffers (PostgreSQL) ya da innodb_buffer_pool_size (MySQL) RAM'in %50-70'ine kurulur. Detay için PostgreSQL Performans Optimizasyonu, MySQL vs PostgreSQL ve Redis Nedir, Nasıl Kullanılır.

3. Uygulama / API Sunucusu

Node.js, Python (Django, FastAPI), Go, Java/Spring Boot,.NET uygulamaları için VDS, container orkestrasyonuna geçmeden önce çoğu projenin doğal evi. PM2 cluster mode ile her vCPU'ya bir worker, Nginx reverse proxy önünde TLS sonlandırma ve rate limiting kombinasyonu temel şablondur.

# /etc/nginx/sites-available/api.example.com
upstream api_backend {
 least_conn;
 server 127.0.0.1:3000 max_fails=2 fail_timeout=10s;
 server 127.0.0.1:3001 max_fails=2 fail_timeout=10s;
 server 127.0.0.1:3002 max_fails=2 fail_timeout=10s;
 server 127.0.0.1:3003 max_fails=2 fail_timeout=10s;
 keepalive 64;
}

limit_req_zone $binary_remote_addr zone=api_rl:10m rate=20r/s;

server {
 listen 443 ssl http2;
 listen 443 quic reuseport;
 server_name api.example.com;

 ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;

 location / {
 limit_req zone=api_rl burst=40 nodelay;
 proxy_pass http://api_backend;
 proxy_http_version 1.1;
 proxy_set_header Connection "";
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_read_timeout 30s;
 }
}

4. Oyun Sunucusu

Minecraft, CS2, Rust, ARK, Valheim, Garry's Mod gibi oyunlar için VDS yaygın bir tercih. Burada CPU saat hızı (3.5 GHz+) ve düşük ağ jitter'ı kritik; vCPU sayısından çok tek thread performansı önemlidir. Pek çok oyun sunucusu hâlâ tek-thread sıkı döngüye dayanır. RAM 8-32 GB bandında, disk için NVMe şart, TCP/UDP için public IP ve düşük latency'li route gerekli.

5. Mail Sunucusu

Postfix + Dovecot + Rspamd + DKIM/SPF/DMARC kombinasyonu için VDS uygundur, ancak IPv4 reputation meselesi vardır: yeni IP'ler büyük postacılar tarafından şüpheyle karşılanır. Sağlayıcı seçerken IP'nin daha önce spam göndermediğine dair garanti aramak ve Spamhaus ile multirbl.valli.org üzerinden kontrol etmek önemlidir.

6. VPN / WireGuard / OpenVPN Sunucusu

Kurumsal uzaktan erişim ya da kişisel gizlilik için WireGuard tek başına 1 vCPU + 1 GB RAM ile yüzlerce eşzamanlı tüneli taşır. Sertifika tabanlı OpenVPN benzeri yüklerde mTLS doğrulaması CPU'yu daha çok yorar. Self-hosted VPN tercih edenlerin VDS'i bu amaçla seçmesi yaygındır.

7. CI/CD Runner ve Build Server

GitHub Actions self-hosted runner, GitLab Runner, Jenkins agent, Drone runner için VDS ekonomiktir. Build I/O ağırlıklı olduğu için NVMe disk şart; bellek 8-16 GB Java/Node tarafında, 4-8 GB Go/Rust tarafında yeterli olur. GitHub Actions CI/CD rehberi entegrasyonu için iyi bir başlangıç.

8. Container ve Kubernetes Worker Node

Docker, Docker Compose ve Kubernetes ile uygulama deploy etmek için VDS doğal bir altyapıdır. Tek host Docker Compose'tan k3s/k0s mikro Kubernetes'e ve oradan multi-node cluster'a geçiş, hep aynı VDS'leri kullanarak yapılabilir.

9. İzleme ve Log Toplama

Prometheus + Grafana, ELK / Loki stack'leri için ayrı bir VDS, üretim sistemini bozmadan izlemenin standart yoludur. Disk burada en kritik kaynak: 30 günlük log retention için 100-500 GB NVMe rahat tüketilir.

10. Yedekleme Hedefi

Restic, BorgBackup, Duplicacy ile şifreli yedekleri tutmak için VDS uygun maliyetli bir hedeftir — ana sunucudan farklı bir veri merkezinde olması koşuluyla. 3-2-1 yedek kuralı burada uygulanır.

11. Geliştirme ve Test Ortamı

Production ortamından izole bir staging/dev VDS, takım için altın değerindedir. Üretimle aynı işletim sistemi, aynı paketler, aynı sürümler — sadece daha düşük kapasiteyle. Pull request başına geçici staging VDS ayağa kaldıran iş akışları, modern DevOps pratiklerinin kalbini oluşturur.

12. Mikro SaaS / Yan Proje

Tek geliştirici tarafından yönetilen, ayda birkaç bin ziyaretçi alan SaaS uygulamaları için bir VDS yeterlidir. Pek çok başarılı bootstrap edilmiş ürün, ilk birkaç bin müşteriye tek VDS üzerinden hizmet vermiştir. Erken aşamada mikroservis ya da çok bölgeli mimari kurmak prematüre optimizasyondur.

VDS Üzerinde İlk Saat: Sıfırdan Hazırlık

Yeni bir VDS aldığınızda ilk 60 dakika, sunucunun bir sonraki yıl boyunca güvenli ve ölçülebilir olmasını belirler. Burada Linux (Debian 12 / Ubuntu 24.04 / AlmaLinux 9) varsayımıyla minimum standart bir kurulum şablonu paylaşıyoruz. Detaylı sertleştirme için VPS güvenlik sertleştirme rehberini incelemenizi öneririz.

Adım 1: Sistem Güncellemesi ve Temel Paketler

# Debian/Ubuntu
apt update && apt -y full-upgrade
apt -y install ufw fail2ban htop tmux curl wget git \
 unattended-upgrades vim ca-certificates \
 gnupg lsb-release rsync chrony

# AlmaLinux/Rocky
dnf -y update
dnf -y install epel-release
dnf -y install firewalld fail2ban htop tmux curl git \
 vim ca-certificates rsync chrony

Adım 2: SSH Sertleştirme

# /etc/ssh/sshd_config.d/00-hardening.conf
Port 22 # mümkünse 2200 gibi alternatif port + ufw kuralı
Protocol 2
PermitRootLogin prohibit-password
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2
AllowUsers admin deploy
AllowGroups ssh-users
X11Forwarding no
UseDNS no

# Yeni admin kullanıcı
adduser admin
usermod -aG sudo admin # Debian/Ubuntu
usermod -aG wheel admin # RHEL ailesi
mkdir -p /home/admin/.ssh
chmod 700 /home/admin/.ssh
# anahtar yapıştır
vim /home/admin/.ssh/authorized_keys
chmod 600 /home/admin/.ssh/authorized_keys
chown -R admin:admin /home/admin/.ssh

systemctl restart ssh # veya sshd

Adım 3: Güvenlik Duvarı

# UFW (Debian/Ubuntu)
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 443/udp # HTTP/3 / QUIC
ufw enable
ufw status verbose

# firewalld (RHEL ailesi)
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --permanent --add-port=443/udp
firewall-cmd --reload

Adım 4: Otomatik Güvenlik Güncellemeleri

# Debian/Ubuntu
dpkg-reconfigure --priority=low unattended-upgrades

# AlmaLinux/Rocky
dnf -y install dnf-automatic
systemctl enable --now dnf-automatic.timer

# Sadece security güncellemelerini otomatik kurmak için
# /etc/dnf/automatic.conf
# upgrade_type = security
# apply_updates = yes

Adım 5: Zaman Senkronizasyonu ve Hostname

timedatectl set-timezone Europe/Istanbul
timedatectl set-ntp true
timedatectl status

# Anlamlı bir hostname ver
hostnamectl set-hostname web01.ornek.local
echo '127.0.1.1 web01.ornek.local web01' >> /etc/hosts

Performans Ölçümü: VDS'iniz Söz Verileni Yapıyor mu?

Sağlayıcı 4 vCPU 8 GB RAM yazıyor; iyi de bunu nasıl doğrularsınız? Tek bir benchmark hiçbir zaman yetmez; CPU, bellek, disk, ağ ayrı ayrı ölçülmeli ve sonuçlar saklanıp zaman içinde karşılaştırılmalıdır. Aşağıdaki test seti standart referansımızdır.

CPU Benchmark

# sysbench — CPU prime hesaplama
apt -y install sysbench

# Tek thread
sysbench cpu --cpu-max-prime=20000 --threads=1 run

# Tüm vCPU'lar
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) --time=60 run

# 7zip benchmark — gerçek dünyaya yakın MIPS
apt -y install p7zip-full
7z b -mmt$(nproc) -md22

# Geekbench tarzı CPU mini-test
apt -y install stress-ng
stress-ng --cpu $(nproc) --cpu-method matrixprod --metrics --timeout 60s

Önemli not: VDS sağlayıcılarının paylaşılan altyapı havuzlarında, host'un genel yükü saatten saate değişebilir. Aynı testi farklı saatlerde 3-5 kez tekrar edip medyanını alın; tek bir veri noktası yanıltıcıdır.

Bellek Benchmark

# stream — gerçek bellek bant genişliği
apt -y install stream
stream

# sysbench memory
sysbench memory --memory-block-size=1M --memory-total-size=64G \
 --threads=$(nproc) run

# /proc/meminfo özeti
grep -E 'MemTotal|MemFree|MemAvailable|Buffers|Cached|Swap' /proc/meminfo

Disk Benchmark — fio Ana Senaryo Seti

# 4K random read — OLTP veritabanı simülasyonu
fio --name=oltp-read --rw=randread --bs=4k --size=4G \
 --numjobs=4 --iodepth=32 --direct=1 \
 --ioengine=libaio --runtime=60 --time_based \
 --group_reporting

# 4K random write — log/journal simülasyonu
fio --name=oltp-write --rw=randwrite --bs=4k --size=4G \
 --numjobs=4 --iodepth=32 --direct=1 \
 --ioengine=libaio --runtime=60 --time_based \
 --group_reporting --fsync_on_close=1

# 1M sequential read — yedek/restore simülasyonu
fio --name=seq-read --rw=read --bs=1M --size=8G \
 --numjobs=1 --iodepth=16 --direct=1 \
 --ioengine=libaio --runtime=60 --time_based

# Karışık 70/30 random — web sunucusu profili
fio --name=mixed --rw=randrw --rwmixread=70 --bs=8k \
 --size=4G --numjobs=4 --iodepth=16 --direct=1 \
 --ioengine=libaio --runtime=60 --time_based \
 --group_reporting

Ağ Benchmark

# Latency — ping (round-trip)
ping -c 100 -W 2 8.8.8.8 | tail -2
ping -c 100 -W 2 cloudflare.com | tail -2

# iperf3 — bant genişliği
apt -y install iperf3
# uzak bir iperf3 sunucusuna karşı (örn. speedtest sunucusu)
iperf3 -c iperf.he.net -p 5201 -t 30 -P 4
iperf3 -c iperf.he.net -p 5201 -t 30 -R # ters yön

# mtr — yol kalitesi + paket kaybı
apt -y install mtr-tiny
mtr -rwz -c 50 cloudflare.com

Beklenen değerler kabaca: 1 Gbps portta iperf3 ile 850-940 Mbps, 10 Gbps portta 5-9 Gbps. Latency Türkiye içi tipik veri merkezleri arası 5-25 ms, Türkiye-Frankfurt 35-50 ms, Türkiye-ABD doğu 100-130 ms, Türkiye-Asya 180-250 ms. Bu değerlerin çok dışında sonuçlar route problemine işaret eder.

Güvenlik: VDS Sahibinin Birinci Sınıf Sorumluluğu

Shared hosting'te sağlayıcı kernel'i, web sunucusunu, PHP'yi sertleştirir; VDS'te ise tüm sorumluluk size geçer. Saldırı yüzeyini küçük tutmanın altın kuralları, deneyim biriktikçe netleşir. Daha derin tartışma için VPS güvenlik sertleştirme, OWASP Top 10 2026, Fail2ban ve DDoS koruma rehberlerimizi öneririz.

Az servis, az açık: Sadece gerçekten gerekli daemon'lar (nginx, php-fpm, mariadb) çalışsın. systemctl list-unit-files --state=enabled ile envanterinizi belirli aralıklarla denetleyin.
SSH'i şifresiz, anahtar bazlı, AllowUsers ile kısıtlı tutun: Şifre ile SSH 2026'da kabul edilebilir bir profil değil.
Fail2ban: SSH, Postfix-SASL, Nginx, Dovecot için aktif jail'ler. 5 başarısız girişte 1 saat blok, kademeli artışla 24 saat.
Güvenlik duvarı varsayılanı DENY: ufw/firewalld/nftables hepsinde aynı kural — gereken portu açıp diğerini kapatın.
Otomatik güvenlik güncellemeleri: Kernel hariç security paketleri otomatik kurulsun; kernel için manuel reboot pencereniz olsun.
Düzenli yedek + restore testi: Yedek var demek yetmez; ayda bir gerçek restore tatbikatı yapılmalı.
Log gözetimi: journalctl, auth.log, nginx access/error her gün otomatik özetlenip e-postaya/Slack'e düşürülmeli.
Servis-bazlı user: Hiçbir uygulama root ile çalışmamalı. nginx, php-fpm, postgres kendi kullanıcılarına ait.

nftables ile Modern Firewall

# /etc/nftables.conf — minimal, modern, IPv4+IPv6
flush ruleset

table inet filter {
 set ssh_throttle {
 type ipv4_addr
 flags dynamic, timeout
 timeout 1m
 }

 chain input {
 type filter hook input priority 0; policy drop;

 ct state established,related accept
 iif lo accept

 # ICMP — IPv4 + IPv6
 ip protocol icmp icmp type echo-request \
 limit rate 10/second accept
 ip6 nexthdr icmpv6 icmpv6 type { nd-router-advert, \
 nd-neighbor-solicit, nd-neighbor-advert, \
 echo-request } accept

 # SSH — rate limit
 tcp dport 22 ct state new \
 add @ssh_throttle { ip saddr limit rate 5/minute } accept

 # Web
 tcp dport { 80, 443 } accept
 udp dport 443 accept # QUIC / HTTP/3

 log prefix "nft drop: " limit rate 5/minute
 reject with icmpx type port-unreachable
 }

 chain forward { type filter hook forward priority 0; policy drop; }
 chain output { type filter hook output priority 0; policy accept; }
}

Yedekleme Stratejisi: VDS Tek Kopya Değil

Sağlayıcının panelinde sunulan snapshot'lar genellikle aynı veri merkezindeki bir SAN üzerinde tutulur. Bu, hipervizör çökmesi gibi olaylarda kurtarmaya yarar — ama veri merkezi seviyesindeki bir yangın, düzenleyici el koyma ya da hesabın kapanması gibi senaryolarda yetersiz kalır. 3-2-1 yedek kuralı burada da geçerlidir: 3 kopya, 2 farklı medya, 1 kopya offsite.

# Restic ile şifreli, sıkıştırılmış, dedup edilmiş offsite yedek
apt -y install restic
export RESTIC_REPOSITORY="s3:s3.eu-central-1.amazonaws.com/markaadi-backup"
export RESTIC_PASSWORD_FILE="/root/.restic-passwd"
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."

restic init # ilk seferde

# Web kökü + DB dump'lar + /etc + crontab
restic backup \
 --tag daily \
 --exclude='/var/www/*/cache' \
 /var/www \
 /var/backups/db \
 /etc \
 /root

# Politika: 7 günlük, 4 haftalık, 12 aylık
restic forget --prune \
 --keep-daily 7 --keep-weekly 4 --keep-monthly 12 \
 --keep-yearly 3

Veritabanı yedeklemesinde dosya sistemi snapshot'ı yetmez; tablo açıkken alınan kopya bozuk olur. PostgreSQL için pg_basebackup + WAL arşivlemesi (PITR), MySQL/MariaDB için mariabackup ya da Percona XtraBackup kullanılır. Detay: PostgreSQL performans optimizasyonu.

İzleme: Görmediğiniz Sorunu Çözemezsiniz

Bir VDS'i "sahip olmak" onu izlemekle gerçek olur. Minimum izleme katmanı şunları içerir: dış uptime kontrolü (HTTP, DNS, SSL expiry), system metrics (CPU, RAM, disk, network), application metrics (response time, error rate, queue length), log toplama (auth, web, app).

Uptime: UptimeRobot, BetterStack, StatusCake — 1 dakika frekans, 3+ bölgeden kontrol, sertifika ve içerik eşleşme doğrulaması.
System metrics: Prometheus + Grafana + node_exporter, ya da Netdata Cloud. Disk %85 dolunca, swap %20 üzerine çıkınca, load 5 dakika boyunca core sayısının iki katını aşınca alarm.
Logs: Loki + Promtail veya ELK; ELK için ELK rehberi.
APM: OpenTelemetry, Sentry, Datadog APM — slow transaction trace, exception correlation.
SLO/Error budget: Aylık %99.9 hedef → ~43 dakika downtime tolerans. Bu pencere dolduğunda yeni özellik geliştirmesi durur, stabilite öncelik kazanır.

Ölçeklendirme: VDS Ne Zaman Yetmez Olur?

Doğru profilli bir VDS pek çok projeyi yıllarca taşır. Ama büyüme geldiğinde dikey/yatay ölçeklendirme arasındaki seçim önemli olur.

Dikey (vertical scale-up): Aynı VDS'in vCPU/RAM/disk'ini büyütmek. En basit yol, 5-10 dakikalık reboot ile gerçekleşir. Genellikle 32-64 GB RAM seviyesine kadar mantıklı.
Yatay (horizontal scale-out): Birden fazla VDS'i load balancer arkasında çalıştırmak. Stateful uygulamalarda session'ı Redis'e veya sticky-session moduna almak gerekir.
DB ayrıştırma: Tek VDS üzerindeki uygulama + veritabanı ikilisini, web VDS + DB VDS olarak ikiye bölmek. RAM uzun ömürlü kazançlar getirir.
Read replica: Read-heavy uygulamalarda PostgreSQL streaming replication, MySQL async replication ile okuma yükünü dağıtmak.
CDN ekleme: Cloudflare, Bunny, Fastly ile statik içeriği edge'e taşımak — origin yükünü %50-90 azaltır.
Bare-metal'e geçiş: Tek bir VDS'e 16+ vCPU + 64+ GB RAM gerektiğinde, fiyat-performans hesabı genelde bare-metal lehine döner.

Lokasyon Seçimi: Türkiye Mi, Yurtdışı Mı?

Hedef kitleniz Türkiye'deyse, ana yığını Türkiye veri merkezinde tutmak round-trip latency'i 5-25 ms bandında tutar — kullanıcı deneyimi için önemli bir kazanım. Hedef kitleniz çok ülkelere yayılmışsa, Frankfurt veya Amsterdam gibi merkezi Avrupa lokasyonları + bir CDN katmanı genellikle daha iyi sonuç verir.

Yasal boyutta KVKK'ya tabi kişisel veri, Türkiye'de işlenen verinin yurt dışına aktarımında dikkat edilmesi gereken kurallar getirir. Sağlık, finans, kamu sözleşmeli işler için yerel veri merkezi neredeyse zorunluluktur. Bu kararı baştan vermek, sonradan veri taşıma maliyetinden korur.

Sağlayıcı Seçim Kriterleri

VDS pazarı çok rekabetçi. Türkiye'deki yerel sağlayıcılar (Turhost, Natro, GuzelHosting, Hosting.com.tr, Doruk Net, Sadece Hosting, Vargonen vb.) ile global sağlayıcılar (Hetzner, OVH, Contabo, DigitalOcean, Vultr, Linode/Akamai, Upcloud) farklı avantajlar sunar. Bir tarafı diğerine "genel olarak" üstün ilan etmek doğru olmaz; karar değişkenleri şunlardır.

Lokasyon: Hedef kitle nerede? Türkiye, Avrupa, ABD, Asya?
Donanım nesli: Intel Xeon Scalable hangi nesil? AMD EPYC Milan/Genoa? NVMe doğrudan mı, yoksa SAN üzerinden mi?
Ağ kapasitesi: 1 Gbps mi, 10 Gbps mi? Aylık trafik kotası nedir? Aşımda ne ücretlendirilir?
SLA: %99.9 mu, %99.95 mi? Tazminat şartı net yazılı mı?
DDoS koruma: Dahil mi, ek mi? Hangi seviyede (L3/4 mi, L7 mi)?
Yedekleme: Snapshot dahil mi? Geri yükleme süreleri?
API ve otomasyon: Terraform provider var mı? CLI'sı düzgün çalışıyor mu?
Destek: 7/24 mü, hafta içi mesai mi? Türkçe destek var mı?
Sözleşme şeffaflığı: Kaynak garantisi yazılı mı? Oversubscribe oranı belirtilmiş mi?
Faturalandırma: Saatlik mi, aylık mı? KDV dahil mi?

Yönetilen (Managed) VDS: Ne Zaman Mantıklı?

Managed VDS, sağlayıcının işletim sistemi kurulumu, sertleştirme, güncelleme, izleme ve temel sorun giderme işlemlerini üstlendiği bir hizmet katmanıdır. Her zaman mantıklı değildir — eğer ekibinizde Linux deneyimli bir SysAdmin/DevOps varsa, managed maliyetinin marjinal faydası düşük kalır. Aşağıdaki durumlarda managed lehine eğilim artar:

Şirket içinde Linux uzmanlığı yok ve eklemek pahalı.
Uygulama 7/24 ayakta kalmalı; gece 03:00'te kalkıp güncelleme yapmak istemiyorsunuz.
Mevzuat gereği belirli sertleştirme standartları (CIS, ISO 27001) belgelenmeli.
Sektör hassas: ödeme, sağlık, finans.
Geliştirme ekibi büyüktür ama altyapı tarafına vakit ayıramaz.

Sık Sorulan Sorular

VDS ile VPS aynı şey midir?

Teknik olarak ikisi de "hipervizör üzerinde sanal makine"dir — yani aynı altyapı kategorisi. Ayrım pazarlama tarafındadır: VDS, kaynak garantisinin daha sıkı tutulduğu, oversubscribe edilmediği iddia edilen üst segment ürün. Pratikte hangisinin gerçekten ne sunduğunu görmek için ürün sayfasındaki teknik özellikler ve sözleşmedeki kaynak maddesine bakmak gerekir.

Sanal sunucu fiziksel sunucudan ne kadar yavaştır?

Modern donanım destekli sanallaştırmada CPU overhead'i %2-5 bandında, virtio sürücüleriyle disk ve ağ overhead'i %3-10 bandındadır. Ölçülebilir ama uygulamada nadiren hissedilir. Asıl fark komşu etkisinden gelir: paylaşılan host'ta diğer guestler agresif yük üretirse, sanal makinenin gözlemlenen performansı oynar — bare-metal'de bu sorun yoktur.

Sanal server üzerinde Windows kurulabilir mi?

Evet. KVM, VMware ESXi ve Hyper-V'nin tamamı Windows Server 2019 / 2022 / 2025 ve Windows 10/11 desteğine sahiptir. Lisansı ayrıca temin etmeniz gerekir — sağlayıcı kiralama paketi sunabilir ya da kendi MAK/KMS lisansınızı kullanabilirsiniz.

Bir VDS aynı anda kaç eşzamanlı kullanıcıyı karşılayabilir?

Bu soru tek bir cevabı olmayan klasik. "Eşzamanlı kullanıcı" tanımı bile değişken. Statik HTML için 4 vCPU 8 GB RAM bir VDS saniyede on binlerce isteği karşılayabilir; ağır WooCommerce checkout için aynı VDS'te tepe yükü dakikada 200-500 işlem civarındadır. Doğru cevap her zaman kendi uygulamanızı sentetik yükle ölçmektir — k6, Apache Bench, wrk, Locust ile.

VDS'imin RAM'i sürekli %95 dolu görünüyor, sorun mu?

Linux'ta boş RAM kullanılmayan RAM'dir — kernel disk önbelleği için kullanır. free -h çıktısında available sütununa bakın; used değil. Available yüksekse sistem sağlıklıdır. Detay: linuxatemyram.com.

Sağlayıcı snapshot yedeklerine güvenebilir miyim?

Tek başına hayır. Snapshot, sağlayıcı altyapısının bir parçasıdır; hesabınız kapansa, sağlayıcı iflas etse veya bölge çöküşü yaşansa beraber gider. Off-site, sağlayıcıdan bağımsız bir yedek katmanı şarttır.

Tipik Hatalar ve Bunlardan Kaçınma

Root ile direkt SSH: PermitRootLogin no + sudo'lu kullanıcı standart olmalı.
Yedek var sanmak: 6 ay yedek almışsınız ama hiç restore denememişsiniz — yedek yok demektir.
Servis sayısının kontrolden çıkması: Aynı VDS'e 12 farklı uygulama. Her biri başka bir saldırı vektörü. Tek bir uygulama, bir lifecycle.
Disk dolması alarmsız: Disk %95 dolduğunda log servisleri yazamaz, MySQL kilitlenir. Disk %80'de uyarı, %90'da kritik alarm.
OS sürümü EOL: Ubuntu 18.04 ya da CentOS 7 hâlâ çalışıyor olabilir; ama EOL = güvenlik patch yok = saldırıya açık.
Aynı zayıf root şifresi: Şifre kullanmayın derdik, ama eğer mecburen kullandıysanız her sunucuda farklı, password manager'da saklı.
Public S3 / nginx autoindex: Yedek dosyalarını yanlışlıkla public yere koymak, klasik veri sızıntısı sebebi.
Cron scriptlerin output'u kaybolması: Cron çıktısı root mailbox'a düşer, root mailbox kimse okumaz. Output'u syslog'a veya alarm sistemine yönlendirin.
İmaj hijack: docker pull alpine diye başlayan ama tag belirtilmeyen production iş akışları, bir sonraki Alpine major sürümünde patlar. Tag pin'leyin.
Kernel update sonrası reboot ertelemek: Live patch yoksa kernel update reboot gerektirir. Aylarca ertelenmiş kritik güncellemeler birikir.

Container ve Mikroservis Çağında VDS'in Yeri

"Herkes Kubernetes'e geçti" söylemi medyada yaygın olsa da, gerçek pazarda halen küçük-orta ölçek projelerin çoğu tek VDS ya da küçük bir Docker Compose kümesi üzerinde verimli şekilde yaşar. Mikroservise erken geçmek operasyonel maliyeti artırır; monolitik bir uygulamayı düzgün yapılandırılmış tek bir VDS'te tutmak çoğu zaman daha hızlı, daha ucuz ve daha az hata yüzeyli olur.

Kubernetes'e geçiş için doğal sinyaller şunlardır: 5+ servis, çoklu takımın ayrı deployment cycle'ı, otomatik horizontal scaling ihtiyacı, çok-bölgeli aktif-aktif setup. Bu sinyaller olmadan k8s genellikle prematüre optimizasyondur. Detay için Kubernetes temelleri.

VDS'i Otomatize Etmek: Terraform + Cloud-init

Manuel kurulan sunucu kar topu gibi büyür: kim ne yaptı, hangi paket nereden geldi, bir sonraki sunucuyu nasıl aynı yapacağız bilinemez. Infrastructure-as-Code bu kaosu çözer. Terraform ile VDS provision'lanır, Ansible veya cloud-init ile içi doldurulur.

# /etc/cloud/cloud.cfg.d/99-markaadi.cfg — ilk açılışta uygulanır
hostname: web01
fqdn: web01.ornek.local

users:
 - name: admin
 sudo: ALL=(ALL) NOPASSWD:ALL
 groups: sudo
 shell: /bin/bash
 ssh_authorized_keys:
 - ssh-ed25519 AAAA... admin@laptop

package_update: true
package_upgrade: true
packages:
 - ufw
 - fail2ban
 - chrony
 - unattended-upgrades
 - curl
 - vim
 - git

runcmd:
 - sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
 - sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
 - systemctl restart ssh
 - ufw default deny incoming
 - ufw default allow outgoing
 - ufw allow 22/tcp
 - ufw allow 80/tcp
 - ufw allow 443/tcp
 - ufw allow 443/udp
 - ufw --force enable
 - timedatectl set-timezone Europe/Istanbul

VDS'in Geleceği: Cloud, Edge, Sanallaştırma 2.0

Sanallaştırma teknolojisi de evrimini sürdürüyor. Üç eğilim öne çıkıyor: microVM (Firecracker, Cloud Hypervisor — saniyenin altında başlatma süresi, FaaS workloadı), confidential computing (AMD SEV, Intel TDX — VM belleği host'tan bile şifreli), ve edge computing (CDN POP'larında çalışan light VDS — kullanıcıya 10-30 ms uzaklıkta hesaplama).

Geleneksel VDS bu yeniliklerin gölgesinde değil; aksine üzerine eklenen yeni katmanlar olarak konumlanıyor. Çoğu uygulama için temel hesaplama birimi hâlâ bir KVM sanal makinesidir; bunun adına ister VPS, ister VDS, ister cloud instance deyin, mimari aynıdır.

Karar Verme Pratiği: 60 Saniyede Doğru VDS

Hızlı bir öz-değerlendirme şablonu. Aşağıdaki sorulara cevaplarınız VDS profilinizi belirler.

Hedef kullanıcı kitlem nerede? → Türkiye ağırlıklı: Türkiye DC. Avrupa: Frankfurt/Amsterdam. Çoklu: edge + CDN.
Uygulamam CPU mu, RAM mi, IO mu yoğun? → CPU yoğun: yüksek frekanslı vCPU + tek-thread perf. RAM yoğun: 16+ GB ile başla. IO: NVMe + yüksek IOPS sınırı.
Aylık trafik beklentim? → 1 TB altı: standart paket. 1-10 TB: trafik kotası kontrolü. 10 TB üstü: bant genişliği unmetered seçeneği.
Yedek planım var mı? → Yoksa ilk gün kur, off-site şart.
Lisans ihtiyacım var mı? → Windows, MSSQL, Plesk, cPanel: lisans maliyetini topla.
Ekibimde Linux deneyimi var mı? → Yoksa managed VDS ya da Plesk/cPanel paketli profil değerlendir.
SLA ihtiyacım kritik mi? → Evet ise %99.95+ taahhüt yazılı; aksi halde %99.9 yeterli.

İleri Okuma ve Kaynaklar

linux-kvm.org — KVM resmi belgesi
libvirt.org — libvirt API ve virsh komut satırı
Proxmox VE belgeleri
QEMU resmi dökümantasyonu
Proxmox performans ipuçları
Arch Wiki — KVM (paravirt, virtio, hugepages bölümleri)
Brendan Gregg — Linux performance
CIS Benchmarks — sertleştirme rehberleri
RFC 7042 — IANA OUI / MAC ayrımları (sanal NIC'ler için)

İlgili markaadi Yazıları

Özet: Hangi Cümleyi Hatırlamalı?

Bu rehberi tek bir paragrafa indirgemek gerekirse: VDS, hipervizör üzerinde çalışan, kaynak garantisi nispeten daha sıkı tutulan bir sanal makinedir. Doğru profillenmiş tek bir VDS, milyonlarca lira değerinde bir SaaS işini bile yıllarca taşıyabilir. Yanlış profillenmiş VDS, en güzel bare-metal'i bile aşağı çeker. Karar verirken donanım nesline, ağ kapasitesine, sözleşme şeffaflığına ve sağlayıcının operasyonel olgunluğuna bakın; pazarlama sloganlarına değil. Performans iddialarını kendi fio ve sysbench sonuçlarınızla doğrulayın. Yedek almayı ve restore tatbikatı yapmayı erteleme; ilk haftada kurun. Güvenliği baştan, sertleştirme rehberi gibi bir şablonla başlayarak inşa edin.

Bu yaklaşımla VDS, sanal sunucu macerasını başlatanlar için ekonomik bir başlangıç noktası, deneyimli ekipler için ise mikro-saaS'tan kurumsal mimarilere kadar uzanan ölçeklenebilir bir taşıyıcı olur. Önemli olan teknolojiyi anlamak, gerçek beklentilerle satın almak ve düzenli ölçmek.

VDS / sanal sunucu kurulumu, sertleştirme ve sürekli izleme için profesyonel destek

Sıfırdan VDS provisioning, hipervizör seçimi, performans tuning, KVKK uyumlu yedekleme stratejisi ve 7/24 sunucu yönetimi için markaadi ekibiyle iletişime geçin

İlgili Yazılar

Bu yazıyı okuyanlar bunları da okudu

hosting 27 dk