Wie man alle cPanel-Konten von einem Server auf einen anderen verschiebt

Die Migration aller cPanel-Konten zwischen Servern ist der Prozess der Übertragung jeder gehosteten Domain, ihrer Dateien, MySQL-Datenbanken, E-Mail-Konten, DNS-Zonen, SSL-Zertifikate und Cron-Jobs von einer Quell-WHM-Instanz zu einer Ziel-WHM-Instanz — typischerweise mithilfe des integrierten WHM Transfer Tools über eine authentifizierte SSH-Verbindung. Bei korrekter Ausführung erfordert dieser Prozess kein manuelles Kopieren von Dateien und bewahrt alle Kontometadaten vollständig.

Dieser Leitfaden behandelt den vollständigen Migrations-Workflow auf Produktionsebene: Vorab-Prüfungen, Transfer Tool-Konfiguration, DNS-Umstellungsstrategie, Validierung nach der Migration und Bereinigung — einschließlich Sonderfälle, die in realen Umgebungen zu stillen Fehlern führen.

Voraussetzungen und Checkliste vor der Migration

Das Überspringen der Vorbereitung ist die häufigste Ursache für fehlgeschlagene oder unvollständige cPanel-Migrationen. Bevor Sie einen der Server anfassen, überprüfen Sie jeden der folgenden Punkte.

Root-Zugriff auf beiden Servern. Das WHM Transfer Tool authentifiziert sich beim Quellserver über SSH als root. Wenn der Quellserver PermitRootLogin no in /etc/ssh/sshd_config hat, müssen Sie es entweder vorübergehend aktivieren oder SSH-schlüsselbasierte Authentifizierung für Root vorkonfigurieren.

Kompatible cPanel/WHM-Versionen. cPanel kann Konten von älteren Versionen auf neuere übertragen, aber nicht umgekehrt. Ein Zielserver mit cPanel 110 kann von einem Quellserver mit cPanel 98 abrufen, aber das Gegenteil schlägt fehl. Überprüfen Sie die Versionen in WHM unter Server Information oder führen Sie aus:

cat /usr/local/cpanel/version

Übereinstimmende oder kompatible PHP- und MySQL-Versionen. Wenn der Quellserver PHP 7.4 und MySQL 5.7 verwendet, während der Zielserver PHP 8.2 und MySQL 8.0 betreibt, können Anwendungen nach der Übertragung fehlschlagen, selbst wenn die Dateien sauber kopiert wurden. Überprüfen Sie die installierten PHP-Versionen und Standard-Handler auf beiden Servern, bevor Sie fortfahren.

Ausreichend Speicherplatz auf dem Zielserver. Das Transfer Tool benötigt freien Speicherplatz, der mindestens der gesamten komprimierten Größe aller zu übertragenden Konten entspricht, zuzüglich Puffer für die Extraktion. Führen Sie df -h auf dem Zielserver aus und vergleichen Sie dies mit der gesamten Kontospeichernutzung, die in der List Accounts-Ansicht von WHM auf dem Quellserver sichtbar ist.

Firewall-Regeln, die SSH zwischen Servern erlauben. Der Zielserver initiiert eine ausgehende SSH-Verbindung zum Quellserver. Stellen Sie sicher, dass Port 22 (oder der benutzerdefinierte SSH-Port) in der Firewall des Quellservers für die IP-Adresse des Zielservers geöffnet ist.

Vollständige Kontosicherungen auf dem Quellserver. Erstellen Sie vor dem Start eine vollständige cPanel-Sicherung für jedes Konto. Dies ist Ihr Wiederherstellungspunkt, falls die Übertragung ein Konto beschädigt oder nur teilweise kopiert.

/scripts/pkgacct username /backup/directory

Wenn Sie Ihre neue Umgebung auf einem VPS Hosting-Plan betreiben, stellen Sie sicher, dass Ihr VPS bereits mit cPanel/WHM lizenziert und installiert ist, bevor Sie fortfahren. Eine frische cPanel-Installation erfordert eine gültige Lizenz, die an die IP-Adresse des Servers gebunden ist.

Schritt 1: cPanel/WHM auf dem Zielserver installieren und konfigurieren

Wenn cPanel noch nicht auf dem Zielserver installiert ist, führen Sie das offizielle Installationsprogramm als Root aus. Dieser Vorgang dauert je nach Hardware 20–45 Minuten:

cd /home && curl -o latest -L https://securedownloads.cpanel.net/latest && sh latest

Nach Abschluss der Installation greifen Sie auf WHM unter https://your-server-ip:2087 zu und schließen Sie den anfänglichen Einrichtungsassistenten ab. Achten Sie besonders auf:

• Hostname: Legen Sie einen vollqualifizierten Domänennamen (FQDN) fest, der zur IP des Servers aufgelöst wird. Ein nicht auflösbarer Hostname verursacht nach der Migration Fehler bei der E-Mail-Zustellung.
• Nameserver: Konfigurieren Sie Ihre Nameserver-Hostnamen und deren IP-Adressen, wenn Sie planen, DNS auf dem neuen Server zu hosten.
• PHP-Handler: Installieren Sie dieselben PHP-Versionen, die auf dem Quellserver verfügbar sind, mithilfe von WHM > MultiPHP Manager, um Anwendungskompatibilitätsprobleme zu vermeiden.
• MySQL/MariaDB-Version: Passen Sie die Datenbankengine-Version des Quellservers nach Möglichkeit an, oder testen Sie die Anwendungskompatibilität mit der neueren Version, bevor Sie Produktionskonten migrieren.

Für Teams, die mehrere Client-Umgebungen verwalten, bietet ein VPS mit cPanel eine vorkonfigurierte Umgebung, die die manuelle Installationsphase vollständig eliminiert.

Schritt 2: Das WHM Transfer Tool konfigurieren

Das WHM Transfer Tool ist die maßgebliche Methode für die Massenkonten-Migration. Es übernimmt Paketierung, Übertragung, Extraktion und Kontoerstellung atomisch für jedes Konto.

2.1 Zugriff auf das Transfer Tool

Melden Sie sich auf dem Zielserver bei WHM an und navigieren Sie zu:

WHM > Transfers > Transfer Tool

Dies ist ein kritischer Punkt, der viele Administratoren verwirrt: Das Transfer Tool wird immer vom Zielserver aus ausgeführt, der Konten vom Quellserver abruft — nicht umgekehrt.

2.2 Mit dem Quellserver verbinden

Geben Sie die folgenden Verbindungsdetails ein:

• Remote Server Address: IP-Adresse oder Hostname des Quellservers
• Remote SSH Port: Standard ist 22; verwenden Sie den tatsächlichen Port, wenn er geändert wurde (überprüfen Sie /etc/ssh/sshd_config auf dem Quellserver für die Port-Direktive)
• Authentifizierungsmethode: Root-Passwort oder SSH-Schlüssel (schlüsselbasiert wird aus Sicherheits- und Zuverlässigkeitsgründen dringend bevorzugt)

Um SSH-Schlüsselauthentifizierung zu verwenden, kopieren Sie den öffentlichen Root-Schlüssel des Zielservers auf den Quellserver:

ssh-copy-id -i /root/.ssh/id_rsa.pub -p 22 root@source-server-ip

Nach der Verbindung fragt das Transfer Tool den Quellserver ab und gibt eine Liste aller cPanel-Konten, Pakete und Reseller-Konfigurationen zurück.

2.3 Konten und Übertragungsumfang auswählen

Sie können alle Konten oder eine Teilmenge auswählen. Über einzelne Konten hinaus bietet das Transfer Tool auch:

• Pakete: Übertragen Sie Hosting-Plan-Definitionen, damit Konten ihre Ressourcenzuweisungen behalten
• DNS-Zonen: Kopieren Sie alle Zonendateien, was unerlässlich ist, wenn der neue Server als autoritativer Nameserver fungieren soll
• Reseller-Berechtigungen und ACLs: Bewahren Sie Reseller-Kontokonfigurationen und deren zugehörige Berechtigungen

2.4 Übertragungsoptionen konfigurieren

Zwei Einstellungen haben hier erhebliche betriebliche Auswirkungen:

Express Transfer automatisiert die DNS-Umstellung, indem die DNS-Zonen auf dem Quellserver sofort nach dem Kopieren jedes Kontos aktualisiert werden, um auf die IP des Zielservers zu zeigen. Dies minimiert das Zeitfenster, in dem eine Domain auf den alten Server aufgelöst wird. Verwenden Sie dies nur, wenn der Zielserver bereit ist, sofort Datenverkehr zu bedienen, und Sie bestätigt haben, dass alle Anwendungen funktionsfähig sind.

Mail Routing: Setzen Sie dies auf Automatic, es sei denn, Sie haben einen bestimmten Grund, lokales oder Remote-Routing zu erzwingen. Falsches Mail-Routing ist eine der häufigsten Ursachen für E-Mail-Zustellungsfehler nach der Migration.

2.5 Die Übertragung starten

Klicken Sie auf Copy, um den Prozess zu starten. WHM wird:

1. Per SSH in den Quellserver einloggen
2. pkgacct ausführen, um ein komprimiertes Archiv jedes Kontos zu erstellen
3. Das Archiv über SSH/SCP auf den Zielserver übertragen
4. restorepkg auf dem Zielserver ausführen, um das Konto zu extrahieren und zu erstellen
5. Das Ergebnis für jedes Konto protokollieren

Überwachen Sie das Live-Übertragungsprotokoll sorgfältig. Fehler bei einzelnen Konten stoppen den Gesamtprozess nicht — ein Konto kann still fehlschlagen, während andere erfolgreich sind. Überprüfen Sie das vollständige Protokoll nach Abschluss der Übertragung und führen Sie fehlgeschlagene Konten einzeln erneut aus.

Die Übertragungsdauer hängt vom Gesamtdatenvolumen und der Bandbreite zwischen den Servern ab. Ein Server mit 50 GB Kontodaten über eine 1 Gbps-Verbindung wird typischerweise in unter 30 Minuten abgeschlossen. Über eine 100 Mbps-Verbindung sollten Sie 60–90 Minuten einplanen.

Schritt 3: DNS-Umstellungsstrategie

Das DNS-Management ist der Bereich, in dem Migrationen am häufigsten zu längeren Ausfallzeiten führen. Das Verständnis der Propagationsmechanik ist entscheidend für die Minimierung der Auswirkungen auf Benutzer.

3.1 TTL vor der Migration reduzieren

Idealerweise sollten Sie 24–48 Stunden vor der Migration den TTL aller A-Records für gehostete Domains auf 300 Sekunden (5 Minuten) reduzieren. Dies stellt sicher, dass sich die Änderung nach der Aktualisierung der DNS-Records innerhalb von Minuten statt Stunden global verbreitet. Wenn Sie dies nicht im Voraus getan haben, müssen Sie den vorhandenen TTL-Wert als Ihr maximales Propagationsfenster berücksichtigen.

3.2 DNS-Zonen aktualisieren

Wenn der neue Server der autoritative Nameserver für die Domains ist, aktualisieren Sie die A-Records in jeder Zonendatei über WHM > DNS Functions > Edit DNS Zone, indem Sie die IP von der Adresse des alten Servers auf die neue ändern.

Wenn Domains einen externen DNS-Anbieter oder Registrar-DNS verwenden, melden Sie sich bei jedem Registrar oder DNS-Verwaltungspanel an und aktualisieren Sie die A-Records manuell. Für Massenaktualisierungen über viele Domains bieten die meisten Registrare API-Zugriff oder CSV-Import an.

3.3 Nameserver-Glue-Records aktualisieren

Wenn Sie auch Nameserver migrieren (z.B. ns1.yourdomain.com), müssen Sie die Glue-Records beim Domain-Registrar aktualisieren — nicht nur die Zonendatei. Glue-Records sind IP-Adress-Zuordnungen für Nameserver, die unter derselben Domain registriert sind, der sie dienen. Das Versäumnis, Glue-Records zu aktualisieren, ist ein häufiger Fehler, der zu einem vollständigen DNS-Auflösungsfehler für alle gehosteten Domains führt.

3.4 Propagation überprüfen

Verwenden Sie dig, um die Auflösung von mehreren geografischen Standorten aus zu überprüfen:

dig A yourdomain.com @8.8.8.8
dig A yourdomain.com @1.1.1.1

Vergleichen Sie mit einem webbasierten Propagations-Checker. Die vollständige globale Propagation wird typischerweise innerhalb von 1–4 Stunden abgeschlossen, wenn der TTL vorab reduziert wurde, oder bis zu 48 Stunden, wenn der TTL nicht im Voraus reduziert wurde.

Wenn Ihre Domains über Domain Registration registriert sind, können Nameserver-Aktualisierungen direkt über dasselbe Kontrollpanel verwaltet werden, was den Umstellungsprozess vereinfacht.

Schritt 4: Validierung nach der Migration

Erklären Sie eine Migration niemals als abgeschlossen, nur weil das Erfolgsprotokoll des Transfer Tools dies anzeigt. Validieren Sie jede Schicht des Stacks unabhängig.

4.1 Funktionalität der Webanwendung

Greifen Sie auf jede übertragene Domain direkt per IP über eine Hosts-Datei-Überschreibung zu (um die DNS-Propagation zu umgehen) und überprüfen Sie, ob die Anwendung korrekt lädt:

# Add to /etc/hosts on your local machine temporarily
203.0.113.50  yourdomain.com www.yourdomain.com

Überprüfen Sie auf Datenbankverbindungsfehler, fehlende Dateipfade und fehlerhafte Anwendungskonfigurationen. WordPress-Seiten schlagen häufig fehl, wenn die wp-config.php-Datenbankanmeldeinformationen auf localhost verweisen, aber der MySQL-Socket-Pfad zwischen den Servern unterschiedlich ist.

4.2 Datenbankintegrität

Melden Sie sich bei cPanel für jedes Konto an und überprüfen Sie, ob Datenbanken vorhanden und zugänglich sind. Führen Sie für kritische Datenbanken eine Integritätsprüfung durch:

mysqlcheck -u root -p --all-databases --check

4.3 E-Mail-Funktionalität

Testen Sie eingehende und ausgehende E-Mails für jedes Konto. Überprüfen Sie, ob MX-Records korrekt aufgelöst werden und ob der Mailserver Verbindungen auf den Ports 25, 465 und 587 akzeptiert. Überprüfen Sie /var/log/exim_mainlog auf Zustellungsfehler:

tail -f /var/log/exim_mainlog

Für Unternehmen mit dedizierter Mail-Infrastruktur bietet Email Hosting isolierte Mail-Umgebungen, die von Web-Server-Migrationen nicht betroffen sind.

4.4 SSL-Zertifikat-Überprüfung

Bestätigen Sie, dass SSL-Zertifikate korrekt übertragen wurden und aktiv sind. Navigieren Sie in WHM zu SSL/TLS > Manage SSL Hosts und überprüfen Sie, ob jede Domain ein gültiges, nicht abgelaufenes Zertifikat hat. AutoSSL sollte automatisch Let’s Encrypt-Zertifikate für alle neu ausstellen, die nicht übertragen werden konnten, aber lösen Sie es manuell aus, um nicht auf den geplanten Lauf warten zu müssen:

/usr/local/cpanel/bin/autossl_check --all

Wenn Sie Zertifikate unabhängig verwalten, können SSL Certificates direkt auf dem neuen Server installiert werden, ohne Abhängigkeit vom Übertragungsprozess.

4.5 Cron-Jobs und geplante Aufgaben

Cron-Jobs werden als Teil des Kontopakets übertragen, aber überprüfen Sie sie in cPanel > Cron Jobs für jedes Konto. Achten Sie besonders auf Cron-Jobs, die absolute Dateipfade oder serverspezifische Umgebungsvariablen referenzieren, die auf dem neuen Server unterschiedlich sein können.

Schritt 5: Bereinigung und Härtung nach der Migration

5.1 Konten auf dem Quellserver sperren

Sobald DNS propagiert und die Validierung abgeschlossen ist, sperren Sie alle Konten auf dem Quellserver über WHM > List Accounts > Suspend. Löschen Sie sie noch nicht. Die Sperrung verhindert, dass neue Daten auf den Quellserver geschrieben werden, während er als Fallback verfügbar bleibt, falls nach der Migration ein kritisches Problem auftritt.

5.2 Sicherung nach der Migration

Erstellen Sie unmittelbar nach der Migration eine neue vollständige Sicherung aller Konten auf dem neuen Server. Der übertragene Zustand ist Ihre neue Baseline:

/scripts/cpbackup --force

Überprüfen Sie, ob Sicherungen erfolgreich abgeschlossen werden und an einem Ort gespeichert sind, der vom Server selbst getrennt ist — idealerweise ein Off-Server-Sicherungsziel, das in WHM > Backup Configuration konfiguriert ist.

5.3 Leistungsüberwachung

Überwachen Sie die Ressourcenauslastung des neuen Servers 72 Stunden nach der Migration. Wichtige zu beobachtende Metriken:

• CPU-Lastdurchschnitt (sollte unter normaler Last unter der Anzahl der CPU-Kerne bleiben)
• Speichernutzung und Swap-Aktivität
• Disk I/O-Wartezeit (erhöhte I/O-Wartezeit weist auf Speicherengpässe hin)
• MySQL-Slow-Query-Log für Abfragen, die auf dem neuen Schema oder der neuen Engine-Version schlecht abschneiden

Verwenden Sie top, iostat und vmstat für die Echtzeit-Überwachung und überprüfen Sie cPanels Resource Monitor in WHM für den Ressourcenverbrauch pro Konto.

5.4 Den Quellserver außer Betrieb nehmen

Nach einer Mindestbeobachtungszeit von 7 Tagen ohne gemeldete Probleme können Sie den Quellserver außer Betrieb nehmen. Bevor Sie den alten Server kündigen, archivieren Sie eine abschließende Sicherung im Cold Storage. Dieses Archiv dient als rechtlicher und betrieblicher Nachweis und ist sehr kostengünstig aufzubewahren.

cPanel-Kontomigration: Methodenvergleich

Häufige Fallstricke und wie man sie vermeidet

Stille Kontomigrationsfehler. Das Transfer Tool setzt die Verarbeitung fort, auch wenn einzelne Konten fehlschlagen. Lesen Sie immer das vollständige Übertragungsprotokoll — gehen Sie nicht von Erfolg aus, nur weil das Tool ohne Unterbrechung beendet wurde.

MySQL-Benutzerberechtigungsabweichung. restorepkg erstellt Datenbankbenutzer neu, aber wenn ein Datenbankbenutzername MySQLs 32-Zeichen-Limit überschreitet (ein häufiges Problem bei Legacy-Konten), wird der Benutzer mit einem abgeschnittenen Namen erstellt und die Datenbankanmeldeinformationen der Anwendung stimmen nicht mehr überein. Überprüfen Sie lange Datenbankbenutzernamen vor der Migration.

Perl-Modul- und benutzerdefinierte Software-Abhängigkeiten. Anwendungen, die auf benutzerdefiniert kompilierte Perl-Module, Python-Pakete oder Systembibliotheken angewiesen sind, die außerhalb der verwalteten Pfade von cPanel installiert wurden, werden nicht übertragen. Diese Abhängigkeiten müssen manuell auf dem Zielserver neu installiert werden.

Disk-Quota-Abweichungen. Das Disk-Quota-System von cPanel verwendet Quotas auf Dateisystemebene. Nach der Migration spiegeln Quotas möglicherweise nicht korrekt wider, bis das Quota-Neuberechnungsskript ausgeführt wird:

/scripts/fixquotas

ModSecurity-Regelkonflikte. Wenn der Quellserver benutzerdefinierte ModSecurity-Regeln oder eine andere Regelversion als der Zielserver hatte, erhalten übertragene Seiten möglicherweise unerwartete 403-Fehler. Überprüfen Sie ModSecurity-Protokolle unter /usr/local/apache/logs/error_log nach der Migration.

Reseller-Konto-Berechtigungslücken. Reseller-ACLs und Paketzuweisungen werden übertragen, aber wenn der Ziel-WHM andere Feature-Listen konfiguriert hat, stellen Reseller möglicherweise fest, dass ihre Konten weniger oder andere Funktionen als erwartet haben. Überprüfen Sie Reseller-Konfigurationen nach der Migration.

Für Hochverkehrsumgebungen, bei denen die Ausfallzeittoleranz nahe null liegt, sollten Sie die Migration auf einem Dedicated Server mit dedizierten Ressourcen durchführen, um das Risiko von Ressourcenkonflikten während der Übertragungs- und Validierungsphasen zu eliminieren.

Technische Entscheidungsmatrix

Verwenden Sie diese Matrix, um Ihren Migrationsansatz basierend auf den Umgebungsmerkmalen zu bestimmen:

FAQ

Kann ich cPanel-Konten ohne Root-Zugriff auf den Quellserver migrieren?

Nein. Das WHM Transfer Tool erfordert Root-SSH-Zugriff auf den Quellserver, um pkgacct auszuführen und alle Kontodaten zu lesen. Wenn Root-Zugriff nicht verfügbar ist, besteht die einzige Alternative darin, individuelle cPanel-Sicherungsdateien (.tar.gz-Archive) vom Administrator des Quellservers anzufordern und sie manuell mit restorepkg auf dem Zielserver wiederherzustellen.

Wie lange dauert eine vollständige cPanel-Server-Migration?

Die Übertragungszeit hängt vom Gesamtdatenvolumen und der Netzwerkbandbreite zwischen den Servern ab. Ein Server mit 100 GB Kontodaten über eine dedizierte 1 Gbps-Verbindung wird typischerweise in 15–30 Minuten übertragen. Über gemeinsam genutzte oder gedrosselte Verbindungen kann dieselbe Datenmenge mehrere Stunden dauern. Die DNS-Propagation fügt je nach TTL-Werten zusätzliche 1–48 Stunden hinzu.

Werden SSL-Zertifikate automatisch übertragen?

SSL-Zertifikate, die über AutoSSL (Let’s Encrypt) installiert wurden, werden nicht als gültige Zertifikate übertragen — sie werden von AutoSSL auf dem Zielserver neu ausgestellt, da sie an die IP des Servers und das Konto gebunden sind. Kommerziell erworbene Zertifikate, die in cPanel gespeichert sind, werden als Teil des Kontopakets übertragen, müssen aber nach der Migration überprüft und reaktiviert werden.

Was passiert mit E-Mails auf dem alten Server während des Migrationsfensters?

E-Mails, die während des Migrationsfensters an den alten Server zugestellt werden, werden in der Mail-Queue und den Benutzerpostfächern des alten Servers gespeichert. Sie werden nicht automatisch auf den neuen Server repliziert. Um Mailverlust zu verhindern, halten Sie entweder die Mail-Dienste des alten Servers aktiv, bis DNS vollständig propagiert ist, oder konfigurieren Sie Exim des alten Servers so, dass eingehende Mails während des Übergangszeitraums an die IP des neuen Servers weitergeleitet werden.

Kann das WHM Transfer Tool Konten zwischen verschiedenen Betriebssystemen migrieren (z.B. CentOS zu AlmaLinux)?

Ja. Das Transfer Tool ist auf Anwendungsebene OS-agnostisch — es überträgt cPanel-Kontodaten, keine OS-Konfigurationen. Migrationen von CentOS 7 zu AlmaLinux 8 oder Rocky Linux 8 werden vollständig unterstützt und sind das häufigste Migrationsszenario nach dem End-of-Life von CentOS 7. Stellen Sie sicher, dass alle benutzerdefinierten Konfigurationen auf Systemebene (SELinux-Richtlinien, benutzerdefinierte Kernel-Module, Nicht-cPanel-Dienste) manuell auf dem Zielserver repliziert werden.