Langsame Proxmox-Restores: 8 Engpässe, die Sie prüfen sollten

Ein langsamer Proxmox-Restore ist meist ein Problem der gesamten Pipeline, nicht eine einzelne Proxmox-Einstellung. Die effektive Restore-Rate wird von der langsamsten Stufe zwischen Backup-Repository, Backup-Worker, Netzwerk und dem Ziel-Storage in Proxmox begrenzt.

Messen Sie diese Stufen, bevor Sie die MTU ändern, NICs hinzufügen oder dem Hypervisor die Schuld geben. Ein 25-GbE-Link garantiert keinen 25-GbE-Restore, wenn bereits ein CPU-Kern, ein Deduplizierungs-Repository oder das Ziel-Datastore ausgelastet ist.

Dieser Leitfaden wurde durch einen Bericht im Veeam-R&D-Forum vom August 2026 angestoßen, in dem ein Proxmox-Restore trotz zweier 25-GbE-Links und schnellem NVMe-Storage nur bei rund 500 Mbit/s lag. Das ist ein einzelner Bericht eines Anwenders, kein universelles Veeam-Limit. Die folgende Fehlersuche stützt sich auf Veeams aktuelle Proxmox-Worker-Dokumentation und die Proxmox-Storage-Hinweise, statt anzunehmen, dass der Forumsfall eine einzige magische Lösung hat.

Was sollten Sie vor der Fehlersuche messen?

Messen Sie den Lesedurchsatz des Repositorys, die Worker-CPU, den Worker-RAM, den Netzwerkdurchsatz und die Schreiblatenz des Ziel-Storage gleichzeitig. Eine Restore-Geschwindigkeit allein identifiziert den Engpass nicht.

Notieren Sie sich während eines repräsentativen Restores fünf Werte:

1. Vom Backup-Job gemeldeter Restore-Durchsatz.
2. CPU-Auslastung pro Kern auf Worker und Backup-Server.
3. Netzwerkdurchsatz auf Worker und Proxmox-Host.
4. Lesedurchsatz und Latenz auf dem Backup-Repository.
5. Schreibdurchsatz und Latenz auf dem Ziel-Storage.

Führen Sie denselben Test zunächst mit einer großen VM durch, bevor Sie mehrere gleichzeitige Restores testen. Parallelität kann das Verhalten eines einzelnen Datenpfads verschleiern.

Wenn Sie noch überlegen, wie Sie die Umgebung schützen möchten, vergleicht der Proxmox-Backup-Leitfaden die wichtigsten Ansätze, bevor Sie die Restore-Performance optimieren.

1. Ist der Veeam-Proxmox-Worker CPU-limitiert?

Der Worker ist der erste Ort, an dem ich nachsehen würde, wenn die Netzwerkkapazität hoch, der Restore-Durchsatz aber unerwartet niedrig ist. Veeam zufolge verarbeiten Proxmox-Worker die Backup-Workloads und verteilen den Backup-Traffic zwischen der virtuellen Umgebung und den Repositories.

Die dokumentierte Standardgröße des Workers ist 6 vCPU, 6 GB RAM und 100 GB Festplatte. Ein Standard-Worker kann bis zu 4 gleichzeitige Backup- und Restore-Aufgaben bewältigen.

Das bedeutet nicht, dass alle sechs vCPUs während jedes Restores gleichmäßig ausgelastet sind. Betrachten Sie die Auslastung pro Kern. Eine gesättigte vCPU bei ansonsten weitgehend untätigen Kernen unterscheidet sich von sechs Kernen, die alle mit 80 Prozent laufen.

Wenn die CPU die Obergrenze bildet, sammeln Sie die Job-Logs und Worker-Metriken, bevor Sie undokumentierte Einstellungen ändern. Veeam warnt ausdrücklich davor, Worker-VMs manuell über die Proxmox-Oberfläche zu ändern, und verweist Administratoren darauf, Worker-Einstellungen über Veeam selbst zu bearbeiten.

Die entscheidende Frage ist einfach: Stagniert die Worker-CPU zum selben Zeitpunkt, an dem der Durchsatz stagniert?

2. Erzeugen Limits für gleichzeitige Aufgaben Contention?

Mehr Aufgaben bedeuten nicht automatisch mehr aggregierten Durchsatz. Sie können Storage-Latenz, CPU-Contention und Netzwerk-Queueing verschlimmern.

Veeam dokumentiert einen Standard-Höchstwert von 4 gleichzeitigen Backup- und Restore-Aufgaben pro Worker. Für jede zusätzliche Aufgabe sieht die Dimensionierungsempfehlung 1 weitere vCPU und 1 GB RAM vor.

Führen Sie zwei Tests durch. Stellen Sie zunächst eine VM wieder her. Dann mehrere VMs.

Wenn eine VM mit 800 Mbit/s wiederhergestellt wird und vier VMs zusammen immer noch etwa 800 Mbit/s erreichen, ist wahrscheinlich eine gemeinsam genutzte Ressource gesättigt. Skaliert der aggregierte Durchsatz deutlich, ist möglicherweise der einzelne Aufgabenpfad der limitierende Faktor.

Prüfen Sie auch die Seite des Repositorys. Ein Backup-Repository hat seine eigenen Concurrency- und Ressourcenlimits. Ein perfekt dimensionierter Proxmox-Worker kann Daten nicht schneller lesen, als das Repository sie bereitstellen kann.

3. Ist das Backup-Repository der eigentliche Engpass?

Ein Repository kann langsam sein, selbst wenn seine Datenträger auf dem Papier schnell wirken. Deduplizierung, Kompression, Objektabruf, Cache-Verhalten, Fragmentierung und gleichzeitige Jobs können die Restore-Performance allesamt verändern.

Testen Sie das Repository getrennt von Proxmox, sofern Ihre Backup-Software das unterstützt. Betrachten Sie physischen Lesedurchsatz, Latenz und CPU-Auslastung des Repositorys während des Restore-Fensters.

Das ist wichtig, weil Backup-Lesevorgänge nicht dieselbe Art von Workload sind wie ein sequenzieller Benchmark mit einem synthetischen Tool. Ein Restore muss unter Umständen Daten aus komprimierten oder deduplizierten Backup-Ketten rekonstruieren, bevor überhaupt etwas bei Proxmox ankommt.

Ist das Repository der Flaschenhals, hilft Tuning am Ziel-Hypervisor nicht.

4. Nutzt der Worker den Netzwerkpfad, den Sie erwarten?

Verlassen Sie sich nicht allein auf das Vorhandensein einer schnellen NIC. Bestätigen Sie den tatsächlichen Pfad, den der Restore-Traffic nimmt.

Veeam unterstützt die Anbindung von Proxmox-Workern an mehrere Netzwerke und dokumentiert ausdrücklich die Verwendung eines ausgewählten Netzwerks für die Übertragung zu und von Backup-Repositories. Das ist nützlich, wenn Management-, Backup- und Produktionsnetzwerke getrennt sind.

Prüfen Sie die Interface-Zähler des Workers, während der Job läuft. Prüfen Sie auch die Zähler des Proxmox-Hosts. Verifizieren Sie Routing, VLANs, Link-Aushandlung und ob Traffic eine langsamere Firewall oder ein geroutetes Segment durchquert.

Prüfen Sie außerdem die Netzwerk-Traffic-Regeln von Veeam. Traffic-Drosselung existiert genau dafür, die Bandbreitennutzung von Jobs zu begrenzen. Eine vergessene Regel kann eine an sich schnelle Infrastruktur mysteriös gedeckelt wirken lassen.

Ich würde nicht mit Jumbo Frames beginnen. Weisen Sie zuerst nach, dass beide Endpunkte das erwartete Interface nutzen und keine explizite Drosselung existiert.

5. Ist das Ziel-Storage in Proxmox gesättigt?

Das Ziel-Storage muss die rekonstruierten VM-Disks aufnehmen. Hohe Netzwerkbandbreite ist irrelevant, wenn das Datastore beim aktuellen I/O-Muster nur einen Bruchteil dieser Schreibrate verkraftet.

Beobachten Sie das Ziel, nicht nur den Host.

Bei lokalem ZFS achten Sie auf Pool-Latenz und Geräteverhalten. Bei Ceph prüfen Sie Cluster-Health, OSD-Auslastung, Recovery-Aktivität und Netzwerk-Contention. Bei gemeinsam genutztem NFS oder iSCSI prüfen Sie sowohl die Initiator-Seite in Proxmox als auch das Storage-Array.

Die Ceph-Empfehlungen von Proxmox raten dort, wo Performance zählt, zu schnellem Storage-Networking und geeigneten SSDs oder NVRAM. Die genaue Architektur ist wichtiger als das Etikett „Ceph“.

Wenn Sie unsicher sind, was Ceph innerhalb von Proxmox eigentlich tut, beginnen Sie mit was Proxmox Ceph ist.

Ein nützlicher Diagnosetest besteht darin, dieselbe VM auf ein anderes Storage-Backend wiederherzustellen. Ändert sich die Rate drastisch, haben Sie das Problem eingegrenzt.

6. Stoßen Sie an eine Restore-Format- oder Storage-Einschränkung?

Kompatibilität kann den Restore-Pfad beeinflussen. Das aktuelle Dokument zu Veeams Proxmox-Einschränkungen listet nicht unterstützte Fälle auf, darunter BTRFS und benutzerdefiniertes Ziel-Storage für VM-Restores.

Es dokumentiert außerdem eine wichtige Interaktion bei Proxmox VE 9 rund um Snapshots als Volume-Chains. VMs mit einer älteren QEMU-Version können in dem von Veeam beschriebenen Szenario nicht auf Storage mit aktivierter entsprechender Volume-Chain-Einstellung wiederhergestellt werden.

Behandeln Sie nicht jeden Fehler oder langsamen Pfad als reines Performance-Problem.

Erfassen Sie Quellplattform, Quell-Disk-Format, Ziel-Storage-Typ, Guest-Firmware, QEMU-Generation und ob die VM von VMware oder einem anderen Hypervisor stammt. Ein plattformübergreifender Restore kann Treiber- und Disk-Konvertierungsarbeit erfordern, die ein nativer Restore nicht braucht.

Je ungewöhnlicher die VM, desto wichtiger ist es, sie vor einem echten Ausfall zu testen.

7. Konkurriert der Restore mit Ceph-Recovery-, Backup- oder Migrationstraffic?

Ein Restore läuft oft im ungünstigsten Moment. Ein Node ist ausgefallen, Ceph balanciert gerade neu aus, Anwender warten, und jemand startet drei weitere Recovery-Jobs, weil der erste langsam wirkt.

So wird aus einem beherrschbaren Engpass ein Incident.

Trennen Sie Storage-Recovery-Traffic von VM-Restore-Traffic, soweit Ihr Design das erlaubt. Beobachten Sie Ceph-Health und Backfill-Aktivität. Prüfen Sie, ob Backup-Jobs, Replikation, Scrub-Vorgänge oder Live-Migrationen dieselben Links nutzen.

Ist die Umgebung bereits beeinträchtigt, ist maximaler Benchmark-Durchsatz das falsche Ziel. An erster Stelle steht die stabile Wiederherstellung der wichtigsten Workloads.

Der Mr.PlanB-Storage-Leitfaden kann helfen, wenn der Cluster Backup-, Migrations- und Storage-Traffic routinemäßig durch dasselbe zu enge Design zwingt.

8. Sollten Sie Instant Recovery statt eines vollständigen Restores nutzen?

Manchmal ist die richtige Optimierung, das Wiederherstellungsziel selbst zu ändern. Veeam unterstützt Instant Recovery auf Proxmox VE und erlaubt es einem Workload, direkt aus einem komprimierten und deduplizierten Backup zu laufen, während der Recovery-Prozess weiterläuft.

Das kann die Zeit bis zur Verfügbarkeit eines Dienstes verkürzen, auch wenn es die zugrunde liegende Storage-Übertragung nicht schneller macht.

Es gibt einen Trade-off. Der Betrieb aus dem Backup-Storage ist nicht dasselbe wie der Betrieb aus dem finalen Produktions-Datastore. Die Performance im temporären Zustand hängt vom Backup-Repository und der Recovery-Architektur ab.

Nutzen Sie Instant Recovery, wenn die Recovery-Zeit wichtiger ist als sofortige Steady-State-Performance. Nutzen Sie einen vollständigen Restore, wenn der Workload lange genug offline bleiben kann, um direkt auf seinem finalen Storage zu landen.

Was würde ich zuerst ändern?

Ich würde nichts ändern, bevor ich einen einzelnen Restore mit Worker-CPU, Repository-Lesevorgängen, Netzwerkdurchsatz und Ziel-Schreibvorgängen auf einer gemeinsamen Zeitachse erfasst habe. Die erste Komponente, die sättigt, wenn der Durchsatz abflacht, ist Ihr Hauptverdächtiger.

Ist der Worker der Flaschenhals, untersuchen Sie Worker-Dimensionierung und Softwareverhalten mit Veeam. Ist das Repository der Flaschenhals, beheben Sie das Repository. Ist das Netzwerk gedeckelt, verfolgen Sie den tatsächlichen Pfad und die Traffic-Regeln. Springt die Storage-Latenz, arbeiten Sie am Ziel-Datastore.

Erst nach dieser Baseline würde ich mit MTU, Parallelität und tieferem Tuning experimentieren.

Ein Restore-Test ist erfolgreich, wenn er das Wiederherstellungsziel belegt, nicht wenn er die größte Zahl auf einem Dashboard erzeugt. Braucht das Unternehmen eine VM in 15 Minuten zurück, entwerfen und testen Sie genau für dieses Ergebnis. Ein 25-GbE-Port ist nur eine Komponente im Pfad.