Een live migratie uitvoeren

Een klant verhuizen van een draaiende server naar CoreCP, zonder dat de site uren uit de lucht is. Dit is de begeleide variant: één wizard die de stappen in de juiste volgorde zet, dagenlang mag duren en het dichtklappen van je laptop overleeft. Wil je alleen een back-upbestand inlezen, lees dan "Van cPanel migreren".

De wizard staat in het paneel onder Migratie → Live migraties, en dezelfde stappen zijn commando's op de node. Het is één dossier: wat je in de browser start kun je op de server afmaken en andersom.

De negen fasen

De fase wordt afgeleid uit het dossier en nergens opgeslagen. Draait een collega een delta vanaf de commandoregel terwijl jij in de browser kijkt, dan is er geen tweede waarheid die kan verouderen.

Beginnen

In het paneel: Migratie → Live migraties → Nieuwe migratie. Je vult per dienst de gegevens in — één tabblad per dienst — en drukt op testen. Wat niet lukt, mag ontbreken: zonder SSH werkt de wizard in "degraded"-modus met FTP, IMAP en MySQL over TCP, en het rapport zegt dan zelf welke weg is gebruikt.

Vanaf de node is dat:

ssh root@stck1.corecp.dev
corectl migrate source add web1 --keep-for-delta --retain-days 30 < creds.json
corectl migrate source test lm-1786… --install-key

--install-key zet een sleutelpaar klaar dat alleen voor deze migratie bestaat; dat is het voorkeurspad boven het meesturen van een wachtwoord.

Staat de oude server geen wachtwoordlogin toe, dan lukt dat niet — en dat is geen verkeerd wachtwoord. SSH antwoordt in dat geval met "Permission denied (publickey)", wat leest alsof het wachtwoord fout is terwijl het nooit is geprobeerd. CoreCP zegt het er sinds versie 0.19.1 bij, met de sleutelregel die je nodig hebt:

root@stck1:~# corectl migrate discover lm-1786…
corectl: installing this migration's key on olduser@oud.voorbeeld.nl failed:
exit status 255 — Permission denied (publickey).

The source offered public-key authentication only, so the password was never
tried … Install this migration's key on the source by hand, in the account's
~/.ssh/authorized_keys, and run this again:

  ssh-ed25519 AAAAC3Nza… corecp-migration lm-1786…

Zet die ene regel met de hand in ~/.ssh/authorized_keys van het account op de oude server en draai het commando opnieuw. Alles daarna gaat via de sleutel.

Inventariseren, plannen, goedkeuren

corectl migrate discover lm-1786…   # lees de bron uit
corectl migrate plan     lm-1786…   # plan + dry run
corectl migrate approve  lm-1786…   # een mens keurt goed

De dry run is niet een schatting: het zijn de overdrachtsmotoren zelf met hun eigen --dry-run. Wat je leest is dus wat er straks gebeurt. Goedkeuren is een aparte stap omdat het de enige plek is waar iemand kan zeggen "dit klopt niet" vóórdat er data beweegt.

Synchroniseren

corectl migrate sync lm-1786… --pass initial
corectl migrate sync lm-1786… --pass delta     # zo vaak als je wilt

Een pass draait de onderdelen van het plan parallel, met een rem erop — drie tegelijk — omdat de bron een levende server is die ook nog zijn eigen klanten bedient. Elk onderdeel is een eigen stap met een eigen logboek, in het paneel zichtbaar in een slide-over.

Alles is hervatbaar. Een stap die door een herstart blijft hangen op "bezig" krijgt na zes uur het eerlijke label hervatbaar — onderbroken, draai de pass opnieuw.

Controleren en het groene sein

corectl migrate checklist lm-1786…
corectl migrate status    lm-1786…

[corecp] live migration lm-1786… → web1 (ready)
  discovery:   ssh, directadmin layout — 2 site(s), 1 database(s), 1 mailbox(es), 1 zone(s)
  plan:        5 item(s), approved 2026-08-10 11:02 by admin@corecp.dev
  READY FOR CUTOVER — every check is green.

"Klaar voor omzetten" betekent precies twee dingen tegelijk: het plan is goedgekeurd en elke controle is groen. Elke nieuwe pass gooit de checklist weg, want een vinkje dat ouder is dan de data waarover het gaat, is het enige soort fout dat deze wizard niet mag maken. Een checklist zonder controles erin is ook niet groen.

Omzetten en afronden

Verzet de nameservers of de A-records. Dat doet CoreCP niet voor je: het is de enige stap waarvan de klant de gevolgen draagt.

corectl migrate cutover  lm-1786…   # bevestig dat DNS is omgezet
corectl migrate finalise lm-1786…   # finale delta, certificaten, advies

De finale ronde doet bestanden met een snelle pass, mail met een hersynchronisatie van de vlaggen, en de databases opnieuw onder een korte freeze. Certificaten worden daarna aangevraagd, met HTTP-01 per naam: vóór de omzetting beantwoordt de oude server die uitdaging nog. Een naam die nog niet is doorgezakt levert een waarschuwing op met het commando om het opnieuw te proberen — geen mislukte migratie.

Het advies over de oude machine is advies. CoreCP zet geen server uit die het niet beheert.

Opruimen

corectl migrate source forget lm-1786…

Dat is geen huishoudelijke luxe: tot dit draait, houdt deze node een werkende login vast op een machine waar de klant zo stopt met betalen. corectl migrate expire doet het uit zichzelf als niemand eraan denkt, en migrate source show zegt hoe lang dat nog duurt.

Wat de migratie met wachtwoorden doet

Twee kanten, en ze zijn niet hetzelfde.

De oude server. Daar geef je een login voor op, en die is een echte: hij wordt versleuteld bewaard zolang de migratie loopt en verdwijnt met migrate source forget of vanzelf met migrate expire. In logboeken en foutmeldingen komt hij nooit terecht — CoreCP filtert hem eruit voordat er iets wordt opgeschreven.

De nieuwe server. Daar heeft CoreCP het wachtwoord van je mailbox niet: dat staat alleen versleuteld op de server. Voor het kopiëren maakt de migratie daarom een tijdelijke sleutel die alleen die ene mailbox opent en die na de overzetpas weer wordt ingetrokken. Die sleutel is géén wachtwoord: je kunt hem niet in een mailprogramma typen, en hij opent geen andere mailbox. Ben je op dat moment zelf in webmail bezig, dan merk je van het opruimen niets — je eigen sessie blijft staan.

Wie de migratie ziet, en wat er gebeurt als de server verhuist

Een migratie hoort bij de server waar hij naartoe loopt, niet bij de groep waar die server toevallig in stond toen je begon. Verplaats je de machine naar een andere servergroep, dan verhuizen de migraties mee: de beheerder van de nieuwe groep ziet ze, de beheerder van de oude niet meer.

Dat betekent ook dat je de oude, leeggemaakte groep gerust kunt opruimen. De migratieregels blijven staan — ze horen bij de machine, die er nog is.

corectl migrate status lm-1786…      # de migratie zelf, op de node

lm-1786… · sync · 3 van 7 passen · bron web1.oude-host.nl

Zie je een migratie níet in het overzicht die je wel verwacht, kijk dan eerst in welke groep de doelserver staat. Onder Servers staat de groep op de detailpagina van de machine.

Zie ook

• Van cPanel migreren
• Waar een website draait

Een adres verhuizen is iets anders

Deze pagina gaat over het verhuizen van een klant van een andere server. Verhuist het IP-adres van je eigen server — je provider levert een nieuw blok, of je gaat naar een ander datacentrum — dan is dat een andere wizard, met een periode waarin je sites op allebei de adressen antwoorden. Zie Een IP-adres vervangen.

De eigen opslag van een node verhuizen

Naast klantmigraties is er één verhuizing die over de server zelf gaat: de administraties die CoreCP zelf bijhoudt — de maillijst en de zonegegevens — verhuizen van de database-engine van de klanten naar een opslag die van de node is. Doe dat node voor node, en pas nadat je een node hebt bekeken de vorige kopie weggooien.

Kijk eerst wat er zou verhuizen; dat verandert niets:

corectl node store migrate --dry-run

Voer daarna de verhuizing uit. Hij zet de opslag klaar, kopieert elke tabel, telt aan de andere kant na wat er is aangekomen en laat de diensten opnieuw inlezen:

corectl node store migrate
corectl node store status

Gaat er iets niet zoals verwacht, dan is de weg terug één opdracht — de oude kopie staat er nog:

corectl node store rollback

Pas als de node een tijd goed heeft gedraaid, gooi je die oude kopie weg. Daarna is de verhuizing niet meer terug te draaien zonder een restore:

corectl node store remove-legacy --confirm