Sjekkliste for VPS-migrering: sikkerhetskopier, DNS, TLS og tilbakerulling
En praktisk migreringssekvens for en selvhostet applikasjon: inventar, konsistente sikkerhetskopier, en testet destinasjon, kontrollerte skrivinger, DNS-overgang og en gjenopprettingsvei.
I et øyeblikk
En kontrollert VPS-migrering inventerer tjenester og data, lager en konsistent sikkerhetskopi, verifiserer en gjenopprettet destinasjon, tester vertsnavn og TLS-ruting, koordinerer endelige skrivinger og DNS, og bevarer en databevisst tilbakerulling. Ingen sjekkliste alene garanterer null nedetid.
Inventer applikasjonen før du flytter den
List opp tjenestene, versjonene, portene, planlagte oppgaver, databaser, opplastede filer og konfigurasjonen som trengs for at applikasjonen skal fungere. Identifiser hvor skrivinger skjer og hvilke eksterne tjenester den er avhengig av. En kopiert webkatalog er ikke en fullstendig migrering når dataene ligger et annet sted.
Registrer gjeldende DNS-navn, aktive IPv4 og IPv6-poster, metoder for sertifikfornyelse og en gjenopprettingsvei for tilgang. Oppbevar hemmeligheter i ditt private distribusjonsverktøy. Ikke legg passord, private nøkler eller databasedumper i en offentlig dokumentrot eller en delt migreringssjekkliste.
Lag en konsistent sikkerhetskopi og bevis at den gjenopprettes
Bruk databasesstøttet sikkerhetskopimekanisme i stedet for å kopiere vilkårlige filer mens skrivinger fortsetter. For SQLite oppretter Online Backup API et konsistent databaseøyeblikksbilde. I WAL-modus deltar WAL-filen i vedvarende databasetilstand, så å kopiere bare hoveddatabasefilen kan utelate bekreftede endringer.
En konsistent databasesikkerhetskopi er ikke automatisk konsistent med separat lagrede opplastinger, køer eller filer. Koordiner opptaket av dem med applikasjonen din. Gjenopprett til et separat teststed og verifiser poster, filreferanser og applikasjonsoppførsel før du behandler sikkerhetskopien som brukbar.
Forbered destinasjonen før du endrer DNS
Opprett de tiltenkte brukerne, tillatelsene, kjøretidsversjonene, tjenestene og applikasjonskatalogene på den nye serveren. Gjenopprett testsikkerhetskopien til dens destinasjonsdatalokasjon, utenfor den offentlige webroten der det er hensiktsmessig. Sjekk eierskap og tilgang ved å bruke tjenestekontoen som faktisk skal kjøre applikasjonen.
Bevar ikke-relaterte nettsteder på en delt server. Bruk en dedikert dokumentrot, virtuell vert og kjøretid, valider web-tjenerkonfigurasjonen og forbered en tilbakerulling som bare gjenoppretter filene og konfigurasjonen som tilhører denne endringen.
Test det faktiske vertsnavnet og sertifikatet på den nye serveren
En nettleserforespørsel til en bar IP-adresse gjengir ikke vertsnavnbasert ruting eller sertifikatvalidering. curl --resolve lar en test bruke det tiltenkte vertsnavnet og en valgt destinasjons-IP mens den beholder de vanlige vertsnavn- og TLS-sjekkene. Sjekk HTTP-statusen og forventet applikasjonsinnhold også. Eksemplet bruker kun dokumentasjonsverdier; erstatt dem med ditt eget verifiserte domene og din destinasjon.
Et gyldig sertifikat og en tillatt nettverksvei må allerede eksistere for at testen skal bestå. Deaktiver aldri sertifikatverifisering for å kalle migreringen klar. DNS-basert ACME-validering kan validere et domene uten å endre web-tjeneradressen; HTTP-basert validering har andre tilgjengelighetskrav. Test fornyelse separat fra den opprinnelige utstedelsen.
curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/Velg en plan for skrivekontroll og endelig synkronisering
Planlegg en kort vedlikeholdsperiode eller en annen applikasjonstilpasset konsistensmekanisme. Stopp eller omdiriger skriverne du identifiserte, ta den endelige konsistente databasesikkerhetskopien, synkroniser de tilsvarende muterbare filene og verifiser resultatet. Køarbeidere, webhooks og cron-oppgaver kan skrive selv når det offentlige grensesnittet ser stille ut.
Bruk en tørrkjøring før en filsynkronisering. Ikke legg til sletteflagg eller kopier hele systemkataloger som en snarvei. Hold den gamle tjenesten gjenopprettbar til du har sjekket den nye applikasjonen og fastslått hvilken lokasjon som er autoritativ for skrivinger.
Endre DNS, og observer begge adressefamiliene
Oppdater postene som kreves for tjenesten, og ta høyde for eksisterende resolver-buffer. Sjekk de autoritative svarene og flere normale klientveier. Hvis en foreldet AAAA-post forblir aktiv, kan IPv6-klienter fortsette å nå den gamle serveren mens IPv4-klienter når den nye.
Test pålogging, lesinger, skrivinger, opplastinger, bakgrunnsjobber og eksterne tilbakeringinger på den nye tjenesten. Unngå å kjøre to uavhengige skrivbare kopier av samme applikasjon under overgangen. Hold en tydelig regel for håndtering av trafikk som fortsatt når den gamle destinasjonen.
Gjør tilbakerulling til en dataavgjørelse så vel som en DNS-avgjørelse
Definer feilforholdene som utløser en tilbakerulling, og hvem som styrer overgangen. Å reversere DNS alene er ikke nok etter at nye skrivinger har nådd destinasjonen: du må bevare eller avstemme disse dataene før du går tilbake til en eldre kopi.
Behold kilden og sikkerhetskopiene i en passende gjenopprettingsperiode. Fjern gammel tilgang og avvikle ressurser først etter at destinasjonen, sikkerhetskopiene, fornyelsen og overvåkingen er sjekket. Oppbevaring og sletting bør følge den faktiske tjenestepolicyen, ikke et generisk fast antall timer.