Offline USB Backup mit PBS – Removable Datastore zu langsam, welche Alternativen nutzt ihr?

jsterr

jsterr

Famous Member
Jul 24, 2020
908
273
108
34
Hintergrund / Use-Case:

Ein Kunde von mir möchte migrieren: von VMware + Veeam auf Proxmox VE + PBS und sucht nach einer sinnvollen Lösung für das Offline-Backup. Täglich soll via Copy-Job auf USB 9TB an Fullbacks transferiert werden, sodass auf dem USB-Datenträger ein vollwertiger Full-Zustand aller 40 VMs vorliegt. Der bisherige Veeam-Workflow war:

  • 19:00 Uhr: Regulärer Backup-Job (inkrementell, läuft bis ca. 02:00 Uhr)
  • 07:00 Uhr: USB-Festplatte einstecken → Veeam kopiert fertige Backup-Dateien auf USB
  • Laufzeit: 07:00 bis 06:00 nächster Tag (22 Stunden)
  • Gesamtdatenmenge: ~9 TB, 40 VMs
  • PBS-Storage: 4x HDD im RAID10 (2x RAID1 vdevs)

Der entscheidende Vorteil unter Veeam war, dass der USB-Sync nur fertige Repository-Dateien kopiert hat – kein erneuter VM-Zugriff, keine Locks, vollständig parallel zum nächsten Backup-Job.


Problem mit PBS Removable Datastore:

Die gemessene Schreibgeschwindigkeit beim PBS Sync Job auf USB-HDD liegt bei ~4 MB/s (1 GB / 4 Minuten). Für 9 TB wären das rechnerisch ~26 Tage – vollkommen unpraktikabel.

Die Ursache ist klar: PBS schreibt ~4 MB Chunk-Dateien auf die USB-HDD. USB-HDDs sind für sequenziellen Schrieb ausgelegt (~120–150 MB/s), nicht für tausende von Einzel-Writes mit open/write/close pro Chunk.

Die verfügbaren Sync-Job-Optionen (--group-filter, --transfer-last 1, run-on-mount) adressieren das Problem nicht, da sie das Chunk-Format nicht verändern.


Warum VZDUMP keine Option ist:

VZDUMP würde zwar große sequenzielle VMA-Dateien schreiben (USB-freundlich), setzt aber pro VM einen Lock. Da der USB-VZDUMP-Job von 07:00 bis 06:00 des nächsten Tages laufen würde, blockiert er den regulären PBS-Backup-Job um 19:00 Uhr für alle VMs, die noch nicht fertig sind. Unter Veeam war dieses Problem nicht vorhanden, weil Veeam beim USB-Sync nie nochmal auf die VMs zugegriffen hat.


Mögliche Ideen - bisherige Evaluation:

  1. PBS Removable Datastore (Sync Job): Zu langsam durch Chunk-IOPS-Problem
  2. VZDUMP auf USB: VM-Lock-Konflikt mit PBS-Job um 19:00 Uhr
  3. Zweiter PBS Offsite: Sauberste Lösung aber kein Medienbruch und kein komplettes Offline-Backup (auch wenn Pull-Jobs natürlich super sind)


Meine Fragen an die Community:
  • Wie löst ihr Offline-Backups bei größeren Datenmengen (5–10 TB+) mit PBS?
  • Gibt es Tricks oder Konfigurationen beim PBS Sync auf USB, die ich übersehen haben?
  • Ist ein zweiter PBS Offsite bei euch die Standardlösung für den "Offline-Copy"-Anwendungsfall, der früher durch Veeam Backup Copy Jobs abgedeckt wurde?

Über Erfahrungsberichte und Einschätzungen würde ich mich sehr freuen – insbesondere ob es einen Ansatz gibt, der den Veeam-Workflow (fertige Daten kopieren, kein VM-Zugriff, 22 Stunden Laufzeit, paralleler Betrieb) annähernd nachbildet. Eventuell bedeutet das für meinen Kunden, dass er letztendlich auf diesen Ansatz mit: ich stecke jeden Tag eine USB-Platte an und hab dort ein Full darauf, verzichten muss.

Edit: Abgelehnte Vorschläge seitens des Kundens:
  • Flash als Offline-Medium (zu hohe Kosten)
  • Tape (zu hohe Kosten, nicht vorhanden)
 
Last edited:
Hey, wie kommst du auf die 4MB/s bei der usb Platte? Ich kann das hier nicht nachvollziehen. Da ist der synjob zu einer usb Platte ( 3.1) wesentlich schneller.
Gerade geschaut, letzter sync sind es 80gb gewesen in durchschnittlich 70MB/s laut log gewesen.
 
Last edited:
  • Like
Reactions: Johannes S and jsterr
Hey,
muss denn bei jedem Offline-Backup immer alle 9TB verschoben werden?
Es sind doch nicht immer 9TB Unterschied zwischen den Backups. Oder wird hier jedes mal eine frische Platte benutzt?
Sonst wird ja immer nur der Delta auf die Platte verschoben. Jedes Backup von PBS ist im Endeffekt ein vollwertiges Backup, nur eben dedupliziert, daher sehe ich den Sinn nicht, jeden Tag alles komplett zu kopieren.
Ich würde nur den Delta mittels eines Syncs kopieren lassen und anschließend einen Verify, um die Konsistenz der Backups sicher zu stellen => Hier müsste man ggf. auch auf die Dauer des Verifies achten.
 
Die Erstbefüllung würde mit 4 MB / s einfach zu lange dauern, daran hatte ich aber auch schon gedacht.

Bezüglich Punkt 3) Offline Backup heißt für mich, kein Server mit den PBS-Pulls drauf sondern Backup ist komplett auf eigenem Medium und kann z.B. in Tresor gelegt werden (Beispielshaft).

Bezüglich der Geschwindigkeit fährt der Kunde erneut einen Test und gibt mir nächste Woche Bescheid.
 
Das ist ein ziemlicher edge case, der sich mit PBS nicht umsetzten lässt.
PBS kann keine traditionell inkrementellen Backups.
Wenn du es also 1:1 wie bei Veeam umsetzten möchtest, wirst vermutlich scheitern.
Wenn du offen bist das System zu überdenken, ist lösbar.
jsterr said:
  1. Zweiter PBS Offsite: Sauberste Lösung aber kein Medienbruch und kein komplettes Offline-Backup (auch wenn Pull-Jobs natürlich super sind)
Click to expand...
Das ist die sauberste Lösung.

Was ist ein Medienbruch?
Was ist gemeint mit Offline-Backup?
Und wie kommst du auf Pull Jobs?

Sauber wäre ein externer PBS. Der ist dann gleich auch noch offsite und somit gegen Brand geschützt.
Mit "offline" ist vermutlich ransomware sicher gemeint. Das lässt sich mittels "PVE hat nur die Berechtigung Backups zu schreiben, nicht löschen" gut umsetzten.

Performance Ansprüche müsste man klären. 9TB ist viel für nur 40VMs (vermutlich files in VMs statt in shares).
Mit Snapshots und ZFS send wäre das deutlich eleganter und schneller lösbar. Das wäre dann auch tatsächlich inkrementell.

Aber je nach Ansprüchen bräuchte es andere Hardware.
Wenn das Ziel wieder 7h wären, sind das 13GBit/s und nicht zu schaffen. Dafür ist bereits der PBS host mit 4 HDDs viel zu langsam, CPU vermutlich auch. IMHO ein gutes Beispiel warum files nicht in VMs gehören.

VMs verschlanken auf eine anständige Grösse, Backup der VMs mit PBS, Backup der Daten mit ZFS send oder was auch immer.
 
  • Like
Reactions: Johannes S and jsterr
Was man versuchen könnte: Die HDDs aus dem USB-Gehäuse aus- und in den PBS einbauen, damit das initiale Backup nicht über den USB-Flaschenhals geht, danach ausbauen und wieder ins USB-Gehäuse packen. Generell werden aber HDDs und PBS zusammen nicht geil performen, das RAID10-Setup holt ja schon aus den gegebenen System das Beste heraus (wobei zusätzliche SSDs als special device sinnvoll wären, wird aber wenig bis nichts für das initiale Backup bringen). Nur: Falls der Usecase des Kunden sein sollte, dass er gerne jeden Tag ein neues Device anhängen möchte (damit man quasi immer ein air-gapped Backup von eine nTag hat), dann wird das natürlich nicht weiterhelfen.

Eine wilde Idee von mir: Vielleicht ist die Übertragungsgeschwindigkeit besser, wenn man die USB-Festplatte über eine virtual tape libary einbindet? Andererseits ist das dann noch ein Layer mehr und Layerschichtungen sind nie gut für die Performance: https://pbs.proxmox.com/wiki/Installing_a_Virtual_Tape_Library

Ich teile die Einschätzung von @IsThisThingOn, dass es sinnvoll wäre den Datenbestand aufzusplitten, sodass VMs-System/Anwendungsstorage und Nutzdaten getrennt gesichert werden. Das hätte auch den Vorteil, dass man zusätzlich zum USB-Storage auch noch Cloud-Storage einsetzen könnte, ohne auf PBS S3-Support angewiesen zu sein (je nachdem welches Backuptool man dann für das Backup der Nutzdaten nimmt).
 
You must log in or register to reply here.
Top Bottom
Back