Performance-Tuning bei langsamen PBS-Backups

Manchmal dauern Backups länger, als Du erwartest. Erstes Inkrementelle nach Voll-Backup hat 3 Stunden gebraucht? Restore einer 50-GB-VM zog sich auf 4 Stunden? Hier die typischen Engstellen und was Du dagegen tust.

Engstelle 1 — Internet-Anbindung Deines PVE

Häufigster Faktor. Symptome:

• Backup hängt mit INFO: read X% (...) ... lange auf einem Wert
• Restore quält sich

Selbsttest: Miss den Upload Deines Anschlusses — der begrenzt die Backup-Geschwindigkeit, nicht der Download. Auf dem PVE-Host geht das z.B. mit speedtest-cli (Paket gleichen Namens), alternativ per Browser-Speedtest von einem Rechner im selben Netz.

Zur Einordnung: Bei 50 Mbit/s Upload gehen ~6 MB/s durch die Leitung — ein 100-GB-Voll-Backup braucht damit rund 4,5 bis 5 Stunden. In der Praxis eher länger, weil TCP-Overhead, Verschlüsselungs-Overhead etc.

Was hilft:

• Anbindung upgraden (Glasfaser, Business-DSL).
• Backup-Zeitfenster verlängern (nachts laufen lassen).
• Bandwidth Limit aktivieren, damit Backup tagsüber nicht andere Dienste killt.
• Nur die wichtigen VMs sichern (statt allem).

Engstelle 2 — Compression-CPU am PVE

PBS komprimiert Daten beim Senden (zstd standardmäßig). Wenn Dein PVE schwach ist (Atom-CPU, älterer Xeon), kann CPU der Flaschenhals sein.

Test: während des Backups in einer SSH-Session htop öffnen, schauen ob proxmox-backup-client die CPU auf 100% drückt.

Was hilft:

• Compression auf lzo (schneller, weniger Kompression) oder gzip mit niedrigem Level.
• CPU-Quota für andere VMs während Backup runterfahren.
• Mehrere Backups parallel laufen lassen (CPU pro Backup wird kleiner, aber Gesamt-Durchsatz steigt — bis I/O zum Engpass wird).

In der GUI: Datacenter → Backup → Job → Edit → Compression.

Engstelle 3 — Lokale Disk-Performance am PVE

PBS muss die Daten vom PVE-Storage lesen, hashen, komprimieren, schicken. Wenn Dein lokaler Storage langsam ist (alte HDD, überlastetes RAID), sind selbst 10 GBit unbrauchbar.

Test: iostat -x 5 während des Backups — %util der Backup-Source-Disk schauen.

Was hilft:

• Disk-Defragmentierung (auch bei VMs, je nach Filesystem).
• Storage-Migration auf NVMe/SSD.
• VMs auf weniger Storage verteilen (manchmal hängt Backup, weil eine andere VM gerade hart schreibt).

Engstelle 4 — Verify oder GC laufen parallel

Wenn auf unserem PBS gerade ein großer Verify-Job oder eine Garbage Collection läuft, ist die Disk-I/O des Datastores belastet — Backups schreiben langsamer.

Bei uns laufen Verify und GC nachts zwischen 3 und 6 Uhr. Wenn Deine Backups zu dieser Zeit langsam sind, könnte das die Ursache sein.

Was hilft:

• Backup-Schedule auf 22:00 oder 02:00 legen, vor unserem Verify-Fenster.
• Bei wiederholten Performance-Problemen: schreib uns ein Ticket mit Task-IDs, wir schauen unsere Datastore-Last an.

Engstelle 5 — Inkrementeller Modus klappt nicht

Wenn ein Backup, das eigentlich inkrementell sein sollte, plötzlich wieder voll überträgt, ist das ein Hinweis auf:

• Lokales VM-Disk-Image wurde neu erstellt (etwa nach Disk-Migration)
• Snapshot-Index wurde verworfen
• VM-Snapshots wurden gelöscht/eingerichtet, was den Dirty-Bitmap-State kaputt macht

Test: im Backup-Log nach using fast-incremental suchen. Wenn das fehlt, ist’s ein Voll-Backup.

Was hilft:

• VM-Snapshots vor dem Backup nicht manuell anfassen.
• Bei Migration auf neuen Storage: einmal Voll-Backup hinnehmen, danach läuft inkrementell wieder.

Engstelle 6 — TLS-Overhead bei vielen kleinen Files

Bei VMs mit Millionen kleiner Dateien und entsprechend vielen kleinen Chunks kann TLS-Handshake Overhead spürbar werden.

Was hilft:

• Auf eine kleinere Anzahl gut gepackter Disk-Images bauen (statt 100 kleinen).
• Mit proxmox-backup-client benchmark die theoretische Performance messen — wenn die deutlich unter Deinem Backup-Durchsatz liegt, hängt’s nicht am Netzwerk.

Restore-Performance speziell

Restore ist oft langsamer als Backup, weil:

• PBS muss Chunks aus dem deduplizierten Pool zusammensuchen — wenn eine VM viele “fremde” Chunks teilt, ist das Random-I/O.
• Dein PVE-Storage muss Daten schreiben (oft langsamer als lesen).

Was hilft:

• Live Restore aktivieren bei großen VMs — die VM startet sofort, Datentransfer läuft im Hintergrund.
• Restore in unbelastete Zeiten verschieben.
• Bei wirklich kritischen Restores: schreib uns ein Ticket, wir können auf der PBS-Seite Caches vorwärmen.

PBS-Server-seitige Performance

Wir betreiben PBS auf Hardware, die für Backup-Workloads ausgelegt ist:

• Supermicro-Server mit großen SAS-HDDs hinter Hardware-RAID-Controllern als RAID 10
• RAID 10 liefert hohe I/O-Werte bei Backup und Restore und verkraftet einzelne Platten-Ausfälle
• Mindestens 64 GB RAM, oft mehr
• 10 GBit Anbindung pro Datastore-Server

Wenn Du den Eindruck hast, dass die Performance nicht stimmt — schreib uns ein Ticket mit:

• Task-ID des langsamen Backups
• Erwartete vs. gemessene Übertragungsrate
• Zeit, in der das Problem auftrat

Wir schauen Server-seitig nach Last, Disk-Healthstats und Storage-Latenzen.

Häufige Fragen

Mein erstes Backup ist sehr langsam, alle weiteren sind schnell — normal? Ja. Erstes Backup ist voll, alle weiteren inkrementell. Das ist by design.

Wie viel TB pro Stunde sollte realistisch durchgehen? Auf 1 GBit symmetrisch: ~400 GB/h netto. Auf 100 MBit: ~40 GB/h. Auf 50 MBit Heim-DSL: ~20 GB/h.

Mein Backup zeigt 80 % gebraucht aber dauert noch ewig — warum? Manchmal sind die letzten % “Verifikation am Ende” (PBS prüft den Index) — kann ein paar Minuten dauern, ohne dass der Prozentsatz weitergeht. Logs prüfen.

Macht es einen Unterschied, ob ich einen oder mehrere Backup-Jobs habe? Performance-mäßig fast nicht. Wichtig ist die Reihenfolge — wenn alles auf 02:00 schedule, läuft alles parallel. Bei 5 VMs gleichzeitig wird’s eng.

Wieso ist die GC manchmal langsam? GC liest alle Chunks (auch nicht-referenzierte). Bei einem 5-TB-Datastore = sehr viele Chunks, sehr viel Random-I/O. RAID 10 verteilt die Last auf mehrere Platten, trotzdem dauert das bei großen Datastores. Bei wiederholtem Performance-Problem: Ticket öffnen.

Was, wenn meine VM zu groß ist für ein einzelnes Backup-Window? Backup-Job läuft auch über das Window hinaus zu Ende, blockiert nur den nächsten Job-Start. Wenn das chronisch ist: VM verkleinern, oder zwei VMs draus machen, oder die VM auf Sub-Disks aufteilen.

Weiter geht’s

• Backup-Job in PVE konfigurieren
• Speicherverbrauch verstehen
• Garbage Collection