Bir mağazanın sipariş kaybetmeden güvenilir olmayan barındırma hizmetini değiştirmesi gerekiyor. Yeni sunucu hazır; ancak DNS hâlâ eski sunucuyu gösteriyor ve kopyalama sürerken müşteriler hesap açıp ödeme yapmaya devam ediyor.
Güvenli bir site taşıması; hedef sunucunun hazırlanmasını, taşıma sırasında oluşan verilerin korunmasını, trafiğin kontrollü yönlendirilmesini ve eski sunucunun geri dönüş için hazır tutulmasını gerektirir. WordPress yalnızca dosya ve veritabanından ibaret değildir; sunucu kuralları, zamanlanmış işler, e-posta, sertifikalar ve dış hizmetler de taşınmalıdır.
Bu konu ne anlama gelir?
WordPress'i başka bir sunucuya taşırken gerekli dosyalarla veritabanı kopyalanır, ortama özgü ayarlar uyarlanır ve trafik ancak hedef sınandıktan sonra yönlendirilir. Genel alan adı değişmiyorsa kayıtlı URL'leri değiştirmek gerekmeyebilir. Asıl güçlük, ilk kopya ile son geçiş arasında oluşan verileri eksiksiz aktarmaktır.
- Dosyalar, veritabanı, PHP uzantıları, web sunucusu kuralları, zamanlanmış işler, posta yönlendirmesi, SSL ve dış bağlantılar birlikte çalışan siteyi oluşturur.
- Geçişten saatler önce alınan paket, sipariş veya üyelik kabul eden bir sitede hızla güncelliğini yitirir. İlk kopyadan sonra oluşan veriler kısa süreli bir yazma durdurma ya da son eşitleme ile yeni sunucuya aktarılmalıdır.
- DNS değişikliği tüm kullanıcılara ulaşmadan ve yeni sunucu belirlenen gözlem süresini sorunsuz tamamlamadan eski hizmeti kapatmayın veya verilerini silmeyin.
Gerçekçi bir WordPress örneği
Bir çevrimiçi mağazanın güvenilir olmayan barındırma hizmetinden ayrılması gerekiyor. İlk kopya yeni sunucuda çalışıyor, ancak genel DNS hâlâ müşterileri eski sunucuya gönderiyor. Kopyalama sonrasında gelen siparişler ve hesap değişiklikleri, ekip yazma işlemlerini kısa süre durdurmaz veya geçişten hemen önce desteklenen son eşitlemeyi yapmazsa yeni sunucuda bulunmayacak.
Neden önemlidir ve ne zaman kullanılır?
Mevcut sağlayıcı sitenin gereksinimlerini karşılamıyorsa ya da başka bir platform gereken güvenilirliği, desteği, konumu veya kapasiteyi sunuyorsa sunucu taşıma doğru seçenek olabilir. Hedef ortam boyutlandırılmadan, yapılandırılmadan ve sınanmadan işleme başlamayın. Yerinde giderilebilecek tek bir görünüm veya eklenti sorunu için sunucu değiştirmek gereksiz risk yaratır.
Gün boyunca sipariş, üyelik, form kaydı veya yeni içerik alan sitelerde ilk kopya yalnızca bir provadır. Asıl geçişte bu kopyadan sonra eklenen her kaydın yeni sunucuya ulaştığı doğrulanmalıdır. DNS geçişi tamamlanıp yeni sunucu belirlenen gözlem süresini doldurana kadar eski hizmeti ve verilerini koruyun.
Yeni başlayanlar için anlaşılır yol
- PHP ve veritabanı sürümlerini, depolamayı, DNS kayıtlarını, sertifikaları, zamanlanmış işleri, e-posta işleyişini, yönlendirmeleri ve dış hizmetlerin geri çağrı adreslerini kaydedin.
- Uygunsa ilgili DNS TTL değerini önceden düşürün ve planlanan geçişten önce eski değerin süresinin dolmasını bekleyin.
- Tam kopyayı hedefte geri yükleyin. Genel DNS’i değiştirmeden yerel hosts kaydı veya sağlayıcının ön izleme adresi üzerinden sınayın.
- Trafiğin düşük olduğu bir zaman seçin. Yeni kayıtları kısa süre durdurun veya desteklenen son eşitlemeyi çalıştırın; ardından en yeni içeriklerle işlemlerin hedefte bulunduğunu denetleyin.
- DNS’i değiştirin ve önbelleksiz sayfaları,
wp-admin‘i, girişi, formları, e-postayı, cron’u, medyayı, aramayı, ödeme adımlarını, webhook’ları ve sertifika zincirini sınayın.
İleri teknik yol
Kaynak ve hedef adresleri, paket kimliğini, yeni kayıtların durdurulduğu zamanı, son eşitlemenin tamamlandığı anı, DNS değişikliğini ve doğrulama sonuçlarını kaydedin; geri dönüş kararının en geç ne zaman verileceğini de belirtin. Kopyalama işinin başarı mesajına güvenmek yerine önemli tablolardaki sayıları ve en yeni kayıtları karşılaştırın. Dosya sayıları ve sağlama değerleri geç gelen veya eksik yüklemeleri gösterebilir.
Platformlar farklıysa mutlak yolları, dosya sahipliğini, PHP uzantılarını, proxy başlıklarını, HTTPS algılamasını, cron işleyişini ve e-posta gönderimini inceleyin. Genel alan adı değişiyorsa kayıtlı URL’ler için serileştirilmiş WordPress verisini doğru işleyen bir araç kullanın. SQL dökümünde düz metin değişikliği yapmak yapılandırılmış değerleri bozabilir.
Riskler, sık hatalar ve geri dönüş planı
- Yalnızca ana sayfayı sınayıp DNS’i hedefe çevirmeyin; giriş ve önemli tüm yazma akışları da çalışmalıdır.
- Saatler önce alınan bir pakette son siparişler, dosyalar veya hesap değişiklikleri bulunmayabilir.
- Prova sırasında cron, e-posta veya ödeme geri çağrılarının iki kopyada birden etkin çalışmasına izin vermeyin.
- Önbelleğe alınmış DNS yanıtları hâlâ ziyaretçileri eski sunucuya gönderebiliyorsa eski hizmeti kapatmayın.
Hedef ortam kabul testini geçemezse iki site de yeni veri toplamaya başlamadan trafiği eski sunucuya döndürün. Sorunu incelemek için başarısız hedefi koruyun, eski siteyi ana kaynak olarak bırakın ve nedeni öğrendikten sonra yeni geçiş planlayın. İki kopya bağımsız olarak veri almaya başladıysa geri dönüş artık basit bir DNS değişikliği değildir.
AIOWS nasıl yardımcı olur?
AIOWS Yedekleme Yöneticisi
AIOWS Yedekleme Yöneticisi, yeni sunucunun ilk kopyasını oluşturmakta kullanılacak desteklenen yedeği hazırlamanıza ve yönetmenize yardımcı olur. Dosya ve veritabanı kapsamını, hedefi ve kurtarma noktasını açıkça belirleyin. Genel trafik eski sunucudayken paketi hedefte geri yükleyerek yapılandırma ve testler için çalışan bir kopya oluşturabilirsiniz.
Modül taşımanın yedekleme ve geri yükleme bölümünü kapsar. DNS, TLS, e-posta yönlendirmesi, webhook’lar, ortama özgü ayarlar ve paket alındıktan sonra oluşan veriler için ayrıca geçiş planı gerekir. Geri yüklenen sitede medyayı, veritabanına bağlı işlevleri ve yönetici erişimini sınayın; son eşitlemenin hemen ardından önemli kayıtları karşılaştırın.
Yedekleme Yöneticisi barındırma kurallarını aşamaz, geçersiz kaynak veriyi onaramaz ve kabul edilebilir veri kaybına karar veremez. Hedef ortam teknik ve işlevsel kontrolleri geçene kadar eski sunucuyu ve son doğrulanmış paketi kullanılabilir tutun. Paketi, hedefi, yeni kayıtların durdurulduğu zamanı, son eşitlemeyi, DNS değişikliğini ve testleri kaydedin; geri dönüş kararının en geç verileceği zamanı da not edin. Böylece taşımanın her aşamasında hangi kopyanın ana kaynak olduğu açık kalır.
AIOWS Yedekleme Yöneticisi’ni inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- Taşıma sonrası WordPress sitesi bozuldu: Çözüm rehberi
- WordPress taşıma kontrol listesi: Öncesi ve sonrası
- Taşıma sonrası WordPress URL değiştirme: Güvenli rehber
Sonuç ve önerilen yol
Ziyaretçileri yeni sunucuya yönlendirmeden önce hedef ortamı eksiksiz sınayın. İlk kopyadan sonra oluşan verileri kısa süreli yazma durdurma veya son eşitlemeyle aktarın; en yeni kayıtları ve önemli kullanıcı akışlarını doğruladıktan sonra DNS'i değiştirin. Geri dönüş gerekirse iki site farklı kayıtlar toplamaya başlamadan trafiği eski sunucuya yönlendirin.
