[Sammelthread] ZFS Stammtisch

Hmm, erst napp-it starten und dann 3 Minuten warten? Ich habe deutlich länger gewartet. Muss morgen früh mal testen Server neu zu starten nach der Methode. Aber glaube, bei mir ist das hartnäckiger. Hatte nach napp-it sicher 20 Minuten gewartet. Starte immer alles händisch.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Also, das war leider nicht die Lösung. Habe jetzt neu gestartet, napp-it gestartet und 5 Minuten gewartet. VMs waren immer noch nicht verfügbar. Dann napp-it neu gestartet und nochmal 5 Minuten gewartet. VMs nach wie vor nicht da, Datastores lassen sich nicht durchsuchen. Einen NFS Share gelöscht und neu angelegt, 1 Minute später waren die VMs da.

Ist halt auch immer ein bisschen blöd, da den richtigen Zeitpunkt zu finden. Werfe nicht gerne meine Pilotenbuddys raus für solche Experimente.
 
  • Danke
Reaktionen: gea
Ich suche eigentlich drei SSDs für ein ZFS Raid-Z1. Dort sollen TrueNAS Apps/VMs und Daten (Fotos, Dokumente, ...) abgelegt werden, Last gering. Ich dachte erst an die WD Red SN700 1TB für 86€, habe dann aber gesehen, dass es die Kioxia Exceria Plus G3 2TB derzeit schon für 106€ gibt. Davon würden mir dann auch ggf. zwei als ZFS Mirror reichen. Was ist von der Kioxia für den Zweck zu halten?
 
@Techlogi
Da Kioxia (ehemals Thoshiba) seinen Flash selbst entwickelt und produziert sehe ich kein Problem.
Ich würde die 2TB SSD nehmen.

Info am Rande:
Die von dir verlinkte WD SSD nutzt auch Kioxia Flash.


Kioxia SSD:
Bildschirmfoto_20250318_201151.png

WD SSD:
Bildschirmfoto_20250318_201141.png
 
Kein Plan, hab nie eine Kioxia Exceria gehabt.
Is son mittelprächtiges Produkt, als System-Drive dann lieber 25€ mehr zahlen für "was ordentliches" (Renegade, KC3000, evtl. SN850X, evtl 990pro, wobei schon teurer... je nach Angebot).
Dürfte halt DRAM-less sein, aber is ja nicht weiter schlimm, denk ich.


Sieht mir aber am Papier ganz in Ordnung aus, und dank des guten P/L dürfte sie außerhalb des Luxx häufig verbaut werden (siehe gh Bewertungen)...
Wenns eine gewisse Redundanz gibt, seh ich kein Problem...

Lieber sowas als 2tb als ne 1tb WD red...
Hab btw. eine 1tb WD red hier, die mir mal in pool degradet hat, habs aber noch nicht eingeschickt bzw. genauer geprüft... die SSD Prüfung des MC12LE0 im Bios hat sie 1x fehlerhaft und 3x gut getestet, kA obs vllt. nur schlecht gesockelt war.
Würd ne KC3000 oder Fury Renegade der WD red vorziehen, haben auch beide gut TBW.

tl,dr: Kannst kaufen, denk ich.
 
Hallo zusammen,
Ich habe folgende eigenartige Situation. Mein ESXi mit der Napp-It-VM und weiteren VMs musste kürzlich geplant wegen Arbeiten an der Stromversorgung des Hauses heruntergefahren werden. Ich hab zwar eine USV, aber da ich nicht wusste, wie lange die Arbeiten dauern, habe ich alles geordnet heruntergefahren. Oder wollte es zumindest. Zuerst die anderen VMs, dann Napp-It, dann ESXi. Napp-It hatte „gemuckt“, sodass ich die VM irgendwann hart abschalten musste (da waren dann schon viele Services herunter gefahren).
Nachdem die Arbeiten erledigt waren, alles wieder hoch gefahren. Bei Napp-It auch keine Anzeichen von Problemen. Auf einer zweiten VM läuft ein Docker mit dem einen oder anderen Service drauf. Einer davon ist Paperless-ngx, das zwar noch in der Pilotphase bei mir ist, aber schon ganz gut lief und schon einige eingescannte Dokumente verarbeitet hat. Genau dieser Service macht mir nun Probleme, deren Ursache möglicherweise in meinem Fileserver (Napp-It) liegen könnte. Die Volumes für Dokumente, MariaDB usw. sollten wohl auf einem NFS-Share liegen, die vom Fileserver bereitgestellt werden. Da sollte auch die docker-compose.yml liegen - zumindest soweit ich das aus meiner Erinnerung und der Bash History rekonstruieren kann. Nur: Auf dem NFS-Share sind bis auf drei angelegte Verzeichnisse keine weiteren Dateien zu finden, weshalb die Docker-Container für Paperless-ngx nicht starten.

Bis vor dem geplanten Shutdown funktionierte noch alles. Ich frage mich nun, ob es ein Szenario geben könnte, welches das NFS Share derart „korrumpiert“ hat, dass sämtliche Files auf dem Share bis auf die drei Verzeichnisse hat verschwinden lassen. Aktiv gelöscht wurde zumindest von mir nix. Natürlich war für dieses noch recht neue NFS-Share bzw. ZFS-Filesystem noch keine automatischen Snapshots eingerichtet und auch manuell wurde hier noch nix gesichert, sodass ich nicht einfach aus dem Backup zurück sichern könnte… (ja, ja, selbst schuld, wenn man sich nicht als erstes ums Backup kümmert, habt Ihr recht…).

Danke vorab für Eure Rückmeldungen.
 
Es gibt keinen nachvollziehbaren Grund dafür dass Daten auf einem ZFS Dateisystem "einfach so" verschwinden. Ohne sync write kann es lediglich passieren dass ein paar Sekunden bestätigte Schreibaktionen verloren gehen, das wars aber schon.

Ansonst gäbe es nur Bootenvironments auf rpool. Das sind bootfähige Snaps bei denen man in einen älteren Systemstand booten kann. Mit System snappoints könnte man einen früheren Stand erhalten. Das erfordert aber ein pool import auf den snappoint.

Ansonst gäbe es rollback aber das passiert auch nicht von allein und es erfordert snaps.
ZFS Aktionen kann man aber mit Pool > History nachvollziehen.

ESXi könnte auch einen Rollback auf ESXi snaps machen, vielleicht mal per ssh oder smb nachschauen was tatsächlich auf dem Dateisystem liegt.
 
und falls in älteren Ständen am Fileserver nicht zu finden sein sollte => prüfe noch ob die Dateien nicht doch lokal liegen. Womöglich war der Mountpoint nicht aktiv und die Files liegen "lokal" in deiner Docker VM.
 
Danke für Eure Rückmeldungen! Mir kommt das Ganze ja auch spanisch vor und dass bis auf ein paar Verzeichnisse quasi alles in dem Filesystem verschwunden sein soll, da erscheint mir schon sehr fragwürdig… Die Pool History zeigt bis auf monatliches Srcubbing keine Besonderheiten. BE Snaps gibt‘s nur von OmniOS Updates, da ist auch nix zu holen.

Die docker-compose.yml habe ich tatsächlich zuerst lokal gesucht, ohne Erfolg. Die Paperless Installation hatte ich nach einer Anleitung von Heise vorgenommen und meine Bash History scheint das auch so zu bestätigen, dass ich die docker-compose.yml in dem NFS Share angelegt und von dort den Container gestartet habe. In der Verzeichnisstruktur liegen u.a. Verzeichnisse für die MariaDB Dateien, die zur Paperless Installation gehören - all das liegt aber nicht (mehr?) auf dem NFS Share. Nun ja, ein ganzer Stapel PDFs von vor der Paperless Intallation hatte ich glücklicherweise gesichert und was hinterher gescannt wurde, kann man mit etwas Aufwand wieder Scannen - ordentlichem Dokumentenscanner sei Dank.

Was mich halt total kirre macht ist, dass ich nicht verstehe, wie es zu diesem Verlust kam. Und ohne dieses Verständnis fehlt natürlich das Vertrauen, dass das nicht wieder passiert… Nun ja, Unterschied wird wohl sein, dass ich als erstes automatische Snaps einrichte für das Filesystem, auf dem das NFS Share liegt…

Danke für den Unterstützungsversuch, auch wenn es diesmal nicht zum Ziel geführt hat… Aber ich will aus einem ZFS-Thread nun auch nicht weiter einen Docker/Paperless Thread machen. ;-)
 
Guten Morgen,

das ist jetzt vielleicht nicht direkt ZFS, sondern schon eher eine OmniOS Spezialität, aber da @gea hier liest, addressiert das hoffentlich genau den richtigen :-)

Also ich habe folgende Konstellation: Active Directory mit Windows Server 2025 FileServer mit Shares auf denen recht viel mit ACLs gearbeitet wird.
Ich möchte jetzt Altdaten archivieren und weil ich keinen 2ten Windows Server nutzen will, soll es OmniOS sein, weil
* ACLs von NTFS-like
* ZFS Snapshots als Vorgängerversionen
* keine weiteren Windows Lizenzkosten

Jetzt stehe ich vor folgendem Problem: ich kann die ACLs nicht übernehmen. Und mir ist nicht richtig klar warum.

Ablauf:
OmniOS installieren + Napp-it installieren (IP:172.23.1.249)
ZFS Pools (data) und Shares (archive) anlegen
lokalen napp-it User "transfer" anlegen, User transfer@domain.local anlegen
User transfer@domain.local auf die Dateien berechtigen mit Vollzugriff
mapping transfer@domain.local --> user:transfer
Map user/group =/=> to user/group
wingroup:Power Users@BUILTIN => unixgroup:staff
winuser:transfer@domain.local => unixuser:user:transfer

ACL auf Share:
0user:transferrwxpdDaARWcCosfull_setrd(acl,att,xatt) wr(acl,att,xatt,own) del(yes,child) x, s

ACL auf Folder
0user:rootrwxpdDaARWcCosfull_setrd(acl,att,xatt) wr(acl,att,xatt,own) add(fi,sdir) del(yes,child) x, sfile,dirallowdelete
1user:transferrwxpdDaARWcCosfull_setrd(acl,att,xatt) wr(acl,att,xatt,own) add(fi,sdir) del(yes,child) x, sfile,dirallowdelete
Und dann als transfer@domain.local auf dem Fileserver angemeldet und ein beherztes
Code: 
robocopy "F:\Shares\Bilder" "\\172.23.1.249\archive\Bilder" /E /COPYALL /DCOPY:T /MT:4 /R:2 /W:2

führt aber zu folgendem:
Code: 
Neue Datei            107373        F:\Shares\Bilder\20190202_111344.jpg
2025/03/27 09:53:49 FEHLER 1314 (0x00000522) NTFS-Sicherheit wird in Zieldatei kopiert F:\Shares\Bilder\20190202_111344.jpg
Dem Client fehlt ein erforderliches Recht.

Irgendwas hab ich übersehen, aber was?
 
Drei Anmerkungen

1. Der Solaris/ Illumos/ OmniOS SMB Server speichert die Windows SID für SMB direkt als erweitertes ZFS Attribut und verhält sich damit wie ein echtes Windows ntfs System. Man kann also einen Pool importieren oder ein ZFS Dateisystem replizieren ohne dass die SMB ACL verloren gehen. Das bescheuerte ID Mapping um eine Unix uid auf eine Windows SID zu mappen das man unter Linux/SAMBA braucht, entfällt für OmniOS SMB komplett. Man hat Windows SMB Gruppen (Gruppen in Gruppen) und echte ntfs artige ACL statt den simplen Posix ACL unter Linux.

Das einzige Mapping das ich unter OmniOS/Solaris üblicherweise anlege ist
winuser:ich (administrator) -> unixuser:root damit ich immer root Rechte auf OmniOS habe

Sonstige mappings braucht man nur um ssh/nfs/lokale Dateioperationen rechtemäßig mit SMB zu koordinieren.

2. Damit die ACL mit robocopy übertragen werden können, muss man root Rechte haben, also als SMB user root starten (oder user mit mapping auf root). Eventuell den /B Parameter bei robocopy probieren. Sharerechte (everyone@=full) kann man auf default lassen.

3. Am einfachsten/schnellsten mit ZFS Replikation Dateisysteme sichern/wiederherstellen. SMB ACL bleiben bei OmniOS intakt.
Für AD user muss OmniOS AD member sein, genau wie die Windows Clients.
 
Zuletzt bearbeitet:
Hi Gea und danke für die Antwort. Das mit den ACLs als ZFS Attribute ist ja genau der Grund warum ich das so machen will, von daher fällt z.B. OpenZFS auf Linux ja aus.

Das mit dem Mapping hatte ich irgendwann mal so mit aufgeschnappt, gut zu wissen, dass ich das nicht brauche. Ich entferne das Mapping transfer@domain.local -> transfer

Was wäre denn jetzt best practice?
a) ich verbinde mich so
Code: 
net use \\172.23.1.249\archive Passwort /user:root
als root mit dem Share und starte robocopy als Transfer@domain.local (da der ja Vollzugriff auf die ACLs windows Seitig hat)?

b) Mapping von transfer@domain.local -> user:root
und dann robocopy als transfer@domain.local?

Zu 3) Das steht am Ende ja dann zur Wegsicherung an (ich find da zrep klasse!), aber aktuell ist auf dem OmniOS SHare noch nix drauf was ich wegsichern kann :-)
 
am Einfachsten
lokalen adminuser auf OmniOS root mappen, dann als dieser user an Windows und root an OmniOS anmelden.
Wenn transfer@domain in der AD admin gruppe ist und man als transfer an Windows angemeldet ist geht das auch nach mapping -> unix:root
Zum ACL lesen/schreiben braucht man halt auf Windows und Unix full permissions.

ps
napp-it kann direkt in der web-gui übers Netz replizieren (jobs > replicate)
ZFS unter Windows ist hoffentlich auch bald released.
 
Zuletzt bearbeitet:
Irgendwie klappt das nicht, ich hoffe mal, ich hab das ganze System einfach nur verkonfiguriert...

Also nochmal von Anfang an
1) AD Computerkonto OmniOS gelöscht
2) OmniOS neu installiert + Updates + Nappit
3) snapshot gemacht :ROFLMAO:
4) Pool erzeugt
5) ZFS Filesystem erzeugt (smb share on, guest off, case insensitive, atime off, nbmand on, ashift 12)
6) Domain Join
7) Mapping (keine weiteren ACLs, weder Share/Folder angefasst, alles default)
Map user/group=/=>to user/group
winuser:transfer@domain.local=unixuser:root
8) am Fileserver als transfer@domain.local anmelden
9) CMD Rechtsklick -> als Administrator starten, UAC bestätigen
10)
Code: 
robocopy "F:\Shares\Bilder" "\\172.23.1.249\archive\Bilder" /E /COPYALL /DCOPY:T /MT:4 /R:2 /W:2

Aber er scheitert direkt beim Anlegen des Verzeichnisses "Bilder"
Code: 
2025/03/28 09:53:49 FEHLER 1314 (0x00000522) NTFS-Sicherheit wird in Zielverzeichnis kopiert\\172.23.1.249\archive\Bilder
Dem Client fehlt ein erforderliches Recht.


EDIT: jetzt hab ich es. Ich hab dem Share unter Windows -> Anmeldeinformationsverwaltung unter generische ANmeldeinformationen einfach die Root Zugangsdaten gegeben und robocopy läuft mit ACLs los. Sehr cool!
 
Zuletzt bearbeitet:
Ich habe aktuell das Problem, das mein Backup-NAS bei der Replication komplett abstürzt.
Es wird das Pull Verfahren genutzt.

Da ich durch Hardwaretausch und Softwareneuinstallation das Problem nicht beheben konnte, habe ich mich erneut durch die Logs gewühlt.

Dabei ist mir aufgefallen, dass das System immer crasht, wenn es alte Snapshots löschen soll, z.B.:
Code: 
[2025/03/28 17:48:27] INFO     [retention] [zettarepl.zettarepl] Retention destroying local snapshots: [('bpool1/App_Data/Nextcloud', 'auto-2023-11-01_00-00'), ('bpool1/App_Data/Nextcloud', 'auto-2023-12-01_00-00'), ('bpool1/App_Data/Nextcloud', 'auto-2024-01-01_00-00'), ('bpool1/App_Data/Nextcloud', 'auto-2024-02>
[2025/03/28 17:48:27] INFO     [retention] [zettarepl.snapshot.destroy] On <Shell(<LocalTransport()>)> for dataset 'bpool1/App_Data/Nextcloud' destroying snapshots {'auto-2024-10-21_00-00', 'auto-2024-08-12_00-00', 'auto-2023-12-01_00-00', 'auto-2024-10-11_00-00', 'auto-2024-09-20_00-00', 'auto-2024-08-06_00-00', >

Egal welches Dataset repliziert werden soll.

Kennt jemand das Problem?

Edit:
Wenn ich die von Hand lösche, dann schmiert das System auch ab!
Code: 
sudo zfs destroy -r bpool1/App_Data/Nextcloud@auto-2023-11-01_00-00
 
Zuletzt bearbeitet:
ludwinator schrieb:
was liefert denn zfs list -t snapshot |wc -l bei dem system ?
Zum Vergrößern anklicken....
da kommt als Ausgabe "1437"



Edit:
Hier mal die Ausgabe von zpool status:
Code: 
pool: bpool1
 state: ONLINE
status: Some supported and requested features are not enabled on the pool.
        The pool can still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(7) for details.
  scan: scrub repaired 0B in 02:24:52 with 0 errors on Mon Mar 24 20:37:02 2025
config:

        NAME                                      STATE     READ WRITE CKSUM
        bpool1                                    ONLINE       0     0     0
          mirror-0                                ONLINE       0     0     0
            9bcd6226-e816-42ea-afa5-63b15bc20110  ONLINE       0     0     0
            2021ce9b-ff76-4b5c-a0ad-f20d6a6ed085  ONLINE       0     0     0

errors: No known data errors
 
Zuletzt bearbeitet:
Der Rechner stürzt ab und startet neu, da bringt warten nichts :(

Auch ohne -r
Code: 
sudo zfs destroy -v bpool1/App_Data/Nextcloud@auto-2023-11-01_00-00
will destroy bpool1/App_Data/Nextcloud@auto-2023-11-01_00-00
will reclaim 454M

und dann crasht er direkt
 
So,
nach etwas mehr Suche habe ich gesehen das es bei openzfs schon seit November 24 ein Issue dafür gibt.
Leider ist da noch nichts gefixed worden bzw. ist das noch nichtmal in Bearbeitung.
 
Ach ja, openzfs ... welche version genau?
betrifft das nur bpool1/App_Data/Nextcloud ?
wenn ja würde ich versuchen, die Daten per zfs send/receive mal zu retten und das ganze share bpool1/App_Data/Nextcloud zu löschen und zurückzusichern
 
Anmelden, um zu antworten.

Ähnliche Themen

G
Wieviel ZFS steckt in Qnap ZFS ??
Antworten
5
Aufrufe
1K
gea
G
Shihatsu
ZFS Pool "verschicken"
Antworten
9
Aufrufe
769
sandreas
S
AG1M
[Kaufberatung] Neuer ZFS Homeserver
Antworten
20
Aufrufe
2K
AG1M
AG1M
E
Unraid ZFS Server 24/7 + Kaufberatung
Antworten
16
Aufrufe
690
Haldi
Haldi
thor17
Ceph Node auf bestehenden ZFS Pools
Antworten
3
Aufrufe
714
gea
G
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh