Servermigrering utan driftstopp

Ingen byter server för nöjes skull. Orsaken är oftast en av fyra: leverantören höjer priset eller lägger ner tjänsten, hårdvaran är gammal, den nuvarande kapaciteten räcker inte längre, eller så har operativsystemets version fallit ur support och säkerhetsuppdateringarna har slutat komma.

Själva migreringen är rutinarbete. Det går fel när den görs i hast och utan lista — för på en server körs nästan alltid fler saker än man först kommer ihåg.

Vad som går sönder vid en dålig migrering

Det mest synliga problemet är driftstoppet: sajten ligger nere i timmar för att datakopieringen tog längre tid än väntat. Men det dyra är det man inte märker direkt.

E-posten slutar komma fram, för SPF-posten pekar fortfarande på den gamla serverns IP. Meddelandena studsar inte — de hamnar tyst i skräpposten och kunden tror att ni aldrig svarade.

Certifikatet går ut, för Let's Encrypt-förnyelsen blev kvar på den gamla maskinen och ingen märker något förrän webbläsaren börjar visa en varning.

Schemalagda jobb startar aldrig. Säkerhetskopior, fakturagenerering, datautbyte — cron-jobb ligger inte i något kodarkiv och följer inte med, eftersom ingen vet att de finns.

Säkerhetskopiorna tas fortfarande från den gamla maskinen. Det farligaste misstaget av alla, för det upptäcks först när något faktiskt behöver återställas.

Så går en migrering till, steg för steg

1. Inventering

Innan något rörs: skriv ner vad som faktiskt körs på servern — webbservern och dess virtuella värdar, databaserna och deras versioner, applikationstjänster, cron-jobb, brandväggsregler, SSL-certifikat, e-postkonfigurationen, åtkomstnycklar och destinationer för säkerhetskopior.

Den listan är hela arbetets viktigaste del. Alla senare överraskningar kommer från det som inte kom med på den.

2. Den nya servern klar innan, inte under

Den nya maskinen sätts upp parallellt medan den gamla fortsätter att köra. Migrering på plats — att uppgradera den gamla servern till den nya — är det enda alternativet utan väg tillbaka.

Samma logik gäller när servern säkras: den nya maskinen härdas ordentligt direkt, inte senare.

3. Provkörning innan DNS rörs

Kopiera över data och starta applikationen på den nya servern genom att tillfälligt peka domänen mot den nya IP-adressen via din egen dators hosts-fil. Då ser du exakt det en besökare kommer att se — innan någon annan ser det.

Det är här saknade PHP- eller biblioteksmoduler, felaktiga filrättigheter och skillnader i databasens teckenkodning kommer fram.

4. Sänk DNS-postens TTL flera dagar i förväg

Om postens TTL är 24 timmar tar omställningen ett helt dygn. Sänk TTL till exempelvis fem minuter ett par dagar före flytten, så sker bytet i praktiken omedelbart. Höj tillbaka den när migreringen har lyckats.

Det enda steget är skillnaden mellan "en migrering utan driftstopp" och "en sajt som fungerade halvdant hela dagen".

5. Data två gånger

Den första fullständiga synkroniseringen görs i lugn och ro i förväg. Precis före omställningen körs en andra som bara omfattar det som ändrats — så stannar det verkliga stängda fönstret vid minuter i stället för timmar. För databasen betyder det en sista dump vid en tidpunkt då skrivningarna är pausade en kort stund.

6. Den gamla servern står kvar

Radera inte den gamla maskinen på bytesdagen. Låt den stå igång i minst ett par veckor, men stängd för skrivningar. Det är den billigaste försäkring som finns.

7. Efter flytten

Kontrollera: certifikatet och dess automatiska förnyelse, att e-posten kommer fram (se guiden till tillförlitlig e-postleverans), att cron-jobben verkligen startar, att en säkerhetskopia skapas OCH att en återställning har testats, övervakning och larm samt loggarna under det första dygnet.

Vad som oftast glöms

I praktiken är listan kort och alltid densamma: cron-jobb, SPF- och DKIM-poster, brandväggsundantag för andra systems IP-adresser, destinationen för säkerhetskopior, certifikatförnyelsen och loggrotationen. Är de sex avprickade är migreringen med stor sannolikhet frisk.

När det är värt att köpa in

En migrering är precis den sortens arbete där erfarenhet betalar sig mest — inte för att det är svårt, utan för att kostnaden för ett misstag visar sig först veckor senare. Om servern kör något vars driftstopp kostar pengar är både flytten och den löpande Linux-serverdriften värd att lämna till någon som gör detta regelbundet.

Vad ett underhållsavtal normalt omfattar står i ett eget inlägg: vad ett underhållsavtal för en Linux-server omfattar. Om det som flyttas är en webbplats eller en e-butik följer ofta även webbplats- och e-butiksunderhåll med.