VPS-migreringscheckliste: backups, DNS, TLS og rollback
En praktisk migreringssekvens for en selvhostet applikation: opgørelse, konsistente backups, en testet destination, kontrollerede skrivninger, DNS cutover og en gendannelsesvej.
Kort overblik
En kontrolleret VPS-migrering opgør tjenester og data, opretter en konsistent backup, bekræfter en gendannet destination, tester hostname- og TLS-routing, koordinerer endelige skrivninger og DNS og bevarer en dataopmærksom rollback. Ingen checkliste alene garanterer nul nedetid.
Opgør applikationen, før du flytter den
List de tjenester, versioner, porte, planlagte opgaver, databaser, uploadede filer og konfiguration, der er nødvendig for, at applikationen fungerer. Identificér, hvor skrivninger sker, og hvilke eksterne tjenester den afhænger af. Et kopieret webkatalog er ikke en komplet migrering, når dataene ligger andre steder.
Registrér aktuelle DNS-navne, aktive IPv4 og IPv6-poster, metoder til certifikatfornyelse og en gendannelsesadgangsvej. Opbevar hemmeligheder i dine private deployment-værktøjer. Læg ikke adgangskoder, private nøgler eller databasedumps i et offentligt dokumentrod eller en delt migreringscheckliste.
Opret en konsistent backup, og bevis, at den gendannes
Brug databaseunderstøttet backupmekanisme i stedet for at kopiere vilkårlige filer, mens skrivninger fortsætter. For SQLite opretter Online Backup API et konsistent databasesnapshot. I WAL-tilstand deltager WAL-filen i vedvarende databasetilstand, så kopiering af kun den primære databasefil kan udelade committede ændringer.
En konsistent databasebackup er ikke automatisk konsistent med separat lagrede uploads, køer eller filer. Koordinér deres optagelse med din applikation. Gendan til en separat testplacering, og bekræft poster, filreferencer og applikationsadfærd, før du betragter backupen som brugbar.
Forbered destinationen, før du ændrer DNS
Opret de tilsigtede brugere, tilladelser, runtime-versioner, tjenester og applikationskataloger på den nye server. Gendan testbackupen til dens destinationsdatalager, uden for det offentlige webrod, hvor det er relevant. Kontrollér ejerskab og adgang ved hjælp af den tjenestekonto, der faktisk skal køre applikationen.
Bevar ikke-relaterede sites på en delt server. Brug et dedikeret dokumentrod, virtuel host og runtime, validér web-serverkonfigurationen og forbered en rollback, der kun gendanner de filer og den konfiguration, som denne ændring ejer.
Test det rigtige hostname og certifikat på den nye server
En browseranmodning til en bar IP-adresse gengiver ikke hostname-baseret routing eller certifikatvalidering. curl --resolve lader en test bruge det tilsigtede hostname og en valgt destinations-IP, mens de normale hostname- og TLS-kontroller bevares. Kontrollér også HTTP-status og forventet applikationsindhold. Eksemplet bruger kun dokumentationsværdier; erstat dem med dit eget bekræftede domæne og din egen destination.
Et gyldigt certifikat og en tilladt netværksvej skal allerede eksistere, for at den test kan bestå. Deaktivér aldrig certifikatbekræftelse for at kalde migreringen klar. DNS-baseret ACME-validering kan validere et domæne uden at ændre dets web-serveradresse; HTTP-baseret validering har forskellige tilgængelighedskrav. Test fornyelse separat fra den oprindelige udstedelse.
curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/Vælg en plan for skrivekontrol og endelig synkronisering
Planlæg en kort vedligeholdelsesperiode eller en anden applikationspassende konsistensmekanisme. Stop eller omdiriger de skrivere, du identificerede, tag den endelige konsistente databasebackup, synkronisér de tilsvarende mutable filer, og bekræft resultatet. Kø-arbejdere, webhooks og cron-opgaver kan skrive, selv når den offentlige grænseflade ser stille ud.
Brug en tør kørsel før en filsyntronisering. Tilføj ikke sletteflag eller kopier hele systemkataloger som en genvej. Hold den gamle tjeneste gendannelig, indtil du har kontrolleret den nye applikation og fastlagt, hvilken placering der er autoritativ for skrivninger.
Ændr DNS, og observer derefter begge adressefamilier
Opdatér de poster, der kræves for tjenesten, og tag højde for eksisterende resolver-caches. Kontrollér de autoritative svar og flere normale klientveje. Hvis en forældet AAAA-post forbliver aktiv, kan IPv6-klienter fortsætte med at nå den gamle server, mens IPv4-klienter når den nye.
Test login, læsninger, skrivninger, uploads, baggrundsjob og eksterne callbacks på den nye tjeneste. Undgå at køre to uafhængige skrivbare kopier af den samme applikation under overgangen. Behold en klar regel for håndtering af trafik, der stadig når den gamle destination.
Gør rollback til en databeslutning såvel som en DNS-beslutning
Definér fejlbetingelserne, der udløser en rollback, og hvem der styrer cutover. At vende tilbage til DNS alene er ikke nok, efter nye skrivninger er nået destinationen: du skal bevare eller afstemme disse data, før du vender tilbage til en ældre kopi.
Behold kilden og backups i en passende gendannelsesperiode. Fjern gammel adgang, og nedlæg ressourcer først, efter at destinationen, backups, fornyelse og overvågning er blevet kontrolleret. Opbevaring og sletning bør følge den faktiske servicepolitik, ikke et generisk fast antal timer.