Flytting av webhotell: bytt uten nedetid

01Hva er det å flytte hosting?

Å flytte hosting betyr å overføre nettsidens filer, databasen og som regel e-postkontoene fra én server til en annen. For den besøkende endres ikke adressen. Det som endres, er maskinen nettsiden kjører på i bakgrunnen.

Behovet for å flytte en nettside oppstår som regel på grunn av treghet, for lite ressurser, sikkerhetsproblemer, misnøye med supporten eller overgang til en ny programvareplattform. Uansett årsak er målet det samme: en overgang som de besøkende aldri merker.

Å flytte hosting må ikke forveksles med domeneflytting. Å bytte domeneregistrar er en egen prosess, og den er forklart i artikkelen vår om domeneflytting. Det er tryggere å gjøre de to etter hverandre enn samtidig.

02Lag en oversikt før flyttingen

Mesteparten av nedetiden skyldes at man har glemt en del. Før du begynner, lag en fullstendig liste over alt som kjører på den gamle serveren:

• Nettsidefiler: kode, opplastede bilder, dokumenter og konfigurasjonsfiler.
• Databaser: alle databasene nettsiden bruker, med brukere og tegnsett.
• E-post: kontoer, videresendinger og gamle e-poster. Ligger e-posten på samme server, må den planlegges separat.
• Planlagte oppgaver: cron-jobber som kjører rapporter, sikkerhetskopier eller synkronisering.
• Serverinnstillinger: PHP- eller Node.js-versjon, minnegrenser, omdirigeringsregler, SSL-sertifikat.
• Eksterne tilkoblinger: IP-baserte tillatelser i betalings-, frakt- eller API-tilkoblinger.

03Hvordan tar du en full sikkerhetskopi?

Det første og viktigste trinnet er en full og kontrollert sikkerhetskopi som gjør det mulig å gå tilbake. Kopien er både kilden til flyttingen og forsikringen din hvis noe går galt. Detaljene om strategi for sikkerhetskopiering har vi forklart i guiden vår om hvordan ta sikkerhetskopi.

Hvis kontrollpanelet ditt tilbyr full sikkerhetskopiering, kan du bruke den. Har du SSH-tilgang til serveren, kan du også ta ut database og filer fra kommandolinjen:

mysqldump -u kullanici -p --single-transaction --default-character-set=utf8mb4 veritabani > yedek.sql
tar -czf site-dosyalari.tar.gz -C /var/www site

Kontroller sikkerhetskopien

Er filstørrelsen rimelig, kan arkivet åpnes, og står det en linje på slutten av SQL-filen som viser at den er fullført? En sikkerhetskopi som ikke kan åpnes, er ingen sikkerhetskopi. Last også ned kopien til din egen datamaskin eller et eget lagringsområde.

04Overføring til den nye serveren

Forbered miljøet på den nye serveren først: samme eller kompatible programvareversjoner, database med bruker, nødvendige utvidelser og mappetillatelser. Overfør deretter filene og databasen. Mellom to servere er rsync en rask og pålitelig metode for direkte overføring:

• Oppdater databasenavn, bruker og passord i konfigurasjonsfilen slik at de passer til den nye serveren.
• Kontroller fil- og mappetillatelser. Opplastingsmappene må være skrivbare.
• Sett opp cron-jobbene på nytt på den nye serveren.
• Installer SSL-sertifikatet på den nye serveren, eller opprett et nytt.

rsync -avz -e ssh /var/www/site/ kullanici@yeni-sunucu:/var/www/site/
mysql -u kullanici -p veritabani < yedek.sql

05Hvordan tester du uten å endre DNS?

Å teste nettsiden på den nye serveren før den går live er det mest kritiske trinnet i flyttingen. Da legger du til en linje i hosts-filen på datamaskinen din som kobler domenenavnet til den nye serverens IP-adresse. Dermed åpner bare din maskin nettsiden fra den nye serveren, mens besøkende fortsetter å se den gamle.

203.0.113.10 alanadiniz.com www.alanadiniz.com

curl -I --resolve alanadiniz.com:443:203.0.113.10 https://alanadiniz.com

Hvor ligger hosts-filen?

Prøv skjemaer, betalingstrinnet, innlogging, søk og administrasjonspanelet ett for ett under testen. Husk å slette linjen du la til når du er ferdig.

• Windows: C:\Windows\System32\drivers\etc\hosts (Notisblokk må åpnes som administrator).
• macOS og Linux: /etc/hosts (redigeres med sudo).

06DNS-bytte og TTL-innstilling

Når testen er vellykket, er det tid for DNS-byttet. Senk TTL-verdien for A-postene, og for MX-postene ved behov, minst en dag før byttet. Da sprer endringen seg raskere på internett. Hvordan DNS-poster og TTL fungerer, har vi forklart i artikkelen hva er DNS.

Pek A-posten mot den nye serverens IP-adresse når du gjør byttet. Hvis nettsiden din tar imot live data, for eksempel lagrer bestillinger eller reservasjoner, må du overføre databasen på nytt rett før byttet. Det tryggeste er å sette nettsiden i vedlikeholdsmodus i noen minutter, slik at det ikke oppstår nye oppføringer i mellomtiden.

Ikke stenge den gamle serveren med en gang etter byttet. Noen besøkende kan fortsatt nå den gamle serveren til DNS-propageringen er ferdig. Å holde den åpen i noen dager gir en trygg buffer.

07Pass på ved flytting av e-post

E-post er den mest følsomme delen av flyttingen. Opprett kontoene med samme navn på den nye serveren, flytt gamle e-poster via IMAP-overføring, og endre MX-posten som siste trinn. Husk også å oppdatere SPF-, DKIM- og DMARC-postene for den nye serveren. Ellers kan e-postene du sender havne i søppelpostmappen.

Hvis du har e-posten hos en egen e-posttjeneste for bedrifter, atskilt fra nettsiden, blir fremtidige serverbytter mye enklere. Da påvirkes ikke e-posten i det hele tatt når nettsiden flyttes.

Hvis du går over til en ny nettside eller plattform, kan du se på flyttingen som en mulighet. Ved å la være å ta med gamle og ubrukte filer, testmapper og unødvendige databasetabeller til den nye serveren reduserer du både risikoen for sikkerhetshull og størrelsen på sikkerhetskopiene. Hvis webdesignet skal fornyes helt, må du også legge planen for omdirigering fra gamle til nye adresser inn i tidsplanen for flyttingen.

08Sjekkliste etter flyttingen

De første 48 timene etter byttet bør følges nøye. Kontroller følgende:

Hvis en av disse kontrollene viser problemer, kan du rulle tilbake DNS-posten og være tilbake til forrige tilstand i løpet av minutter, siden den gamle serveren fortsatt er åpen. En flytting med en tilbakerullingsplan medfører alltid mindre risiko enn en forhastet flytting.

• Åpnes alle sider med HTTPS, og er SSL-sertifikatet gyldig?
• Sender skjemaene e-post, og blir bestillinger og betalinger registrert?
• Er bildene og filnedlastingene komplette?
• Hvordan er serverens responstid og sidehastighet sammenlignet med før?
• Har det kommet flere krypefeil fra søkemotorene?
• Dukker det opp nye advarsler i feilloggene?

09Når må du bytte server?

Beslutningen om å bytte server kommer som regel på grunn av klager på treghet, men trege sider skyldes ikke alltid serveren. Tunge bilder, unødvendige skript eller feil hurtigbufferinnstillinger gjør også nettsiden treg. Å måle før flyttingen sørger for at du løser det riktige problemet. Denne målingen og forbedringen tar vi for oss samlet i bilder, kode, server og hurtigbuffer innenfor hastighet og ytelse.

Hvis du flytter av sikkerhetsgrunner, er det noe du må være oppmerksom på: hvis du flytter en nettside som er infisert med skadelig kode, flytter du også problemet til den nye serveren. Rydd først, flytt etterpå. Trinnene i et slikt tilfelle har vi forklart i artikkelen nettsiden er hacket.

For systemer som behandler live data, som en nettbutikk eller bransjeprogramvare, må flyttingen planlegges slik at bestillings- og lagerflyten ikke avbrytes. For virksomheter som bruker nettbutikkplattformen eller Aurora-løsninger kan overgangen planlegges sammen med teamet vårt.