Flytt av webbhotell: byte utan avbrott

01Vad är en webbhotellsflytt?

Att flytta webbhotell innebär att överföra webbplatsens filer, databas och oftast e-postkonton från en server till en annan. För besökaren ändras inte adressen; det som byts är maskinen som sajten körs på i bakgrunden.

Behovet av en sajtflytt uppstår oftast på grund av långsamhet, otillräckliga resurser, säkerhetsproblem, missnöje med supporten eller övergång till en ny mjukvaruplattform. Oavsett orsak är målet detsamma: en flytt som besökaren inte märker.

Man ska inte blanda ihop webbhotellsflytt med domänflytt. Att byta domänregistrator är en separat process som vi gått igenom i inlägget om domänflytt. Att göra de två i tur och ordning i stället för samtidigt minskar risken.

02Gör en inventering före flytten

De flesta avbrott beror på en del som glömts bort. Innan du börjar flytta ska du göra en fullständig lista över vad som körs på den gamla servern:

• Sajtfiler: Kod, uppladdade bilder, dokument och konfigurationsfiler.
• Databaser: Alla databaser som sajten använder, deras användare och teckenuppsättning.
• E-post: Konton, vidarebefordringar och gamla meddelanden; om e-posten ligger på samma server måste den planeras separat.
• Schemalagda uppgifter: Cron-jobb som körs för rapporter, säkerhetskopior eller synkronisering.
• Serverinställningar: PHP- eller Node.js-version, minnesgränser, omdirigeringsregler, SSL-certifikat.
• Externa kopplingar: Behörigheter som är knutna till IP-adress i betalnings-, frakt- eller API-anslutningar.

03Så tar du en full säkerhetskopia

Flyttens första och viktigaste steg är en full och verifierad säkerhetskopia som gör det möjligt att backa. Kopian är både källan för flytten och din garanti om något går fel. Detaljerna i strategin för säkerhetskopiering har vi gått igenom i guiden Så tar du säkerhetskopior.

Om din kontrollpanel har en funktion för full säkerhetskopia kan du använda den. Har du SSH-åtkomst till servern kan du också ta databasen och filerna från kommandoraden:

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

Verifiera kopian

Är säkerhetskopians storlek rimlig, går arkivet att öppna och finns det en avslutande rad i slutet av SQL-filen som visar att den är komplett? En kopia som inte går att öppna är ingen kopia. Ladda dessutom ner kopian till din egen dator eller till en separat lagringsplats.

04Överföring till den nya servern

Förbered först miljön på den nya servern: samma eller kompatibla programversioner, databas och användare, nödvändiga tilläggsmoduler och katalogbehörigheter. Överför sedan filerna och databasen. För direktöverföring mellan två servrar är rsync en snabb och pålitlig metod:

• Uppdatera databasnamn, användare och lösenord i konfigurationsfilen för den nya servern.
• Kontrollera fil- och mappbehörigheter; uppladdningsmapparna måste vara skrivbara.
• Definiera om cron-jobben på den nya servern.
• Installera SSL-certifikatet på den nya servern eller skapa ett nytt.

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

05Hur testar man utan att ändra DNS?

Att prova sajten på den nya servern innan den går live är flyttens mest kritiska steg. För det lägger du till en rad i datorns hosts-fil som kopplar din domän till den nya serverns IP-adress. Då är det bara din dator som öppnar sajten från den nya servern; besökarna fortsätter att se den gamla.

203.0.113.10 alanadiniz.com www.alanadiniz.com

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

Var finns hosts-filen?

Prova formulär, betalningssteg, medlemsinloggning, sökning och adminpanel en och en i testet. När du är klar ska du komma ihåg att ta bort raden du lade till.

• Windows: C:\Windows\System32\drivers\etc\hosts (Anteckningar måste öppnas som administratör).
• macOS och Linux: /etc/hosts (redigeras med sudo).

06DNS-byte och TTL-inställning

Om testet lyckades är det dags för DNS-bytet. Sänk TTL-värdet för A-posten och vid behov MX-posterna minst en dag före bytet, så sprids ändringen snabbare på internet. Hur DNS-poster och TTL fungerar har vi förklarat i inlägget Vad är DNS.

Vid bytet pekar du om A-posten till den nya serverns IP-adress. Tar din sajt emot levande data, till exempel beställningar eller bokningar, måste du överföra databasen igen strax före bytet. För att inga nya poster ska skapas under den korta tiden är det säkrast att sätta sajten i underhållsläge i några minuter.

Stäng inte den gamla servern direkt efter bytet. Tills DNS-spridningen är klar kan en del besökare fortfarande nå den gamla servern; att hålla den igång i några dagar ger en trygg buffert.

07Att tänka på när e-posten flyttas

E-post är flyttens känsligaste del. Skapa kontona med samma namn på den nya servern, flytta gamla meddelanden med IMAP-överföring och byt MX-posten som sista steg. Glöm inte att uppdatera SPF-, DKIM- och DMARC-posterna för den nya servern; annars kan mejl du skickar hamna i skräpposten.

Att ha e-posten hos en separat företagse-posttjänst, åtskild från webbplatsen, gör framtida serverbyten mycket enklare. Då påverkas e-posten inte alls när sajten flyttas.

Om du ändå går över till en ny sajt eller plattform kan du se flytten som en möjlighet. Genom att inte flytta gamla filer som inte används, testmappar och onödiga databastabeller till den nya servern minskar du både risken för säkerhetshål och storleken på säkerhetskopiorna. Om webbdesignen ska förnyas från grunden bör du dessutom lägga in en plan för omdirigering från gamla till nya adresser i flyttens tidsplan.

08Checklista efter flytten

De första 48 timmarna efter bytet bör du följa noga. Kontrollera följande:

Visar någon av kontrollerna ett problem kan du ångra DNS-posten och vara tillbaka i det tidigare läget på några minuter, eftersom den gamla servern fortfarande är igång. En flytt med en reservplan innebär alltid mindre risk än en förhastad flytt.

• Öppnas alla sidor med HTTPS och är SSL-certifikatet giltigt?
• Skickar formulären e-post, och sparas beställningar och betalningar?
• Är bilder och filnedladdningar kompletta?
• Hur är serverns svarstid och sidhastighet jämfört med tidigare?
• Ökar crawlfelen från sökmotorerna?
• Dyker det upp nya varningar i felloggarna?

09När behöver man byta server?

Beslutet att byta server kommer oftast av klagomål på långsamhet, men orsaken till långsamheten är inte alltid servern. Tunga bilder, onödiga skript eller felaktiga cache-inställningar gör också sajten långsam. En mätning före flytten gör att du kan vara säker på att du löser rätt problem. Vi tar hand om mätningen och förbättringen i våra tjänster för hastighet och prestanda, där bild-, kod-, server- och cachelagren hanteras tillsammans.

Görs flytten av säkerhetsskäl gäller det att vara uppmärksam: om en sajt som smittats av skadlig kod flyttas, flyttar problemet med till den nya servern. Först ska sajten rengöras och sedan flyttas; stegen för det har vi gått igenom i inlägget Min webbplats har hackats.

För system som hanterar levande data, som en e-handelsbutik eller branschspecifik mjukvara, ska flytten planeras utan att order- och lagerflödet bryts. Företag som använder vår e-handelsplattform eller Aurora-lösningar kan planera flytten tillsammans med vårt team.