# Checklista för VPS-migrering: säkerhetskopior, DNS, TLS och återställning [Checklista för VPS-migrering: säkerhetskopior, DNS, TLS och återställning]() Uppdaterad 2026-10-15 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. 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. ## Frågor, besvarade ### Kan jag kopiera en levande SQLite-databasfil direkt? Anta inte att kopiering av en fil från en levande databas ger en fullständig, konsekvent säkerhetskopia. Använd en stödd säkerhetskopieringsmetod och ta hänsyn till WAL-tillstånd. Samordna även filer som lagras utanför databasen. ### Flyttar en ändring av en DNS-post mina applikationsdata? Nej. DNS dirigerar framtida namnuppslagning mot en adress. Applikationsfiler, databaser, hemligheter och bakgrundstjänster kräver en separat migrerings- och verifieringsprocess. ### Kan jag lova noll driftstopp med denna checklista? Nej. Driftstopp och konsekvens beror på applikationen, trafiken, data och övergångsmetoden. Checklistan hjälper dig förbereda och testa en kontrollerad flytt; den är inte en garanti för noll driftstopp. ## Hitta guiden för ditt nästa beslut - [Dimensionera destinationen utifrån uppmätta behov]() - [Förstå gäst- och värdkontroll]() - [Planera din egenhostade arbetsbelastning]() - [Utforska VPS-resurserna]() ## Officiella referenser - [SQLite Online Backup API]() - [SQLite write-ahead-loggning]() - [curl-manual: åsidosättningar av värdnamnsuppslagning]() - [ACME utmaningstyper]() - [rsync-manual]()