VPSCrypto
Çalıştırdığınız her sunucu en az bir kez taşınacaktır. Sağlayıcı fiyatlarını yükseltir, ya da göndermek istemeyeceğiniz bir belge istemeye başlar, ya da bir komşu hakkındaki kötüye kullanım şikâyeti yüzünden koca bir /24'ü bir öğleden sonra boyunca devre dışı bırakır. Soru hiçbir zaman taşınıp taşınmayacağınız değildi — yalnızca bunun sizin seçtiğiniz bir Salı sabahı mı, yoksa başkasının sizin yerinize seçtiği bir Cumartesi gecesi mi olacağıydı.
Mekanik kısım zor olan değildir. Dosyaları kopyalamak rsync'tir ve bunu zaten biliyorsunuz. Taşımaları bozan şey zamanlamadır: bir taşıma sırasında üç ayrı saat birden çalışır, bunlar birbiriyle senkronize değildir ve her gerçek hata bunların arasındaki boşluklarda meydana gelir. Bu rehber o boşluklarla ilgilidir — bir hafta önce düşürmüş olmanız gereken DNS TTL'si, hâlâ yazılmakta olan hâliyle kopyaladığınız veritabanı, yalnızca az önce kapattığınız bir makinede var olan sertifika ve eski sağlayıcının baştan beri okuyabildiği kimlik bilgileri.
Komutlar, her iki uçta da Debian veya Ubuntu ve veritabanlı bir web uygulaması olduğunu varsayar, çünkü çoğu insanın taşıdığı şey budur. Bir Nextcloud, bir oyun sunucusu, bir bot ya da bir BTCPay örneği hepsi aynı şekli izler — yalnızca veri adımı farklılaşır.
Üç saat ve “sıfır kesinti” neden yanlış bir hedeftir
Bir taşıma tek bir olay değildir. Farklı hızlarda çalışan üç sayaçtır ve işin bütün sanatı, bunların birbiriyle kötü şekilde çakışmasını önlemekte yatar:
- DNS saati. Bir A kaydını değiştirdiğiniz andan itibaren, çözümleyiciler önbelleğe alınmış kopyaları geçerliliğini yitirene kadar eski adresle yanıt vermeye devam eder. Bu saati geçiş anında kontrol edemezsiniz — onu günler önce TTL'yi ayarladığınızda kontrol etmiştiniz.
- Veri saati. Verinin son kopyanız, bir anın fotoğrafıdır. O andan sonra yazılan her şey yalnızca eski makinede yaşar ve onu ya yeniden uygulamazsanız ya da gerçekleşmesini durdurmazsanız kaybolur.
- Oturum saati. Devam eden yüklemeler, açık WebSocket'ler, iki dakika önce ana bilgisayar adınızı çözümlemiş bir işlemciden kırk saniye içinde gelecek bir ödeme geri çağrısı (callback). Bunlar, gönderenin çözümlediği kutuya iner, sizin tercih edeceğiniz kutuya değil.
Tam anlamıyla sıfır kesinti peşinde koşmak, üçünü de aynı anda çalışır tutmak demektir; bu da pratikte uygulamayı aynı anda iki veritabanına yazan iki sunucuda çalıştırmak anlamına gelir. Bu gerçekten zor bir problemdir ve tek bir VPS için çözülmesi yanlış olan problemdir. Dürüst hedef daha dar ve tutturulması çok daha kolaydır:
Hiçbir ziyaretçi hata görmez ve hiçbir yazma kaybolmaz. Sitenin ayakta ama salt okunur olduğu doksan saniyelik bir pencere ikisini de karşılar ve neredeyse kimse bunu fark etmez. Bakım penceresi olmadan yapılan, form gönderimlerinin son kırk dakikasını sessizce kaybeden canlı bir geçiş ise ikisini de karşılamaz ve bunu bir müşteriden öğrenirsiniz.
Yani plan şudur: salt okunur pencereyi olabildiğince kısa tutun, sıradan hâle getirin ve geri döndürülebilir kılın. Aşağıdaki her şey bu üç şeye hizmet eder.
Eski sağlayıcının, siz ayrıldıktan sonra elinde kalanlar
Bu kısım genellikle atlanır, ama aslında birçok kişinin taşınma nedeni tam olarak budur, bu yüzden üzerinde titizlikle durmaya değer. Sunucunuz başkasının donanımında yaşarken, o sağlayıcı şunları görebilecek konumdaydı:
- Diskin tamamını. Birim LUKS ile şifrelenmiş ve yalnızca sizin tarafınızdan kilidi açılmıyorsa, hipervizör onun her baytını okuyabilirdi — anahtarlar, token'lar, veritabanı içeriği, hepsi. Şifreleme olsa bile, çalışan bir VM'in belleği kilidi açılmış anahtarı içerir.
- Makinenin kullandığı her kimlik bilgisini. Ortam dosyalarındaki API token'ları, SMTP parolaları, cüzdan daemon'ının RPC sırları, SSH genel anahtarlarınız ve, eğer bir kurtarma konsoluna özel bir anahtar yapıştırdıysanız, bundan çok daha fazlası.
- Hesabın gerektirdiği her şeyi. Bir isim, bir kart, bir adres, SMS doğrulaması için bir telefon numarası, giriş yaptığınız IP adresleri. Bu küme, hesabı kapattığınızda küçülmez ve çoğu yargı bölgesinde sağlayıcının bunun bir kısmını yıllarca saklaması zorunludur.
Bunların hiçbiri kötü niyetli değildir — bu, her yerde olduğu gibi burada da başkasının donanımında sanal makine çalıştırmanın anlamıdır. Önemli olan şudur: bir taşıma, elde edeceğiniz tek temiz kopuş noktasıdır. Yeni kutu, taze anahtarlar, taze token'lar ve taze bir IP ile başlar; eski sırları da beraberinde taşırsanız, eski açığı da onlarla birlikte taşırsınız ve kopuş yalnızca kozmetik olmuş olur.
Bu yüzden eski makinedeki her sırrı varsayılan olarak ele geçirilmiş sayın ve taşıma sırasında yeniden verin. Bu, size bir kez, bir saate mal olur. Bunu daha sonra, ayrıca yapmak, kimsenin asla gerçekleştiremediği bir iştir. Ve taşınma nedeninizin bir kısmı hesabın kendisinin sızıntı olmasıysa, yenisini Monero ile ödemek ve bunu bir KYC'siz hesap üzerinden yapmak, kopuşu sembolik değil gerçek kılan adımdır — yine de bunun size gerçekte ne kazandırıp ne kazandırmadığı konusunda kendinize karşı dürüst olun, ki bu başlı başına ayrı bir konudur.
TTL saati, taşımadan bir hafta önce işlemeye başlar
Time to live (yaşam süresi), bir çözümleyicinin kaydınızı yeniden sormadan önce ne kadar süre saklamasına izin verildiğini gösteren saniye sayısıdır. A kaydınızın varsayılan TTL değeri olan 3600'e sahipse, onu değiştirdiğiniz anda, bir saniye önce sormuş olan bir çözümleyici sonraki elli dokuz dakika elli dokuz saniye boyunca ziyaretçileri eski sunucuya göndermeye devam eder. Birçok kayıt şirketinin hâlâ varsayılan olarak sunduğu 86400 ile bu tam bir güne çıkar.
Gerçekte neye sahip olduğunuzu kontrol edin — ne ayarladığınızı sandığınızı değil:
dig +noall +answer example.com A
dig +noall +answer www.example.com A
dig +noall +answer example.com MX
dig +noall +answer example.com NSHer yanıtın ikinci sütunu, geri sayan TTL'dir. Taşımayla ilgili her kaydı 300 saniyeye düşürün ve bunu geçişinizden önce en az o anki TTL'nin iki katı kadar süre önce yapın: kayıt 86400'deyse, değişikliğin kendisinin evrensel olarak görünür hâle gelmesi bir gün sürer, ki bu DNS taşımalarının tam merkezindeki özyinelemeli şakadır.
İnsanları yakalayan iki ayrıntı:
- NS kayıtlarının kendi TTL'si vardır, genellikle uzun bir tanesi, ve bu, sizin bölgenizde değil kayıt şirketinde ayarlanır. Bu yalnızca aynı zamanda ad sunucularını da değiştiriyorsanız önemlidir — ki bunu bir sunucu taşımasıyla aynı haftada yapmaktan kaçınmalısınız. Önce sunucuları değiştirin, oturmasını bekleyin, sonra isterseniz DNS sağlayıcılarını değiştirin. İki değişken, iki hafta sonu.
- “DNS yayılması” diye bir şey yoktur. Hiçbir şey yayılmaz; önbellekler geçerliliğini yitirir. Beklenecek bir kuyruk ve güncellemeyi daha hızlı gönderen bir düğme yoktur. Tek kaldıraç TTL'dir ve geçiş anına gelindiğinde o zaten çekilmiştir.
Bölge dosyasındayken, bir ada değil de sunucunun IP adresine işaret eden her kaydı not edin. Genellikle hatırladığınızdan bir tane daha fazlası vardır: mail, webmail, çıplak bir @, eski bir staging, içinde bir ip4: literali bulunan SPF kaydı ve ilk IPv6 bloğunuzu aldığınızda eklediğiniz ve sonra unuttuğunuz AAAA kaydı. Bunların her biri bir plan gerektirir ve AAAA, klasik sessiz hatadır — A kaydını değiştirirsiniz, dizüstü bilgisayarınızdan her şey yolunda görünür ve çalışan IPv6'ya sahip her ziyaretçi zaten sildiğiniz bir sunucuya inmeye devam eder.
Yeni kutuyu boyutlandırma ve ona karar vermeden önce kontrol edilmesi gerekenler
Şu anda sahip olduğunuz aynı özellikleri sipariş etme dürtüsüne direnin. Faturadaki rakamlardan alışveriş yapıyorsunuz, iş yükünün gerçekte ne kullandığından değil. Önce ölçmek için iki dakika ayırın:
# peak RAM actually in use, not allocated
free -m
# what has been paging, if anything
vmstat -s | grep -i swap
# real disk consumption, biggest first
du -xh --max-depth=2 / 2>/dev/null | sort -rh | head -20
# load relative to core count
uptime; nprocİki genel kural oldukça işe yarar. Yük ortalamanız çekirdek sayınızın altındaysa ve swap'a hiç dokunulmamışsa, kutu CPU veya bellek sınırlı değildir ve yana ya da aşağı doğru geçebilirsiniz. Disk yüzde yetmişin üzerindeyse, yeniyi bugün kullandığınıza değil bir yıl içinde ihtiyaç duyacağınıza göre boyutlandırın — bir birimi sonradan büyütmek küçük çaplı bir taşımadır ve zaten şu anda bir tanesini yapıyorsunuz.
Bizim tarafımızda bu net bir şekilde eşleşir: Pup (1 vCPU, 1 GB, 25 GB) bir statik site, bir VPN veya küçük bir bot çalıştırır; Cub (1 vCPU, 2 GB, 40 GB), bir uygulamayı kendi veritabanıyla birlikte paging yapmadan barındıran en küçük kutudur; Scout (2 vCPU, 4 GB, 70 GB), gerçek trafiği olan gerçek bir site için rahat varsayılan seçimdir; Hunter (4 vCPU, 8 GB, 140 GB) ve üzeri, konteynerlerin, CI'nin veya bir kutu üzerindeki birkaç servisin ait olmaya başladığı yerdir. Hepsi sınırsız trafikli tam NVMe'dir, böylece bant genişliği aşımı — zaten taşınmanın yaygın bir nedeni — bir değişken olmaktan çıkar. Tam liste burada.
Sonra, tek bir bayt bile taşımadan önce, size az önce verilen makine hakkında üç şeyi kontrol edin. Bunların her biri şimdi ucuz, geçişten sonra pahalıdır:
- IP'nin itibarı. Başkasının geçmişine sahip geri dönüştürülmüş bir adres, postanızın reddedilmesine ve ziyaretçilerinizin sorgulanmasına yol açar. Bizimkiler verilmeden önce taranır ve risk bölümlendirmesine tabi tutulur, ama artık üzerinde sizin servisiniz var, bu yüzden kendiniz doğrulayın — beş dakikalık versiyonu burada. Bunu DNS çevirisinden önce, cevabın size hâlâ hiçbir şeye mal olmadığı zaman yapın.
- Ters DNS. Kutu bir gün posta gönderecekse, PTR kaydı aynı IP'ye geri çözümlenen bir ana bilgisayar adına çözümlenmelidir. Özel rDNS talep üzerine mevcuttur; şimdiden isteyin ki geçiş zamanına kadar otursun.
- Kullanıcılarınızın bulunduğu yerden rota. Kullanıcılarınızın bölgesindeki bir makineden çekilen bir
mtr, herhangi bir teknik veri sayfasından daha çoğunu yargı bölgesi seçimi hakkında söyler. Ölçtüğünüz gecikme, varsaydığınız gecikmeden daha iyidir.
Adım adım
- Taşımayı planlamadan günler önce her TTL'yi düşürün
Bu ilk sıradadır çünkü zorunlu bir bekleme süresi olan tek adım budur. Geri kalan her şey bir öğleden sonrada yapılabilir; bu ise aceleye getirilemez ve onu atlamak, beş dakikalık bir geçişi iki günlük bir geçişe dönüştüren şeydir.
Bölgenizin bulunduğu yere giriş yapın ve değişecek her kayıtta TTL'yi 300'e ayarlayın: apex
A,AAAA,www,mailve bir IP literaline işaret eden başka her şey. Sonra dışarıdan doğrulayın, çünkü kontrol panelleri ile gerçeklik bazen uyuşmaz:dig +noall +answer example.com A @1.1.1.1 dig +noall +answer example.com AAAA @1.1.1.1 dig +noall +answer www.example.com A @8.8.8.8IN'den önceki sayı, kalan TTL'dir. Bir dakika sonra tekrar sorgulayın: 300'den geri saymalı, daha büyük bir şeyden değil. Hâlâ 3600'den geri sayıyorsa, eski değer önbelleğe alınmıştır ve bunun geçmesini beklersiniz — ki bunun taşımanın sabahında değil de eksi yedinci günde olmasının tam nedeni de budur.Geri dönüşünüzün de hızlı olması için TTL'yi taşıma boyunca ve sonrasında bir hafta daha 300'de bırakın. Eski kutu gittikten sonra onu makul bir değere — 3600 gayet iyidir — geri döndürün.
- Herhangi bir şeyi kopyalamadan önce eski sunucunun envanterini çıkarın
Bir diski değil, çalışan bir sistemi taşıyorsunuz ve insanların unuttuğu parçalar asla
/var/wwwiçinde değildir. Bunlar ayın dördünde çalışan cron işi, bir olay sırasında eklenen güvenlik duvarı kuralı, iki yıl önce üçüncü taraf bir depodan kurulmuş pakettir. Makinenin durumunu metin olarak yakalayın ve bu metni geri kalan her şeyle birlikte karşıya kopyalayın:mkdir -p /root/mig dpkg --get-selections > /root/mig/packages.txt systemctl list-units --type=service --state=running --no-pager > /root/mig/services.txt systemctl list-timers --all --no-pager > /root/mig/timers.txt crontab -l > /root/mig/cron-root.txt 2>/dev/null for u in $(cut -d: -f1 /etc/passwd); do crontab -lu "$u" 2>/dev/null | sed "s/^/[$u] /"; done > /root/mig/cron-users.txt ss -tlnp > /root/mig/listening.txt nft list ruleset > /root/mig/firewall.txt 2>/dev/null || iptables-save > /root/mig/firewall.txt cp -a /etc/hosts /etc/fstab /root/mig/ du -xh --max-depth=2 / 2>/dev/null | sort -rh | head -40 > /root/mig/disk.txtŞimdi
listening.txtdosyasını satır satır okuyun ve her portun hesabını verin. O dosya, “bu sunucu gerçekte ne yapıyor” sorusunun kesin cevabıdır ve genellikle bir sürpriz içerir — bir metrik dışa aktarıcı, unutulmuş bir staging kopyası, hiçbir zaman olmaması gereken hâlde herkese açık bir arayüzde dinleyen bir veritabanı.Dışlama listenizi de aynı anda yazın, böylece ilk senkronizasyon istemediğiniz veriler için bir saat harcamaz:
cat > /root/mig/excludes <<'EOF' /dev /proc /sys /run /tmp /var/tmp /var/cache /var/lib/apt/lists /swapfile /var/lib/docker/overlay2 /var/lib/mysql /var/lib/postgresql **/node_modules **/.cache EOFVeritabanı dizinlerinin bilerek dışlandığını unutmayın. Bunların kendi adımları vardır ve onları burada kopyalamak, altıncı adımın önlemek için var olduğu hatadır.
- Yeni sunucuyu devreye alın ve herhangi bir şey tutmadan önce sertleştirin
Kutuyu sipariş edin, konumu seçin ve mümkünse eskiyle aynı ana işletim sistemi sürümünü alın. Sunucuları taşımak ile aynı işlemde Debian 12'den Debian 13'e geçmek, bir şey bozulduğunda hangi değişikliğin buna neden olduğunu bilemeyeceğiniz anlamına gelir. Önce taşıyın, sonra yükseltin.
Hassas herhangi bir şey üzerine inmeden önce, makineye on dakikalık sertleştirme geçişini uygulayın: yalnızca anahtarla SSH, devre dışı bırakılmış root girişi, varsayılan olarak reddeden bir güvenlik duvarı, gözetimsiz güvenlik güncellemeleri. Şimdi on dakika sürer ve daha sonra canlı bir servisin etrafına eklemek gerçekten sıkıcıdır.
Sonra, yalnızca bu taşıma için var olan bir anahtarı eski sunucuda oluşturun, böylece taşıma erişimini daha sonra iptal etmek kendi girişinize dokunmak anlamına asla gelmez:
# on the OLD server ssh-keygen -t ed25519 -f /root/.ssh/id_migrate -C 'migration' -N '' cat /root/.ssh/id_migrate.pubO genel anahtarı yeni sunucuda
/root/.ssh/authorized_keysiçine koyun, sonra gidiş yönünü doğrulayın — eski yeniye gönderir (push), böylece kimlik bilgisi ayrılmakta olduğunuz makinede yaşar ve onunla birlikte ölür:ssh -i /root/.ssh/id_migrate root@NEW_IP 'hostname; df -h /; free -m'Son olarak, yeni IP'yi eski sunucunun
/etc/hostsdosyasınanewboxgibi bir ad altında koyun. Bunu izleyen her komut hem daha kısa olur hem de, daha faydalı bir şekilde, sabahın birinde yanlış makineyi hedef almak daha zor hâle gelir. - Ona herhangi bir şeyi emanet etmeden önce yeni IP'yi kontrol edin
Artık daha önce kimsenin servisiniz için kullanmadığı bir adresiniz var ve bununla ilgili bir sorun bulmanın bedava olduğu son an budur. Üç kontrol, beş dakika:
Kara listeler. Adresi çoklu RBL kontrollerinden geçirin — tam prosedür ve sonuçların nasıl okunacağı burada. Spamhaus PBL gibi bir politika listesindeki bir isabet, bir veri merkezi IP'si için normaldir ve web trafiği için pek bir şey ifade etmez. SBL veya XBL'deki bir isabet ise gerçektir ve bunu gündeme getirme zamanı, kullanıcılarınız üzerinde olduktan sonra değil, şimdidir.
Ters DNS. Adresin bugün neyle yanıt verdiğini kontrol edin:
dig +short -x NEW_IPKutu posta gönderecekse, istediğiniz PTR kaydını talep edin ve A kaydı aynı IP'ye geri işaret eden bir ana bilgisayar adıyla eşleştiğinden emin olun. İleri ve ters yön uyuşmalıdır; bir uyuşmazlık, genel bir addan daha kötüdür.
Erişilebilirlik ve rota. Güvenlik duvarınızın yoldaki tek şey olduğunu varsaymak yerine, ihtiyacınız olan portların dışarıdan uçtan uca gerçekten açık olduğunu doğrulayın:
# from a third machine, or your laptop nc -vz NEW_IP 22 mtr -rwc 20 NEW_IPmtrçıktısı saklanmaya değer olandır. Son sıçramadaki (hop) kayıp önemlidir; aradaki bir sıçramadaki kayıp genellikle bir yönlendiricinin ICMP'yi önceliksizleştirmesidir ve hiçbir anlam taşımaz. Kullanıcılarınızın dünyanın hangi bölgesinde olduğundan gelen gecikme eski sağlayıcıya göre belirgin şekilde daha kötüyse, bunu şimdi öğrenmek daha iyidir; çünkü fikir değiştirmek hâlâ yalnızca bir siparişe mal olur, hiçbir veriye mal olmaz. - Dosya sistemini rsync ile kopyalayın — ve önce deneme çalıştırması yapın
Şimdi büyük hacimli aktarım. Bunu iki geçişte yapın: günler öncesinden, ne kadar sürerse sürsün tamamlanan ilk tam kopya, ardından yalnızca değişeni taşıyan kısa delta geçişleri. Her zaman önce deneme çalıştırması (dry-run) yapın — çıktı, tam olarak ne olmak üzere olduğunun bir listesidir ve onu bir kez okumak, buradaki başka herhangi bir alışkanlıktan daha fazla taşımayı kurtarmıştır.
# on the OLD server, dry run rsync -aHAXx --numeric-ids --info=progress2 --dry-run \ --exclude-from=/root/mig/excludes \ -e 'ssh -i /root/.ssh/id_migrate' \ /var/www/ root@newbox:/var/www/Sonra aynı komutu
--dry-runolmadan çalıştırın. Önemli olan her dizin için bunu tekrarlayın: bütün olarak değil seçici bir şekilde/etc,/home,/srv,/optve uygulamanızın yüklemelerini gerçekte nerede tuttuğu her yer.Bayraklar yerlerini hak ediyor.
-aizinleri, sahipliği, zaman damgalarını ve sembolik bağlantıları korur;-Hsabit bağlantıları (hard link) korur;-Ave-X, herhangi biri onları ayarladıysa yüklemeler dizininizin ihtiyaç duyduğu şey olan ACL'leri ve genişletilmiş öznitelikleri taşır;-x, rsync'in başka bağlı dosya sistemlerine dalmasını engeller.--numeric-ids, insanların dışarıda bıraktığı ve pişman olduğu bayraktır: o olmadan, rsync sahipliği ada göre eşler vewww-data'nın iki kutuda farklı bir UID'si varsa, her dosya, çözmesi sıkıcı bir şekilde yanlış kullanıcıya ait olarak gelir.İki uyarı.
/etc'yi çalışan bir sisteme bütün olarak kopyalamak, yeni makinenin ağ yapılandırmasının, fstab'ının ve SSH ana bilgisayar anahtarlarının üzerine yazar — dizini değil, ihtiyacınız olan belirli yapılandırmayı kopyalayın. Ve--delete'i yalnızca son geçiş için saklayın: yeni kutuyu eskiyle tam olarak eşleştirmek için doğrudur, ama hedefte zaten bir şey oluşturduysanız yıkıcıdır.İlk tam geçiş bittiğinde, düşündüğünüzü yaptığını bilmek için iki tarafı karşılaştırın:
du -sh /var/www ssh -i /root/.ssh/id_migrate root@newbox 'du -sh /var/www' - Veritabanını bir dump ile taşıyın, asla bir dosya kopyasıyla değil
Taşımanızın sıkıcı mı yoksa unutulmaz mı olacağına karar veren adım budur. Bir veritabanının veri dizini yalnızca sunucu durdurulduğunda tutarlıdır. Onu canlıyken kopyalarsanız, iyi görünen, sorunsuz aktarılan ve incelikli bir şekilde kalıcı olarak bozuk bir veritabanına geri yüklenen bir dosya kümesi elde edersiniz — çoğu zaman haftalar sonrasına kadar bir hata bile vermeden.
Onu düzgün bir şekilde dump edin. MySQL veya MariaDB için,
--single-transaction, işin tamamını kilitlemeden size tutarlı bir anlık görüntü veren şeydir:mysqldump --single-transaction --quick --routines --triggers --events \ --default-character-set=utf8mb4 --databases appdb \ | zstd -T0 > /root/mig/appdb.sql.zstPostgreSQL için, özel (custom) format buna değer — sıkıştırır ve gerekirse seçici olarak geri yüklemenize izin verir:
pg_dump -Fc -Z6 appdb > /root/mig/appdb.dumpKarşıya gönderin ve geri yükleyin:
scp -i /root/.ssh/id_migrate /root/mig/appdb.sql.zst root@newbox:/root/ # on the NEW server zstd -dc /root/appdb.sql.zst | mysql # postgres equivalent pg_restore -d appdb -j4 /root/appdb.dumpSonra doğrulayın, çünkü “geri yükleme bitti” ile “veri orada” farklı iddialardır. Önemli olan tablolardaki satır sayılarını her iki tarafta da karşılaştırın:
mysql -N -e "SELECT COUNT(*) FROM appdb.orders; SELECT COUNT(*) FROM appdb.users;"Dump'ların içinde gizlenen iki şey var: bozulmuş aksanlı karakterlerin nereden geldiği olan karakter kümesi ve collation — eski veritabanı
utf8kullanıyor veutf8mb4kullanmıyorsa, taşımanın aynı zamanda bunu düzeltme anı olup olmadığına bilerek karar verin; bir de veritabanı kullanıcıları ve yetkileri var, ki bunlarımysqldump --databasesiçermez. Uygulamanın kullanıcısını ve parolasını yeni kutuda açıkça yeniden oluşturun, sonra yapılandırmanızdaki bağlantı dizesinin bununla eşleşmesi gerektiğini unutmayın.Uygulamanız SQLite kullanıyorsa, dosyanın kendisi veritabanıdır ve aynı kural geçerlidir — onu canlıyken kopyalamayın. Güvenli bir şekilde tutarlı bir kopya alan
sqlite3 app.db ".backup /root/mig/app.db"komutunu kullanın. - Yığını ayağa kaldırın ve bir hosts dosyası geçersiz kılmasının arkasında prova edin
Yeni sunucuda artık dosyalar ve veri var. Her şeyi başlatın ve onu gerçek ana bilgisayar adı altında test edin — dünyanın geri kalanı hâlâ mutlu bir şekilde eski kutuyu kullanırken. Bu, tüm prosedürdeki en değerli numaradır ve bir satıra mal olur.
Kendi dizüstü bilgisayarınızda, yeni sunucunun IP'sini
/etc/hosts'a (veyaC:\Windows\System32\drivers\etc\hosts'a) ekleyin:203.0.113.10 example.com www.example.comTarayıcınız artık gerçek alan adını yeni sunucuya çözümler ve başka kimseninki bunu yapmaz. Her URL doğrudur, her çerez alan adı eşleşir, her yönlendirme ve geri çağrı (callback) yolu geçişten sonra davranacağı şekilde davranır — ki geçici bir
new.example.comalt alan adına karşı test etmenin tam olarak yakalayamadığı şey de budur, çünkü bir taşımada bozulan şeylerin yarısı ana bilgisayar adına bağımlıdır.Hiçbir şeyi düzenlemeden tek seferlik hızlı bir kontrol için,
curlaynı şeyi satır içinde yapabilir:curl -sSI --resolve example.com:443:203.0.113.10 https://example.com/ curl -sS --resolve example.com:80:203.0.113.10 http://example.com/ -o /dev/null -w '%{http_code}\n'Yalnızca ana sayfayı değil, uygulamanın tamamını gezin: giriş yapın, bir form gönderin, bir dosya yükleyin, bir parola sıfırlama postası tetikleyin, bir yönetici sayfası yükleyin, bir ödeme işlemcisinin çağırdığı uç noktaya (endpoint) gidin. Sonra her şey yolunda görünse bile hata günlüklerini okuyun — eksik PHP eklentileri, bir önbellek dizininde yanlış bir dosya modu ve henüz var olmayan bir veritabanı kullanıcısı, hepsi ekranda görünmeden önce orada görünür.
Daha sonra hosts satırını kaldırmayı unutmayın. Herkes bir kez unutur ve sonra geri dönüşün neden çalışmamış göründüğünü merak ederek yirmi dakika harcar.
- Herhangi bir şeyi çevirmeden önce yeni kutuda TLS'i çalışır hâle getirin
Sertifikalar IP adreslerine değil adlara bağlıdır, bu yüzden bir taşımayla ilgili hiçbir şey zaten sahip olduğunuz bir sertifikayı geçersiz kılmaz. Bozulan şey verilme sürecidir: olağan HTTP-01 doğrulaması, Let's Encrypt'ten, sertifikalandırılmakta olan adın 80 numaralı portu üzerinden bir dosya getirmesini ister ve o ad hâlâ eski sunucuya işaret eder. Tavuk mu yumurta mı sorunu, zorluğun tamamıdır ve bundan çıkmanın üç temiz yolu vardır.
Var olan sertifikaları kopyalayın. En basiti ve genellikle doğru olanı. Özel anahtar ve zincir, başka herhangi bir dosya gibi taşınır:
rsync -aHAX -e 'ssh -i /root/.ssh/id_migrate' \ /etc/letsencrypt/ root@newbox:/etc/letsencrypt/Yeni sunucu geçerli TLS'i hemen sunabilir ve DNS ona işaret eder etmez yenileme kendiliğinden çalışmaya başlar. Zamanlayıcının orada etkin olduğunu doğrulayın:
systemctl list-timers | grep certbot.Bir DNS-01 doğrulaması kullanın. Alan adı üzerindeki kontrolü bir HTTP isteği yerine bir TXT kaydı aracılığıyla kanıtlar, bu yüzden henüz hiçbir şeyin işaret etmediği bir sunucudan da çalışır. Geçişten önce yeni kutuda gerçekten bağımsız bir sertifika istiyorsanız idealdir ve bir wildcard için tek seçenektir.
Çeviriden sonra verin. Geçerlidir, ama sitenin sertifika olmadan yeni IP'de canlı olduğu bir boşluk bırakır; bu da HSTS kullanan herhangi bir şey için ziyaretçilerinizin tıklayıp geçebileceği bir uyarı değildir. Yalnızca kimsenin ziyaret etmediği yepyeni bir alan adı için mantıklıdır.
Hangisini seçerseniz seçin, aynı
--resolvenumarasını kullanarak geçişten önce doğrudan yeni IP'ye karşı doğrulayın:curl -sSI --resolve example.com:443:203.0.113.10 https://example.com/ | head -1 echo | openssl s_client -connect 203.0.113.10:443 -servername example.com 2>/dev/null \ | openssl x509 -noout -subject -datesTarihleri ve subject'in
wwwdahil sunduğunuz her adı kapsadığını kontrol edin. Ve uzun bir max-age ile HSTS kullanıyorsanız, sertifikayı çeviriden sonra değil önce doğru olması gereken tek şey olarak ele alın — o başlık, geri dönen her ziyaretçiye zaten verdiğiniz bir sözdür. - Geçiş: yazmaları dondurun, son delta, kaydı değiştirin
On dakikalık gerçek bir iş ve üzerinde saat işleyen tek kısım. Bunu sabah, kendi saat diliminizde, başka bir şeyle meşgul olmadığınız bir günde yapın. Asla bir Cuma günü değil.
Dondur. Eski uygulamayı bakım veya salt okunur moduna alın. Worker'ları, kuyruk tüketicilerini ve cron işlerini durdurun — tarayıcı bağlı olmadan yazan her şeyi. Bu noktadan itibaren, eski kutuda yeni hiçbir şey yazılmaz, ki bundan sonraki her şeyi güvenli kılan da budur:
# on the OLD server systemctl stop app-worker.service systemctl stop cron touch /var/www/maintenance.flagSon delta. Bir rsync daha, artık hedefin tam olarak eşleşmesi için
--deleteile, ve bir dump daha. İlk geçiş günler önce yapıldığı için, bu çok az şey taşır ve saniyeler sürer:rsync -aHAXx --numeric-ids --delete --exclude-from=/root/mig/excludes \ -e 'ssh -i /root/.ssh/id_migrate' /var/www/ root@newbox:/var/www/ mysqldump --single-transaction --quick --routines --triggers --events \ --default-character-set=utf8mb4 --databases appdb | zstd -T0 \ | ssh -i /root/.ssh/id_migrate root@newbox 'zstd -dc | mysql'Kontrol et. Her iki tarafta satır sayıları, hosts dosyası geçersiz kılması üzerinden uygulamadan bir geçiş daha ve yeni kutudaki bakım bayrağını kaldırma.
Çevir.
Akaydını yeni IP'ye değiştirin.AAAAkaydını da değiştirin — bir geçişin yarım çalışmasının en yaygın tek yolu budur. Kontrol etmediğiniz bir çözümleyiciden doğrulayın:dig +short example.com A @1.1.1.1 dig +short example.com AAAA @1.1.1.1Sonra her iki makineyi de izleyin. Trafik bir iki dakika içinde yenisinde belirmeli ve sonraki beş dakika içinde eskisinden kaybolmalıdır:
tail -f /var/log/nginx/access.log # on both, side by sideEski uygulamayı kapatmak yerine bakım modunda bırakın. Ona ulaşan gecikmiş bir istek, bir bağlantı hatası yerine kibar bir sayfa görür ve muhtemelen ihtiyaç duymayacağınız geri dönüş için makineyi kullanılabilir tutarsınız.
- Bir hafta izleyin, sonra düzgün bir şekilde hizmet dışı bırakın
Taşıma, DNS çözümlendiğinde bitmiş olmaz. Tam bir faturalandırma ve cron döngüsü sürprizsiz geçtiğinde biter.
İlk saatlerde, çalışma süresini değil hata oranlarını izleyin — bir sunucu mükemmel şekilde ayakta olabilir ve isteklerin üçte birine 500 döndürebilir:
journalctl -u nginx -u php8.4-fpm -f awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | headSonra kısa bir listeyi sırayla ele alın, çünkü bir taşımadan sonra gerçekte bozulan şeyler bunlardır ve hiçbiri kendini haber vermez: yeni kutuda çalışan cron işleri ve systemd zamanlayıcıları (ikinci adımda aldığınız envantere karşı
systemctl list-timers); giden postanın ulaşması ve spam'e düşmemesi; hâlâ eskisini arşivlemek yerine yeni sunucuya işaret eden zamanlanmış yedekler; IP adresiniz bir izin listesinde (allowlist) bulunan herhangi bir üçüncü taraf — bir ödeme işlemcisi, bir API, bir ortağın güvenlik duvarı; ve yalnızca ayın birinde kendini kanıtlayan aylık iş.Eski sunucuyu en az bir hafta boyunca çalışır, bakım modunda ve dokunulmamış hâlde bırakın. O sizin geri dönüşünüz ve referans kopyanızdır ve mal olduğu birkaç dolardan çok daha değerlidir. Sonra onu şu sırayla kapatın: okuyabileceği her sırrı döndürün, üçüncü bir konuma son bir şifrelenmiş arşiv alın, uygulama ve veritabanı dizinlerinin üzerine yazın, sağlayıcının yok etme veya yeniden kurulum işlemini çalıştırın ve ancak o zaman iptal edin — yenileme tarihini kontrol ettikten sonra, çünkü fazladan bir aylık geri dönüş sigortası genellikle daha iyi bir takastır.
Son olarak, artık beş dakikalık geri döndürülebilirliğe ihtiyacınız kalmadığına göre TTL'yi tekrar 3600'e çıkarın ve elinizde tuttuğunuz her türlü belgeyi yeni adresle güncelleyin. Daha sonraki bir gece saat ikide, gelecekteki siz, çalışma kılavuzunun sunucuyla eşleştiğine son derece minnettar kalacaksınız.
Posta, geri kalanıyla birlikte taşınmaz
Eski sunucu posta gönderiyorsa — yalnızca parola sıfırlamaları bile olsa — bunu, birincisiyle birlikte yürüyen ikinci ve daha yavaş bir taşıma olarak ele alın. Teslim edilebilirlik bir itibar sistemidir ve itibar, kopyaladığınız yazılıma değil, IP adresine ve alan adına bağlıdır.
Dört kayıt, postanızın okunup okunmayacağına ya da atılıp atılmayacağına karar verir ve bunlardan üçü, sunucu değiştiğinde değişen şeyler içerir:
- SPF, alan adınız için kimin gönderim yapabileceğini listeler. Sizinki bir
ip4:literali içeriyorsa, artık yanlıştır. Yeni IP'yi geçişten önce ekleyin ve eskisini bir hafta sonra kaldırın — birkaç gün boyunca her iki adresin de yetkili olması hiçbir şeye mal olmaz ve örtüşmeyi kapsar. - DKIM, mesajı özel bir anahtarla imzalar. Anahtarı yapılandırmanın geri kalanıyla birlikte kopyalayın, seçici (selector) çalışmaya devam eder. Bunun yerine taze bir anahtar üretirseniz yeni seçiciyi yayımlamanız ve onu beklemeniz gerekir, bu yüzden aksini gerektiren bir nedeniniz olmadıkça kopyalayın.
- DMARC, ilk ikisi başarısız olduğunda alıcılara ne yapacaklarını söyler.
p=rejectüzerindeyseniz, pencere sırasında bozuk bir SPF bir uyarı değil, sessiz bir silmedir. Taşıma haftası içinp=none'a düşürmeyi ve sonra geri koymayı düşünün. - PTR, yukarıdaki ters kayıttır. Yeni bir IP, siz istemediğiniz sürece genel bir tanesine sahiptir ve birçok büyük sağlayıcı genel ters adlardan gelen postayı doğrudan reddeder.
Dürüst beklenti şudur: yepyeni bir IP hiçbir itibarla başlar, ki bu iyi bir itibarla aynı şey değildir. Hacim, saatler içinde değil günler içinde artar. Posta sizin için kritik önem taşıyorsa, tek adımda geçiş yapmak yerine eski sunucuyu taşımadan sonra bir hafta boyunca canlı ve gönderim yapar hâlde tutun — ve eğer bu iş açısından kritikse, özel bir röle her iki kutudan da daha iyi bir cevaptır.
Durumu kötüleştirmeden geri dönmek
Bir geri dönüş planının amacı, onu kullanmayı beklemeniz değildir. Amaç, sabah 10'da endişeyle değil sakin bir şekilde geçiş yapmanızı sağlamasıdır ve hataları asıl önleyen şey de bu sakinliktir.
Geri dönüşünüz basittir ve eski veritabanı hâlâ yetkili olduğu sürece basit kalır: A kaydını geri değiştirin. 300 saniyelik bir TTL ile beş dakika içinde toparlanmış olursunuz. O pencere — çeviri ile yalnızca yeni kutuda var olan ilk yazma arasındaki an — sizin ücretsiz geri alma imkânınızdır ve eski sunucunun en az bir hafta boyunca dokunulmadan ve silinmeden çalışır durumda kalmasının nedeni de budur.
Bunu mahveden şey split-brain'dir: her iki makineye de yazma düşmesi. Artık iki veritabanından hiçbiri doğru değildir ve bunları elle uzlaştırmak, kaçındığınız her türlü kesintiden daha kötüdür. Üç alışkanlık bunu tamamen önler:
- DNS'in trafiği göndermeyi durdurduğuna güvenmek yerine, pencerenin başında eski uygulamayı salt okunur veya bakım moduna alın. DNS bir ipucudur; durdurulmuş bir servis ise bir gerçektir.
- Çeviriden sonra, yeninkini değil eski sunucunun erişim günlüğünü izleyin. Oraya hâlâ ulaşan istekler sizin gecikmiş kalanlarınızdır ve bu sızıntı durduğunda taşıma gerçekten bitmiş demektir.
tail -f /var/log/nginx/access.log, aracın tamamıdır. - Yeni kutudaki ilk gerçek yazmayı kabul ettiğiniz anda, geri dönmek artık bir DNS değişikliği değildir — bir geri yüklemedir. Bu çizgiyi ne zaman geçtiğinizi bilinçli olarak karar verin ve iki kişiyseniz bunu yüksek sesle söyleyin.
Başlamadan önce kendinize bir durdurma kuralı koyun: eğer yeni yığın, diyelim ki otuz dakika içinde doğru şekilde hizmet vermiyorsa, kaydı eski hâline döndürün, akşamı geri alın ve saat işlemiyorken sorunu çözün. Taşımalar, insanlar geri dönmenin başarısızlık gibi hissettirmesi yüzünden ileriye doğru zorlamaya devam ettiğinde kötü gider. Oysa öyle değildir; ucuz olan seçenek odur ve yalnızca kesinlikle sınırlı bir süre için mevcuttur.
Hizmet dışı bırakma: döndür, sil, doğrula, sonra iptal et
Geçişten bir hafta sonra, eski sunucu, artık ilgilenmediğiniz bir altyapı üzerinde verilerinizin eksiksiz, çalışan ve gözetimsiz bir kopyasıdır. Aynı zamanda o noktada, sahip olduğunuz en az yamalanmış makinedir. İşi şu sırayla bitirin:
- Eski kutunun okuyabildiği her şeyi döndürün. Uygulama sırları, API token'ları, veritabanı parolaları, SMTP kimlik bilgileri, webhook imzalama sırları, herhangi bir cüzdan RPC parolası. İfşa edildiğini varsayın, çünkü aksini kanıtlayamazsınız. Taşıma için taze bir SSH anahtarı ürettiyseniz, eski yetkilendirilmiş anahtarların çıkarılma zamanı da tam olarak budur.
- Son bir arşiv alın — ikisi de olmayan bir hedefe şifrelenmiş bir restic veya Borg anlık görüntüsü (snapshot). Onu tam olarak bir kez, altı hafta sonra, kimsenin hatırlamadığı bir dosya için isteyeceksiniz.
- Veriyi üzerine yazın. Bir VPS'te fiziksel ortamı doğrulayamazsınız, bu yüzden yapabildiğinizi yapın: uygulama ve veritabanı dizinlerini
shrededin ya da üzerine yazın, sonra sağlayıcının yeniden kurulum veya yok etme rutininin çalışmasına izin verin. Baştan itibaren bekleme hâlinde şifreleme, bunu ucuza getiren şeydir; o olmadan, başkasının silme politikasına güvenmiş olursunuz. - Doğrula, sonra iptal et. Yeni kutunun, kimsenin aklına gelmeyen aylık cron dahil, tam bir hafta boyunca her şeye hizmet verdiğini doğrulayın ve eski kutuda hiçbir şeyin hâlâ çözümlenmediğini teyit edin. Sonra iptal edin — ve önce yenileme tarihini kontrol edin, çünkü fazladan bir aylık geri dönüş sigortası için ödeme yapmak, çoğu zaman sekiz doları biriktirmekten daha akıllıcadır.
Eski hesabın kendisini en son ve yalnızca emin olduğunuzda silin. Destek talepleri, faturalar ve tuhaf bir şekilde unutulmuş bir alt servis genellikle orada yaşar ve giriş yapamadığınız bir hesap, taşımayı unuttuğunuz bir DNS kaydını keşfetmek için garip bir yerdir.
İşe yarayan bir zaman çizelgesi
Bir haftaya yayıldığında bunların hiçbiri stresli değildir. Bir akşama sıkıştırıldığında ise hepsi stresli olur.
- Gün −7. Her TTL'yi 300'e düşürün. Eski sunucunun envanterini çıkarın. Yeniyi sipariş edin ve IP'sini, rDNS'ini ve rotasını kontrol edin.
- Gün −5. Yeni kutuyu sertleştirin. Yığını kurun. İlk tam
rsync, ki bu yavaş olanıdır — sonraki her geçiş yalnızca deltayı taşır. - Gün −3. Yeni kutuya bir veritabanı dump'ını geri yükleyin ve uygulamayı ayağa kaldırın. Her şeyi bir hosts dosyası geçersiz kılma yöntemiyle test edin. Hiçbir şey tehlikede değilken bozuk olanı düzeltin, çünkü bir şey tehlikede olacak.
- Gün −1. Yeni sunucuda TLS verin. Sertifika zincirini ve, eğer kullanıyorsanız, HSTS'in küçük bir hatayı tıklanamaz bir hataya dönüştürmeyeceğini doğrulayın. Yeni IP'yi SPF'ye ekleyin. Her TTL'nin gerçekten düştüğünü yeniden kontrol edin.
- Gün 0, sabah. Eski kutuda bakım modu. Son delta senkronizasyonu. Son dump ve geri yükleme. Satır sayısı kontrolü. A kaydını değiştirin — AAAA'yı da. Her iki erişim günlüğünü de izleyin.
- Gün +1 ile +7 arası. Eski sunucu ayakta ve dokunulmamış kalır. Günlükleri, postayı ve yeni IP'nin itibarını izleyin. Yapabiliyorsanız aylık işlerin en az bir kez çalışmasına izin verin.
- Gün +7. Sırları döndürün, son arşivi alın, silin, doğrulayın, iptal edin.
Sıkıcı bir taşımanın tek en iyi göstergesi, birinci adımın beşinci adımdan bir hafta önce gerçekleşmiş olmasıdır. Bir sunucu taşımasında yanlış giden hemen hemen her şey, gece saat on birde hâlâ 86400 olan bir TTL'dir.
Sık sorulan sorular
Bir VPS taşıması gerçekten sıfır kesintiyle olabilir mi?
Her iki makinede de sürekli olarak yazma kabul edilen tam anlamıyla sıfır kesinti, replikasyon ve paylaşılan ya da kümelenmiş bir veritabanı gerektirir — gerçekten zor bir problemdir ve tek bir sunucu için yanlış olan problemdir. Güvenilir bir şekilde ulaşılabilir olan şey, hiçbir ziyaretçinin hata görmemesi ve hiçbir yazmanın kaybolmamasıdır: son senkronizasyon sırasında kısa bir salt okunur pencere, DNS'in çevirmenin kendisinin dakikalar sürmesi için zaten 300 saniyelik bir TTL'de olmasıyla birlikte. Pratikte bu, neredeyse her site için sıfırdan ayırt edilemeyen ve alternatiften çok daha güvenli olan, bir ila beş dakikalık bir bakım sayfası demektir.
DNS yayılması gerçekte ne kadar sürer?
Yayılma diye bir şey yoktur. Hiçbir şey hiçbir yere itilmez — çözümleyiciler yalnızca kaydınızı TTL'nizin belirttiği saniye sayısı kadar önbelleğe alır ve süresi dolduğunda tekrar sorar. Yani dürüst cevap “değişikliği yaptığınız anda geçerli olan TTL kadar sürer”dir. Bir hafta önce 300'e ayarlanmış bir TTL ile, esasen herkes beş dakika içinde yeni adrestedir. Birçok kayıt şirketinin hâlâ varsayılan olarak kullandığı 86400 ile, bazı çözümleyiciler trafiği tam bir gün boyunca eski sunucuya göndermeye devam eder. TTL'yi düşürmenin birinci adım olup dokuzuncu adım olmamasının nedeni de budur.
Sunucu değiştirdiğimde IP adresimi koruyabilir miyim?
Adres uzayının kendisine sahip olmadığınız ve onun yeni sağlayıcı tarafından duyurulmasını sağlayamadığınız sürece hayır; bu da kendi tahsisinize sahip bir RIPE veya ARIN üyesi olmak anlamına gelir — bir şirket için gerçekçidir, tek bir sunucu için değil. Geri kalan herkes için, yeni bir sunucu yeni bir IP anlamına gelir; itibarını ve ters DNS'ini geçişten sonra değil önce kontrol etmenizin tam nedeni de budur. Bizim tarafımızda, adresler Spamhaus'a ve yüzden fazla başka listeye karşı taranır ve en son kimde olduğundan geri dönüştürülmek yerine risk bölümlendirilmiş havuzlardan verilir, ama bunu kendiniz doğrulamak beş dakika sürer ve yapmaya her zaman değer.
Bunun yerine bir disk imajı veya bir sağlayıcı taşıma aracı mı kullanmalıyım?
Her iki uç da aynı sağlayıcı ve aynı hipervizörse, bir imaj geri yüklemesi sorunsuzdur ve çok daha hızlıdır. Sağlayıcılar arasında ise genellikle bir tuzaktır: imaj, eski makinenin ağ yapılandırmasını, çekirdek modüllerini, sürücülerini ve donanım varsayımlarını taşır ve artık var olmayan bir makineye açılan bir sistemi hata ayıklayarak akşamı geçirirsiniz. Temiz bir kurulum artı verilerinizin ve yapılandırmanızın özenle düşünülmüş bir kopyası, size anladığınız bir sunucu verir ve eskisinin birikmiş pisliğini bırakır. Taşınmak, geride bir şeyler bırakmak için elde edeceğiniz en ucuz fırsattır.
Sürekli olarak yazılmakta olan bir veritabanı ne olacak?
Artan çaba sırasına göre iki seçenek. Basit olanı, dokuzuncu adımdaki salt okunur penceredir: yoğun ama normal boyutlu bir veritabanının --single-transaction dump'ı saniyeler ile birkaç dakika arasında sürer ve o kadarlık bir bakım sayfası makul bir takastır. Kapsamlı olanı ise replikasyondur — yeni sunucuyu günler öncesinden bir replika olarak kurun, senkronize kalmasına izin verin, sonra pencere sırasında onu terfi ettirin. Bu, dondurmayı saniyelere indirir, ama bunun bedeli gerçekten daha karmaşık bir kurulumdur. İkinciyi yalnızca birincisi kabul edilebilir değilse seçin ve bunu asla o gece doğaçlama yapmayın.
Sunucu değiştirmek arama sıralamalarıma zarar verir mi?
Tek başına hayır. Google, IP adreslerini değil ana bilgisayar adlarını indeksler ve URL'lerin ile içeriğin aynı kaldığı bir taşıma etkin bir şekilde görünmezdir. Size mal olan şey, kötü bir taşımaya eşlik etme eğiliminde olan şeydir: tarayıcılar ziyaret ederken 5xx döndüren sayfalar, bir sertifika hatası, içinde Disallow: / bulunan bir staging kopyasından gelmiş bir robots.txt ya da sessizce şekli değişmiş yönlendirmeler. Çeviriden hemen sonra robots.txt'i, canonical etiketlerinizi ve bir avuç gerçek URL'yi kontrol edin. Site, yeni IP'de eskisiyle aynı yanıtları veriyorsa, telafi edilecek hiçbir şey yoktur.
TLS sertifikalarım yeni sunucuda hâlâ çalışır mı?
Evet — sertifikalar IP adresleri için değil alan adları için verilir, bu yüzden /etc/letsencrypt'i karşıya kopyalamak size yeni kutuda hemen geçerli bir sertifika verir. Karmaşık olan kısım geçerlilik değil yenilemedir: bir HTTP-01 doğrulaması, alan adının yenilemeyi yapan makineye işaret etmesini gerektirir, bu yüzden DNS'i çevirene kadar orada yenileme başarısız olur. Sertifikaları geçişten önce kopyalayın, çevirin, sonra yenileme zamanlayıcısının yeni sunucuda başarıyla çalıştığını doğrulayın. Çeviriden önce bağımsız bir sertifikaya — ya da bir wildcard'a — ihtiyacınız varsa, bunun yerine bir DNS-01 doğrulaması kullanın.
