[Sammelthread] ZFS Stammtisch

[v3nom]

Ich sehe da kein Problem. Kommt ggf noch darauf an ob du die Komprimierung nutzen möchtest und wenn ja welche.
Ich nutze ZFS mit 4x12TB WD Red im RaidZ1 und LZ4 auf einem Intel Atom C3000 ohne Probleme. Ich schaffe aber durch die Platten auch nicht 10GbE.

 

[gea]

Ich habe jetzt noch keine größeren Tests mit unterschiedlichen CPUs gemacht. Insgesamt ist RAM als Schreib/Lesecache aber meist wichtiger als CPU. Dennoch muss eine Menge Daten verarbeitet werden. Die reine Pool Performance wird sicher > 500 MB/s sein können.

Ich würde mit dem Celeron auch davon ausgehen dass deutlich mehr als 100MB/s via SMB möglich ist. Ohne viel Tuning Massnahmen kann man in einem 10G Netz bei einer schnellen CPU und einem schnellen Pool ca 300-400 MB/s über SMB erwarten. Da würde ich bereits davon ausgehen dass die CPU bremst. Volle 10G Performance (1000MB/s) ist sicher nicht drin.

Compress und Verschlüssellung sollte man eventuell deaktivieren. Auch ist ein Multi Mirror schneller als ein Raid Z bei dem mehr Berechnungen anfallen.

 

[p4n0]

Hi in die Runde,

ich stehe vor der Entscheidung welches OS ich fuer meine ZFS VM verwenden soll.
Habe bisher keine Erfahrungen mit selbstbau+betrieb mit ZFS.

Das Ganze wird auf einem ESXi 7 virtualisiert.

FreeNas? Omni-OS + Napp-IT ?

Ziel soll sein:
- Verschlüsselte Volumes
- iSCSI fuer den ESXi (VM Storage)
- Wartungsarm
- Am besten LTS, moeglichst idiotensichere Updatemoeglichkeiten

Vllt. is die Frage hier auch gut aufgehoben:
Ich moechte gerne SSD Only fuer den Filer verwenden.
Tendiere aktuell zu Micron ION 5210 SATA SSDs. Wuerden auch gebrauchte Samsung PM883 gehen?

Waeren in dieser Konstellation noch Optane's notwendig um ein 'smoothes' Storage-Erlebnis zu erhalten?
Falls ja: Muessen es 2 Stueck fuer Cache und Log sein?

Danke fuer euren Input!

 

[gea]

Stable und Long Term Stable sind Konzepte von Betriebssystemen wie OmniOS oder Ubuntu. Das ist unabhängig von einer Web-Managementoberfläche.

Updates was ZFS, iSCSI/Comstar oder Kernel-SMB/NFS angeht sind bei OmniOS und Solaris meist mit Abstand am problemlosesten. Das liegt nicht nur daran dass ZFS für Solaris entwickelt wurde sondern auch daran dass diese Dienste von Sun entwickelt wurden und immer noch Teil des Betriebssystems sind und keine Extra/Fremd Tools wie z.B. SAMBA sind. Ein normales OS Update via "pkg update" sorgt automatisch dafür dass auch diese Dienste upgedated werden.

ZFS Verschlüssellung gibt es seit 2019 für Illumos (OmniOS), Solaris (seit 2010) und Linux, noch nicht für Free-BSD.

btw
- Ich würde NFS statt iSCSI nehmen, um Storage an ESXi anzubinden
- Die Storage VM sollte so wenig Resourcen verbrauchen wie möglich damit der RAM als Cache auch der Performance zugute kommt. OmniOS ist ideal. Unter Free-BSD eher sowas wie XigmaNAS nehmen anstatt dem recht überladenen FreeNAS.
-SSD only ist kein Problem. Man sollte nach Möglichkeit einen 12G SAS HBA vorsehen (BroadCom 9300 etc). SSD mit Powerloss Protection erhöhen die Sicherheit nicht nur aber vor allem bei sync write.

Mit sehr guten Datacenter SSDs bringt ein Extra Optane Slog oder L2Arc nur wenig. Besser mehr RAM verwenden. Eine neue Option für mehr Performance sind "special vdev" unter OmniOS oder Linux. Darauf lassen sich Metadaten, kleine IO, einzelne Dateisysteme oder Dedup Daten speichern. Dafür wäre ein Optane Mirror ideal.

Für L2Arc bringt ein Mirror garnichts. Für Slog sorgt er vor allem dafür dass bei einem Slog Ausfall die Performance nicht einbricht. Es schützt auch vor dem extrem seltenen Fall eines Crash beim Schreiben bei dem gleichzeitig das Slog kaputt geht. Ansonst schaltet ZFS bei einem Slog Ausfall einfach auf onpool Logging um.

 

[p4n0]

Danke fuer deinen Input, gea.

Soweit ich das Thema durchdrungen habe, verhält sich iSCSI performanter als NFS. Vor allem wenn man Sync-Writes bei NFS aktiviert und mit Snapshots arbeitet.
Da iSCSI Blockbasiert ist soll das laut meinen Recherchen performanter laufen UND unter Last weniger Latenz erzeugen. (Im Vergleich zu NFS).

RAM sehe ich nicht so als Problem, die Moehre hat 384GB. Kann der VM also geschmeidige 128GB spendieren.

Keine ZFS native Verschlüsselung unter FreeBSD bedeutet, dass FreeNas/XigmaNAS raus fallen?

Kann man L2Arc und das Slog device im Nachgang noch an den Pool hängen? Dann wuerde ich erstmal mit SSDs only starten.

Ich moechte gerne so wenig wie moeglich falsch machen und auch nicht 10 versch. distributionen/unixe testen
Danke fuer deine Hilfe!

Grueße

 

[gea]

Bei gleichen sync Einstellungen arbeitet iSCSI und NFS ähnlich schnell. Man darf aber nicht NFS (sync aktiviert per default unter ESXi) und iSCSI (sync deaktiviert per default/=writeback cache enabled) vergleichen. Aktiviert/ deaktiviert man beidesmal sync, sind die Ergebnisse ähnlich, das Handling von NFS insbesondere durch den Filebasierten Zugriff auf Snaps oder einzelne VMs per SMB/vorherige Version aber deutlich komfortabler.

Slog/L2Arc/special vdevs kann man jederzeit hinzufügen/entfernen. Bei special vdev muss man nur darauf achten dass diese den gleichen ashift haben wie die anderen vdevs.

 

[fdiskc2000]

@v3nom und @gea : Danke für Eure Antworten. Ich werde dem Celeron einfach mal eine Kleie Chance geben, einfach weil er eh da ist. Zur Not muss dann doch noch ein XEON drauf.

 

[gea]

Aktuelles Open-ZFS kann SSD Trim im Raid. In OmniOS 151034 ist Trim enthalten und aktiviert

Ein neu entdeckter Bug verhindert Trim wenn man ein Slog entfernt.

Bug #12764: Holes prevent TRIM - illumos gate - illumos

Redmine

www.illumos.org

Don't attempt trimming "hole" vdevs by haasn · Pull Request #10227 · openzfs/zfs

Motivation and Context I noticed that my zpool trim <poolname> command fails with: cannot trim 'hole': no such device in pool I've never seen such "hole" devices before...

github.com

Ein Bugfix ist unterwegs.

 

[Lampos]

Guten Tag,

ich habe ein paar Fragen zu Solaris und ACLs und hoffe da bin ich hier richtig.

Ich betreibe einen File-Server unter OmnioOS auf den mehrere Windows- und Mac-Clients zugreifen. Für die freigegebenen Verzeichnisse sollen authentifizierte Benutzer (Alfred und Berta) einer Gruppe (family) Zugriffsrechte bekommen. Alle anderen Benutzer haben kein Zugriffsrechte.

1. Sind die Benutzernamen 'case-sensitive' ? Oder genauer, müssen Benutzer unter Window/MacOS und OmniOS absolut identisch eingerichtet werden ? Oder geht auch win='Alfred' und ix='alfred' ?
2. Die Gruppe 'family' muß unter Windows als auch unter OmniOS eingerichtet sein, oder genügt es unter OmniOS die Benutzer 'Alfred' und 'Berta' der Grupp 'family' zuzuordnen ?

Grüße
Lampos

 

[gea]

Ich gehe jetzt mal davon aus, dass der Solarish eigene kernelbasierte SMB Server benutzt wird und nicht SAMBA.

Entscheidend ist jetzt nur, dass man die beiden Nutzer und die SMB Gruppe family auf Solaris/OmniOS anlegt und die beiden der SMB Gruppe zuweist. Eine Unix Gruppe family ist nicht nötig, da der Solarish SMB Server nur auf die SMB Gruppe mit den Windows sid zugreift. Auf den Windows/OSX Clients muss man weder die Nutzer noch die Gruppe anlegen, die sind nur auf dem Server nötig.

Dann die File/Folder ACL für das Share auf family=read oder modify oder full setzen und everyone löschen.

Beim Zugriff auf den Server wird man jetzt nach Benutzer und Passwort gefragt. Für den Benutzernamen sollte Groß/Kleinschreibung egal sein.

Eine Besonderheit hat man, wenn man auf dem Client z.B. Windows einen gleichnamigen Benutzer mit gleichem Passwort anlegt und als dieser Benutzer an Windows angemeldet ist. Verbindet man sich hier mit dem Server entfällt die Passwortabfrage. Ansonst werden Benutzer/ Gruppen auf dem Client nicht weiter beachtet. Die sind nur wichtig, wenn man z.B. nicht auf den Solaris Server sondern auf den Windows Desktop zugreifen möchte oder wenn sich mehrere den Windows Rechner teilen und sich jeder namentlich anmeldet.

OSX verhält sich entsprechend.

 

[Trambahner]

Gibt es eigentlich eine schnelle Methode, Snaps zwischen zwei Hosts zu vergleichen? Z.B. per "zfs diff" ?

 

[ludwinator]

mit zstreamdump snapshot checksum vergleichen
siehe http://blog.richardelling.com/2009/10/check-integrity-of-zfs-send-streams.html

cu

 

[Lampos]

Ich gehe jetzt mal davon aus, dass der Solarish eigene kernelbasierte SMB Server benutzt wird und nicht SAMBA.

Ja wird er! Das hatte ich vergessen zu erwähnen.

Dann die File/Folder ACL für das Share auf family=read oder modify oder full setzen und everyone löschen.

Ok, verstanden. Setzte ich die Rechte in napp-it über 'ACL on folders" oder "ACL on SMB share"?
Die Zugriffsrechte werden ja dem SMB-Share zugewiesen - wirkt sich das auf bereits bestehende Unterverzeichnisse aus, wenn die Eigenschaften 'vererbt' ('inherit') werden?

 

[gea]

Normalerweise setzt man Rechte auf Dateien und Ordner für die einzelnen Nutzer und Gruppen. Nur diese Rechte sind dauerhaft im Dateisystem gespeichert, bei Solarish sogar als Windows Security ID sid. Am Einfachsten macht man das per Windows indem man sich als root anmeldet (=volle Rechte) über einen Rechts-Mausklick auf eine Datei/Ordner und Eigenschaft > Sicherheit. Lediglich Deny-Regeln muss man direkt auf Solarish/napp-it setzen.

Wenn man Rechte setzt, kann man die auch auf tieferliegende Objekte anwenden. Das ersetzt dann deren Rechte. Ansonst kann man beim Rechte auf einen Ordner setzen angeben, ob die vererbt werden sollen (Dieser Ordner oder auch enthaltene Ordner und Dateien). Das ACL wirkt für die angewählte Datei/Ordner oder bei einem Ordner auf darin neu erstellte Dateien oder Ordner. Die Vererbung kann man dann bei einem tieferliegenden Ordner auch wieder abschalten.

ACL auf Shares ist eine Möglichkeit Rechte kurzzeitig global zu reduzieren z.B. alle nur lesen oder root only. Wenn man eine Freigabe aus/einschaltet geht das immer zurück auf default (jeder=full).

 

[maxblank]

Hallo zusammen,

momentan beschäftige ich mich gerade mit ZFS in einer Testumgebung. Zum Einsatz kommt momentan FreeNAS.
Ich habe eine Frage zum Dashboard bzw. zum RAM, die ich mir nicht erklären kann. Falls Einzelheiten zum System gebraucht werden, liefere ich diese gerne nach.

Angeblich würden die Services 21,8 GiB in Anspruch nehmen und der ZFS Cache lediglich 3,8 GiB.

Edit: Es laufen sonst keinerlei Dienste, Container oder VMs. Dient momentan als reines NAS.

Kann das sein? Danke im voraus.

Gruß
maxblank

 

[Gen8 Runner]

Hallo zusammen,

momentan beschäftige ich mich gerade mit ZFS in einer Testumgebung. Zum Einsatz kommt momentan FreeNAS.
Ich habe eine Frage zum Dashboard bzw. zum RAM, die ich mir nicht erklären kann. Falls Einzelheiten zum System gebraucht werden, liefere ich diese gerne nach.

Angeblich würden die Services 21,8 GiB in Anspruch nehmen und der ZFS Cache lediglich 3,8 GiB.

Edit: Es laufen sonst keinerlei Dienste, Container oder VMs. Dient momentan als reines NAS.

Kann das sein? Danke im voraus.

Anhang anzeigen 509565

Gruß
maxblank

Sieht nicht normal aus. Keine Jails installiert, kein Scrubbing (wobei da fraglich wäre, ob der unter Services läuft) läuft, einfach Idle? Bei mir werden gerade mal 1,7GB von 64GB genutzt.
Schau mal links in der Menübar unter "Display System Processes", ob du da den Übeltäter ausfindig machen kannst, wer sich so viel RAM genehmigt.

 

[maxblank]

Es laufen keine Jails, kein Scrubbing. Und unter den Prozessen finde ich nix, was da zusammen auch nur annähernd über 21 GiB belegen sollte.

 

[Gen8 Runner]

Und mit htop in der Shell?

 

[CommanderBond]

Ich nutze bei nappit "jobs" um regelmäßig snapshots zu erstellen. Habe grad hold=1 geändert und er hat mir alle snapshots von gestern daraufhin gelöscht. Ein Snapshot der am gestern um 23Uhr erstellt wurde kann aber um 3Uhr des Folgetags noch nicht 1 Tag alt sein. Stimmt da vielleicht etwas mit der Berechnung nicht und hold löscht bei 1 alle Snaps des vorherigen Tages? Vielleicht wäre es klüger das script rechnet hier in Stunden oder addiert zumindest immer ein Tag drauf damit die Snaps dann nicht schon vorher gelöscht werden. Bei hold=1 wäre ich jetzt davon ausgegangen dass auch wirklich 24h gemeint sind.

 

[maxblank]

Und mit htop in der Shell?

Mit HTOP sieht es so aus.

 

[martingo]

Dein "Problem" sind die 22GB Wired Memory. Das ist Speicher, der durch den Kernel in Verwendung ist und nicht ausgelagert werden kann.
Standardmäßig nimmt sich FreeNAS bis zu 80% des verfügbaren RAMs für ZFS Zwecke. ARC wird bei Dir zwar nur mit 4GB angezeigt, aber ich vermute, dass das nur der Netto Lese Cache ist. Was in die ZFS Caching Mechanismen noch alles mit reinspielt kann ich leider nicht sagen. Es gibt aber mehrere Parameter mit denen man die Nutzung reduzieren kann.

Aber drehen wir den Spieß mal um: Hast Du denn Probleme, dass Dir irgendeine Anwendung zu wenig RAM bekommt? Üblicherweise gilt die Regel "unbenutzter RAM ist verschwendeter RAM". Insofern ist nichts verwerfliches daran, wenn Dein Speicher nahezu vollständig ausgelastet wird. Üblicherweise gibt ZFS im Kernel auch wieder Speicher frei, sobald andere Programme nach Speicher verlangen.
Früher lief auf meinem Microserver mit 16GB ein Proxmox mit zfs Pool. Speicher war immer gut ausgelastet. Wenn ich dann eine neue VM starten wollte, kam erstmal der Fehler, dass nicht genug RAM zur Verfügung steht. Dadurch wurde dann zfs getriggert, seinen RAM Verbrauch zu reduzieren und einige Sekunden später konnte ich die VM problemlos starten.

 

[gea]

Ich nutze bei nappit "jobs" um regelmäßig snapshots zu erstellen. Habe grad hold=1 geändert und er hat mir alle snapshots von gestern daraufhin gelöscht. Ein Snapshot der am gestern um 23Uhr erstellt wurde kann aber um 3Uhr des Folgetags noch nicht 1 Tag alt sein. Stimmt da vielleicht etwas mit der Berechnung nicht und hold löscht bei 1 alle Snaps des vorherigen Tages? Vielleicht wäre es klüger das script rechnet hier in Stunden oder addiert zumindest immer ein Tag drauf damit die Snaps dann nicht schon vorher gelöscht werden. Bei hold=1 wäre ich jetzt davon ausgegangen dass auch wirklich 24h gemeint sind.

Das Einfachste wäre es mit "keep" eine Mindesanzahl von Snaps zusätzlich anzugeben. Snaps werden dann nur gelöscht wenn die Anzahl über der Mindestanzahl liegt und die Snaps gleichzeitig älter als "hold" Tage sind.

Für die Kurzzeitsnaps wäre zudem die naheliegende Methode einen eigenen Job mit einem Snap je Stunde zu erstellen und mit keep=12 oder 24 die Anzahl festzulegen. Mit 24 hätte man immer für die letzten 24 Stunden einen Snap je Stunde. Dazu könnte man weiter einen Snap Job alle 15 Minuten mit keep=8 erstellen. Da könnte man die letzten 2 Stunden sogar viertelstündlich auf Snaps zugreifen.

 

[CommanderBond]

ja das ist mir bewusst. Aber bezieht sich hold wirklich auf ganze Tage? Meine Beobachtung ist dass er am 26. halt alles löscht was am 25. erstellt wurde wenn ich hold=1 setze.
Bei delzero hab ich auch die Beobachtung gemacht dass wenn ich es nachträglich aktiviere er wirklich alle snaps der größe 0 löscht. Das "Problem" sind dann nur die Blöcke die von mehr als einem Snap festgehalten werden weil die ebenfalls Size=0. Da müsste man dann nach jedem Löschen eines Snaps erneut schauen welche immer noch Size=0 sind.

Woher kommt es eigentlich dass manchmal Veränderungen in einem ZFS Dataset stattfinden obwohl man nichts geändert hat? Hab hier nen snap der ist paar KB groß aber die Dateien sind alle identisch. Auch rtime ist deaktiviert.

 

[gea]

Ein Snap mit size=0 ist zunächst identisch zum Vorgänger. Normalerweise kann man die alle löschen ohne eine Wiederherstellungsmöglichkeit zu verlieren. Ich hatte bisher nur Probleme wenn der letzte Snap size=0 ist und der vorletzte ein Basis-Replikationssnap. Löscht man da den letzten kann es Probleme mit der fortlaufenden Replikation geben. Ich lösche daher bei delzero den letzten Snap nicht wenn er size=0 hat.

Wenn ein Snap > zero ist, dann gibt es einen Unterschied zum Vorgängersnap auf ZFS Blockebene. Das können auch Datei Attribute wie readonly, hidden oder ZFS Attribute sein die sich nicht in unterschiedlichen Dateiinhalten äußern.

 

[CommanderBond]

Was ich ausprobiert habe ich Snap erstellt, eine Datei erstellt, Snap erstellt, noch nen Snap erstellt. Datei gelöscht, Snap erstellt. Wenn ich dann nachträglich delzero aktiviere löscht er alle Snaps, bis auf den letzten natürlich. Allerdings ist die Datei nicht wiederherstellbar da sie nur vom vorletzten und vorvorletzten festgehalten wurde der Snapshot aber size=0 ist und das script einfach kurzerhand alle Snaps mit size=0 löscht.
Klar wenn man von anfang an delzero aktiviert hat hat man das Problem nicht nur dann wenn sich seitdem mehrere Snaps mit size=0 angestaut haben.
Die Size beim Snap ist ja die Speichermenge die frei werden würde wenn man den snap löschen würd daher haben 2 direkt aufeinander folgende Snaps wo es keine Unterschied zwischen diesen beiden Snaps gibt die Größe 0. Löscht man einen der beiden ist der andere nicht länger size=0 sondern bekommt die größe der blöcke die er festhält.
In meinen Augen könnte man das nur lösen indem man jeden snap einzelnt löscht und danach muss man erst wieder kontrollieren ob der nächste snap auch nach der Löschung eines anderen snaps immer noch size=0 hat.

Weiter oben habe ich hold=1 gesetzt und keep leergelassen da ich einen bestimmten Snapjob nicht mehr gebraucht habe. Also war meine Idee einfach month=1 zu setzen und ein Tag abzuwarten bis das script die von ihm erstellen snaps dann automatisch löscht. War bei hold=1 von 24h ausgegangen, aber offenbar kontrolliert er nur den Kalendertag. Ergo löscht er auch den stündlich erstellten Snap um 23Uhr eine stunde später um 0Uhr weil dann ein neuer Tag anfängt.

Ich vermute mal wenn ich einen Snap um 23:59 erstelle wird er ihn auch eine Minute später löschen bei hold=1. Damit hätte ich aber so nicht gerechnet dass hold=1 dazu führt dass er am 26. dann komplett alle stündlichen Snaps vom 25. löscht.
Ich wäre davon ausgegangen folgendes passiert: Wenn der 26. ist um 0Uhr dass er dann den Snap vom 25. um 0Uhr löscht weil das der einzige Snap ist der ein Tag alt ist, also 24h. Alle anderen sind jünger.
Hoffe es ist rüber gekommen was ich meine.

Was ich vermisse ist einen Job in den Status zu versetzen dass er keine neuen Snaps mehr erstellt, aber anhand von hold nach und nach die älteren anfängt zu löschen. Hab mir beholfen indem ich month=1 setze da weit genug in der Zukunft und keep lösche. Dann sollten die Snaps durch den Job anhand der Regeln von Hold mit der Zeit gelöscht werden und ich muss sie nicht manuel löschen.

 

[gea]

Danke für die Anregung

Ich bin gerade am Snap Thema. Da dreht es sich allerdings um das Thema Daisy Chain Replikation eines Dateisystems Server1 > Server2 > Server3 statt dem bisherigen Server 1 >Server 2 und parallell dazu Server 1 > Server 3.

Ich nehme aber das Thema "Verbesserungen beim Löschen von Snaps mit Size=0" als Anregung auf wenn ich mich das nächste Mal der Autosnap Verwaltung widme.

Bis dahin bitte mit mehreren Snap-Jobs für unterschiedliche Anforderungen arbeiten.

 

[CommanderBond]

Okay. Beachte aber dass es im Grunde 2 voneinander getrennte Dinge sind die nichts direkt miteinander zu tun haben.
Das eine Problem mit delzero ist nur dann ein Problem wenn man die funktion nachträglich aktiviert, legt man den job von vornerein mit delzero=yes an spielt es eh keine Rolle.

Das Zweite Problem mit hold rührt daher dass ich vermute dass dein Script hier nur auf den Kalendertag schaut, ergo gibt hold nicht die Dauer an sondern heißt im Grunde eher hold=1 => lösche alle snaps von gestern und älter. Und gestern kann eben auch vor einer Minute gewesen sein. Vielleicht muss man da einfach nur die Differenz in Stunden ausrechnen und intern den Wert von hold mit 24 multiplizieren und dann einfach die Stunden vergleichen

Und das letzte als Feature Request dass es praktisch wäre den Job in den Status zu versetzen dass er keine neuen Snaps erstellt, aber man die "Lösch-Logik" weiterhin laufen lassen kann damit die Snaps nach und nach sich automatisch löschen die der Job angelegt hat.

Nochmal in verständlicher.

 

[gea]

In letzter Konsequenz dreht es sich darum, Snapshots/Dateiversionen in einem gewünschtem Intervall und Zeitraum bereit zu halten um im Fall der Fälle darauf zurückzugreifen.

Dazu kann man einen Snapjob intelligenter machen und mehr Variablen setzen oder eben mehrere unabhängige Auto-Snapjobs mit einem gewünschtem Gesamt-Verhalten anlegen.

Im Moment tendiere ich zu zweiterem Vorgehen da das Verhalten eher vorhersehbar ist, auch wenn das ein paar Snaps mehr bedeutet. ZFS ist ja nicht wie bei ESXi wo man nur wenige Kurzzeitsnaps habe sollte. Ist bei ZFS ja fast egal ob man 100 oder tausend Snaps hat. Wenn es 10000 sind, dann geht es etwas an die Performance - aber nicht beim Dateisystem sondern nur beim Auflisten der Snaps.

 

[CommanderBond]

Ja da hast du sicherlich recht. Ändert aber meiner Meinung nach trotzdem nichts daran dass hold offenbar die Snaps bis zu 24h zu früh löscht und bei einer nachträgliche Aktivierung von delzero man im betreffenen Job snaps verliert (in gewissen Fällen) die man aber zum Wiederherstellen von Dateien gebraucht hätte.
Da bei meinem Filer eher selten was geändert wird finde ich Snaps alle 15Minuten in Verbindung mit delzero mit hold und keep für mich aber am besten. Hatte vorher 3 Jobs für 15minuten, stündliche und tägliche snaps.

 

[gea]

Ich habe im Autosnapjob der 20.dev von heute eine Extra Abfrage vor dem Löschen eines Snaps eingefügt ob used immer noch 0 ist und sich das nicht zwischenzeitlich durch das Löschen einens anderen Snaps geändert hat. Das sollte das Problem soweit beheben.

Zum Tag: Das Script liest den Erstellungstag für hold aus. Will man vermeiden, dass zu früh gelöscht wird, dann halt das Mindestalter hold auf 2 Tage setzen