İçindekiler
- 1 Paylaşımlı hostingden VPS’e geçiş neden kritik bir eşik?
- 2 Paylaşımlı hostingden VPS’e ne zaman geçmelisiniz?
- 3 Adım 1: Trafik analizi ile gerçek ihtiyacı netleştirmek
- 4 Adım 2: CPU, RAM, disk ve bant genişliğini planlamak
- 5 Adım 3: Doğru VPS ve altyapı tercihini yapmak
- 6 Adım 4: Taşıma öncesi hazırlık ve risk azaltma
- 7 Adım 5: Paylaşımlı hostingden VPS’e adım adım taşıma planı
- 8 Adım 6: Taşıma sonrası performans, güvenlik ve izleme
- 9 Sonuç: Doğru analiz + iyi planlanmış geçiş = Sorunsuz VPS’e terfi
Paylaşımlı hostingden VPS’e geçiş neden kritik bir eşik?
Birçok web sitesi yolculuğa paylaşımlı hosting ile başlar. Başlangıçta düşük maliyet, hazır kontrol paneli ve bakım yükünün az olması çok caziptir. Ancak zamanla trafik artar, veritabanı büyür, eklentiler çoğalır, kampanyalar düzenlenir ve bir noktada paylaşımlı hosting altyapısının sınırlarına çarpmaya başlarsınız. İşte tam bu noktada VPS’e geçiş, performansı, güvenilirliği ve ölçeklenebilirliği aynı anda iyileştirebileceğiniz stratejik bir adım hâline gelir.
Biz DCHost olarak, özellikle e-ticaret, içerik platformu ve kurumsal sitelerde paylaşımlı hostingden VPS’e geçişin doğru analiz edilmediğinde gereksiz maliyet veya gereksiz risk ürettiğini sık sık görüyoruz. Bu rehberde, yalnızca “nasıl taşınır?” sorusunu değil, ondan önce gelen iki kritik soruyu netleştireceğiz: Gerçekte ne kadar kaynağa ihtiyacınız var? ve hangi trafik eğrisi sizi hangi VPS seviyesine taşımalı?. Ardından da kesintiyi minimuma indirerek, hatta çoğu senaryoda fark edilmez düzeye çekerek, nasıl adım adım taşıma yapabileceğinizi anlatacağız.
Paylaşımlı hostingden VPS’e ne zaman geçmelisiniz?
Önce doğru zamanlamayı netleştirmek gerekiyor. Paylaşımlı hostingde “idare eder” seviyesinden “artık taşınmak zorundayım” noktasına gelindiğini gösteren hem teknik hem de iş taraflı sinyaller var.
Teknik sinyaller
- cPanel’de CPU, RAM veya IO grafiklerinin sık sık %100’e vurması
- Site açılış sürelerinde (TTFB) belirgin artış, zaman zaman 2–3 saniyeyi aşması
- Yoğun saatlerde beyaz sayfa, 500 hatası veya “Resource Limit Reached” uyarıları
- PHP
max_execution_timesınırlarının sık sık aşılması, zaman aşımı hataları - Yoğun trafikli kampanya veya içerik sonrası sitenin geç yanıt vermesi ya da cevap verememesi
Bu belirtiler sizde varsa, önce sorunun kaynağının gerçekten limitler olup olmadığını görmek gerekiyor. Bu noktada paylaşımlı ortamda limitlere nasıl takıldığınızı anlamak için hazırladığımız Paylaşımlı hostingde “Resource Limit Reached” hatasını önleme rehberine mutlaka göz atmanızı öneririz.
İş taraflı sinyaller
- Organik trafik, reklam ve sosyal medya kampanyalarıyla istikrarlı biçimde artıyorsa
- Tek seferlik değil, sık tekrarlanan anlık trafik sıçramaları yaşamaya başladıysanız
- Sepette veya ödeme adımında yavaşlama yüzünden dönüşüm oranınız düşüyorsa
- Projeyi büyütmek (ek mikro servisler, ayrı API, arka plan işleyiciler vb.) istiyorsanız
Bu durumda yalnızca mevcut sorunu çözmek için değil, aynı zamanda önümüzdeki 12–24 ayı düşünerek VPS’e geçiş planı yapmak en mantıklısı oluyor.
Adım 1: Trafik analizi ile gerçek ihtiyacı netleştirmek
VPS boyutunu hissiyatla değil, ölçerek seçmek gerekir. Yetersiz VPS performans sorunları yaratır, aşırı güçlü VPS ise gereksiz maliyet demektir. Bunun için hem analytics verilerini hem de sunucu taraflı gözlemleri birlikte okumak gerekiyor.
Analytics tarafında bakmanız gereken metrikler
- Eşzamanlı kullanıcı sayısı (concurrent users): Özellikle yoğun saatlerde aynı anda sitede kaç kişi var?
- Sayfa görüntüleme sayısı: Günlük / saatlik sayfa görüntüleme rakamları, isteğin yoğunluğunu gösterir.
- Yoğunluk eğrisi: Trafik gün içinde düz mü dağılıyor, yoksa 2–3 tepede mi toplanıyor?
- Cihaz ve konum dağılımı: Mobil ağırlıklı trafik, ağır front-end ve yavaş mobil bağlantılar ile sunucu yükünü farklı etkileyebilir.
Örneğin günde 20.000 sayfa görüntülemesi alan ama bunun %60’ını akşam 20:00–23:00 aralığında yaşayan bir site ile gün boyu dengeli trafik alan site, aynı VPS’e ihtiyaç duymaz. Birinde kısa sürede yüksek CPU ihtiyacı, diğerinde daha dengeli bir kaynak kullanımı ortaya çıkar.
Sunucu ve uygulama tarafında okunması gerekenler
Paylaşımlı hostingde her detaya erişemeseniz bile, çoğu zaman aşağıdaki sinyalleri görebilirsiniz:
- cPanel kaynak kullanımı grafikleri (CPU, Memory, I/O, Entry Processes)
- PHP hata ve erişim loglarında zaman aşımı veya 500 hatalarının yoğun saatlere denk gelmesi
- Veritabanı sorgu sürelerinin artması, yavaş sorgu loglarında birikmeler
Bu metriklerden çıkan tabloyu, VPS boyutlandırmaya çevirmek için bant genişliği hesaplarını da devreye almak gerekir. Bu konuda ayrıntılı formüller ve örnekler görmek isterseniz, hazırladığımız Shared hosting ve VPS için trafik ve bant genişliği ihtiyacı nasıl hesaplanır? rehberi güzel bir başlangıç noktası olacaktır.
Adım 2: CPU, RAM, disk ve bant genişliğini planlamak
Artık trafik profilinizi kabaca biliyorsunuz. Sırada bunu kaynak planına dönüştürmek var. Burada basit ama işe yarar bir yaklaşımı paylaşalım.
CPU (vCPU) planlama
- Basit kurumsal siteler, bloglar: Genellikle 1–2 vCPU başlangıç için yeterlidir.
- Orta trafikli WordPress + birkaç eklenti, hafif WooCommerce: 2–3 vCPU mantıklı bir alt sınırdır.
- Daha yoğun WooCommerce, haber siteleri, özel PHP/Laravel projeleri: 4+ vCPU ile başlamak, ani sıçramalarda nefes payı sağlar.
Paylaşımlı hostingde CPU’nuz anlık olarak yukarı çekilebildiği için, geçişte “aa, ben buradan da bu kadar çekiyordum” yanılgısına düşmeyin. VPS’te size tahsis edilen vCPU çekirdekleri nettir; bu yüzden biraz güvenli pay bırakmak iyidir.
RAM (bellek) planlama
- Sade WordPress/blog: 2–4 GB RAM
- WooCommerce, LMS, üyelik sistemleri: 4–8 GB RAM
- Laravel, Node.js gibi ek uygulamalar, arka plan işleyiciler: 8 GB ve üzeri mantıklı olabilir.
PHP-FPM havuzları, veritabanı (MySQL/MariaDB), önbellek (Redis/Memcached) ve web sunucusu (Nginx/Apache) hepsi RAM tüketir. Bu nedenle “WordPress’im var, 2 GB yeter” demeden önce hangi bileşenlerin aynı VPS’te koşacağını netleştirin.
Disk türü ve kapasite
- Disk türü: Güncel projelerde mutlaka SSD, mümkünse NVMe tercih edin.
- Kapasite: Mevcut paylaşımlı hosting disk kullanımınız + loglar + yedekler + büyüme payı düşünülmeli.
- Örneğin 10–15 GB kullanan bir site için en az 40–50 GB’lık bir alan konfor sağlar.
Disk, sadece dosya depolamaz; veritabanı IOPS (saniyedeki giriş/çıkış) kapasitesi performans için kritik bir parametredir. Özellikle WooCommerce ve yoğun veritabanı kullanan projelerde IOPS değeri, saf kapasiteden çok daha belirleyici olabilir.
Bant genişliği (trafik) planlama
Aylık trafik limitiniz, sayfa boyutlarınız ve ziyaretçi sayınız üzerinden hesaplanabilir. Örneğin:
- Ortalama sayfa boyutu: 2 MB
- Aylık sayfa görüntüleme: 300.000
Bu durumda teorik trafik: 2 MB x 300.000 = 600.000 MB ≈ 586 GB civarında olacaktır. Üstüne görsel optimizasyon, CDN kullanıp kullanmadığınız, API istekleri, dış servis çağrıları gibi unsurları da eklemek gerekir. Daha hassas hesaplama için yukarıda link verdiğimiz bant genişliği rehberindeki formülleri kullanabilirsiniz.
Adım 3: Doğru VPS ve altyapı tercihini yapmak
Trafik ve kaynak ihtiyacı netleştikten sonra sırada VPS mimarisini seçmek var. Burada iki temel soruya yanıt vermelisiniz:
- Sunucuyu kendim mi yöneteceğim, DCHost ekibinin yönettiği managed bir model mi isteyeceğim?
- Tüm bileşenler (web, veritabanı, önbellek, cron işler) tek VPS’te mi olacak, yoksa orta vadede ayrıştırma planım var mı?
DCHost tarafında tipik bir ilk geçiş senaryosunda, çoğu müşteri için tek VPS üzerinde bütünleşik mimari (web + veritabanı + önbellek) genellikle yeterli oluyor. İleride yük arttığında veritabanını veya önbellek katmanını ayrı bir VPS’e taşımak çok daha kolay.
Ayrıca kontrol paneli tercihlerini (cPanel, DirectAdmin, Plesk vb.) ve işletim sistemi (genellikle Linux/AlmaLinux, Ubuntu, Debian) seçeneklerini de geçişten önce netleştirmeniz iyi olur. Panel tercihine göre taşıma araçları ve yedekleme stratejisi de değişecektir.
Adım 4: Taşıma öncesi hazırlık ve risk azaltma
Şimdi kritik kısım başlıyor: Henüz hiçbir şeyi taşımadan önce yapmanız gerekenler. İyi bir hazırlık, geçiş esnasında ve sonrasında yaşayacağınız stresin %80’ini ortadan kaldırır.
1. En güncel yedeği almak ve test etmek
Öncelikle paylaşımlı hosting hesabınızda tam bir yedek alın:
- Web dosyaları (public_html veya ilgili dizinler)
- Veritabanları (MySQL/MariaDB dump veya panelin tam yedeği)
- E-posta kutuları (IMAP senkronizasyonu veya panel yedekleri)
cPanel kullanıyorsanız, adım adım ekran görüntüleriyle yedek alma ve geri yükleme sürecini anlattığımız cPanel’de tüm siteyi yedekleme ve geri yükleme rehberi bu aşamada doğrudan işinize yarayacaktır.
2. Kod ve veritabanı versiyonlarını not almak
- WordPress, tema ve eklenti sürümleri
- PHP sürümü
- MySQL/MariaDB sürümü
VPS’te aynı (veya uyumlu) sürümlere geçiş yapmanız, sürpriz hataları azaltır. PHP yükseltmesi gibi işleri, mümkünse taşıma tamamlandıktan sonra planlamak daha güvenlidir.
3. DNS ve TTL planı yapmak
Taşımadan önce alan adınızın DNS kayıtlarını yönettiğiniz yerdeki A, AAAA ve MX kayıtlarını inceleyin. Özellikle A kaydınızın TTL (Time To Live) değerini, geçişten 24–48 saat önce 300 saniye (5 dakika) gibi düşük bir değere çekmek, kesintisiz geçişte hayat kurtarır. Bu konuyu daha detaylı ele aldığımız Zero‑downtime taşıma için TTL stratejileri yazımızı mutlaka okumanızı öneririz.
Adım 5: Paylaşımlı hostingden VPS’e adım adım taşıma planı
Hazırlıkları tamamladığımıza göre artık gerçek taşıma akışına geçebiliriz. Aşağıdaki senaryo, klasik bir cPanel paylaşımlı hosting → cPanel veya panelsiz VPS geçişi için genellenmiş bir akıştır.
1. VPS’i hazırlama (boşta ve kapalı değilken)
- VPS üzerinde işletim sistemini ve (kullanacaksanız) kontrol panelini kurun.
- PHP, veritabanı sunucusu, web sunucusu (Apache/Nginx/LiteSpeed) ve gerekli PHP eklentilerini yapılandırın.
- Güvenlik duvarı (firewall), SSH portu, temel güvenlik sertleştirmelerini uygulayın.
Bu aşamada site trafiği hâlâ eski paylaşımlı hosting üzerinde akmaya devam eder. Yani henüz canlı ortamı etkilemiş olmazsınız.
2. Dosya ve veritabanlarını ilk kez taşımak
- cPanel’den aldığınız tam yedeği VPS’e aktarın ve açın, ya da
- FTP/SFTP ile dosyaları,
mysqldumpveya panel aracı ile veritabanlarını manuel taşıyın.
Bu ilk taşıma, “kaba kopya” gibidir. Amaç, sitede büyük yapısal bir sorun olup olmadığını görmek ve VPS üzerinde test ortamını ayağa kaldırmaktır.
3. Hosts dosyası ile gizli test
Alan adınızı tüm dünyaya yönlendirmeden önce, sadece kendi bilgisayarınızda yeni VPS’i işaret ederek test yapabilirsiniz. Bunun için işletim sisteminizin hosts dosyasına:
VPS_IP_ADRESI alanadiniz.com VPS_IP_ADRESI www.alanadiniz.com
gibi satırlar ekleyip tarayıcıdan siteyi gezebilirsiniz. Bu sayede DNS kayıtlarını değiştirmeden, yeni ortamı gerçek alan adınızla test etmiş olursunuz.
4. İkinci senkronizasyon (delta kopya)
İlk kopyadan sonra eski sunucuda yeni siparişler, yorumlar, içerik güncellemeleri yapılmış olabilir. DNS değişikliğinden hemen önce:
- Veritabanını yeniden dump alıp VPS’e import edin.
- Değişen veya yeni yüklenen dosyaları (örneğin
wp-content/uploads) tekrar senkronize edin.
Eğer çok yoğun yazma trafiğiniz varsa (sürekli sipariş alan bir e-ticaret gibi), bakım moduna kısa süre almak ya da taşıma için gece saatlerini seçmek mantıklı olabilir.
5. DNS cutover (trafiği yeni VPS’e almak)
Her şey yolunda görünüyorsa sıra DNS kayıtlarını yeni VPS IP’sine yönlendirmeye gelir:
- A kaydını (ve varsa AAAA kaydını) yeni VPS IP’sine güncelleyin.
- TTL değeri daha önce düşürülmüşse, çoğu ziyaretçi birkaç dakika içinde yeni sunucuya geçer.
- Eski sunucuyu 24–48 saat boyunca kapatmayın; DNS önbelleği geç güncellenen bazı kullanıcılar hâlâ eski sunucuya düşebilir.
Bu aşamaların daha kısa ve pratik bir kontrol listesi versiyonunu görmek isterseniz, paylaşımlı hostingden VPS’e geçiş için hazırladığımız ayrıntılı kontrol listesini de inceleyebilirsiniz.
6. Geri dönüş (rollback) planı
Profesyonel bir geçiş planı her zaman rollback içerir. Yani yolunda gitmeyen bir durumda, hızla eski ortama dönebilmeyi. Bunun için:
- DNS kayıtlarının eski IP değerlerini bir yere not alın.
- Taşımadan hemen önce eski sunucunun tam bir yedeğini saklayın.
- Taşıma sonrası kritik hatalar çıkarsa, DNS’i tekrar eski IP’ye çekebileceğinizi bilin.
Tabii ki asıl hedef rollback kullanmak değildir; ama var olduğunu bilmek, taşıma stresini ciddi şekilde azaltır.
Adım 6: Taşıma sonrası performans, güvenlik ve izleme
Trafiği VPS’e aldığınızda asıl yolculuk yeni başlıyor diyebiliriz. Çünkü artık kaynaklar sizin; paylaşımlı ortamda olduğu gibi başkalarının yoğunluğu sizi etkilemiyor. Bu avantajı tam kullanmak için birkaç kritik adımı atlamamak gerekiyor.
Performans iyileştirmeleri
- PHP-FPM ve OPcache ayarları: Çalıştırdığınız uygulamaya göre havuz sayısı, max children, idle timeout gibi değerleri optimize edin.
- Veritabanı tuning: MySQL/MariaDB için buffer pool, query cache (kullanıyorsanız), slow query log analizlerini yapın.
- Önbellek katmanı: WordPress veya benzeri sistemler için Redis/Memcached nesne önbelleği ve tam sayfa cache çözümlerini devreye alın.
- HTTP/2/HTTP/3 ve sıkıştırma: Gzip/Brotli, HTTP/2 ve mümkünse HTTP/3 etkinleştirmesiyle yanıt sürelerini iyileştirin.
Güvenlik sertleştirmeleri
- SSH erişimini sadece ihtiyaç duyulan IP’lere ya da anahtarlara sınırlandırın.
- Güncellemeleri (OS, panel, uygulama) düzenli yapın.
- Güvenlik duvarı, Fail2ban benzeri araçlar ve temel WAF kurallarıyla brute-force ve basit saldırıları azaltın.
Sürekli izleme ve alarmlar
Artık VPS’iniz var; bu da kaynak kullanımını ve erişilebilirliği izleyebileceğiniz anlamına geliyor. CPU, RAM, disk doluluk oranı, I/O, ağ trafiği, 5xx hata oranları gibi metrikler için alarm eşikleri belirlemek, sorunu kullanıcılarınızdan önce fark etmenizi sağlar. Dilerseniz bu konuda detaylı çözümler anlattığımız izleme ve alarm odaklı rehberlerimizden de yararlanabilirsiniz.
Sonuç: Doğru analiz + iyi planlanmış geçiş = Sorunsuz VPS’e terfi
Paylaşımlı hostingden VPS’e geçiş, doğru yapıldığında hem performans hem güvenlik hem de ölçeklenebilirlik tarafında size ciddi avantaj sağlar. Bunun için üç temel noktayı unutmamanız yeterli:
- Trafik ve kaynak analizi: Sadece bugünü değil, önümüzdeki 12–24 ayı da düşünerek CPU, RAM, disk ve bant genişliği ihtiyacınızı hesaplayın.
- Planlı taşıma: Yedekler, test ortamı, DNS/TTL stratejisi ve rollback planı olmadan canlı trafiği taşımayın.
- Taşıma sonrası bakım: Performans tuning, güvenlik sertleştirmesi ve düzenli izleme ile VPS’inizi gerçekten üretim‑hazır hâle getirin.
Biz DCHost olarak, hem paylaşımlı hosting hem de VPS tarafında onlarca farklı senaryoda müşterilerimizin geçişlerini adım adım planlıyor, mümkün olan en düşük kesinti ve en yüksek güvenlikle yeni ortama taşımalarına yardımcı oluyoruz. Siz de mevcut sitenizin durumunu birlikte analiz etmek, trafiğinize uygun VPS boyutunu belirlemek ve net bir taşıma planı çıkarmak isterseniz, teknik ekibimizle detaylı bir değerlendirme yapabilirsiniz. Doğru analiz ve iyi bir planla, paylaşımlı hostingden VPS’e geçiş süreci zahmet değil, büyüme fırsatı hâline gelir.
