Flytta din VPS till en ny leverantör utan driftstopp

Varje skräckhistoria om en migrering har samma mitt: någon ändrade DNS först och började kopiera sedan. Driftstopp under en flytt beror nästan aldrig på att kopieringen är långsam. Det beror på att stegen görs i fel ordning.

Här är ordningen som fungerar, oavsett om du lämnar en annan leverantör eller byter mellan två av våra tariffer.

1. Två dagar innan: sänk TTL:en

Leta upp de DNS-poster du ska ändra (oftast A, AAAA och alla CNAME som pekar på dem) och sänk deras TTL till 300 sekunder. Vänta sedan minst lika länge som den gamla TTL:en var. En post med en TTL på ett dygn betyder att vissa resolvrar fortsätter att servera den gamla adressen ett dygn efter ändringen, och inget du gör på servern snabbar upp det.

Det här är steget folk hoppar över, och det är det som gör ett byte på fem minuter till en dag där hälften av användarna ser den gamla servern.

2. Inventera den gamla servern

Du ska bygga upp den här maskinen någon annanstans, så skriv ner vad den faktiskt gör. Inte vad du minns att den gör. Vad den gör:

ss -tlnp                                # what is listening, and which process
crontab -l; ls /etc/cron.d              # scheduled jobs
systemctl list-timers --all             # the scheduled jobs people forget
systemctl list-units --type=service --state=running

Lägg till på listan: TLS-certifikaten och hur de förnyas, miljöfiler med hemligheter, brandväggsregler, användare och deras SSH-nycklar, databasen och dess storlek, och allt som pratar med servern via IP-adress. Den sista gruppen är den lömska: en partners tillåtelselista, en betalleverantörs webhook-inställningar, en övervakningskontroll.

3. Bygg den nya servern bredvid den gamla

Beställ den nya servern och låt den gamla vara. Välj en tariff från VPS-listan med lika mycket eller mer disk än du faktiskt använder, inte än du blev såld. Får den gamla maskinen någon inkommande trafik alls (en webbplats, webhooks, ett API) behöver den nya en egen IPv4. En NAT-tariff tar bara emot inkommande anslutningar på sin SSH-port, och vad en enda vidarebefordrad port kan och inte kan förklarar varför det spelar roll.

Anslut, installera samma paket, skapa om användarna och brandväggen. Anslutningsguiden går igenom nycklar och första inloggningen.

4. Synka filerna två gånger

Den första synken kopierar allt medan den gamla servern fortsätter jobba. Den kan ta timmar; det är okej.

rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/

--numeric-ids behåller filägarna efter nummer, vilket undviker den klassiska överraskningen ”allt tillhör fel användare” när de två systemen skapat användare i olika ordning. Har du aldrig använt rsync över SSH går så överför du filer till en VPS igenom det steg för steg.

Den andra synken, precis före bytet, kopierar bara det som ändrats sedan den första. Den tar oftast några sekunder.

5. Flytta databasen med eftertanke

Filer är enkla. En databas som tar emot skrivningar är den enda del där ”utan driftstopp” kräver antingen en liten kompromiss eller mer arbete.

Det enkla sättet: dumpa och återställ en gång för att testa, och vid bytet stoppa skrivningarna en minut (sätt appen i skrivskyddat läge eller stoppa den), ta en färsk dump, återställ den på den nya servern och starta appen där. För de flesta små projekt är det en paus på en minut eller två, aviserad i förväg.

Sättet utan paus: sätt upp replikering från den gamla databasen till den nya, låt den komma ikapp och gör den nya till primär vid bytet. Mer uppsättning, och det är värt det när inte ens en minut av förlorade skrivningar är acceptabel.

6. Testa den nya servern innan någon annan ser den

DNS pekar fortfarande på den gamla servern, så du kan testa den nya i lugn och ro. Skicka en förfrågan för din riktiga domän till den nya adressen:

curl --resolve example.com:443:203.0.113.10 https://example.com/health

Finns certifikatet inte där än, testa på samma sätt över HTTP, eller lägg till en tillfällig rad i hosts-filen och klicka runt på webbplatsen i en webbläsare. Kontrollera inloggningar, uppladdningar, bakgrundsjobb och utgående e-post. Billigare än så hittar du aldrig ett saknat PHP-tillägg.

7. Växla, och låt den gamla servern vara igång

Gör den sista filsynken och databassteget, och ändra sedan DNS-posterna. Med en TTL på 300 sekunder flyttar det mesta av trafiken inom några minuter. Håll koll på den gamla serverns åtkomstlogg: dit kommer fortfarande en strimma förfrågningar från resolvrar och klienter som ignorerar TTL. Låt den köra oförändrad i några dagar. Uppdatera sedan allt som pekar på den gamla IP-adressen: partners tillåtelselistor, webhook-URL:er och för e-post den omvända DNS:en för den nya adressen (på våra tariffer med dedikerad IP ställer du in den själv, se omvänd DNS) samt din SPF-post.

Det som oftast går sönder

Ungefär i den ordning vi ser det: en systemd-timer som ingen listade, en konfigurationsfil med den gamla IP-adressen hårdkodad, filer som ägs av fel användare, en brandvägg som blockerar appens egen port, ett certifikat som förnyas på den gamla servern men inte på den nya, och e-post som hamnar i skräppost eftersom den nya adressen ännu saknar omvänd DNS.

Där den här checklistan inte passar

En hårt skrivbelastad databas utan tolerans för paus behöver riktig replikering och en generalrepetition, inte en bloggchecklista. Windows-servrar flyttas med andra verktyg än rsync. Och om flytten egentligen handlar om storlek, läs det här först: här växer tarifferna på plats. Att byta till en större tariff av samma nätverkstyp lägger till vCPU, RAM och disk med en omstart, helt utan migrering. Bara för att krympa krävs en ny server. Flyttar du för att du inte är säker på att maskinen räcker, kan när du faktiskt behöver 64 GB RAM spara dig resan, och VPS, delad hosting, dedikerad server eller moln hjälper om du är osäker på om en VPS alls är rätt hem.