netcup G12 auf G12.5 umziehen: Server mit rsync oder Snapshot wechseln

Seit dem 22.09.2026 stellt netcup seine VPS und Root-Server auf die Generation 12.5 um. Wer noch einen VPS der Generation 12 hat, kann ihn laut netcup nicht per Upgrade auf die neue Generation heben. Der Weg dorthin ist ein neuer Vertrag, ein neuer Server mit neuer IP-Adresse und ein Umzug der Daten. Diese Anleitung zeigt Schritt für Schritt den Umzug mit rsync und den Weg über einen exportierten Snapshot. Alle Befehle, Ausgaben und Bilder stammen aus unserem Test: Als alter Server diente ein Ubuntu-System auf einem eigenen Testserver, Ziel war ein neu bestellter VPS 500 G12.5. Snapshot, Export und Wiederherstellung haben wir am G12.5-Server durchgespielt.

Dies ist Teil 1 der Reihe „netcup Spezial“, die Funktionen und Eigenheiten von netcup behandelt, die anderswo kaum beschrieben sind.

Voraussetzungen

• Ein bestehender netcup-Server der Generation 12 mit SSH-Zugang als root
• Ein neu bestellter Server der Generation 12.5 mit installiertem Linux, im Test ein VPS 500 G12.5 (2 vCore, 4 GB RAM, 64 GB SSD, x86) mit Ubuntu 24.04
• Zugang zum Server Control Panel (SCP) und zum Customer Control Panel (CCP)
• Zugriff auf die DNS-Einträge Ihrer Domains
• Ein aktuelles Backup außerhalb des alten Servers
• Etwa 1 bis 2 Stunden, je nach Datenmenge

Warum es kein Upgrade auf G12.5 gibt

netcup beantwortet die Frage in den FAQ zu den VPS-Tarifen eindeutig: Ein direktes Upgrade von VPS G12 auf VPS G12.5 ist nicht möglich. Sie bestellen stattdessen einen G12.5-Tarif, kündigen den G12-Tarif zum Ende seiner Mindestvertragslaufzeit und migrieren Ihre Daten. Upgrades innerhalb der Generation 12 bleiben möglich, das beschreibt unsere Anleitung zum Instance Upgrade im CCP. Dort bleiben Daten und IP erhalten.

Beim Wechsel der Generation bekommt der neue Server eine eigene IPv4-Adresse und ein eigenes IPv6-Netz.

Weg	Geeignet für	Ausfallzeit	Wichtigste Grenze
rsync und Datenbank-Dump	Webserver, Datenbanken, Docker-Daten, Umzug auf ein frisches System	nur für den letzten Abgleich	Dienste und Konfiguration müssen Sie auf dem neuen Server selbst einrichten
Offline-Snapshot exportieren	exakte Kopie des ganzen Systems	Server ist während des Snapshots aus	Export wird nach 48 Stunden gelöscht, auf anderem Server eventuell Netzwerk anpassen

Verifizieren: Sie wissen, welcher Weg zu Ihrem Server passt. Für die meisten Umzüge empfehlen wir rsync, weil das neue System sauber startet und Altlasten zurückbleiben.

Schritt 1: Den neuen Server bestellen

Bestellen Sie den G12.5-Tarif auf der Website von netcup. Drei Einstellungen in der Konfiguration verdienen einen zweiten Blick.

• Vertragslaufzeit: netcup bietet für die G12.5-VPS 1, 12 oder 24 Monate an. Längere Laufzeiten sind günstiger, binden Sie aber.
• Standort: „Keine Präferenz Europa“ heißt laut netcup, dass der Server in Österreich, Deutschland oder den Niederlanden stehen kann. Einen festen Standort wählen Sie gegen Aufpreis.
• Netzwerk: Seit Generation 12 wählen Sie zwischen IPv4 und IPv6, nur IPv6 oder nur Cloud vLAN. Laut netcup lässt sich das nachträglich nicht ändern. Für einen Umzug eines normalen Servers nehmen Sie die Voreinstellung „IPv4 + IPv6 Connectivity“.

Beide Server laufen eine Zeit lang parallel, beide Verträge kosten in dieser Zeit Geld.

Verifizieren: Der neue Server erscheint im SCP mit dem Zusatz G12.5.

Schritt 2: Das neue System vorbereiten

Installieren Sie im SCP unter Medien und Images ein Betriebssystem und wählen Sie dabei einen SSH-Schlüssel aus. Wie das geht, beschreibt unsere Anleitung zu SSH-Schlüsseln im SCP. Notieren Sie sich danach die neuen Adressen im Reiter Allgemein.

Installieren Sie auf dem neuen Server dieselben Dienste wie auf dem alten, im Beispiel Webserver und Datenbank:

apt-get update
apt-get install -y nginx mariadb-server rsync

Im Test meldeten die Programme danach nginx 1.24.0, MariaDB 10.11.14 und rsync 3.2.7. rsync muss auf beiden Servern installiert sein.

Verifizieren: Sie können sich per SSH am neuen Server anmelden, und die benötigten Dienste laufen.

Schritt 3: Inventur auf dem alten Server

Bevor Sie Daten bewegen, halten Sie fest, was auf dem alten Server liegt und läuft. Das verhindert, dass ein Cronjob oder eine vergessene Datenbank erst nach der Kündigung auffällt.

df -h /
du -sh /var/www /etc/nginx /var/lib/mysql
systemctl list-units --type=service --state=running --no-pager --plain

In unserem Test ergab das unter anderem:

21M	/var/www
68K	/etc/nginx
125M	/var/lib/mysql
cron.service             loaded active running Regular background program processing daemon
mariadb.service          loaded active running MariaDB 10.11.14 database server
nginx.service            loaded active running A high performance web server and a reverse proxy server

Prüfen Sie zusätzlich crontab -l, /etc/cron.d, docker volume ls und /etc/letsencrypt.

Verifizieren: Sie haben eine Liste aller Verzeichnisse, Datenbanken und Dienste, die umziehen müssen.

Schritt 4: DNS-TTL rechtzeitig senken

Wie lange Resolver den alten DNS-Eintrag behalten, bestimmt die TTL. Senken Sie die TTL der betroffenen A- und AAAA-Einträge deshalb einen Tag vor dem Umzug, etwa auf 300 Sekunden. Wie Sie Einträge im CCP bearbeiten, zeigt unsere Anleitung zu DNS-Records bei netcup.

Verifizieren: dig +noall +answer www.example.com zeigt die niedrigere TTL.

Schritt 5: SSH vom alten zum neuen Server

rsync arbeitet über SSH. Erzeugen Sie auf dem alten Server einen Schlüssel für den Umzug. Liegt unter diesem Pfad schon ein Schlüssel, etwa für ein Backup, überschreiben Sie ihn nicht, sondern nutzen den vorhandenen:

ssh-keygen -t ed25519 -N "" -C server-migration -f /root/.ssh/id_ed25519

Ohne hinterlegten Schlüssel lehnt der neue Server die Verbindung ab. Im Test sah das so aus, die IP ist hier wie im ganzen Artikel ein Platzhalter:

root@203.0.113.10: Permission denied (publickey).

Hängen Sie den öffentlichen Schlüssel auf dem neuen Server an /root/.ssh/authorized_keys an. Von Ihrem eigenen Rechner aus, der beide Server erreicht, geht das in einer Zeile:

ssh root@alt.example.com cat /root/.ssh/id_ed25519.pub | ssh root@203.0.113.10 'cat >> /root/.ssh/authorized_keys'

Den Fingerabdruck, nach dem SSH beim ersten Verbinden fragt, vergleichen Sie mit ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub auf dem neuen Server. Danach klappt es:

ssh root@203.0.113.10 'echo Verbindung erfolgreich'

Verbindung erfolgreich

Verifizieren: Die Verbindung vom alten zum neuen Server klappt ohne Passwortabfrage.

Schritt 6: Probelauf mit rsync

Ein Probelauf mit -n zeigt, was rsync übertragen würde, ohne etwas zu schreiben. Achten Sie auf den Schrägstrich am Ende der Quelle: /var/www/shop/ überträgt den Inhalt des Ordners, ohne Schrägstrich landet ein zusätzlicher Unterordner im Ziel.

rsync -aHAXn --itemize-changes /var/www/shop/ root@203.0.113.10:/var/www/shop/ | head -5
rsync -aHAXn --stats /var/www/shop/ root@203.0.113.10:/var/www/shop/

created directory /var/www/shop
cd+++++++++ ./
<f+++++++++ index.html
cd+++++++++ bilder/
<f+++++++++ bilder/artikel-1.txt
Number of files: 204 (reg: 202, dir: 2)
Number of regular files transferred: 202
Total file size: 20,973,837 bytes

-aHAX erhält Rechte, Eigentümer, Zeitstempel, harte Links, ACLs und erweiterte Attribute. Trotz „created directory“ legt der Probelauf nichts an, das Verzeichnis fehlte danach noch.

Verifizieren: Anzahl und Größe der Dateien passen zu Ihrer Inventur aus Schritt 3.

Schritt 7: Erster Lauf mit Dateien und Datenbank

Der erste echte Lauf überträgt alles und darf laufen, während der alte Server noch Besucher bedient:

rsync -aHAXz --stats /var/www/shop/ root@203.0.113.10:/var/www/shop/
rsync -aHAX /etc/nginx/sites-available/shop root@203.0.113.10:/etc/nginx/sites-available/shop

Number of regular files transferred: 202
Total transferred file size: 20,973,837 bytes
Total bytes sent: 20,990,481

Die rund 21 MB brauchten im Test knapp 5 Sekunden. Große Datenmengen übertragen Sie in screen oder tmux, damit ein Verbindungsabbruch den Lauf nicht beendet.

Datenbanken kopieren Sie nicht als Dateien, solange sie laufen. Übertragen Sie stattdessen einen Dump direkt in die Datenbank des neuen Servers:

mysqldump --single-transaction --databases shop | ssh root@203.0.113.10 mysql

Auf dem neuen Server waren danach beide Testbestellungen vorhanden. Übertragen Sie Zertifikate unter /etc/letsencrypt auf dieselbe Weise mit rsync, sonst scheitert nginx -t bei Seiten mit TLS. Alternativ stellen Sie das Zertifikat nach der DNS-Umstellung neu aus.

Der Dump enthält die Daten, aber keine Datenbank-Benutzer. Ohne sie kommt Ihre Anwendung auf dem neuen Server nicht an die Datenbank. Der naheliegende Weg mariadb-dump --system=users brach im Test beim Einspielen ab, weil er auch die Systemkonten enthält, die auf dem neuen Server schon existieren:

ERROR 1396 (HY000) at line 18: Operation CREATE USER failed for 'mariadb.sys'@'localhost'

Lesen Sie deshalb nur Ihre eigenen Benutzer aus. Dieses Skript schreibt deren Anlage und Rechte in eine Datei:

for u in $(mysql -N -e "SELECT CONCAT(QUOTE(User),'@',QUOTE(Host)) FROM mysql.user WHERE User NOT IN ('root','mysql','mariadb.sys','')"); do
  mysql -N -e "SHOW CREATE USER $u"
  mysql -N -e "SHOW GRANTS FOR $u" | grep -v '^GRANT USAGE'
done | sed 's/$/;/' > /root/users.sql

Kopieren Sie users.sql auf den neuen Server und spielen Sie sie mit mysql < /root/users.sql ein. Im Test meldete sich unser Benutzer danach mit seinem alten Passwort an und las die Bestellungen. Die Datei enthält Passwort-Hashes, löschen Sie sie danach auf beiden Servern.

Verifizieren: mysql -e "SELECT COUNT(*) FROM shop.bestellungen" zeigt auf beiden Servern dieselbe Zahl.

Schritt 8: Zweiter Lauf überträgt nur Änderungen

Zwischen erstem Lauf und Umschalten ändert sich auf dem alten Server weiter etwas. Im Test kamen eine Datei und eine Bestellung dazu. Derselbe rsync-Befehl erneut ausgeführt:

Number of regular files transferred: 1
Total transferred file size: 12 bytes
Total bytes sent: 4,076

Statt rund 21 MB gingen nur gut 4 KB über die Leitung. Den großen Teil erledigen Sie also vorab, der letzte Abgleich im Wartungsfenster ist kurz.

Verifizieren: Der zweite Lauf meldet nur noch wenige übertragene Dateien.

Schritt 9: Umschalten im Wartungsfenster

Stoppen Sie auf dem alten Server alles, was Daten schreibt: Webserver, PHP-FPM, Cronjobs, Worker und Container. MariaDB läuft für den letzten Dump weiter. Ab hier ist die Website offline, bis DNS umgestellt ist, planen Sie das Wartungsfenster entsprechend:

systemctl stop nginx
rsync -aHAXz --delete --stats /var/www/shop/ root@203.0.113.10:/var/www/shop/
mysqldump --single-transaction --databases shop | ssh root@203.0.113.10 mysql

Die Option --delete entfernt im Ziel Dateien, die auf der Quelle nicht mehr existieren. Setzen Sie sie erst im letzten Lauf und machen Sie vorher einen Probelauf mit rsync -aHAXn --delete --itemize-changes …: Jede Zeile mit *deleting wäre eine Löschung im Ziel. Im Test meldete der echte Lauf Number of deleted files: 0. Danach aktivieren Sie die Konfiguration auf dem neuen Server:

ln -sf /etc/nginx/sites-available/shop /etc/nginx/sites-enabled/shop
nginx -t && systemctl reload nginx

Bevor Sie DNS umstellen, prüfen Sie die Website direkt auf dem neuen Server, indem Sie den Namen im Host-Header mitschicken:

curl -s -H "Host: shop.example.test" http://127.0.0.1/

<h1>Testshop Quelle</h1>

Im Test hatte der neue Server danach alle 203 Dateien und 3 Bestellungen, die Prüfsumme der 20 MiB großen Testdatei war auf beiden Servern identisch.

Verifizieren: sha256sum wichtiger Dateien und die Zahl der Datensätze stimmen auf beiden Servern überein.

Schritt 10: DNS, Reverse-DNS und Firewall nachziehen

Tragen Sie jetzt die neuen Adressen in die A- und AAAA-Einträge ein. Für Mailserver setzen Sie zusätzlich den Reverse-DNS-Eintrag der neuen IP im SCP, siehe Reverse-DNS bei netcup. Nutzen Sie die Firewall im SCP, prüfen Sie dort auch die Regeln für den neuen Server.

Muss eine Adresse über Serverwechsel hinweg gleich bleiben, hilft eine Failover-IP, die Sie zwischen Servern umhängen.

Verifizieren: dig +short www.example.com liefert die neue IP.

Schritt 11: Alternative mit exportiertem Snapshot

Für einen Klon des ganzen Systems empfiehlt netcup einen Offline-Snapshot, im SCP unter Medien und Snapshots.

Der Server wird für einen Offline-Snapshot heruntergefahren und startete im Test danach von selbst wieder, nach wenigen Minuten war er wieder per SSH erreichbar. Danach klicken Sie in der Liste auf Exportieren.

Der Export erscheint unter Medien, Images, Eigene Images, laut netcup auf allen Ihren Servern. Bei uns war er als Rohabbild mit 999,7 MiB nach wenigen Minuten verfügbar, die Anzeige „Exports“ im Reiter Allgemein sprang danach von 1 auf 0 verbleibend. Auf dem Zielserver wählen Sie dort Installieren.

Lesen Sie die Bestätigung genau. Beim Einspielen löscht das SCP nicht nur alle Daten der Zielfestplatte, sondern auch die Snapshots, die auf dieser Festplatte liegen. Außerdem verlangt netcup in einem Popup-Fenster eine erneute Bestätigung Ihrer Identität.

Im Test haben wir den Testshop vorher gelöscht und den Export auf denselben Server eingespielt. Danach blieb der Server ausgeschaltet, das SCP zeigte „HERUNTERGEFAHREN“. Erst nach einem Klick auf Starten im Reiter Steuerung lief er wieder, und alle 203 Dateien, die 3 Bestellungen und die Prüfsumme der Testdatei waren wie vor dem Löschen.

Ein Klon trägt die Netzwerkkonfiguration des alten Servers mit. Auf unserem G12.5-Server enthält /etc/netplan/50-cloud-init.yaml feste Adressen. Laut netcup müssen Sie nach dem Einspielen auf einem anderen Server deshalb eventuell die Netzwerkkonfiguration anpassen, etwa über die VNC-Konsole im SCP. Die Festplatte des neuen Servers muss mindestens so groß sein wie die genutzte Partition des alten. Mehr dazu in unserer Anleitung zu netcup-Snapshots.

Verifizieren: Nach dem Einspielen starten Sie den Server im Reiter Steuerung und prüfen Daten und Dienste wie in Schritt 9.

Schritt 12: Den alten Vertrag kündigen

Kündigen Sie den alten Server, wenn der neue ein paar Tage ohne Auffälligkeiten läuft. Laut netcup-Hilfe kündigen Sie im CCP unter Produkte, Lupen-Symbol vor dem Produkt, Registerkarte Kündigung. Dort steht auch, wann die Kündigung wirksam wird. Unseren Testserver mit einem Monat Laufzeit haben wir am Tag der Bestellung gekündigt, das CCP meldete danach „Für dieses Produkt ist eine Kündigung zum 02.12.2026 vorgemerkt“.

Prüfen Sie die Frist für Ihren Vertrag rechtzeitig. In der Hilfe zum Produkt-Upgrade nennt netcup 31 Tage vor Ablauf der Mindestvertragslaufzeit, sonst verlängert sich der Vertrag. Mehr dazu in Kündigung und Laufzeiten bei netcup.

Brauchen Sie keinen Nachabgleich mehr, räumen Sie auf: Entfernen Sie den Umzugsschlüssel auf dem neuen Server und löschen Sie ihn auf dem alten, falls Sie ihn nur für den Umzug angelegt haben.

sed -i '/server-migration/d' /root/.ssh/authorized_keys

Verifizieren: Im CCP steht beim alten Produkt ein Kündigungsdatum, und grep -c server-migration /root/.ssh/authorized_keys meldet auf dem neuen Server 0.

Typische Fehler

Symptom	Ursache und Lösung
Permission denied (publickey) beim ersten rsync	Schlüssel des alten Servers fehlt in authorized_keys des neuen. Schlüssel anhängen, Verbindung mit ssh testen.
Daten liegen im Ziel eine Ebene zu tief	Schrägstrich am Ende der Quelle fehlte, Quelle als /pfad/ angeben.
Online-Snapshot lässt sich nicht wählen	UEFI-Boot ist aktiv. Offline-Snapshot nutzen, der Server fährt dafür herunter.
ERROR 1396 beim Einspielen der Benutzer	Systemkonten wie mariadb.sys existieren schon. Nur eigene Benutzer übertragen, siehe Schritt 7.
Server nach Einspielen eines Exports aus	Das SCP startet ihn nicht von selbst. Im Reiter Steuerung auf Starten klicken.

Häufige Fragen

Kann ich die alte IP-Adresse mitnehmen?

Die Hauptadresse gehört zum alten Server. Für eine feste Adresse über Serverwechsel hinweg gibt es die Failover-IP.

Fazit

Der Sprung von netcup G12 auf G12.5 ist kein Klick im CCP, sondern ein kleiner Serverumzug. Mit zwei rsync-Läufen und einem kurzen Wartungsfenster bleibt die Ausfallzeit gering, der alte Server bleibt bis zum Schluss als Rückfallebene unverändert. Planen Sie neue IP, TTL und Kündigung von Anfang an ein.

Weiterführende Anleitungen und Quellen

• netcup VPS innerhalb der Generation upgraden
• netcup-Snapshots: Offline, Online, Export
• Kündigung und Laufzeiten bei netcup
• Docker Compose unter Linux: die Grundlage
• netcup: VPS-Tarife und FAQ zu G12.5
• netcup: Server migrieren per rsync
• netcup: Server migrieren per Snapshot
• netcup: Produkt-Upgrade