Van Plesk migreren

CoreCP leest de back-up die Plesk zelf van een abonnement maakt — het

Geschreven voor: Beheerder

CoreCP leest de back-up die Plesk zelf van een abonnement maakt — het .tar-bestand van plesk bin pleskbackup of de download uit het Plesk-paneel — en zet er hier een compleet account van neer: website(s), mail met alle berichten, database(s), DNS, certificaat en DKIM-sleutel. De import is gemeten tegen een echte back-up van Plesk Obsidian 18; wat hieronder staat is wat die meting liet zien.

Alleen beheerders. Een import maakt unix-gebruikers aan, laadt databases en publiceert DNS op een hele server.

Eerst dit: maak de back-up zónder wachtwoord

Dit is de ene stap die bepaalt of de klant zijn wachtwoorden houdt. Een Plesk-back-up die zonder back-upwachtwoord is gemaakt, bevat de wachtwoorden van mailboxen, van de systeemgebruiker en van de databasegebruiker leesbaar; CoreCP hasht ze hier en de klant merkt niets. Een back-up mét wachtwoord bevat ze versleuteld met een sleutel die alleen die Plesk-server heeft — dan kan niemand ze overzetten en wordt de migratie een massale wachtwoordreset.

Op de oude server, per abonnement:

unset PLESK_BACKUP_PASSWORD
plesk bin pleskbackup --domains-name voorbeeld.nl -exclude-logs -output-file /root/backup_voorbeeld.nl.tar

Het bestand is daarmee zelf een geheim: alleen root mag het lezen, het reist alleen over SSH en je verwijdert elke kopie zodra de import klaar is. De live-route hieronder doet dat allemaal voor je.

Wat er meekomt


Het account	De systeemgebruiker van het abonnement als accountnaam, zijn wachtwoord (leesbaar in de back-up, hier gehasht), de schijflimiet van het abonnement, en of hij een shell had
Websites	Het hoofddomein én elke extra site van het abonnement — een extra domein of een subdomein — elk op de PHP-versie waarop Plesk het serveerde
Bestanden	`httpdocs` wordt de documentroot van het hoofddomein, de map van elke extra site zijn eigen documentroot, en de rest van de webspace (zoals `error_docs`, `cgi-bin`, eigen mappen) komt in de home-map — zie Wat achterblijft
Databases	Elke MySQL/MariaDB-database met haar gegevens en gebruiker(s) met hun wachtwoord
Mail	Elke mailbox met haar wachtwoord en alle berichten; autoresponders die aan stonden
DNS	De zone, met de records die naar de oude server wezen verplaatst naar deze
Certificaten	Het certificaat en zijn sleutel van elke website
DKIM	De sleutel zelf, opnieuw gepubliceerd onder de eigen selector van CoreCP

Wat niet, en wat je eraan doet

Elke regel hieronder staat met naam en toenaam in het rapport van de import:

	Wat je doet
De databasenaam én de gebruikersnaam veranderen. Plesk noemt een database `shop` met gebruiker `shop_user`; hier heten ze `<account>_shop` en `<account>_shop_user`, omdat CoreCP de eigenaar uit dat voorvoegsel leest (en het account bij verwijdering zo ook zijn logins meeneemt)	Bij een WordPress-site past de import `DB_NAME` en `DB_USER` in `wp-config.php` zelf aan en meldt dat; bij een andere toepassing pas je het configuratiebestand zelf aan. Het rapport noemt de oude en de nieuwe namen. Het wachtwoord blijft hetzelfde.
Een databasegebruiker die hier al bestaat (Plesk-gebruikersnamen zijn vrij)	Wordt met rust gelaten; maak voor deze database een eigen gebruiker met `corectl db user add`.
DANE (TLSA-records)	Die pinnen het certificaat van de oude server en CoreCP vernieuwt certificaten zelf; ze worden niet overgenomen. Gebruikt de klant DANE, zet ze dan na de omschakeling opnieuw.
Geplande taken (cron)	Het rapport telt ze; maak ze hier opnieuw met `corectl cron`.
Beveiligde mappen (`.htpasswd`)	De back-up bevat geen bruikbaar wachtwoordbestand; beveilig de map opnieuw.
Catch-all	Wordt gemeld, niet gezet — dezelfde keuze als bij DirectAdmin: `corectl alias add @domein bestemming` als je hem wilt.
Spamfilterinstellingen per mailbox	Filtering is hier per server (rspamd).
CGI	CoreCP heeft geen CGI-handler; de scripts komen mee als bestanden.
PostgreSQL	CoreCP heeft geen PostgreSQL-rol.
Databasegebruikers op abonnementsniveau	Maak ze hier per database aan met `corectl db user add`.

Wat achterblijft

Wat Plesk en zijn uitbreidingen zelf in de webspace bewaren komt niet mee, met naam en omvang in het rapport: de CloudLinux- en Imunify-mappen (.cagefs, .cl.selector, .imunify*), de metadata van WP Toolkit en wp-cli, de LiteSpeed-cache, de logboeken en statistieken van Plesk, en .ssh (sleutels voor de oude server; shell-toegang regel je hier via het account).

Route 1 — een back-upbestand

Zet het .tar-bestand op de server en laat eerst de inspecteur kijken:

python3 scripts/plesk-inspect.py /root/backup_voorbeeld.nl.tar

Die drukt niets vertrouwelijks af en zegt per aanname of de back-up klopt met wat CoreCP verwacht — wachtwoordvormen, PHP-versies, de databasenaam, extra sites, TLSA-records. Daarna:

corectl import plesk /root/backup_voorbeeld.nl.tar --dry-run
corectl import plesk /root/backup_voorbeeld.nl.tar

Bevat de back-up meerdere abonnementen (een klant-, reseller- of serverback-up), noem dan welk je bedoelt met --subscription voorbeeld.nl, of migreer ze allemaal via route 2 met --mode dir.

Route 2 — rechtstreeks van de oude server

corectl import plesk-server root@oude.server --check
corectl import plesk-server root@oude.server --accounts voorbeeld.nl --dry-run
corectl import plesk-server root@oude.server --accounts voorbeeld.nl

CoreCP logt als root in, laat Plesk de back-up maken (zonder wachtwoord, zonder logboeken), haalt hem over SSH op en verwijdert hem op de oude server. Een abonnement heet in Plesk naar zijn hoofddomein, dus --accounts en --exclude noemen domeinen; de accountnaam wordt de systeemgebruiker uit de back-up.

Het rapport

Hetzelfde rapport als bij een DirectAdmin- of cPanel-import: per website, mailbox, database en zone een gecontroleerde regel tegen de draaiende server. Wat het extra zegt bij Plesk: dat de wachtwoorden leesbaar waren en hier gehasht zijn (of, bij een back-up mét wachtwoord, welke mailboxen een reset nodig hebben), welke database van naam veranderde en welk bestand van de site nog de oude noemt, welke TLSA-records niet zijn overgenomen, en wat er in de webspace achterbleef.

corectl import runs
corectl import run report <run> voorbeeld.nl

Twee keer doen is veilig

Een tweede import van dezelfde back-up meldt "already present", maakt niets dubbel en laat de zones met rust. Een afgekapte of beschadigde back-up wordt geweigerd vóór er iets wordt aangemaakt: geen account, geen unix-gebruiker, geen website.

Vanaf de terminal

python3 scripts/plesk-inspect.py <back-up>            # lezen, niets schrijven
corectl import plesk <back-up> [--subscription <domein>] [--dry-run]
corectl import plesk-server root@<host> [--accounts a,b] [--check|--dry-run]
corectl import plesk-server <map-met-exports> --mode dir
corectl import run report <run> <domein>