Backup von großen VMs - splitten von Backup files

[jj-uses-prx]

Guten Morgen,

wir haben in unserem deployment teilweise sehr große VM Disks (+20 TB, raw disks auf iSCSI eingebundenem flash array). Wenn wir Backups von diesen VMs machen wollen, bekommen wir das Problem, dass unser Archive storage maximal Dateien bis 7 TB akzeptiert (könnte geändert werden, hätte aber einen erheblichen performance impact).

Deshalb wäre meine Frage, ist es möglich ZSTD backup files zu segmentieren und die einzelnen chunks < 5TB zu halten?

Ich habe leider bei meiner online Recherche nichts dazu gefunden, falls ich etwas in der Dokumentation überlesen habe bitte einfache einen Wink in die richtige Richtung.

 

[jj-uses-prx]

Danke sehr für die Antwort, unser Proxmox Backup Server Infra ist noch im Aufbau/Beschaffung, falls es keine Möglichkeit gibt, die Backup Files zu splitten werden wir uns für die Übergangszeit eine andere Lösung überlegen müssen.

 

[jj-uses-prx]

Zahlt es sich aus in diesem Fall die VZdump util zu forken und die PVE::VZDump::exec_backup_task Methode anzupassen und ein split command einzufügen bevor die Backup Datei vom tmptar auf target verschoben wird und dann eine äquivalente Änderungen mit cat in qmrestore durchzuführen?

 

[Falk R.]

Ich finde es wieder einmal Super, dass jemand hilft und dann seine Posts löscht. So ist schwer nachzuvollziehen was er geschrieben hat.
Was für ein Archiv Storage hat denn so komische Anforderungen von Max. 7TB?

 

[jj-uses-prx]

Ich finde es wieder einmal Super, dass jemand hilft und dann seine Posts löscht. So ist schwer nachzuvollziehen was er geschrieben hat.
Was für ein Archiv Storage hat denn so komische Anforderungen von Max. 7TB?

Der Storage supported grundsätzlich bis zu 16 TiB aber so weit ich weiß ist aus cach tuning/tiering Gründen (Anforderungen von anderen Applikationen die den storage Cluster nutzen) die maximale file size reduziert. Genauere Infos habe ich dazu leider nicht, wird nicht von mir verwaltet. Allerdings wäre auch die max file size von 16 TiB zu klein für unsere Anforderungen.

Wenn es nicht gegen Forum Regeln verstößt kann ich ursprüngliche Antwort als Quote Posten, hätte sie noch in meinen E-Mail Benachrichtigungen. Ich weiß nicht genau wie hier der Umgang mit von anderen Usern gelöschten Nachrichten ist, hätte nichts dazu in den Regeln gefunden.

 

[Falk R.]

Der Storage supported grundsätzlich bis zu 16 TiB aber so weit ich weiß ist aus cach tuning/tiering Gründen (Anforderungen von anderen Applikationen die den storage Cluster nutzen) die maximale file size reduziert. Genauere Infos habe ich dazu leider nicht, wird nicht von mir verwaltet. Allerdings wäre auch die max file size von 16 TiB zu klein für unsere Anforderungen.

Wenn es nicht gegen Forum Regeln verstößt kann ich ursprüngliche Antwort als Quote Posten, hätte sie noch in meinen E-Mail Benachrichtigungen. Ich weiß nicht genau wie hier der Umgang mit von anderen Usern gelöschten Nachrichten ist, hätte nichts dazu in den Regeln gefunden.

Oft löschen die User selbst ihre Nachrichten.
Ich würde bei so großen VMs sofort auf den PBS wechseln, da du dann inkrementelle Backups machen kannst.
Falls du Infos rausgeben darfst, was für Systeme ihr einsetzt, kann ich ja eine Empfehlung geben wie du das am elegantesten umsetzen könntest.

 

[jj-uses-prx]

Oft löschen die User selbst ihre Nachrichten.
Ich würde bei so großen VMs sofort auf den PBS wechseln, da du dann inkrementelle Backups machen kannst.
Falls du Infos rausgeben darfst, was für Systeme ihr einsetzt, kann ich ja eine Empfehlung geben wie du das am elegantesten umsetzen könntest.

huh, eigenartig ¯\_(ツ)_/¯
Es ist geplant, auf PBS umzustellen, leider dauern nur unsere Beschaffungen gerne mal länger (6-12 Monate) und wir suche für diese Zeit eine Zwischenlösung.
Danke sehr für das Angebot, aber ich fürchte das darf ich leider nicht.

 

[Falk R.]

OK, dann ein paar pauschale Tipps.
Wenn du keinen freien Server hast, einfach eine PBS VM installieren, diese dann per VZDump sichern und damit ist ein DR auch kein Problem.
Du kannst externe Storages an die VM hängen, aber das Storage sollte schon mit Random I/O klar kommen. Wenn du keine physikalischen Diks hast, kein ZFS nutzen, besser XFS.

 

[jj-uses-prx]

Danke für die Tipps

Ich hab mir trotzdem mal einen Prototyp gebastelt und die vzdump util angepasst. Weil die incremental backups bringen mir ja nur bei noch wachsenden Maschinen etwas oder? Die bestehenden großen VM Disks werden wahrscheinlich beim ersten mal auch in ziemlich großen Files enden?

Falls sonst nochmal jemand dieses Problem haben sollte, ich hab ein github repo (gitlab repo Github repo mit neuem Account ist nicht sichtbar) mit dem abgeänderten vzdump gemacht. Werde auch noch ein qmrestore dementsprechend anpassen das es die gesplitteten images wieder automatisch zusammenführt.

Der output schaut daweil mal so aus nach dem vzdump2 100 ausführt:



War ein Test mit 100KB/Segment, der code im Github ist schon auf 1TB/Segment umgestellt. Die schönere Lösung wäre eine zusätzliche option --chunksize aber ob ich das umsetzte weiß ich noch nicht.

 

[UdoB]

Die bestehenden großen VM Disks werden wahrscheinlich beim ersten mal auch in ziemlich großen Files enden?

Nein, keinesfalls.

PBS zerlegt jedes Backup in kleine 4 MiB-Chunks. Und weil eine einzelne 20 TB VM somit in ~5 Millionen einzelne Dateien aufgeteilt wird, braucht ein PBS einen Storage, der vergleichsweise hohe IOPS verarbeiten kann.

Konstrukte wie ein klassisches Raid6 auf Blech ist nach meiner (geringen) Erfahrung schlicht nicht verwendbar, jedenfalls nicht für diese Größen.

 

[Falk R.]

Nein, keinesfalls.

PBS zerlegt jedes Backup in kleine 4 MiB-Chunks. Und weil eine einzelne 20 TB VM somit in ~5 Millionen einzelne Dateien aufgeteilt wird, braucht ein PBS einen Storage, der vergleichsweise hohe IOPS verarbeiten kann.

Konstrukte wie ein klassisches Raid6 auf Blech ist nach meiner (geringen) Erfahrung schlicht nicht verwendbar, jedenfalls nicht für diese Größen.

Kann man nicht so pauschal sagen.
Ein guter Raid Controller mit vernünftigen Batteriecache und guten Einstellungen und dann SAS statt SATA Interface an den Disks geht auch sehr gut. Der Controllercache fasst Random in besser verarbeitbare Chunks zusammen und SAS hat einen großen NCQ (Native Command Queue) womit auch mit weniger mechanischen Bewegungen gearbeitet werden kann.
Das mit den 16TB klingt eher nach einem SAN Speicher oder einem Filer wie NetApp, da kommt in der Regel auch mehr Performance raus.

Danke für die Tipps

Wie Udo schon geschrieben hat, wird alles in 4 MB Chunks geteilt, womit die VDisk Größe vollkommen egal ist. Es werden nach dem ersten Backup immer nur noch Änderungen übertragen, außer das sind Duplikate von Daten welche es im Backup schon gibt, dann werden die auch nicht übertragen sondern nur verlinkt. Der PBS macht immer Deduplikation.
Falls euer bisheriger Backupspeicher auch deduplikation nutzt, solltet ihr das beim Speicher für den PBS abstellen.

 

[UdoB]

Ein guter Raid Controller mit vernünftigen Batteriecache und guten Einstellungen und dann SAS statt SATA Interface an den Disks geht auch sehr gut.

Du hast natürlich Recht. Ich habe seit einigen Jahren echte Raid Controller gar nicht mehr auf dem Schirm - trotz 20 Jahre Dell/PERC.... betriebsblind.

 

[jj-uses-prx]

Danke für die Infos, das die Images in 4MB Chunks aufgeteilt werden ist eine wichtige Info, die mir gefehlt hat.

Ich werde testweiße mal eine PBS als VM aufsetzten und testen, gibt es etwas, was ich da spezifisch beachten muss, was nicht in der Doku angeführt ist?

Falls euer bisheriger Backupspeicher auch deduplikation nutzt, solltet ihr das beim Speicher für den PBS abstellen.

Danke für den Tipp, werde ich so weitergeben.

Bezüglich gibt es bezüglich sizing der VM irgendwas BPS spezifisches, dass ich berücksichtigen muss?
Sizing zum testen hätte ich mal so gemacht:
CPU: 12 Cores
RAM: 64GB
VM Disk: 256GB (profitiert der PBS von einer größeren lokalen Disk?)
NW: VirtIO; Jumbo Frames; ulimited

 

[Falk R.]

Danke für die Infos, das die Images in 4MB Chunks aufgeteilt werden ist eine wichtige Info, die mir gefehlt hat.

Ich werde testweiße mal eine PBS als VM aufsetzten und testen, gibt es etwas, was ich da spezifisch beachten muss, was nicht in der Doku angeführt ist?

Danke für den Tipp, werde ich so weitergeben.

Bezüglich gibt es bezüglich sizing der VM irgendwas BPS spezifisches, dass ich berücksichtigen muss?
Sizing zum testen hätte ich mal so gemacht:
CPU: 12 Cores
RAM: 64GB
VM Disk: 256GB (profitiert der PBS von einer größeren lokalen Disk?)
NW: VirtIO; Jumbo Frames; ulimited

Der PBS wird vermutlich so viele Cores nie auslasten können. RAM geht immer.
Als VM Disk reicht auch was kleineres, der verbraucht in der Regel nie mehr als 10GB. Ich installiere in Der Regel mit 50GB Disks.

Eigentlich steht alles in der Doku und dir Empfehlung immer SSDs zu benutzen liegt an den vielen kleinen Chunks. Das sollte dein Kollege vom Storage ja richtig interpretieren und optimieren, wenn möglich.

 

[jj-uses-prx]

Perfekt, danke sehr. Ich werde nochmal ein kurzes Update posten wenn der Testserver läuft und dann den Thread auf [SOLVED] stellen