das ist ja schräg.
wie kann denn ein verify sauber durchlaufen wenn die chunks nicht mehr da sind?
PBS 2.4-1: Ein fehlerhaftes Backup macht alle Backups einer VM unbrauchbar.
- Thread starter Ariston
- Start date
das ist ja schräg.
wie kann denn ein verify sauber durchlaufen wenn die chunks nicht mehr da sind?
Das ist ein Fehlschluß.
Der Verify-Status wird nicht aktualisiert und zeigt weiterhin einen alten Status.
Wäre vielleicht nett, wenn man irgendwo dabeischreiben könnte, von wann dieser Status eigentlich ist ...
der verfiy kann doch entweder nur erfolgreich sein oder failen - also grün oder rot
wäre es nicht sinnvoller das updaten des status zu fixen im verify fehlerfall , dann braucht man auch keinen extra timestamp
wäre es nicht sinnvoller das updaten des status zu fixen im verify fehlerfall , dann braucht man auch keinen extra timestamp
oh - potz tausend! wenn man den .chunks ordner umbenennt und einen leeren neuen anlegt, dann läuft ein bereits gelaufener verify job tatsächlich komplett ohne fehler durch und auch in der content view wird alles mit grün/ok angezeigt !
Last edited:
Verify guckt sich ja nur Chunks von Backups Snapshots an die nicht bereits verifiziert wurden (oder wenigstens das letzte Verify zu lange her ist). Ein Full Re-Verify sollte dann ja fehlende Chunks bemängeln, da dann wirklich jeder Chunk angeguckt wird. Aber gut, den Full Re-Verify will man ja auch nicht ständig laufen lassen, so langsam wie der sein kann.
Mir würde da jetzt auch nicht einfallen, was man dagegen machen sollte, was nicht massig Ressourcen braucht. Ich meine PBS weiß ja nicht mal wie groß der Datastore ist, weil es einfach zu viel kosten würde da ständig die größe des Datastore-Ordners zu überwachen und nimmt dann einfach die grobe Größe von dem, was da komplette Dateisystem ala "df -h" zurück gibt. Da wird es wohl nicht wenigen aufwändig sein einen manuellen Eingriff in Datastore-Ordner zu überwachen.
Last edited:
ja, das ist irgendwie etwas knifflig - aber einen verify job laufen lassen der dann sagt "alles ok" und bei völliger abwesenheit ALLER chunks "alles grün" anzeigt - damit fühl ich mich irgendwie nicht wohl.
klar muss man immer mitdenken, aber nicht jeder backup-operator weiss über die interne funktionsweise vom pbs bescheid und storage fehler sollten erfahrungsgemäss lieber früh als spät vom system gemeldet werden.
ich finde jedenfalls, wenn chunks fehlen oder gar ein ganzer chunkstore inhalt, dann ist das irgendwie schon sehr unschön, wenn das im zweifel erst 24h später in der gui angezeigt wird. und es ist auch in der tat unschön, daß man dem grünen verify haken das alter nicht ansehen kann, von daher finde ich das mit dem timestamp vorschlag von oben garnicht schlecht.
vor allem wenn ein backup operator ja weiss "hey, gab gerade probleme mit dem storage - ich mach mal eben re-verify" - dann ist das schon irgendwie blöd wenn er erst wissen muss, daß er den "re-verify" haken wegmachen muss
klar muss man immer mitdenken, aber nicht jeder backup-operator weiss über die interne funktionsweise vom pbs bescheid und storage fehler sollten erfahrungsgemäss lieber früh als spät vom system gemeldet werden.
ich finde jedenfalls, wenn chunks fehlen oder gar ein ganzer chunkstore inhalt, dann ist das irgendwie schon sehr unschön, wenn das im zweifel erst 24h später in der gui angezeigt wird. und es ist auch in der tat unschön, daß man dem grünen verify haken das alter nicht ansehen kann, von daher finde ich das mit dem timestamp vorschlag von oben garnicht schlecht.
vor allem wenn ein backup operator ja weiss "hey, gab gerade probleme mit dem storage - ich mach mal eben re-verify" - dann ist das schon irgendwie blöd wenn er erst wissen muss, daß er den "re-verify" haken wegmachen muss
Last edited:
Das steht übrigens dabei. Musst du nur lange genug mit der Maus über dem "OK" eines Backup Snapshots hovern, dann kommt ein Tooltip, der das anzeigt. Bin ich auch erst nach einem Jahr oder so zufällig drauf gestoßen:
oh, das kannt ich noch garnicht. komisch, daß mir das nie aufgefallen ist, ich hab mich wohl nie "versehentlich" mit der mouse über der spalte aufgehalten. danke für den tip
Last edited:
Sorry zum Zeitpunkt des Posts hatte ich den Haken bei "Skip Verified" übersehen. Natürlich werden nun alle als Failed angezeigt wenn ich die manuell erneut prüfe.
GC dauert bei uns ~8h und jeder Test ist zeitfressend. Morgen wollte ich nach einem Sync der täglichen Backups und anschließenden Verify eine Liste alle Chunks generieren. Ab Mittag läuft dann der GC und danach schaue ich welche Files er angeblich nicht finden kann (das GC Log ist 500MB groß).
Der GC sorgt dafür dass unsere täglichen Backups (Sync vom Primary) am Folgetag immer gelöscht werden.
@Ariston ich wollte jetzt nicht dein Thread füllen, denke aber die Ursache der fehlenden Chunks (sofern sie fehlen oder GC es nur behauptet) könnte die gleiche Ursache haben.
@Ariston fehlen bei dir die Chunks nach einem GC bzw. schlägt nach dem GC die Re-Verification fail?
Ich habe bei uns den Fehler gefunden, der GC setzt für jeden Chunk die atime neu und auf unserer Isilon ist das Time Tracking deaktiviert (default Einstellung).
Das ist mir erst aufgefallen nachdem ich direkt nach dem GC ein "stat" auf die gespeicherten Chunks gemacht habe, die atime hatte noch den alten Timestamp.
Ich habe bei uns den Fehler gefunden, der GC setzt für jeden Chunk die atime neu und auf unserer Isilon ist das Time Tracking deaktiviert (default Einstellung).
Das ist mir erst aufgefallen nachdem ich direkt nach dem GC ein "stat" auf die gespeicherten Chunks gemacht habe, die atime hatte noch den alten Timestamp.
Hi Maik_n,
ja das spiegelt das Verhalten, das ich beobachtet habe schon gut wieder. Unser Isilon hat ebenfalls noch die default Einstellung bezüglich des Time Trackings. Ich aktiviere es mal und schau wie sich der GC verhält. Allerdings lieber nicht am Freitag kurz vor Feierabend, das ist für Murphy dann vermutlich doch zu verlockend.
Vielen Dank für den Tip.
bye Ariston
also bei solchen fehlern , der iops-lastigkeit des ganzen verfahrens sowie dem 24h "nachteil" (bei relatime) frag ich mich gerade, ob man das nicht effizienter gestalten könnte, indem man da nicht auf filesyste atime setzt als "marker" sondern diese info irgendwo/irgendwie anders speichert.
d.h. ein versehentlich gesetzes "noatime" hier dann also auch sehr gefährlich !?
d.h. ein versehentlich gesetzes "noatime" hier dann also auch sehr gefährlich !?
Das wurde schon einmal diskutiert. Ich kann nur gerade den Thread nicht mehr finden.
Fazit vom Proxmox Team war es, dass da ein Tracking der Chunks in einer Datenbank oder ähnliches noch mehr IO erzeugen und es alles noch mehr verkomplizieren würde und man sich daher dagegen entschieden hat, nachdem das ausführlich im Team besprochen wurde, bei der Planung von PBS.
Aber auf jedenfall sollte man besser in der Dokumentation darauf hinweisen, dass da ein "noatime" zu Datenverlust führen kann. Z.B. bei den Requirements, dass da der Storage atime oder relatime unterstützen muss.
Der einzige Treffer bei der Dokumentationssuche nach "atime" ist:
Fazit vom Proxmox Team war es, dass da ein Tracking der Chunks in einer Datenbank oder ähnliches noch mehr IO erzeugen und es alles noch mehr verkomplizieren würde und man sich daher dagegen entschieden hat, nachdem das ausführlich im Team besprochen wurde, bei der Planung von PBS.
Aber auf jedenfall sollte man besser in der Dokumentation darauf hinweisen, dass da ein "noatime" zu Datenverlust führen kann. Z.B. bei den Requirements, dass da der Storage atime oder relatime unterstützen muss.
Der einzige Treffer bei der Dokumentationssuche nach "atime" ist:
Last edited:
Theoretisch wäre es möglich, statt der atime die mtime zu nutzen (falls die nicht anderweitig gebraucht wird). Das wäre vielleicht deutlich robuster.
Wäre spannend gewesen, die Diskussion des Proxmox Teams dazu gehört zu haben ...
Wäre spannend gewesen, die Diskussion des Proxmox Teams dazu gehört zu haben ...
hier gibt es 2 threads dazu:
https://forum.proxmox.com/threads/pbs-server-full-two-days-later-almost-empty.83274/
https://forum.proxmox.com/threads/zpool-atime-turned-off-effect-on-garbage-collection.76590/
atime=off und relatime=off heisst bei zfs offensichtlich NICHT, daß atime nicht gesetzt werden kann sondern nur, daß es bei open/read/close NICHT automatisch gesetzt wird. pbs setzt das explizit.
vielleicht mögt ihr @Ariston @maik_n mal testen, wie sich das bei der isilon mit deaktiviertem atime verhält.
https://forum.proxmox.com/threads/pbs-server-full-two-days-later-almost-empty.83274/
https://forum.proxmox.com/threads/zpool-atime-turned-off-effect-on-garbage-collection.76590/
atime=off und relatime=off heisst bei zfs offensichtlich NICHT, daß atime nicht gesetzt werden kann sondern nur, daß es bei open/read/close NICHT automatisch gesetzt wird. pbs setzt das explizit.
vielleicht mögt ihr @Ariston @maik_n mal testen, wie sich das bei der isilon mit deaktiviertem atime verhält.
from datetime import datetime
import os
def set_file_access_time(filename, atime):
"""
Set the access time of a given filename to the given atime.
atime must be a datetime object.
"""
stat = os.stat(filename)
mtime = stat.st_mtime
os.utime(filename, times=(atime.timestamp(), mtime))
set_file_access_time("myfile.txt", datetime(1970, 1, 1, 0, 0, 0))
# python3 atime.py
#
# stat myfile.txt
File: myfile.txt
Size: 0 Blocks: 1 IO Block: 131072 regular empty file
Device: 0,50 Inode: 67096 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 1970-01-01 00:00:00.000000000 +0100. <- hat geklappt. !
Modify: 2023-08-18 20:26:01.579861402 +0200
Change: 2023-08-18 20:26:07.919917008 +0200
Birth: 2023-08-18 20:26:01.579861338 +0200
Last edited:
Ich bin zwar keiner der beiden, kann das aber auch testen (jeweils Isilon OneFS 9.4.0.14):
Auf einem Cluster mit abgeschaltetem Time Tracking klappt es auf einem per NFS gemounteten Share nicht:
Code:
alex@host:~$ python3
>>> set_file_access_time("myfile.txt", datetime(1970, 1, 1))
alex@host:~$ stat myfile.txt
File: myfile.txt
Size: 0 Blocks: 3 IO Block: 1048576 regular empty file
Device: 41h/65d Inode: 1932538741 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ alex) Gid: ( 15/ users)
Access: 2023-08-18 21:30:06.798759937 +0200
Modify: 2023-08-18 21:30:06.798759937 +0200
Change: 2023-08-18 21:30:28.278216000 +0200
Birth: -Auf einem anderen Cluster mit aktiviertem Time Tracking funktioniert es auf einem gemounteten NFS Share dagegen:
Code:
alex@host:/data/loc/test/share$ python3
>>> set_file_access_time("myfile.txt", datetime(1970, 1, 1))
alex@host:/data/loc/test/share$ stat myfile.txt
File: myfile.txt
Size: 0 Blocks: 48 IO Block: 524288 regular empty file
Device: 40h/64d Inode: 4592846716 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ alex) Gid: ( 15/ users)
Access: 1970-01-01 01:00:00.000000000 +0100
Modify: 2023-08-18 21:28:35.615633964 +0200
Change: 2023-08-18 21:29:19.044311000 +0200
Birth: -Andererseits kann man die Datenbank auf wesentlich schnelleren Storage packen. Insbesondere wenn der Pool auf Platten liegt sollte das trotz Overhead noch deutlich schneller sein.
Das auf jeden Fall.
Und man könnte Testdateien ablegen (mindestens zwei, abwechselnd verwendet, damit immer eine definitiv über dem relatime-Cutoff ist) und abbrechen wenn die atime sich nicht ändern läßt.
wenn utime hier keinen fehler zurueck gibt, dann ist das wohl ein bug im NFS server.. automatische updates abzudrehen ist eine sache, aber explizit angeforderte updates nicht durchzufuehren ohne einen fehler zu "schmeissen" ist problematisch.