Umzug oder Übergabe planen: Proxmox-Setup betrifft den Zielaufbau. Für eine bestehende Umgebung und den Dienstleisterwechsel ist die Proxmox-Übernahme der passende Einstieg. Erstgespräch.
Ein Proxmox-Serverumzug und ein Wechsel des Dienstleisters sind zwei verschiedene Vorhaben. Der technische Umzug verlagert Gäste und gegebenenfalls Daten; die Betriebsübergabe klärt Zugänge, Wissen und Verantwortung. Der Artikel enthält die gängigen Befehle für Cluster-Beitritt, Migration, Restore und Node-Entfernung. Stand: Oktober 2026.
Inhalt
- Ausgangslage und Verfahren wählen
- Neue Hardware vorbereiten
- Gäste kontrolliert übertragen
- Beispiel: Befehle für Migration und Restore
- Umschaltung und Rückfall
- Dienstleisterwechsel dokumentieren
- Abnahme und nächste Schritte
- Quellen
Ausgangslage und Verfahren wählen
Inventarisieren Sie Gäste, lokale und gemeinsame Datenträger, CPU-Typen, Passthrough, Container-Mounts, Bridges und externe Dienste. Prüfen Sie den letzten wiederherstellbaren Sicherungsstand, bevor Sie einen Übertragungsweg freigeben. Der PVE-Backup-Weg und die VM-Migration haben unterschiedliche Voraussetzungen.
| Situation | Planungsweg | Vorher klären |
|---|---|---|
| Eigenständiger alter und neuer Host | Gast-Backup auf neuem PVE wiederherstellen | Backup-Zugriff, freies Ziel, Ausfallfenster und finaler Datenstand |
| Ersatz im gleichen Cluster | Leeren Node aufnehmen, Gäste migrieren, alten Node geordnet entfernen | Quorum, Kapazität, CPU-Kompatibilität und Storage |
| CPU-Wechsel oder lokale Gerätebindung | Geplanter Stopp mit Restore beziehungsweise geeigneter Offline-Migration | Gast-CPU-Konfiguration, Treiber und Geräte auf dem Ziel |
| Nur Dienstleisterwechsel | Betriebsübergabe ohne erzwungenen Hardwarewechsel | Dokumentation, Zugänge und Verantwortlichkeiten |
Bei regulärer Live-Migration müssen Quelle und Ziel im selben Cluster liegen, die Verbindung zuverlässig sein und der Ziel-Paketstand mindestens passen. Durchgereichte PCI-/USB-Geräte blockieren diesen Weg; CPU-Kompatibilität muss vorher feststehen (VM-Migrationsanforderungen). Das ist keine Zusage für einen unterbrechungsfreien Umzug. Andere Transferfunktionen werden gesondert nach Version und Topologie bewertet.
Neue Hardware vorbereiten
Prüfen Sie CPU, RAM, Datenträger, Controller und Netzwerk gegen die Proxmox-Systemanforderungen und den tatsächlichen Gastbedarf. Die Hardware- und Sizing-Anleitung ordnet die Ressourcen ein. Reserven für Migration, Backup und einen geplanten Nodeausfall gehören in dieselbe Betrachtung.
Installieren Sie das Ziel mit eindeutigem Hostnamen und passender Netzkonfiguration. Erfassen Sie Bridge-Namen, VLANs, Routing und Storage-IDs. Die Namen von NICs und Datenträgern dürfen nicht allein aus der alten Installation abgeleitet werden (Netzkonfiguration). Halten Sie einen von der betroffenen Netzkonfiguration unabhängigen Konsolenzugang bereit.
Für den Cluster-Beitritt muss der Zielnode frei von Gästen sein. Der Join überschreibt /etc/pve und übernimmt die Cluster-Storage-Konfiguration. Abweichende lokale Storages und Node-Beschränkungen müssen danach passend eingerichtet werden (Cluster Manager). Alte und neue Nodes nicht unkoordiniert entfernen oder umbenennen.
Gäste kontrolliert übertragen
Für Backup-Restore: Zugriff auf den tatsächlichen Backup-Speicher und gegebenenfalls PBS-Namespace, Rechte sowie Verschlüsselungsschlüssel bestätigen. Ziel-Storage und ID wählen, den Gast ohne automatischen Start wiederherstellen und danach Netz sowie Geräte prüfen. Der Restore-Test-Guide beschreibt den isolierten Probelauf.
Bei LXC sichern PVE-Backups keine Bind-/Device-Mount-Inhalte. Zusätzliche Daten daher separat übertragen. Vor einem Teststart alle mpX-Einträge prüfen, produktive Bind-/Device-Mounts entfernen oder auf unabhängige Testkopien umlegen. Diese Grenze steht in der Backup-Dokumentation.
Für Cluster-Migration: zuerst einen geeigneten Gast mit festgelegten Prüfkriterien übertragen. Lokale Disks, CPU-Modell und Gerätebindungen anhand der VM-Dokumentation bewerten. Eine erfolgreiche einzelne Migration ersetzt nicht die Prüfung anderer Gasttypen. Bei einem CPU-Herstellerwechsel einen Stopp und den passenden Start-CPU-Typ einplanen, statt Live-Kompatibilität vorauszusetzen.
Beispiel: Befehle für Migration und Restore
Die folgenden Befehle zeigen die gängigen Wege. Gast-IDs, Node- und Storage-Namen sind Platzhalter.
Neuen Node in den Cluster aufnehmen (auf dem neuen, gästefreien Node):
pvecm add 192.0.2.11 --link0 10.10.10.15 # IP eines bestehenden Nodes, eigene Corosync-Adresse
pvecm status # Quorum und Mitglieder prüfen
pvecm nodes
Gäste migrieren:
qm migrate 100 pve-new --online # VM live, gemeinsamer Speicher
qm migrate 100 pve-new --online --with-local-disks --targetstorage local-zfs # VM mit lokalen Disks
pct migrate 200 pve-new --restart # Container: Neustart-Migration
Eine VM mit unterschiedlichen CPU-Typen auf Quelle und Ziel erhält einen kompatiblen CPU-Typ, bevor sie auf den neuen Host zieht:
qm set 100 --cpu x86-64-v2-AES # breit kompatibles CPU-Modell; wirkt nach dem nächsten Neustart des Gasts
Gäste aus einem Backup wiederherstellen (eigenständiger neuer Host), jeweils ohne automatischen Start:
qmrestore /mnt/backup/vzdump-qemu-100-2026_10_21-02_00_00.vma.zst 100 --storage local-zfs
pct restore 200 /mnt/backup/vzdump-lxc-200-2026_10_21-02_00_00.tar.zst --storage local-zfs
# aus einem Proxmox Backup Server:
qmrestore pbs-store1:backup/vm/100/2026-10-21T02:00:00Z 100 --storage local-zfs
Alten Node entfernen, erst nach Abnahme, nachdem er heruntergefahren und nicht mehr erreichbar ist (auf einem verbleibenden Node):
pvecm delnode pve-old
pvecm status
Den entfernten Node nicht wieder in das Netz bringen, ohne ihn vorher neu zu installieren: Alte Cluster-Identität und neue würden kollidieren.
Umschaltung und Rückfall
Vor der finalen Übertragung Schreibzugriffe kontrolliert beenden und den finalen Datenstand herstellen. Bei Anwendungen mit mehreren VMs zusätzlich deren gemeinsame Konsistenz klären. Quelle anschließend gegen Doppelstart sichern; produktive IP, DNS, Routing und externe Anbindungen erst gemäß Umschaltplan auf das Ziel legen.
Definieren Sie den Rückfall vorab: Wer entscheidet, welche Daten sind seit der Umschaltung neu und wie kommen sie bei einer Rückkehr zur Quelle? Ein alter Sicherungsstand ist nach produktiven Schreibzugriffen auf dem Ziel keine verlustfreie Rückkehr. Dokumentieren Sie deshalb die jeweils schreibende Instanz und einen Abbruchpunkt vor der produktiven Freigabe.
Dienstleisterwechsel dokumentieren
Für die Übergabe werden folgende Punkte mit dem bisherigen und dem künftigen Betreiber geklärt. Das sind Prüfpunkte, keine automatisch enthaltenen Zusatzleistungen:
- Inventar, Netzplan, Storage-Zuordnung und dokumentierte Abweichungen übergeben.
- Administrative Zugänge, MFA-Recovery und Eigentum an Accounts klären.
- Backup-Katalog, Schlüsselzugriff und vorhandene Restore-Nachweise prüfen.
- Überwachung, Alarmwege und offene Störungen erfassen.
- Zuständigkeiten für Host, Gast, Anwendung und externe Anbieter festhalten.
- Zeitpunkt für Rechtewechsel und Widerruf alter Zugänge vereinbaren.
Geheimnisse über einen geschützten Übergabeweg übertragen. Bestehende Zugänge erst nach bestätigtem Ersatz widerrufen. Ein Hardwarewechsel wird daraus nur, wenn Befund und Zielarchitektur ihn verlangen. WZ-IT beschreibt den Einstieg über Health-Check und dokumentierte Übergabe auf der Übernahmeseite.
Abnahme und nächste Schritte
Nach der Umschaltung prüfen: Gaststart, Datenstand, Anwendungsablauf, Erreichbarkeit, Backup und Überwachung. Den alten Node erst nach Abnahme und gemäß Node-Entfernung aus dem Cluster nehmen. Bei erforderlicher Datenlöschung den vereinbarten Sicherungs- und Aufbewahrungsumfang berücksichtigen.
Für neue Zielhardware: Proxmox-Setup. Für Bestandsprüfung, Dokumentation und Betriebsübergabe: Proxmox-Übernahme. Transferweg und Betriebsumfang werden aus dem Befund abgeleitet.
