Verify-Job bei Proxmox Backup Server deaktivieren - bei Nutzung von ZFS?

[fettfoen]

Hallo zusammen,

wir betreiben zwei große Proxmox Backup Server mit jeweils ca. 200–300 TB an Daten. Als Dateisystem setzen wir auf beiden Systemen ZFS ein.
Aktuell laufen regelmäßig die automatischen Verify-Jobs, um die Integrität der Backups zu überprüfen.

Da ZFS jedoch bereits eine eingebaute Mechanik zur Datenintegritätsprüfung besitzt (Checksummen, Scrubs etc.), stellen wir uns die Frage, ob es möglich und sinnvoll wäre, die Verify-Jobs auf dem Proxmox Backup Server zu deaktivieren.

Hintergrund:
Die Verify-Jobs dauern bei unserem Datenvolumen extrem lange und behindern dadurch Backups sowie Replikationsprozesse deutlich. Dies führt regelmäßig zu Fehlern und Verzögerungen.

Daher die Frage:

• Ist es bei Nutzung von ZFS (mit regelmäßigen Scrubs) überhaupt noch notwendig, zusätzlich die Verify-Funktion des Proxmox Backup Servers zu verwenden?

LG
ff

 

[news]

Meiner Meinung nach schon, denn wie will man sonst wissen, dass was man übers lokale Netz in Häppchen kopierte, auch dem Ziel, eines Backups, entspräche.
Fehler entstehen auf unterschiedlichen Ebenen und nur Test können Unterschiede und Problem frühzeitig aufdecken.
Evtl. kann man die Proxmox BS in seiner Hardware: CPU max. Clock, Ram, HDDs mit SSDs Unterstützung (Special Device) und Netzspeed noch verbessern.

 

[fabian]

den "bit rot detection" teil der verification braeuchtet ihr tatsaechlich nicht. den logischen teil (sind alle chunks da die referenziert werden? ist in jedem chunk file das drin was drauf steht - also stimmt der digest mit dem inhalt ueberein?) kann ZFS alleine nicht leisten.

wir haben hier schon ein paar mal andiskutiert, dass die Garbage Collection eine art "lightweight verification" machen koennte (also zumindest die pruefung, ob alle von einem index referenzierten chunks existieren und nicht leer sind), weil die ohnehin ueber alle indizes drueber iteriert..

 

[Falk R.]

Hallo zusammen,

wir betreiben zwei große Proxmox Backup Server mit jeweils ca. 200–300 TB an Daten. Als Dateisystem setzen wir auf beiden Systemen ZFS ein.
Aktuell laufen regelmäßig die automatischen Verify-Jobs, um die Integrität der Backups zu überprüfen.

Da ZFS jedoch bereits eine eingebaute Mechanik zur Datenintegritätsprüfung besitzt (Checksummen, Scrubs etc.), stellen wir uns die Frage, ob es möglich und sinnvoll wäre, die Verify-Jobs auf dem Proxmox Backup Server zu deaktivieren.

Hintergrund:
Die Verify-Jobs dauern bei unserem Datenvolumen extrem lange und behindern dadurch Backups sowie Replikationsprozesse deutlich. Dies führt regelmäßig zu Fehlern und Verzögerungen.

Daher die Frage:

• Ist es bei Nutzung von ZFS (mit regelmäßigen Scrubs) überhaupt noch notwendig, zusätzlich die Verify-Funktion des Proxmox Backup Servers zu verwenden?

LG
ff

Prüfe mal bitte ob die Scrubs überhaupt durchlaufen. Wenn die Platten zu langsam für das Verify sind, dürften die Scrubs auch nicht durchlaufen.
Die Restores sind dann eventuell auch sehr langsam.

 

[Johannes S]

Daher die Frage:

• Ist es bei Nutzung von ZFS (mit regelmäßigen Scrubs) überhaupt noch notwendig, zusätzlich die Verify-Funktion des Proxmox Backup Servers zu verwenden?

Woher soll ZFS denn wissen, ob die Daten noch zu den Backups passen? Diese logische Prüfung kann ZFS gar nicht vornehmen, Fabian hat dazu ja bereits geschrieben. Wenn ihr natürlich regelmäßig einen Restore-Test für alle Backups macht (was ich bei der Datenmenge dreisterweise bezweifle), dann braucht ihr den verify-Job nicht mehr unbedingt Wie ist denn eurer Taskplan aktuell? Macht ihr immer einen kompletten verify, oder habt ihr eingestellt, dass die verify-Jobs erst nach einer bestimmten Zeit (z.B. einer Woche, einen Monat o.ä.) bereits verifizierte Backups wieder überprüfen?

Wie ist denn eurer Storage aufgebaut? RAIDZ ist von der Performance schlechter als mirror (RAID1) oder striped mirror (RAID10), HDDs schlechter als SSDs (und die PBS Doku empfiehlt ja die Verwendung von Enterprise SSDs, aufgrund eurer Datenmenge vermute ich aber, dass das eurer Budget sprengen würde). Eine pragmatische Alternative könnte sein, zusätzlich Enterprise SSDs mit power-loss-protection als special device in den ZFS Pool einzuhängen:
https://pbs.proxmox.com/docs/sysadmin.html#local-zfs-special-device
https://pve.proxmox.com/wiki/ZFS_on_Linux#sysadmin_zfs_special_device

Auf dem special device werden dann die Metadaten und sehr kleine Dateien (wenige KB, die genaue Größe kann konfiguriert und das Speichern kleiner Dateien im special device auch komplett abgeschaltet werden) gespeichert, das beschleunigt insbesondere die garbage collection (da die hauptsächlich aus dem Einlesen der Metadaten besteht) deutlich. Verify logischerweise nicht so stark (da dort auch die realen Daten eingelesen werden müssen), aber auch das profitiert davon.

Aber: Die Redundanz im special device sollte der des restlichen Pools entsprechen, weil bei einen Verlust des special devices der ganze Pool weg ist. Also: Bei einen HDD mirror also aus mindestens zwei SSDs, bei RAIDZ1 mit drei HDDs mindestens aus drei SSDs etc pp. Als Faustregel zur Ermittlung der benötigten Kapazität wird oft 0,02 % bis 2 % der Kapazität des HDD-Pools genannt, wären bei 300 TB also bei 2% ca 6200 GB pro SSD.


Ein striped mirror sorgt dagegen vor allem für eine höhere Leseperformance im Vergleich zu RAIDZ:
Siehe folgendes Beispiel (mit Messdaten) aus dem TrueNAS Forum: https://www.truenas.com/community/t...d-mirror-raid10-performance-comparison.93598/
Oder die offizielle OpenZFS Dokumentation ( https://openzfs.readthedocs.io/en/latest/performance-tuning.html ):

If small random IOPS are of primary importance, mirrored vdevs will outperform raidz vdevs. Read IOPS on mirrors will scale with the number of drives in each mirror while raidz vdevs will each be limited to the IOPS of the slowest drive.

If sequential writes are of primary importance, raidz will outperform mirrored vdevs. Sequential write throughput increases linearly with the number of data disks in raidz while writes are limited to the slowest drive in mirrored vdevs. Sequential read performance should be roughly the same on each.

Random IOPs sind nun gerade bei PBS hoch relevant, da ja der Datenbestand in zig kleine Dateien von wenigen MB Größe (die Chunks) aufgesplittet wird.

Ein weiterer Vorteil: Ein resilvern nach einen Plattentausch sollte schneller fertig sein, als bei RAIDZ.

Wenn ihr das alles schon ausprobiert habt: Nevermind, dann steht es hier nur als Referenz für andere Leute mit ähnlichen Problemen.