Checklista för VPS-migrering: säkerhetskopior, DNS, TLS och återställning
En praktisk migreringssekvens för en egenhostad applikation: inventering, konsekventa säkerhetskopior, en testad destination, kontrollerade skrivningar, DNS-övergång och en återställningsväg.
I korthet
En kontrollerad VPS-migrering inventerar tjänster och data, skapar en konsekvent säkerhetskopia, verifierar en återställd destination, testar värdnamn och TLS-routing, samordnar slutliga skrivningar och DNS samt bevarar en data-medveten återställning. Ingen checklista garanterar i sig noll driftstopp.
Inventera applikationen innan du flyttar den
Lista de tjänster, versioner, portar, schemalagda uppgifter, databaser, uppladdade filer och den konfiguration som behövs för att applikationen ska fungera. Identifiera var skrivningar sker och vilka externa tjänster den är beroende av. En kopierad webbkatalog är inte en fullständig migrering när data ligger någon annanstans.
Anteckna aktuella DNS-namn, aktiva IPv4 och IPv6-poster, metoder för certifikatförnyelse och en återställningsväg för åtkomst. Förvara hemligheter i dina privata distributionsverktyg. Lägg inte lösenord, privata nycklar eller databasdumpar i en offentlig dokumentrot eller en delad migreringschecklista.
Skapa en konsekvent säkerhetskopia och bevisa att den återställs
Använd databasens stödda säkerhetskopieringsmekanism i stället för att kopiera godtyckliga filer medan skrivningar fortsätter. För SQLite skapar Online Backup API en konsekvent databasögonblicksbild. I WAL-läge deltar WAL-filen i det beständiga databastillståndet, så att kopiera endast huvuddatabasfilen kan utelämna bekräftade ändringar.
En konsekvent databassäkerhetskopia är inte automatiskt konsekvent med separat lagrade uppladdningar, köer eller filer. Samordna deras fångst med din applikation. Återställ till en separat testplats och verifiera poster, filreferenser och applikationsbeteende innan du betraktar säkerhetskopian som användbar.
Förbered destinationen innan du ändrar DNS
Skapa de avsedda användarna, behörigheterna, körtidsversionerna, tjänsterna och applikationskatalogerna på den nya servern. Återställ testsäkerhetskopian till dess destinationsplats för data, utanför den offentliga webbroten där det är lämpligt. Kontrollera ägande och åtkomst med det tjänstekonto som faktiskt kommer att köra applikationen.
Bevara orelaterade webbplatser på en delad server. Använd en dedikerad dokumentrot, virtuell värd och körtid, validera webbserverns konfiguration och förbered en återställning som endast återställer de filer och den konfiguration som ägs av denna ändring.
Testa det riktiga värdnamnet och certifikatet på den nya servern
En webbläsarförfrågan till en bar IP-adress återspeglar inte värdnamnsbaserad routing eller certifikatvalidering. curl --resolve låter ett test använda det avsedda värdnamnet och en vald destinations-IP medan de normala värdnamns- och TLS-kontrollerna behålls. Kontrollera även HTTP-statusen och det förväntade applikationsinnehållet. Exemplet använder endast dokumentationsvärden; ersätt dem med din egen verifierade domän och destination.
Ett giltigt certifikat och en tillåten nätverksväg måste redan finnas för att testet ska lyckas. Inaktivera aldrig certifikatverifiering för att kalla migreringen klar. DNS-baserad ACME-validering kan validera en domän utan att ändra dess webbserveradress; HTTP-baserad validering har andra nåbarhetskrav. Testa förnyelse separat från initial utfärdning.
curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/Välj en plan för skrivkontroll och slutsynkronisering
Schemalägg en kort underhållsperiod eller en annan applikationslämplig konsekvensmekanism. Stoppa eller omdirigera de skrivare du identifierade, ta den slutliga konsekventa databassäkerhetskopian, synkronisera motsvarande föränderliga filer och verifiera resultatet. Köarbetare, webhooks och cron-uppgifter kan skriva även när det offentliga gränssnittet ser tyst ut.
Gör en torrkörning före en filsynkronisering. Lägg inte till borttagningsflaggor eller kopiera hela systemkataloger som en genväg. Håll den gamla tjänsten återställbar tills du har kontrollerat den nya applikationen och fastställt vilken plats som är auktoritativ för skrivningar.
Ändra DNS, observera sedan båda adressfamiljerna
Uppdatera de poster som krävs för tjänsten och ta hänsyn till befintliga resolver-cachar. Kontrollera de auktoritativa svaren och flera vanliga klientvägar. Om en föråldrad AAAA-post förblir aktiv kan IPv6-klienter fortsätta nå den gamla servern medan IPv4-klienter når den nya.
Testa inloggning, läsningar, skrivningar, uppladdningar, bakgrundsjobb och externa återanrop på den nya tjänsten. Undvik att köra två oberoende skrivbara kopior av samma applikation under övergången. Håll en tydlig regel för hantering av trafik som fortfarande når den gamla destinationen.
Gör återställning till ett databeslut likaväl som ett DNS-beslut
Definiera de felvillkor som utlöser en återställning och vem som styr övergången. Att återställa DNS ensamt är inte tillräckligt efter att nya skrivningar har nått destinationen: du måste bevara eller avstämma dessa data innan du återgår till en äldre kopia.
Behåll källan och säkerhetskopiorna under en lämplig återställningsperiod. Ta bort gammal åtkomst och avveckla resurser först efter att destinationen, säkerhetskopiorna, förnyelsen och övervakningen har kontrollerats. Bevarande och radering bör följa den faktiska servicepolicyn, inte ett generiskt fast antal timmar.