Listă de verificare pentru migrarea VPS: backupuri, DNS, TLS și rollback
O secvență practică de migrare pentru o aplicație auto-găzduită: inventar, backupuri consistente, o destinație testată, scrieri controlate, comutare DNS și o cale de restaurare.
Dintr-o privire
O migrare VPS controlată inventariază serviciile și datele, creează un backup consistent, verifică o destinație restaurată, testează numele de gazdă și rutarea TLS, coordonează scrierile finale și DNS și păstrează un rollback conștient de date. Nicio listă de verificare singură nu garantează zero downtime.
Inventariază aplicația înainte de a o muta
Listează serviciile, versiunile, porturile, sarcinile programate, bazele de date, fișierele încărcate și configurația necesare pentru ca aplicația să funcționeze. Identifică unde au loc scrierile și de ce servicii externe depinde. Un director web copiat nu este o migrare completă când datele se află în altă parte.
Înregistrează numele curente DNS, IPv4 active și înregistrările IPv6, metodele de reînnoire a certificatelor și o cale de acces pentru recuperare. Păstrează secretele în instrumentele tale private de implementare. Nu pune parole, chei private sau dumpuri de bază de date într-un director rădăcină public sau într-o listă de verificare partajată pentru migrare.
Creează un backup consistent și dovedește că se restaurează
Folosește mecanismul de backup acceptat de baza de date, în loc să copiezi fișiere arbitrare în timp ce scrierile continuă. Pentru SQLite, Online Backup API creează un instantaneu consistent al bazei de date. În modul WAL, fișierul WAL participă la starea persistentă a bazei de date, astfel încât copierea doar a fișierului principal al bazei de date poate omite modificări confirmate.
Un backup consistent al bazei de date nu este automat consistent cu încărcările, cozile sau fișierele stocate separat. Coordonează capturarea lor cu aplicația ta. Restaurează într-o locație de test separată și verifică înregistrările, referințele către fișiere și comportamentul aplicației înainte de a trata backupul ca utilizabil.
Pregătește destinația înainte de a schimba DNS
Creează pe noul server utilizatorii, permisiunile, versiunile de runtime, serviciile și directoarele aplicației dorite. Restaurează backupul de test în locația sa de date de destinație, în afara directorului web public acolo unde este cazul. Verifică proprietatea și accesul folosind contul de serviciu care va rula efectiv aplicația.
Păstrează site-urile fără legătură de pe un server partajat. Folosește un director rădăcină dedicat, un virtual host și un runtime dedicat, validează configurația serverului web și pregătește un rollback care restaurează doar fișierele și configurația deținute de această schimbare.
Testează numele de gazdă real și certificatul pe noul server
O cerere de browser către o adresă IP simplă nu reproduce rutarea bazată pe numele de gazdă sau validarea certificatului. curl --resolve permite unui test să folosească numele de gazdă dorit și o adresă IP de destinație aleasă, păstrând verificările normale ale numelui de gazdă și TLS. Verifică și statusul HTTP și conținutul așteptat al aplicației. Exemplul folosește valori doar pentru documentație; înlocuiește-le cu propriul domeniu și propria destinație verificate.
Un certificat valid și o cale de rețea permisă trebuie să existe deja pentru ca acel test să treacă. Nu dezactiva niciodată verificarea certificatului pentru a declara migrarea gata. Validarea ACME bazată pe DNS poate valida un domeniu fără a-i schimba adresa serverului web; validarea bazată pe HTTP are cerințe de accesibilitate diferite. Testează reînnoirea separat de emiterea inițială.
curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/Alege un plan de control al scrierilor și de sincronizare finală
Programează o perioadă scurtă de mentenanță sau un alt mecanism de consistență adecvat aplicației. Oprește sau redirecționează scriitorii pe care i-ai identificat, fă backupul final consistent al bazei de date, sincronizează fișierele mutabile corespunzătoare și verifică rezultatul. Workerii din cozi, webhook-urile și sarcinile cron pot scrie chiar și atunci când interfața publică pare liniștită.
Folosește o simulare înainte de o sincronizare de fișiere. Nu adăuga opțiuni de ștergere și nu copia directoare întregi de sistem ca scurtătură. Păstrează serviciul vechi recuperabil până când ai verificat noua aplicație și ai stabilit care locație este autoritară pentru scrieri.
Schimbă DNS, apoi observă ambele familii de adrese
Actualizează înregistrările necesare pentru serviciu și ține cont de cache-urile existente ale resolverelor. Verifică răspunsurile autoritative și mai multe căi normale ale clienților. Dacă rămâne activă o înregistrare AAAA obsoletă, clienții IPv6 pot continua să ajungă la serverul vechi, în timp ce clienții IPv4 ajung la cel nou.
Testează autentificarea, citirile, scrierile, încărcările, sarcinile din fundal și callback-urile externe pe noul serviciu. Evită rularea a două copii independente care pot scrie ale aceleiași aplicații în timpul tranziției. Păstrează o regulă clară pentru gestionarea traficului care ajunge încă la destinația veche.
Fă din rollback o decizie privind datele, precum și o decizie privind DNS
Definește condițiile de eșec care declanșează un rollback și cine controlează comutarea. Revenirea doar la DNS nu este suficientă după ce noi scrieri au ajuns la destinație: trebuie să păstrezi sau să reconciliezi acele date înainte de a reveni la o copie mai veche.
Păstrează sursa și backupurile pentru o perioadă de recuperare adecvată. Elimină accesul vechi și dezafectează resursele numai după ce destinația, backupurile, reînnoirea și monitorizarea au fost verificate. Retenția și ștergerea trebuie să urmeze politica reală a serviciului, nu un număr generic fix de ore.