[Verbesserungsvorschlag] Reihenfolge VM´s beim Verify

[Lun4r]

English below

Verbesserungsvorschlag:

• Möglichkeit im Verifyjob die Reihenfolge der VM´s anzupassen
  • dazu müsste live der Ordner ausgelesen werden unter Berücksichtigung der Einstellung für den Verifyjob (Ordner, Tiefe etc.pp) und alle gefundenen VM\xxx gelistet und die Reihenfolge hoch und runter schiebbar werden
• Option alle neuen Snapshots nach Start des Verifyjobs von diesem Verifylauf auszuschließen

Szenario (vereinfacht unter der Woche zur Veranschaulichung):

letzte Backups 20 Uhr
dann Prune (auch der stündlichen Backups vom Tag -> es wird nur das letzte behalten)
dann GC
dann Verify ohne Re-verify (läuft bis 16:00)
stündliche Backups ab 6:00

Aktuell wird die Reihenfolge der Verifizierung nach der VM Nummer (VM\201, VM\205, VM\310....) automatisch und numerisch generiert.
Hier wäre es wünschenswert die großen VM´s (mehrere TB) zuerst verifizieren lassen zu können (unabhängig ihrer VM Nummer) damit die neuen Snapshots ab 6:00 nicht dort mit verifiziert werden und den Verify in die Länge ziehen. Die werden eh am Abend wieder gelöscht.
Bei den kleineren VM´s fällt das zeitlich nicht ins Gewicht -> deswegen die Sortierung.

Ich weiß das ist immensen Feintuning aber trotzdem Danke schonmal fürs überlegen ob es möglich wäre.

Liebe Grüße

.........................................................................................................................................................................................................................................................................

Suggestion for improvement:

• Possibility to adjust the order of the VMs in the verify job
  • To do this, the folder would have to be read out live taking into account the setting for the verify job (folder, depth etc.pp) and all VM\xxx found would be listed and the order could be moved up and down
• Option to exclude all new snapshots from this verify run after starting the verify job

Scenario (simplified during the week for illustration):

last backups 8 pm
then Prune (also the hourly backups of the day -> only the last one is kept)
then GC
then Verify without Re-verify (runs until 16:00)
hourly backups from 6 am

Currently, the order of verification is generated automatically and numerically according to the VM number
(VM\201, VM\205, VM\310....).
Here it would be desirable to be able to verify the large VMs (several TB) first (regardless of their VM number) so that the new snapshots from 6am are not verified there as well and drag out the verify process. They are deleted in the evening anyway.
For the smaller VMs, this is not important in terms of time -> hence the sorting.

I know this is immense fine-tuning, but thanks for considering whether it would be possible.

Kind regards

Translated with DeepL.com (free version)

 

[Falk R.]

Dein Gedankengang ist löblich aber leider hast du dich vorher nicht mit der Technik auseinander gesetzt.

Da alles dedupliziert gespeichert wird, ist eh alles Random und der Verify dauert halt immer so lange bis alles gelesen ist.
Falls du eine harte Trennung machen möchtest, wann das Verfy für bestimmte VMs startet, dann lege die Backups dieser VMs einfach in entsprechende Namespaces und lass den Verify dann passend laufen, für den jeweiligen Namespace.

Generell, klingt das aber eher nach einen falschen Diskdesign des PBS. Hast du mal einen Restoretest gemacht? Wenn das Verify schon zu langsam ist, solltest du schauen ob du überhaupt schnell genug restoren kannst.

 

[Lun4r]

Hi danke für deine Antwort,
erstmal vorweg -> das hier dient nur zum Brainstormen und evtl. zum Verbessern des Programms. Durch die Optimierung des GC in 3.4 habe wir 4h Zeit gewonnen täglich (Riesen Probs an euch!) und es ist alles entspannt in der Jobkette. Also mir geht es nicht um "Das muss jetzt da rein.". Was auch ziemlich vermessen wäre ohne eine Subscription (ich arbeite daran).
Wenn ich technisch irgendwo daneben liege in folgendem korrigier mich gern.

Zum Thema:
Das mit der Trennung nach Namespaces habe ich schon im groben gemacht, aber noch nicht nach der größe der VM´s (nur täglich/stündlich um die verifys zu trennen).
Dies scheint mir auch unnötig kompliziert das noch auf die Größe der VMs umzubauen und eher ein Workaround (der funktionieren wird aber dann wieder die verifys zueinander getimet werden müssen) als eine Lösung. Wenn man hier eine Verkettung ala "Wenn Verify 1 durch ist Starte Verify 2" bauen könnte sähe das anders aus wäre aber durch die Ordnerstruktur immernoch kompliziert.

Bei dem Diskdesign hast du richtig getippt -> Es ist kein ZFS Raid mit SSD´s, RAM Cache und SSD Cache sondern ein Standard Raid 6 aus 18TB HDDs -> das lässt sich aktuell leider nicht ändern. 32 Threads und 64GB RAM langweilen sich zu Tode.
Tests bei unserer Datenmenge auf einem Test PBS haben aber auch "nur 15-30%" mehr Geschwindigkeit gebracht mit SSD und RAM Cache und HDDs drunter.

Mir geht es nicht darum den verify physisch zu beschleunigen (da wüsste ich die Umsetzung und auch wieviel der Umbau kostet) sondern bestimmen zu können wann welche VM verifiziert wird bzw. er einfach nur die Snapshots verifiziert die zum start des Jobs da sind.
Zudem kann man in der Rechnung einfach davon ausgehen das wir pro VM 1TB in Zukunft mehr haben -> dann stehen wir an dem gleichen Problem trotz Umrüstung. Ein umrüsten auf komplett SSD´s bei einer deduplizierten Backupgröße von aktuell 37TB kommt aus wirtschaftlicher Sicht nicht in Frage.
Prune ist richtig eingestellt, GC ebenso, Tapeout ist auch vorhanden -> da lässt sich nichts einkürzen.

Ich habe mich deswegen/in der (Hardware-)Not ziemlich tiefgehend mit der Funktionsweise des PBS auserinander gesetzt und kann deiner Aussage "der Verify dauert halt immer so lange bis alles gelesen ist." auf diesen Fall bezogen nicht im Detail zustimmen. Im Groben hast du natürlcih Recht.
Initiales einlesen der VM -> ja -> das ist auch technisch notwendig und okay.
Alle darauffolgenden zu verifizierenden Snapshots der VM -> Jein

Nun zum technischen Ablauf, was man in folgendem Log auch sieht:

• Er liest die VM anhand des letzten aktuellen Snapshots ein -> das dauert was okay ist.
• Alle Snapshots gleicht er gegen diese Verion ab
• Alle vorherigen stündlichen dauern entsprechend nur sehr kurz (weil der Dateiunterschied gering ist ?!). (Hierfür spricht das er beim Re-Verify auch länger braucht je weiter der Zeitliche Abstand zum initial eingelesenen Snapshot liegt.)
• Aber der den wir eigentlich behalten wollen, vom Vortag, kommt zuletzt und hat den längsten Datenabstand zum initialen einlesen -> die 3. VDisc braucht dann nochmal ca. 17min.

In folgendem Beispiel würde man grob 20min sparen wenn er nur das Initiale einlesen würde und statt dem Aktuellsten, dafür das Letzte von 20:00 vom Vortag nimmt (2025-06-17T12:16:24+02:00: verify backup:vm/209/2025-06-16T18:01:04Z -> 20:01). Dies ist der letzte\aktuellste Snapshot, welcher da ist, wenn er um 21:00 den verify startet.

Der Verify würde ausgehen von dem Log:
439s + 2093s + 6141s dauern -> 2h24min
statt
522s + 2110s + 7323s dauern -> 2h45min
dauern

Der Gewinn erscheint gering aber summiert sich über mehrere VM´s.

Logdaten:
Die VM hat ca. 2,5 TB und kommt in der Reihenfolge sehr spät (deswegen auch die neuen stündlichen mit im verify) -> wir haben mehrere VMs der Größe.

Ersteinlesen der VM:
Snapshot fliegt am Abend weg
2025-06-17T09:48:44+02:00: percentage done: 50.00% (6/12 groups)
2025-06-17T09:48:44+02:00: verify group backup:vm/209 (42 snapshots)
2025-06-17T09:48:44+02:00: verify backup:vm/209/2025-06-17T07:03:23Z
2025-06-17T09:48:44+02:00: check qemu-server.conf.blob
2025-06-17T09:48:44+02:00: check drive-virtio2.img.fidx
2025-06-17T09:56:04+02:00: verified 54367.20/122188.00 MiB in 439.91 seconds, speed 123.59/277.76 MiB/s (0 errors)
2025-06-17T09:56:04+02:00: check drive-virtio1.img.fidx
2025-06-17T10:30:57+02:00: verified 131625.12/905636.00 MiB in 2093.67 seconds, speed 62.87/432.56 MiB/s (0 errors)
2025-06-17T10:30:57+02:00: check drive-virtio0.img.fidx
2025-06-17T12:13:19+02:00: verified 994704.26/1585648.00 MiB in 6141.90 seconds, speed 161.95/258.17 MiB/s (0 errors)

Snapshot fliegt am Abend weg
2025-06-17T12:13:19+02:00: percentage done: 50.20% (6/12 groups, 1/42 snapshots in group #7)
2025-06-17T12:13:19+02:00: verify backup:vm/209/2025-06-17T06:02:20Z
2025-06-17T12:13:19+02:00: check qemu-server.conf.blob
2025-06-17T12:13:19+02:00: check drive-virtio2.img.fidx
2025-06-17T12:13:28+02:00: verified 879.14/2500.00 MiB in 8.75 seconds, speed 100.42/285.56 MiB/s (0 errors)
2025-06-17T12:13:28+02:00: check drive-virtio1.img.fidx
2025-06-17T12:13:33+02:00: verified 225.54/1420.00 MiB in 4.77 seconds, speed 47.25/297.52 MiB/s (0 errors)
2025-06-17T12:13:33+02:00: check drive-virtio0.img.fidx
2025-06-17T12:14:23+02:00: verified 5083.27/15028.00 MiB in 49.70 seconds, speed 102.27/302.35 MiB/s (0 errors)

Snapshot fliegt am Abend weg
2025-06-17T12:14:23+02:00: percentage done: 50.40% (6/12 groups, 2/42 snapshots in group #7)
2025-06-17T12:14:23+02:00: verify backup:vm/209/2025-06-17T05:01:14Z
2025-06-17T12:14:23+02:00: check qemu-server.conf.blob
2025-06-17T12:14:23+02:00: check drive-virtio2.img.fidx
2025-06-17T12:14:47+02:00: verified 2800.81/6620.00 MiB in 24.41 seconds, speed 114.75/271.23 MiB/s (0 errors)
2025-06-17T12:14:47+02:00: check drive-virtio1.img.fidx
2025-06-17T12:14:50+02:00: verified 187.43/1176.00 MiB in 3.45 seconds, speed 54.28/340.60 MiB/s (0 errors)
2025-06-17T12:14:50+02:00: check drive-virtio0.img.fidx
2025-06-17T12:15:42+02:00: verified 4907.57/13900.00 MiB in 51.97 seconds, speed 94.43/267.46 MiB/s (0 errors)

Snapshot fliegt am Abend weg
2025-06-17T12:15:42+02:00: percentage done: 50.60% (6/12 groups, 3/42 snapshots in group #7)
2025-06-17T12:15:42+02:00: verify backup:vm/209/2025-06-17T04:11:54Z
2025-06-17T12:15:42+02:00: check qemu-server.conf.blob
2025-06-17T12:15:42+02:00: check drive-virtio2.img.fidx
2025-06-17T12:15:50+02:00: verified 882.06/2252.00 MiB in 7.70 seconds, speed 114.50/292.34 MiB/s (0 errors)
2025-06-17T12:15:50+02:00: check drive-virtio1.img.fidx
2025-06-17T12:15:53+02:00: verified 159.51/1012.00 MiB in 3.11 seconds, speed 51.35/325.75 MiB/s (0 errors)
2025-06-17T12:15:53+02:00: check drive-virtio0.img.fidx
2025-06-17T12:16:24+02:00: verified 3083.90/8924.00 MiB in 30.89 seconds, speed 99.84/288.91 MiB/s (0 errors)
2025-06-17T12:16:24+02:00: percentage done: 50.79% (6/12 groups, 4/42 snapshots in group #7)

Snapshot wird behalten -> ist der letzte vom Vortag und der einzige den er verifizieren soll. Die Laufzeiten wären dann die oben vom initialen Einlesen.
2025-06-17T12:16:24+02:00: verify backup:vm/209/2025-06-16T18:01:04Z
2025-06-17T12:16:24+02:00: check qemu-server.conf.blob
2025-06-17T12:16:24+02:00: check drive-virtio2.img.fidx
2025-06-17T12:17:07+02:00: verified 5251.30/12332.00 MiB in 42.59 seconds, speed 123.30/289.56 MiB/s (0 errors)
2025-06-17T12:17:07+02:00: check drive-virtio1.img.fidx
2025-06-17T12:17:11+02:00: verified 240.15/1688.00 MiB in 4.57 seconds, speed 52.53/369.23 MiB/s (0 errors)
2025-06-17T12:17:11+02:00: check drive-virtio0.img.fidx
2025-06-17T12:34:41+02:00: verified 141766.92/243832.00 MiB in 1049.64 seconds, speed 135.06/232.30 MiB/s (0 errors)

Technische Umsetzbarkeit:
Option nur Snapshots die zum Start des verifys da sind:
Also so wie man skippen kann das bereits verifizierte geskippt werden oder den Re-Verify einstellen kann, sollte es auch möglich sein eine Prüfung des Startdatums des Jobs mit dem Erstelldatum der Snapshots abzugleichen.

Sortieren von VM´s:
Einen Mechanismus der die Ordnerstruktur des Datastore zugrunde liegt, aus der er die Reihenfolge der VM´s automatisch festlegt, gibt es ja auch, wo man evtl eine sortierung derer dazwischen bauen könnte.


Liebe Grüße

 

[Falk R.]

Da hast du natürlich Recht und hast bisher schon viel Tuning betrieben und die Unzulänglichkeiten der Hardware auszubessern.
Ich glaube nur ganz wenige Leute betreiben so viel Analyse und Optimierung, daher wird sich wahrscheinlich der Programmieraufwand nicht lohnen.

Vermutlich hast du dein Raid6 über einen Raid Controller gebaut? Welches Dateisystem nutzt du?
Hast du schon etwas Tuning am Cache des RaidController betrieben? Normalerweise haben die meisten 90% Write und 10% Read Cache eingestellt. Ich würde das mal mit 75/25 und einmal mit 50/50 testen. Kannst du bei allen gängigen Controller mit den CLI Tool im laufenden Betrieb ändern.

Eventuell bringt dich das ja auch ein ganzes Stück weiter.

 

[Lun4r]

Alles klar -> ergibt Sinn.
Jop, das ist über einen RAID Controller (PERC-H745) gebaut.
Dateisystem ist xfs.
Ich schau mir das mal an mit dem Cache. Danke für den Tip und deine Zeit.

 

[Lun4r]

Am RAID Controller und im Internet hab ich jetzt nichts finden können wo ich das RAM Verhältnis einstellen könnte -> Hast du da vielleicht eine Anleitung zur Hand -Aber vielleicht ist das auch gar nicht mehr nötig:

Hab im IDrac die Cacherichtlinie der virtuellen Festplatte nochmal angepasst bei "!":
Leseregel: von adaptives Vorrauslesen auf Kein Vorrauslesen (sind ja random Daten) !
Schreibregel: Rückschreiben
Festplattencache: von Aktiviert auf Standardeinstellungen !

Ich will mich nicht zu früh freuen aber das sieht grad extrem gut aus:

Alter Initialverify und Re-Verifys:
2025-06-15T21:39:26+02:00: verify group backup:vm/404 (30 snapshots)
2025-06-15T21:39:26+02:00: verify backup:vm/404/2025-06-14T18:10:22Z
2025-06-15T21:39:26+02:00: check qemu-server.conf.blob
2025-06-15T21:39:26+02:00: check drive-virtio0.img.fidx
2025-06-15T21:43:42+02:00: verified 14891.18/28524.00 MiB in 256.52 seconds, speed 58.05/111.20 MiB/s (0 errors)
2025-06-15T21:43:42+02:00: percentage done: 78.89% (26/33 groups, 1/30 snapshots in group #27)
......
skiped verifys
......
2025-06-15T21:43:43+02:00: percentage done: 80.40% (26/33 groups, 16/30 snapshots in group #27)
2025-06-15T21:43:43+02:00: verify backup:vm/404/2025-05-10T18:09:47Z
2025-06-15T21:43:43+02:00: check qemu-server.conf.blob
2025-06-15T21:43:43+02:00: check drive-virtio0.img.fidx
2025-06-15T21:46:24+02:00: verified 8943.09/17912.00 MiB in 161.78 seconds, speed 55.28/110.72 MiB/s (0 errors)
......
skiped verifys
......
2025-06-15T21:46:24+02:00: verify backup:vm/404/2025-04-05T18:10:34Z
2025-06-15T21:46:24+02:00: check qemu-server.conf.blob
2025-06-15T21:46:24+02:00: check drive-virtio0.img.fidx
2025-06-15T21:48:54+02:00: verified 8341.35/17104.00 MiB in 149.14 seconds, speed 55.93/114.69 MiB/s (0 errors)
......
skiped verifys
......
2025-06-15T21:48:54+02:00: verify backup:vm/404/2025-01-25T19:08:34Z
2025-06-15T21:48:54+02:00: check qemu-server.conf.blob
2025-06-15T21:48:54+02:00: check drive-virtio0.img.fidx
2025-06-15T21:51:41+02:00: verified 9216.40/19656.00 MiB in 167.58 seconds, speed 55.00/117.29 MiB/s (0 errors)


Neuer Initialverify nach Änderung mit Reverifys:
2025-06-18T13:34:46+02:00: verify backup:vm/404/2025-06-17T18:10:07Z
2025-06-18T13:34:46+02:00: check qemu-server.conf.blob
2025-06-18T13:34:46+02:00: check drive-virtio0.img.fidx
2025-06-18T13:36:40+02:00: verified 15099.51/28832.00 MiB in 113.79 seconds, speed 132.69/253.37 MiB/s (0 errors)
......
skiped verifys
......
2025-06-18T13:36:40+02:00: verify backup:vm/404/2025-05-17T18:10:04Z
2025-06-18T13:36:40+02:00: check qemu-server.conf.blob
2025-06-18T13:36:40+02:00: check drive-virtio0.img.fidx
2025-06-18T13:37:50+02:00: verified 9392.09/18740.00 MiB in 70.58 seconds, speed 133.07/265.51 MiB/s (0 errors)
......
skiped verifys
......
2025-06-18T13:37:50+02:00: verify backup:vm/404/2025-04-12T18:09:12Z
2025-06-18T13:37:50+02:00: check qemu-server.conf.blob
2025-06-18T13:37:50+02:00: check drive-virtio0.img.fidx
2025-06-18T13:38:53+02:00: verified 8060.57/16476.00 MiB in 62.92 seconds, speed 128.12/261.87 MiB/s (0 errors)
......
skiped verifys
......
2025-06-18T13:38:53+02:00: verify backup:vm/404/2024-12-28T19:07:11Z
2025-06-18T13:38:53+02:00: check qemu-server.conf.blob
2025-06-18T13:38:53+02:00: check drive-virtio0.img.fidx
2025-06-18T13:40:10+02:00: verified 9958.70/20628.00 MiB in 76.17 seconds, speed 130.74/270.81 MiB/s (0 errors)


In beiden Fällen lief kein anderer Job oder Backup parallel der das Ergebnis verzerren könnte.
Datenmengen sollten ca. vergleichbar sein.

Ich beobachte das mal aber denke das hier gerade durch das deaktivieren des "adaptiv Vorrausschauenden lesens" die Bremse gelöst wurde.
Riesen Dank nochmal für den Wink da nochmal nachzuschauen!
*der Zug, der Zug, der Zug hat keine Bremse (mehr)*

 

[Lun4r]

Der Verify der stündlichen Backups, ohne Re-Verify und im Leerlauf in der Nacht, ist von 9-10h auf 8h geschrumpft.
Das sieht sehr gut aus.
Ich denke das Thema ist damit erledigt.