Web Sitesini VPS’ye Taşıma ve Güvenli Geri Dönüş

Önce taşınacak durumu ve bağımlılıkları çıkarın

Web kökünün dışında kalan yüklemeler, özel depolama dizinleri, veritabanları, kuyruklar, oturum verisi ve yapılandırma dosyalarını listeleyin. Şifreleme anahtarları olmadan geri gelen bir veritabanı uygulama için kullanılamayabilir. Sırları komut geçmişine veya herkese açık bir taşıma notuna koymayın.

PHP veya Node.js sürümü, uzantılar, veritabanı sürümü, dosya sahipliği ve servis kullanıcısını karşılaştırın. Taşımayı zorunlu olmadıkça büyük bir sürüm yükseltmesiyle birleştirmeyin. Alan adı değişmiyorsa gereksiz URL dönüşümü yapmayın; WordPress gibi uygulamalarda alan adı değişiyorsa uygulamanın kendi taşıma yöntemini izleyin.

DNS ve sertifika hazırlığını önceden tamamlayın

Değiştireceğiniz A, AAAA veya CNAME kayıtlarını ve mevcut TTL değerlerini kaydedin. TTL düşürmek, daha önce önbelleğe alınmış uzun TTL’li yanıtları anında geçersiz kılmaz. Hazırlığı eski önbellek süresini hesaba katarak yapın; tüm istemcilerin aynı anda yeni adrese geçmesini beklemeyin.

CDN veya ters proxy kullanıyorsanız ziyaretçinin gördüğü DNS ile gerçek origin adresini ayırın. Proxy arkasındaki kaydın TTL davranışı farklı olabilir. IPv4’ü değiştirip eski AAAA kaydını bırakmak, IPv6 kullanan ziyaretçileri eski sunucuya götürebilir. Posta hizmeti taşınmıyorsa MX ve ilgili TXT kayıtlarını gereksiz yere değiştirmeyin.

migration_host='www.example.com'
dig +noall +answer "$migration_host" A
dig +noall +answer "$migration_host" AAAA
dig +noall +answer "$migration_host" CNAME

Bu çıktılar kullandığınız çözümleyicinin gördüğü durumu gösterir. Yetkili DNS yanıtını ve başka ağlardan gözlemi ayrıca değerlendirin. Sertifikayı hedefte DNS geçişinden önce hazırlayabilecek, alan adı sahipliğine uygun bir doğrulama yöntemi seçin.

İlk kopyayı son tutarlı kopyadan ayırın

Büyük dosyaların ilk aktarımı site çalışırken yapılabilir; bu yalnız hazırlık kopyasıdır. Canlı veritabanının veri dizinini sıradan dosya kopyasıyla almak, uygulamaya uygun bir yedek yöntemi sayılmaz. Veritabanınızın desteklediği mantıksal dışa aktarma veya tutarlı fiziksel yedek yöntemini kullanın.

Örneğin PostgreSQL pg_dump, eşzamanlı kullanım sırasında tek veritabanının tutarlı dışa aktarımını sağlayabilir. Ancak dışarıdaki medya dosyalarını, kuyrukları ve ortak rol bilgilerini aynı ana sabitlemez. Veritabanı tutarlılığı ile bütün uygulamanın tutarlılığı aynı kapsam değildir; dosya ve veritabanı ilişkisini ayrıca koruyun.

Son aktarım için yalnız yönetim panelini kapatmak yeterli olmayabilir. Form uç noktaları, ödeme bildirimleri, API istemcileri, cron görevleri ve kuyruk çalışanları da yazabilir. Bunları durdurma, boşaltma veya güvenli biçimde bekletme sırasını belirleyin. Ardından son veritabanı kopyasını ve onunla eşleşen dosyaları aktarın; çıkış kodu ve geri yükleme sonucunu kontrol edin.

DNS değişmeden doğru alan adıyla hedefi sınayın

Hedef sunucuda geçerli sertifika ve aynı alan adı için doğru sanal sunucu yapılandırması bulunmalıdır. Yalnız IP adresine istek göndermek, gerçek ziyaretçinin TLS/SNI ve Host davranışını temsil etmez. curl --resolve, tek komutta alan adını belirli hedef adrese bağlayarak bu kontrolü kolaylaştırır.

migration_host='www.example.com'
migration_ip='192.0.2.44'
curl --noproxy '*' \
  --resolve "$migration_host:443:$migration_ip" \
  --silent --show-error --connect-timeout 5 --max-time 15 \
  --output /dev/null \
  --write-out 'http=%{http_code} tls_verify=%{ssl_verify_result} total=%{time_total}\n' \
  "https://$migration_host/"

Örnek IP ve alan adını kendinize ait hedefle değiştirin; yan etkisiz bir URL kullanın. Sertifika doğrulamasını kapatmayın. Yönlendirme varsa hedef adresini inceleyin; eski sunucudan gelen başarılı sayfayı yeni VPS testi sanmayın. Bu kontrol bir HTTP yanıtı ve TLS doğrulamasıdır, uygulamanın tüm işlevlerinin testi değildir.

Uygulama testlerini gerçek dış etkilerden ayırın

İzole veri üzerinde oturum açma, içerik okuma, örnek yükleme ve veritabanı yazma işlemini doğrulayın. Dosyanın kaydı ile içeriğinin birlikte bulunmasına bakın. E-posta, ödeme, webhook ve zamanlanmış işler denemede gerçek müşteriye işlem üretmemelidir. Yeni ortamın otomatik işlerini henüz üretim modunda başlatmayın.

Dosya sayısı veya arşiv özeti aktarımı denetlemeye yardımcı olur; veritabanıyla işlevsel uyumu tek başına kanıtlamaz. Uygulamanın kritik kayıtlarını, izinlerini ve çalışma dizinlerini inceleyin. Hedefteki bu denemeden sonra üretime açılacak son veri kopyasını nasıl yeniden oluşturacağınızı da netleştirin.

Geçişte tek yazma noktasını koruyun

Geçiş anını ve son doğrulanmış iş kaydını not edin. DNS veya origin hedefini değiştirdikten sonra eski önbellekle gelen isteklerin davranışını izleyin. Eski sunucuya ulaşan ziyaretçinin yeni veri oluşturmasına izin vermeyin. Proxy ile yeniye iletme kullanılıyorsa döngü, yetkilendirme ve TLS davranışı önceden denenmiş olmalıdır.

Kuyrukları ve zamanlanmış işleri yalnız seçilen üretim ortamında açın. İki sunucunun aynı zamanlanmış görevi yürütmesi mükerrer e-posta veya işlem oluşturabilir. Geçiş sırasında kabul edilmiş bildirimleri körlemesine tekrar göndermek yerine uygulamanın tekrar deneme ve idempotency yöntemini izleyin.

Geri dönüş kararını yeni yazmalara göre verin

Yeni ortam henüz üretim yazması kabul etmediyse, eski ortamı yetkili veri kaynağı olarak yeniden açma planı daha basittir. Yine de DNS önbelleği nedeniyle bir süre iki adrese de istek gelebileceğini hesaba katın. Açılacak tek yazma noktasını açıkça belirleyin.

Yeni ortamda sipariş, form veya dosya oluştuysa yalnız eski DNS kaydına dönmeyin. Önce yeni yazmaları durdurun; yeni verinin uygulamayla tutarlı kopyasını ve bekleyen işleri koruyun. Şema uyumunu doğruladıktan sonra bu durumu eski ortama taşıyın veya uygulamanın desteklediği kayıt uzlaştırma yöntemini uygulayın. Yeni kayıtların sayısı kadar iş kimlikleri ve ilişkili dosyaları da doğrulayın.

İzlemeyi ve eski ortamı kapatma koşulunu belirleyin

HTTP hatalarını, oturumları, dosya yüklemelerini, kuyrukları, sertifikayı ve yeni yedeklerin sonucunu izleyin. İlgili ağlardan IPv4 ve IPv6 erişimini kontrol edin. Eski ortamı yalnız DNS değişti diye hemen silmeyin; yazmaya kapalı tutun ve belirlediğiniz gözlem ile saklama süresi sonunda kaldırın.

Bu yöntem otomatik olarak kesintisiz taşıma sağlamaz. Kabul edilebilir bakım süresini uygulamanın veri hacmi ve iş akışları belirler. Son notunuzda geçiş zamanı, kullanılan sürümler, kontrol sonuçları ve geri dönüşte korunacak yetkili veri kaynağı bulunmalıdır.