Paylaşımlı Hosting’den VPS’e Geçişi Planlama
Paylaşımlı hosting hesabında CPU, bellek, işlem veya I/O sınırlarına düzenli takılıyorsanız VPS daha fazla kaynak ve yapılandırma kontrolü sağlayabilir. Ancak her yavaşlık kapasite sorunu değildir: önce sorgu sürelerini, hata kayıtlarını, önbellek davranışını ve kaynak sınırı olaylarını inceleyin. Kötü bir sorgu veya dış servis gecikmesi yeni sunucuda da devam edebilir.
Bu kontrol listesi, geçişte kesinti ve veri kaybı riskini azaltmak için envanterden geri dönüş planına kadar gerekli adımları açıklar. Dosyalar, veritabanı, DNS, TLS, e-posta, kuyruklar ve zamanlanmış işler birlikte düşünülmelidir. Dinamik bir sitede kısa yazma duraklaması gerekebilir; “kesintisiz” sözüyle sipariş veya kullanıcı verisinin kaybolmayacağı varsayılmamalıdır.
Ne Zaman VPS’e Geçmeli? Sinyaller, Küçük İpuçları ve Gerçekler
Geçiş kararını tekrarlanan ölçümlere dayandırın. Trafik artışıyla aynı zamanda görülen işlem sınırı, kuyruk beklemesi, yüksek disk gecikmesi veya bellek baskısı kapasite ihtiyacını gösterebilir. Buna karşılık tek bir ağır eklenti, önbellek hatası ya da yavaş API önce uygulama tarafında çözülmelidir. Yoğun saatlerdeki davranışı ve beklenen büyümeyi birlikte değerlendirin.
VPS, paket ve yönetim modelinin izin verdiği ölçüde işletim sistemi, servisler ve güvenlik duvarı üzerinde kontrol sağlar. Paylaşılan fiziksel altyapı ve CPU tahsis koşulları yine önemlidir; VPS otomatik olarak daha hızlı veya güvenli değildir. Yönetilmeyen bir sunucuda güncelleme, izleme, yedekleme ve olay müdahalesinin sorumluluğu da size geçer. Kapasiteyi ve işletim sorumluluğunu birlikte seçin.
İlk Durak: Hazırlık Defteri — Envanter, Yedek, Plan
Neyi Taşıyacağız? Envanterimizi Çıkartalım
Dosyaları, yüklemeleri, veritabanlarını, karakter setlerini, PHP ve eklenti sürümlerini, cron görevlerini, kuyruk/işçi süreçlerini ve oturum deposunu kaydedin. DNS, alan adı, TLS, CDN, SMTP, posta kutuları, ödeme/webhook uçları ve IP izin listelerini de ekleyin. Paylaşımlı hesaptaki SSH/rsync ve yedek alma yetkilerini kontrol edin; araç yoksa panel yedeği veya şifreli dosya aktarımıyla eşdeğer plan hazırlayın.
Yedekler: En Güzel Güvence
Dosyalar, veritabanı, gerekli yapılandırmalar ve varsa e-posta verisi için kapsamı belirlenmiş yedek alın. Kopyayı sunucudan ayrı, erişimi sınırlı bir yerde saklayın; sırları ve kişisel veriyi koruyun. Yedek dosyasının oluşması yeterli değildir: izole hedefe geri yükleyip temel verileri ve uygulama açılışını doğrulayın. Son eşitleme yedeğini de kesim öncesindeki doğrulanmış noktaya bağlayın.
TTL’yi Erken Düşürmek
Değişecek DNS kayıtlarının TTL’sini, önceki TTL’nin dolmasına zaman bırakacak kadar erken düşürün. Sabit 24–48 saat bütün kurulumlar için gerekli veya yeterli değildir; mevcut değer ve değişecek katman belirleyicidir. Yeni TTL önceden önbelleğe alınmış yanıtları temizlemez; negatif önbellek ve serve-stale davranışı da etkili olabilir. DNS kayıtları ve yaygın hatalar rehberi bu ayrımları açıklar. DNS’i geri çevirmek de anlık değildir.
VPS’in İlk Nefesi: Temel Kurulum, Güvenlik ve İzleme
İşletim Sistemi, Panel ve SSH
Desteklenen işletim sistemi ve uygulamayla uyumlu sürümleri seçin; varsa panelin kurulum ve lisans gereksinimlerini doğrulayın. SSH anahtarıyla yönetici erişimini kurduktan sonra ikinci bir oturumda yeni kullanıcıyla giriş ve gerekli sudo işlemlerini doğrulayın. Mevcut oturumu ve sağlayıcı kurtarma konsolunu erişilebilir tutarak parola/root kısıtlarını uygulayın; çalışan erişimi doğrulamadan kapatmayın.
Güvenlik Duvarı, Güncellemeler ve Servisler
Güncellemeleri uygulayın, gereksiz servisleri kapatın ve gerçek yönetim portu dahil yalnız gereken yolları açın. IPv4 ve IPv6 kurallarını ayrı doğrulayın; veritabanı ve Redis gibi servisleri gereksiz yere internete açmayın. Bellek, CPU, disk alanı/gecikmesi, hata oranı ve sertifika süresi için izleme hazırlayın. VPS güvenliği rehberindeki kontrolleri kullanılan işletim sistemi ve yönetim modeline uyarlayın.
Staging Alanı: Prova Sahnesi
Test kopyasını kimlik doğrulama veya ağ erişim kısıtıyla koruyun; yalnız robots.txt ya da noindex kullanmak gizlilik sağlamaz. Google robots.txt içindeki noindex kuralını desteklemez; meta/HTTP noindex kuralını görebilmesi için sayfaya erişebilmelidir. Klonda gerçek ödeme, müşteri e-postası, webhook ve cron/işçileri devre dışı tutun; ayrı test kimlik bilgileri kullanın. Yerel hosts eşlemesi yalnız sizin çözümlemenizi değiştirir, VPS’i dünyadan gizlemez.
Dosyalar ve Tutarlı Veritabanı Aktarımı
Dosyaları Aktarmanın Sakin Yolu
Önce dosyaların ilk kopyasını alın, ardından son kesimde değişen dosyaları eşitleyin. rsync belgelerinde kaynak/hedef yolu, sondaki eğik çizgi, dry-run ve silme seçeneklerinin etkisini kontrol edin. Gerçek kullanıcı yüklemelerini yalnız büyük oldukları için dışlamayın; yeniden üretilebilir önbellekler ayrı değerlendirilebilir. Çalışan veritabanının veri dizinini sıradan rsync ile kopyalamak tutarlı veritabanı yedeği değildir.
Veritabanı Yedeği ve Geri Yükleme
Veritabanını ilişkili tablolar arasında tutarlı bir noktadan dışa aktarın; tabloları ayrı ayrı almak bunu garanti etmez. mysqldump belgelerindeki single-transaction yaklaşımı InnoDB için tutarlı anlık görünüm sağlayabilir; MyISAM/MEMORY tabloları ve eşzamanlı şema değişiklikleri bu güvenceye dahil değildir. Gerçek sürümün yetki ve seçeneklerini kontrol edin; gerekiyorsa planlı yazma duraklaması/kilitleme kullanın. Karakter seti, sıralama, tetikleyici, olay ve yordam kapsamını doğrulayarak izole hedefe geri yükleyin. İlk yedekten sonraki yazılar son eşitlemeyle ayrıca taşınmalıdır.
Yapılandırmalar: Çevre Değişkenleri, Yol Ayarları, Yetkiler
Yeni veritabanı adresi ve yetkilerini, dosya yollarını, SMTP/API sırlarını ve oturum/önbellek bağlantılarını açıkça yapılandırın. Sırlar web kökünden sunulmamalı ve yalnız gerekli kullanıcılarca okunabilmelidir. Uygulama kodu okunabilir; yükleme, önbellek ve oturum dizinleri yalnız gerektiği ölçüde yazılabilir olsun. Genel 777 izniyle sorun gizlemeyin. Klonun yanlışlıkla üretim veritabanına veya kuyruklarına bağlanmadığını doğrulayın.
SSL, E-Posta ve DNS: Küçük Ayarların Büyük Etkisi
SSL Sertifikası: Otomatik Yenileme ve Temiz Yönlendirmeler
Yeni uçta geçerli TLS/SSL sertifikasını, www/çıplak alan kapsamını, zinciri ve yönlendirmeleri DNS değişmeden hazırlayın. Let’s Encrypt belgelerine göre HTTP-01 doğrulaması CA’nın ulaştığı genel HTTP yolunda çalışır; yerel hosts değişikliği CA’yı yeni sunucuya göndermez. Uygun DNS-01 otomasyonu veya koordineli challenge yolu planlayın. Yenileme denemesini ve bağımsız süre/hata alarmını doğrulayın; Let’s Encrypt’in sona erme e-postalarına güvenmeyin, bu hizmetin bitişi 4 Haziran 2025 olarak duyuruldu. HSTS değişikliklerini ayrıca test edin.
E-Posta Tarafı: MX, SPF, DKIM ve rDNS
Posta kutularının eski hostta kalıp kalmayacağını ve uygulamanın hangi SMTP hizmetiyle göndereceğini belirleyin. Kutular taşınıyorsa eski mesajları ve geçiş sırasında gelenleri ayrıca eşitleyin; MX değişikliği ileti kopyalamaz. Doğrudan VPS’ten gönderimde port/sağlayıcı koşullarını, gönderici IP’nin PTR kaydını ve bu addan aynı IP’ye ileri çözümlemeyi kontrol edin. PTR’yi IP sağlayıcısı yönetir. SPF, DKIM, DMARC ve rDNS rehberi kimlik doğrulamayı açıklar; doğru kayıtlar tek başına teslimat garantisi değildir.
DNS Geçişi: Kısa Bir Pencere, Uzun Bir Huzur
Üretim alan adını yalnız test makinenizde yeni IP’ye eşleyerek TLS, yönlendirmeler ve uygulama akışlarını doğrulayın; IP’yle açılan sayfa aynı testi yapmaz. Son eşitleme ve tek yazıcı hazır olduğunda ilgili A/AAAA veya sağlayıcının desteklediği hedef kaydını değiştirin. IPv6 hizmeti hazır değilse eski AAAA’yı unutmayın; kaldırma veya geçişi önceki önbellekle birlikte planlayın. CDN varsa genel DNS’i atlayarak origin’i açmak yerine CDN origin ayarını güncelleyin. Anycast DNS ve failover veri eşitlemesini kendiliğinden yapmaz.
Taşımanın İncelikleri: WordPress, Önbellek, Kuyruklar ve Cron
WordPress mi? Küçük Dokunuşlarla Büyük Fark
WordPress’te URL aynı kalıyorsa bütün veritabanında adres değiştirmek gerekmez. Kalıcı bağlantı kuralları, yüklemeler, tema/eklentiler, PHP uzantıları ve oturum davranışını doğrulayın. URL değişiyorsa serileştirilmiş veriyi anlayan araçla, yedek ve değişiklik önizlemesi üzerinden sınırlı dönüşüm yapın. PHP-FPM, OPcache ve Redis optimizasyonunu uygulama uyumluluğu ve ölçülen kaynak kullanımıyla planlayın; yeni sunucuda otomatik hızlanma varsaymayın.
Önbellek Politikası: Ne, Nereye, Ne Kadar?
Sayfa, nesne ve tarayıcı önbelleği farklı katmanlardır. Ortak sayfa önbelleğinde sepet, ödeme, hesap, kişisel yanıtlar ve uygun olmayan oturum çerezli istekler dışlanmalıdır. CDN origin değişimini, cache anahtarlarını ve gerekli içerik temizliğini doğrulayın; yalnız herkese açık güvenli içerikle kontrollü ısıtma yapın. Önbelleği temizlemek DNS önbelleklerini veya veritabanı farkını ortadan kaldırmaz.
Kuyruklar, Cron ve Arka Plan İşleri
Cron, kuyruk işçileri, ödeme bildirimleri ve diğer yazıcıları envantere göre taşıyın. Staging’de devre dışı tutun; kesimde eski işçileri durdurup devam eden işleri ve bekleyen kuyruğu güvenli biçimde boşaltın veya aktarın. Aynı işi iki sunucuda bağımsız çalıştırmayın. Yeni süreçlerin doğru kuyruk, saat dilimi ve yetkilerle başladığını; yeniden denemelerin mükerrer ödeme/e-posta üretmediğini doğrulayın. İşlem yöneticisiyle yeniden başlama, kuyruk verisinin taşındığı anlamına gelmez.
Canlıya Geçiş: Sessiz Kesim, Geri Dönüş Planı ve Minik Testler
Kuru Koşu: Provanın Gücü
İzole klonda son aktarım süresini ve adımlarını prova edin. Üretim alan adıyla TLS, giriş, arama, yükleme ve yönlendirmeleri inceleyin; ödeme ve e-postaları sandbox/test alıcılarıyla deneyin. Gerçek müşteriye mesaj veya ücret üretmeyin. Dış webhook’ların yerel hosts dosyasını kullanmadığını hesaba katın. Sonuçlar, kesim penceresini ve geri dönüş eşiğini belirlemelidir.
Kesim Anı: Küçük Pencere, Net Adımlar
Dinamik sitede yorum, sipariş, yönetim değişikliği, cron, kuyruk ve webhook dahil bütün yazı kaynaklarını durdurun veya doğrulanmış tek yazıcı düzeninde koordine edin. Son tutarlı veritabanı aktarımını ve yükleme eşitlemesini yapın; sayımlar ve uygulama kontrolleriyle doğrulayın. Ardından trafiği değiştirin. Eski IP’ye gelen önbellekli kullanıcılar için yeni uca test edilmiş proxy veya açıkça tanımlı salt okunur/bakım davranışı gerekir. Birkaç dosya eşitlemesi yazı kaybını önlemez; her kullanıcının birkaç dakikada yeniye geçeceği söylenemez.
Geri Dönüş Planı: İçinizi Rahatlatan Emniyet Kemeri
Geri dönüş kararını hangi hata veya süre eşiğinin tetikleyeceğini önceden belirleyin. Yeni sunucu henüz yazı kabul etmediyse geri dönüş daha basittir. Yeni sipariş veya değişiklikler oluştuysa önce yazıları koordine edip bunları eski hedefe güvenli şekilde taşıyın; eski veritabanına DNS çevirmek veri kaybı yaratabilir. DNS geri alma da önbellekler nedeniyle anlık değildir. Kurtarma kopyasını ve eski ortamı, gerekli veri eşitlemesi ve test tamamlanana kadar koruyun.
Taşımadan Sonra İnce Ayar: Performans, Güvenlik ve Sağlam Altyapı
Performansın Kalıcı Olması
Eski ve yeni ortamı benzer iş yükünde karşılaştırın: yanıt süresi, hata oranı, PHP kuyrukları, CPU, bellek, swap ve disk gecikmesi ölçülsün. FPM işçi sayısını süreç başına bellekle birlikte hesaplayın; OPcache ve veritabanı belleğine de pay ayırın. Yavaş sorguları ve dış servis beklemelerini ayırmadan yalnız RAM eklemek veya bütün önbellekleri büyütmek çözüm olmayabilir. Her değişikliği ölçerek uygulayın.
Güvenliğin Gündelik Rutinleri
Güncellemeleri, yedek saklama politikasını ve erişim kontrollerini düzenli gözden geçirin. WAF, oran sınırlama ve IP kısıtlarını uygulamanın gerçek trafik yollarına göre test edin; bunlar her ağ saldırısını önlemez. DDoS korunma rehberi farklı katmanları ele alır. Kullanılmayan eklentileri bağımlılıklarını doğruladıktan sonra kaldırın; güvenlik ve performans sonuçlarını ayrı ölçün.
HTTP Başlıkları ve İnce Güvenlik Baharatları
HSTS, HTTPS kullanımını tarayıcıda süreli olarak zorlar; sertifika hatası olan yeni uca erişimi engelleyebilir. Başlığı kaldırmak mevcut tarayıcı politikasını anında temizlemez. CSP’yi gerektiğinde raporlama aşamasıyla test edin; includeSubDomains veya uzun HSTS süresini canlı geçişin içine plansız eklemeyin. Test ortamının üretim alanına etki edebilen başlıklar göndermediğini ve canlıda yanlış noindex kalmadığını doğrulayın.
Sorun Giderme: Ufak Pürüzler ve Pratik Çözümler
SSL Var, Ama Tarayıcı Kızgın
Tarayıcı hatasının türünü önce ayırın: sertifika adı, zinciri, süresi ve sistem saati sorunları ile karışık içerik aynı değildir. Tarayıcı güvenlik konsolunu ve sunulan sertifikayı inceleyin. URL aynıysa geniş veritabanı değişikliği yapmayın; gerekli HTTP→HTTPS dönüşümünde yedek, serileştirme uyumlu araç ve önizleme kullanın. Canonical, yönlendirme ve CDN kaynağını doğrulayın; tarayıcı simgesinin görünümü tek başına test sonucu değildir.
Posta Gitmiyor, Kutuda Sessizlik
Gönderim başarısızlığında SMTP yanıtını ve günlükleri inceleyin: bağlantı/port, kimlik bilgisi, TLS, kota, kuyruk veya alıcı reddi ayrı nedenlerdir. SPF/DKIM/DMARC ve PTR’yi gerçek gönderici üzerinden değerlendirin; MX esas olarak gelen postanın yönünü belirler. Gelen/giden testleri kontrollü adreslerle yapın, ilgili başlık ve teslim durumlarını okuyun. Tek başarılı e-posta bütün alıcılara teslimatı kanıtlamaz.
Yavaşlık Hissi: Nerede Tıkanıyoruz?
Kaynaklar boş görünse de veritabanı, dış API veya uygulama kilidi istekleri bekletebilir. Yavaş sorgu kayıtlarını, uygulama zamanlamalarını ve PHP işçi kuyruğunu karşılaştırın. Eklenti devre dışı bırakma gibi etkili değişiklikleri önce staging’de tek tek deneyin; üretimde ödeme veya güvenlik işlevini kontrolsüz kapatmayın. Değişiklik öncesi/sonrası aynı akışı ölçün.
Bir Son Kontrol: Küçük Turlar, Büyük İç Huzuru
Kullanıcı Akışı: Ziyaretçinin Ayak İzleri
Ana sayfa, kategori, içerik, arama, giriş, yükleme ve form akışlarını doğrulayın. Ödeme gibi dış etkili işlemleri sandbox veya önceden belirlenmiş kontrollü test yöntemiyle inceleyin. HTTP durumları, redirect zincirleri, canonical, dil bağlantıları ve sitemap’i karşılaştırın. Host değişimi tek başına yeni URL veya 301 gerektirmez; URL gerçekten değiştiyse eski adresten uygun yeni adrese kalıcı yönlendirme ayrıca planlanır.
Arka Planda Sürenler
Yalnız yeni tarafta çalışması gereken cron ve işçilerin etkin, eskilerin durdurulmuş olduğunu kontrol edin. Kuyruk bekleyenlerini, başarısız işleri, gerçek yedek kapsamını ve izole geri yükleme sonucunu inceleyin. Sertifika yenileme başarısı ve bağımsız süre alarmı çalışsın. Eski hizmeti kapatma kararını tek saatlik sessizliğe değil trafik, veri, e-posta ve DNS bağımlılıklarının doğrulanmasına bağlayın.
Doğrulanmış Bir VPS Geçişini Tamamlama
Başarılı geçiş; envanter, geri yüklenebilir yedek, uyumlu ve korunan hedef, prova, koordineli son eşitleme ve ölçülen hizmet kontrollerinden oluşur. Okuma erişimi sürerken kısa yazma duraklaması gerekebileceğini kullanıcı akışına uygun biçimde planlayın. Eski ve yeni sunucunun ayrı veri kabul etmesini önleyin; geri dönüşü yeni oluşan veriyi de kapsayacak şekilde hazırlayın.
Geçiş kaydında yapılan değişiklikleri, son doğrulanan veri noktasını, sorumluları ve eski hizmeti kapatma koşullarını saklayın. DNS kayıtları, e-posta teslim edilebilirliği, Anycast ve failover ile WordPress performansı ayrı katmanların kontrollerini tamamlar. VPS’in beklenen faydasını, geçişten sonra aynı iş yükü altında ölçerek değerlendirin.
