Je VPS zonder downtime naar een nieuwe aanbieder verhuizen

Elk horrorverhaal over een migratie heeft hetzelfde middenstuk: iemand wijzigde eerst de DNS en begon daarna pas te kopiëren. Downtime tijdens een verhuizing komt bijna nooit doordat het kopiëren traag gaat. Hij komt doordat de stappen in de verkeerde volgorde worden gezet.

Dit is de volgorde die werkt, of je nu bij een andere aanbieder weggaat of tussen twee van onze tarieven wisselt.

1. Twee dagen vooraf: verlaag de TTL

Zoek de DNS-records op die je gaat wijzigen (meestal A, AAAA en eventuele CNAME's die ernaar wijzen) en verlaag hun TTL naar 300 seconden. Wacht daarna minstens zo lang als de oude TTL was. Een record met een TTL van een dag betekent dat sommige resolvers het oude adres nog een dag na de wijziging blijven uitdelen, en niets wat je op de server doet versnelt dat.

Dit is de stap die mensen overslaan, en precies die maakt van een wissel van vijf minuten een dag waarop de helft van de gebruikers de oude server ziet.

2. Inventariseer de oude server

Je gaat deze machine ergens anders opnieuw opbouwen, dus schrijf op wat hij echt doet. Niet wat je je herinnert. Wat hij doet:

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

Zet ook op de lijst: de TLS-certificaten en hoe ze vernieuwen, omgevingsbestanden met geheimen, firewallregels, gebruikers en hun SSH-sleutels, de database en de grootte ervan, en alles wat de server op IP-adres aanspreekt. Die laatste groep is de verraderlijke: de allowlist van een partner, de webhookinstellingen van een betaalprovider, een monitoringcheck.

3. Bouw de nieuwe server naast de oude

Bestel de nieuwe server en laat de oude met rust. Kies een tarief uit de VPS-lijst met evenveel of meer schijfruimte dan je echt gebruikt, niet dan je verkocht is. Krijgt de oude machine ook maar enig inkomend verkeer (een website, webhooks, een API), dan heeft de nieuwe een eigen IPv4 nodig. Een NAT-tarief accepteert inkomende verbindingen alleen op zijn SSH-poort, en wat één doorgestuurde poort wel en niet kan legt uit waarom dat telt.

Maak verbinding, installeer dezelfde pakketten, maak de gebruikers en de firewall opnieuw aan. De verbindingsgids behandelt sleutels en de eerste login.

4. Synchroniseer de bestanden twee keer

De eerste synchronisatie kopieert alles terwijl de oude server gewoon doorwerkt. Dat kan uren duren; geen probleem.

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

--numeric-ids behoudt bestandseigenaren op nummer, wat de klassieke verrassing „alles is van de verkeerde gebruiker” voorkomt wanneer de twee systemen gebruikers in een andere volgorde hebben aangemaakt. Heb je rsync over SSH nooit gebruikt, dan loopt bestanden naar een VPS overzetten het stap voor stap door.

De tweede synchronisatie, vlak voor de wissel, kopieert alleen wat sinds de eerste is veranderd. Meestal duurt dat seconden.

5. Verhuis de database bewust

Bestanden zijn makkelijk. Een database die schrijfacties ontvangt, is het ene onderdeel waarbij „zonder downtime” óf een klein compromis óf meer werk vraagt.

De eenvoudige weg: eenmaal een dump maken en terugzetten om te testen, en bij de wissel de schrijfacties een minuut stoppen (de app in alleen-lezen zetten of stilleggen), een verse dump maken, die op de nieuwe server terugzetten en de app daar starten. Voor de meeste kleine projecten is dat een pauze van een minuut of twee, vooraf aangekondigd.

De weg zonder pauze: replicatie opzetten van de oude naar de nieuwe database, laten bijlopen en bij de wissel de nieuwe tot primaire maken. Meer werk vooraf, en het loont als zelfs een minuut aan verloren schrijfacties onaanvaardbaar is.

6. Test de nieuwe server voordat iemand anders hem ziet

De DNS wijst nog naar de oude server, dus je kunt de nieuwe in alle rust testen. Stuur een verzoek voor je echte domein naar het nieuwe adres:

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

Is het certificaat er nog niet, test dan op dezelfde manier via HTTP, of zet een tijdelijke regel in je hosts-bestand en klik door de site in een browser. Controleer logins, uploads, achtergrondtaken en uitgaande mail. Goedkoper vind je een ontbrekende PHP-extensie nooit.

7. Schakel om, en laat de oude server draaien

Doe de laatste bestandssynchronisatie en de databasestap, en wijzig dan de DNS-records. Met een TTL van 300 seconden verhuist het meeste verkeer binnen minuten. Houd het toegangslog van de oude server in de gaten: daar komt nog een straaltje verzoeken binnen van resolvers en clients die de TTL negeren. Laat hem een paar dagen ongewijzigd draaien. Werk daarna alles bij wat naar het oude IP wijst: allowlists van partners, webhook-URL's en voor mail de reverse DNS van het nieuwe adres (op onze tarieven met dedicated IP stel je die zelf in, zie reverse DNS) en je SPF-record.

Wat het vaakst stukgaat

Ruwweg in de volgorde waarin we het zien: een systemd-timer die niemand had genoteerd, een configuratiebestand met het oude IP erin gehardcodeerd, bestanden die van de verkeerde gebruiker zijn, een firewall die de eigen poort van de app blokkeert, een certificaat dat op de oude server vernieuwt maar niet op de nieuwe, en mail die in de spam belandt omdat het nieuwe adres nog geen reverse DNS heeft.

Waar deze checklist niet past

Een drukke database met constante schrijfacties en nul tolerantie voor een pauze heeft echte replicatie en een generale repetitie nodig, geen blogchecklist. Windows-servers verhuizen met ander gereedschap dan rsync. En als de verhuizing eigenlijk over grootte gaat, lees dan eerst dit: hier groeien tarieven ter plekke. Overstappen op een groter tarief van hetzelfde netwerktype voegt vCPU, RAM en schijf toe met één herstart, zonder enige migratie. Alleen voor verkleinen is een nieuwe server nodig. Verhuis je omdat je niet zeker weet of de machine groot genoeg is, dan bespaart wanneer je echt 64 GB RAM nodig hebt je misschien de reis, en VPS, shared hosting, dedicated server of cloud helpt als je twijfelt of een VPS überhaupt het juiste thuis is.