[Sammelthread] ZFS Stammtisch

[Trambahner]

Mit SMB3 , nem Windows 10-Client und mit Samba auf ZFS @ FreeBSD 11.x (sprich: da läuft eine 11er Version von Xigmanas) funktioniert "serverside copy" bei mir.
( NFS hab ich mit Clients nicht getestet, NFS dient bei mir nur innerhalb des ESXI AIO für die Datastores )

 

[Hürbine]

Danke für Eure Antworten. Ich werde es einfach einmal testen.

 

[Satrap]

Moin zusammen,

keine Ahnung ob meine Frage hier richtig platziert ist, aber ich versuche es Mal.
Ich überlege derzeit eine Festplatte einzurichten damit die möglichst "Cross-Plattförmig" genutzt werden kann. Also auf macOS, Linux und Windows und ggfs. auch verschlüsselt werden kann.
Ist ZFS dafür eine gute Wahl? Ist ZFS überhaupt eine gute Wahl für eine externe USB3.0 Festplatte?

PS: es geht halt darum von meinen Geräten darauf zuzugreifen. Es ist mir klar, dass ZFS nicht auf jedem X-beliebigem System verfügbar ist.

 

[gea]

Wenn es darum geht, einen (verschlüsselten) ZFS Filer einzurichten auf dem man z.B. per FC/iSCSI, NFS, SMB, SSH oder S3 zugreift, dann ist ZFS die perfekte Wahl.

Wenn es darum geht eine ZFS formatierte USB Festplatte an einem anderen Rechner/OS anzuschließen, dann ist ZFS als Dateisystem eher eine schlechte Wahl da ZFS nur bei Solarish das Default Dateisystem ist und man sonst immer erst ZFS installieren muss und auf unterstützte Features oder Partitionierungen achten muss. Bei OSX und vor allem Windows ist ZFS eh Beta und nicht stabil einsetzbar. FAT32 wäre da als Austauschplatte geeigneter (hat halt keines der ZFS Sicherheitsfeatures wie Copy on Write/Snaps oder Prüfsummen)

USB Platten haben an einem Server eher nichts zu suchen, idealerweise 2x12G SAS oder normales 6G Sata nehmen.

 

[Satrap]

Danke für die schnelle Antwort

Wenn es darum geht eine ZFS formatierte USB Festplatte an einem anderen Rechner/OS anzuschließen, dann ist ZFS als Dateisystem eher eine schlechte Wahl da ZFS nur bei Solarish das Default Dateisystem ist und man sonst immer erst ZFS installieren muss und auf unterstützte Features oder Partitionierungen achten muss. Bei OSX und vor allem Windows ist ZFS eh Beta und nicht stabil einsetzbar. FAT32 wäre da als Austauschplatte geeigneter (hat halt keines der ZFS Sicherheitsfeatures wie Copy on Write/Snaps oder Prüfsummen)

Ja genau darum geht es. Wobei ich die Platte nur auf meinem Rechnern einsetzen möchte. D.h., da könnte ich mir einmalig die Mühe machen ZFS zu installieren. An ZFS habe ich gedacht, da ich mir die Funktion unter allen Systemen erhofft habe + die Verschlüsselung. Meine erste Wahl wäre APFS, aber bei der APFS können Linux / Windows mit der T2 Verschlüsslung von Apple nicht umgehen.

 

[gea]

Ich wüßte nicht dass Linux stabil (beta?) APFS nutzen können, egal ob verschlüsselt oder nicht. Bei Windows gibt es Paragon, k.A. wie stabil das ist.
Wieso muss die Platte mobil sein und kein Zugriff übers Netz?

 

[Satrap]

Ich wüßte nicht dass Linux stabil (beta?) APFS nutzen können, egal ob verschlüsselt oder nicht. Bei Windows gibt es Paragon, k.A. wie stabil das ist.
Wieso muss die Platte mobil sein und kein Zugriff übers Netz?

Für Linux gibt es auch "APFS for LInux" von Paragon (hab's auch erst heute erfahren), jedoch ohne Verschlusslesung. Freie APFS Treiber für Linux sind Beta und Schreibzugriff wird nicht empfohlen.

Mobil muss die Platte sein, weil ich keinen Rechner oder Server habe, der 24/7 läuft. Dazu kommt, dass ich nur WLAN habe und da wäre alles etwas langsamer.

 

[Digi-Quick]

1. Du brauchst ein Dateisystem, welches auf allen Plattformen vollständig unterstützt wird : dies dürfte derzeit nur FAT32 oder evtl exFAT sein.
2. Du brauchst eine Verschlüsselung, die auf allen Plattformen vollständig unterstützt wird : ?????
- "Bitlocke" ist es wohl eher nicht.
- Archivverschlüsselung via RAR oder ZIP dürfte nutzbar sein

 

[asche77]

Oder boxcryptor/veracrypt/...

 

[Shihatsu]

Jupp, exFAT mit veracrypt geht auf allen 3 Systemen.

 

[CommanderBond]

Zum automatischen unlock verschlüsselter Dateisysteme in napp-it beim Booten:
Die Sortierung ist egal, ein Grund für das Problem sehe ich aber nicht.

Was passiert wenn man als Root folgendes aufruft
perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/agents/agent-bootunlock.pl

also wenn ich das ausführe unlockt er das nächste dateisystem. jeder erneute aufruf unlockt ein weiteres dateisystem. es scheint dass er jedesmal hängen bleibt wenn er ein dateisystem entsperrt hat.

habe für alle dateisysteme unterschiedliche passwörter sie sind aber alle auf dem server gespeichert und übers webinterface ist ein unlock ohne eingabe des passworts möglich

 

[gea]

Ich habe bootunlock geändert um mehr Informationen zu erhalten.
Bitte beiliegendes Script nutzen oder auf 22.dev von heute updaten Und dann nochmal die Ausgabe posten

perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/agents/agent-bootunlock.pl

 

[CommanderBond]

@gea
Hier das Ergebnis
Dass das Dateisystem „vm“ nicht entschlüsselt werden kann ist schon okay, ich glaube dieser Schlüssel ist nicht auf dem Server gespeichert.

Last login: Tue Aug 23 02:34:19 2022 from 192.168.1.117
OmniOS r151042  omnios-r151042-73702cd512       August 2022
You have new mail.
root@NAS:~# perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/agents/agent-bootunlock.pl
>list enc filesystems
ssdpool/alte_daten, enc_automount:, yes, local
ssdpool/downloads, enc_automount:, yes, local
ssdpool/user30, enc_automount:, yes, local
ssdpool/user30_backup, enc_automount:, yes, local
ssdpool/user30_file_history_backup, enc_automount:, yes, local
ssdpool/user20, enc_automount:, yes, local
ssdpool/user20_file_history_backup, enc_automount:, yes, local
ssdpool/music, enc_automount:, yes, local
ssdpool/projektspeicher, enc_automount:, yes, local
ssdpool/public, enc_automount:, yes, local
ssdpool/user40, enc_automount:, yes, local
ssdpool/user10, enc_automount:, yes, local
ssdpool/vm, enc_automount:, yes, local


process fs with yeautomount yes: ssdpool/alte_daten  enc_split:            L1:L1                     local
check ssdpool/alte_daten, keysource=passphrase,prompt, split=L1:L1, keystatus=available

process fs with yeautomount yes: ssdpool/downloads  enc_split:            L1:L1                    local
check ssdpool/downloads, keysource=passphrase,prompt, split=L1:L1, keystatus=available

process fs with yeautomount yes: ssdpool/user30  enc_split:            L1:L1                  local
check ssdpool/user30, keysource=passphrase,prompt, split=L1:L1, keystatus=available

process fs with yeautomount yes: ssdpool/user30_backup  enc_split:            L1:L1                         local
check ssdpool/user30_backup, keysource=passphrase,prompt, split=L1:L1, keystatus=unavailable

unlock ssdpool/user30_backup
please wait ...
Split=L1:L1Enter passphrase for 'ssdpool/user30_backup':<br><br>



keystatus: available

process fs with yeautomount yes: ssdpool/user30_file_history_backup  enc_split:            L1:L1                                 local
check ssdpool/user30_file_history_backup, keysource=passphrase,prompt, split=L1:L1, keystatus=unavailable

unlock ssdpool/user30_file_history_backup
please wait ...
Split=L1:L1Enter passphrase for 'ssdpool/user30_file_history_backup':<br><br>



keystatus: available

process fs with yeautomount yes: ssdpool/user20  enc_split:            L1:L1                  local
check ssdpool/user20, keysource=passphrase,prompt, split=L1:L1, keystatus=unavailable

unlock ssdpool/user20
please wait ...
Split=L1:L1Enter passphrase for 'ssdpool/user20':<br><br>



keystatus: available

process fs with yeautomount yes: ssdpool/user20_file_history_backup  enc_split:            L1:L1                              local
check ssdpool/user20_file_history_backup, keysource=passphrase,prompt, split=L1:L1, keystatus=unavailable

unlock ssdpool/user20_file_history_backup
please wait ...
Split=L1:L1Enter passphrase for 'ssdpool/user20_file_history_backup':<br><br>



keystatus: available

process fs with yeautomount yes: ssdpool/music  enc_split:            L1:L1                  local
check ssdpool/music, keysource=passphrase,prompt, split=L1:L1, keystatus=unavailable

unlock ssdpool/music
please wait ...
Split=L1:L1Enter passphrase for 'ssdpool/music':<br><br>



keystatus: available

process fs with yeautomount yes: ssdpool/projektspeicher  enc_split:            L1:L1                     local
check ssdpool/projektspeicher, keysource=passphrase,prompt, split=L1:L1, keystatus=unavailable

unlock ssdpool/projektspeicher
please wait ...
Split=L1:L1Enter passphrase for 'ssdpool/projektspeicher':<br><br>



keystatus: available

process fs with yeautomount yes: ssdpool/public  enc_split:            L1:L1                  local
check ssdpool/public, keysource=passphrase,prompt, split=L1:L1, keystatus=available

process fs with yeautomount yes: ssdpool/user40  enc_split:            L1:L1                  local
check ssdpool/user40, keysource=passphrase,prompt, split=L1:L1, keystatus=unavailable

unlock ssdpool/user40
please wait ...
Split=L1:L1Enter passphrase for 'ssdpool/user40':<br><br>



keystatus: available

process fs with yeautomount yes: ssdpool/user10  enc_split:            L1:L1                  local
check ssdpool/user10, keysource=passphrase,prompt, split=L1:L1, keystatus=unavailable

unlock ssdpool/user10
please wait ...
Split=L1:L1Enter passphrase for 'ssdpool/user10':<br><br>



keystatus: available

process fs with yeautomount yes: ssdpool/vm  enc_split:            L1:L1                  local
check ssdpool/vm, keysource=passphrase,prompt, split=L1:L1, keystatus=unavailable

unlock ssdpool/vm
please wait ...
Split=L1:L1cat: cannot open /rpool/keydata/local/keys-part1/ssdpool~vm.kp1: No such file or directory
mess: Keyfile part 1 on L1: no data<br>/rpool/keydata/local/keys-part1/ssdpool~vm.kp1
mess: Keyfile part 2 on L1: no data<br>/rpool/keydata/local/keys-part2/ssdpool~vm.kp2
mess: invalid or missing key
Enter passphrase for 'ssdpool/vm':<br><br>

Key load error: Passphrase too short (min 8).
cannot mount 'ssdpool/vm': encryption key not loaded
error, wrong key

keystatus: unavailable

smb restore fs? ssdpool/alte_daten sharesmb=name=alte_daten
smb restore fs? ssdpool/downloads sharesmb=name=downloads
smb restore fs? ssdpool/user30 name=user30
smb restore fs? ssdpool/user30_backup sharesmb=name=user30_backup
smb restore fs? ssdpool/user30_file_history_backup name=user30_file_history_backup$
smb restore fs? ssdpool/user20 name=user20
smb restore fs? ssdpool/user20_file_history_backup name=user20_file_history_backup$
smb restore fs? ssdpool/music sharesmb=name=music
smb restore fs? ssdpool/projektspeicher name=projektspeicher
smb restore fs? ssdpool/public sharesmb=name=public
smb restore fs? ssdpool/user40 name=user40
smb restore fs? ssdpool/user10 name=user10
smb restore fs? ssdpool/vm name=vm
ok

root@NAS:~#

 

[gea]

Illumos (OmniOS/OI/Nexenta): NVMe Pools können Probleme beim OS Downgrade machen

Topicbox

Feature #14686: nvme should use namespace GUID for devid if available - illumos gate - illumos

Redmine

www.illumos.org

"If you're not using ZFS on NVMe devices, you can ignore this message.

With the integration of #14686, the nvme driver will start to use new
devid types specifically created for NVMe. Updating to #14686 will be
handled gracefully by ZFS, old pools will import correctly and will have
their vdev labels updated with the new devid types automatically.

After updating to #14686, older illumos versions may fail to import the
ZFS pools as they may get confused by the new (unknown) devid types. To
handle this, #14745 has been integrated in illumos on June 24th,
allowing ZFS to import pools on vdevs with unknown or invalid devids.

In order to be able to import your ZFS pools on an older illumos version
before #14686, such as when booting any earlier boot environment from
before #14686, you must use an illumos version that already has #14745
but not yet #14686, resetting the devids to the older types when
importing the pools. After that you can go back even further before
#14745.

The illumos distribution maintainers have been informed about this issue
and should have backported #14745 to any releases they support. Please
consult your distributions release notes for more information."

Beitrag automatisch zusammengeführt: 24.08.2022

@gea
Hier das Ergebnis
Dass das Dateisystem „vm“ nicht entschlüsselt werden kann ist schon okay, ich glaube dieser Schlüssel ist nicht auf dem Server gespeichert.

Dann sollte enc_split: auf prompt oder none stehen und nicht auf L1:L1 (Key gesplittet auf Platte gespeichert) und automount=no ((Menü ZFS Dateisysteme > Encryption)
zfs set enc_split:=prompt ssdpool/vm

 

[CommanderBond]

Ok aber ich nehme an das war nicht der Grund wieso er nur der erste FS entschlüsselt hat immer? Auch nach einem reboot scheint es nun zu funktionieren alle Dateisysteme bis auf vm sind entschlüsselt

 

[gea]

Ich habe nichts am Ablauf geändert - es wird jetzt nur mehr Information angezeigt.
Wenn es jetzt geht, dann wars aber wohl das vm Dateisystem bei dem der Key nicht gespeichert war das für den Abbruch verantwortlich war.

 

[eehm]

Ich hätte mal eine Frage bezüglich euerer Erfahrungswerte.
Kann ich eine ZFS-Mirror auch mit mehr als 80% an Daten füllen, wenn Daten nur hinzukommen und keine gelöscht werden und die Geschwindigkeit eine sehr untergeordnete Rolle spielt?
Falls ja, ist die Grenze dann aus euerer Erfahrung bei 90% oder gar erst 95% erreicht bevor mir am Ende der Pool abschmiert?

 

[gea]

Der Pool wird nicht "abschmieren" sondern nur volllaufen und nichts mehr annehmen.

ZFS hat eine kleine interne Reservierung um das trotz Copy on Write zu verkraften. Da die Fragmentierung mit dem Füllgrad zunimmt, sinkt aber die Schreib/Leseperformance erheblich.

Das ist der Grund, Füllraten > 80% zu vermeiden. In napp-it setze ich daher eine 10% Pool Reservierung um Füllraten > 90% zu vermeiden, Kann man bei Bedarf löschen.

 

[eehm]

Der Pool wird nicht "abschmieren" sondern nur volllaufen.

Noch eine kurze Frage, wenn man von folgenden Szenario ausgeht.

Pool zu 100% gefüllt (jedenfalls was das NAS System freigibt).
Jetzt macht man noch einen Snapshot. Zerlegt das dann den Pool auch nicht, weil dieser Snapshot auch in der "kleinen internen Reservierung" seinen Platz findet?

 

[gea]

Ein ZFS Snapshot schreibt praktisch keine Daten.
Wenn ZFS einen Datenblock z.B 128k schreibt, wird der immer neu angelegt (Copy on Write). Es werden grundsätzlich bei ZFS keine alten Daten überschreiben. Der ZFS Datenblock mit den älteren Daten wird nach erfolgreichem Schreiben freigegeben, sonst bleibt der alte gültig. Damit bleibt ZFS auch bei einem Absturz beim Schreiben immer valide.

Ein ZFS Snapshot sorgt nur dafür dass alte Datenblöcke nicht freigegeben sondern gesperrt werden.

 

[Shihatsu]

So, Verständnisfrage, die vielleicht eher in ein TrueNAS thread gehört - hatten wir da nicht mal einen Sammelthread? Wie dem auch sei:
TrueNAS, ZFS, externe HDD, via Replication Task habe ich den Inhalt eines Pools auf einen anderen Pool repliziert. Darauf hin HDD ab, in den Schrank gepackt, jetzt ists mal wieder Zeit für ein neues Backup. Ich hab den Task ausgeführt und TrueNAS hat den auch brav ausgeführt. JEdoch, o weh: Laut TruaNAS sind auf dem Datapool 1GB mehr Daten als auf dem Backuppool - Anzeigefehler, Dummheit oder sonstwas?

 

[besterino]

Evtl. Zwischensnapshots?

 

[asche77]

Oder Hauptpool Kompression oder dedup, während der backup pool das nicht hat? Andere recordsizes?

 

[Shihatsu]

Evtl. Zwischensnapshots?

Das ist auch meine Vermutung, aber wie gewöhne ich ihm das ab, wie erkenne ich es? Sicherlich Layer 8 Problem...

Oder Hauptpool Kompression oder dedup, während der backup pool das nicht hat? Andere recordsizes?

Compression level ist bei beiden "default" aka LZ4, ZFS Deduplication ist bei beiden Pools off. Record Sizes sind bei beiden ebenfalls "default" - 128k - ich versuche solche Sachen immer auf default zu lassen.

Ich möchte folgendes erreichen: Alle 6 -8 wochen den Inhalt von Pool A auf Pool B spiegeln. Das ganze so effizient wie möglich, aber eben nur den aktuellen Stand der Daten - ich brauche auf diesem Backup-Medium keine Snapshots.

 

[gea]

Ich möchte folgendes erreichen: Alle 6 -8 wochen den Inhalt von Pool A auf Pool B spiegeln. Das ganze so effizient wie möglich, aber eben nur den aktuellen Stand der Daten - ich brauche auf diesem Backup-Medium keine Snapshots.

Inkrementelle Backups (-i) benötigen zumindest den letzten Stand als identischen Snapshotpaar auf Quelle und Ziel, da das Zieldateisystem vor der nächsten Replikation ein Rollback auf diesen Stand machen muss. Ich behalte in napp-it zusätzlich immer noch einen weiteres gemeinsames Snappaar um bei Problemen der letzten Replikation dieses zu nutzen. Da Snapshots nur soviel Platz belegen wie Daten geändert wurden, belegen weitere Snapshots auf dem Backup relativ wenig Platz. Ich halte da meist noch z.B. einen täglichen Snapshot der aktuellen Woche/Monat oder einen monatlichen im aktuellen Jahr. Macht man Replikationen mit -I als Parameter, werden Zwischensnaps mit übertragen, mit -r (rekursiv) alle Datasets (Dateisysteme, Snaps, Zvols)

Fehlt dieses gemeinsame Snappaar kann man keine weitere inkrementelle Replikation machen sondern muss erneut eine volle Erstreplikation durchführen.

 

[Shihatsu]

Inkrementelle Backups (-i) benötigen zumindest den letzten Stand als identischen Snapshotpaar auf Quelle und Ziel, da das Zieldateisystem vor der nächsten Replikation ein Rollback auf diesen Stand machen muss. Ich behalte in napp-it zusätzlich immer noch einen weiteres gemeinsames Snappaar um bei Problemen der letzten Replikation dieses zu nutzen. Da Snapshots nur soviel Platz belegen wie Daten geändert wurden, belegen weitere Snapshots auf dem Backup relativ wenig Platz. Ich halte da meist noch z.B. einen täglichen Snapshot der aktuellen Woche/Monat oder einen monatlichen im aktuellen Jahr. Macht man Replikationen mit -I als Parameter, werden Zwischensnaps mit übertragen, mit -r (rekursiv) alle Datasets (Dateisysteme, Snaps, Zvols)

Fehlt dieses gemeinsame Snappaar kann man keine weitere inkrementelle Replikation machen sondern muss erneut eine volle Erstreplikation durchführen.

Ich verwende kein Napp-it, sondern TrueNAS, wie geschrieben. Daher fällt es mir schwer das zu "übersetzen" auf meinen Anwendungsfall. Ich versuchs trotzdem mal.
In TrueNAS sieeht mein task folgendermaßen aus:

Ich mache also ein rekursives Backup (-r). Ob das nun inkrementell an der Stelle ist steht da interessanterweise nirgends, aber ich gehe mal davon aus (?). Wie ich da -l reinkriege verstehe ich auch nicht ganz. Insofern hilft mir das leider nur wenig weiter, da ich wie gesagt kein Napp-it verwende und schon gerne die eingebauten Features von TrueNAS verwenden will...

 

[gea]

Die Distribution ist egal da es sich um zfs send Parameter handelt. Den Sonderfall zfs send -I scheint man nicht anwählen zu können, recursiv kopiert aber eh alle datasets. (Eventuell aktiviert "Syncronize Destination Snapshots zfs send -I)

Zu zfs send (Basis der Replikation - ob und welche Parameter unterstützt werden hängt vom Replikationstool ab. In letzter Konsequenz dreht es sich immer darum in der Gui die ZFS sedn Befehle abzubilden.

Senden und Empfangen von ZFS-Daten - Oracle Solaris ZFS-Administrationshandbuch

Dieses Handbuch richtet sich an alle Personen, die für die Einrichtung und Verwaltung von ZFS-Dateisystemen von Oracle zuständig sind. Sofern zutreffend, werden Themen für SPARC- und x86-basierte Systeme behandelt.

docs.oracle.com

 

[Shihatsu]

Okay, dann aber zurück zu meiner Frage - kann die mir jemand beantworten? Wie kriege ich das hier hin:
Ich möchte folgendes erreichen: Alle 6 -8 wochen den Inhalt von Pool A auf Pool B spiegeln. Das ganze so effizient wie möglich, aber eben nur den aktuellen Stand der Daten - ich brauche auf diesem Backup-Medium keine Snapshots.

 

[mrpasc]

Klassisch rsync?

 

[Gen8 Runner]

Okay, dann aber zurück zu meiner Frage - kann die mir jemand beantworten? Wie kriege ich das hier hin:
Ich möchte folgendes erreichen: Alle 6 -8 wochen den Inhalt von Pool A auf Pool B spiegeln. Das ganze so effizient wie möglich, aber eben nur den aktuellen Stand der Daten - ich brauche auf diesem Backup-Medium keine Snapshots.

Rsync oder einfach doch replication.
Warum? Am Anfang wird natürlich erstmal ein riesiger Haufen an Daten übertragen. Danach allerdings nur noch die Änderungen, in Form von Snapshots. D.h. nicht mehr 1:1, alles vom ersten bis zum letzten Bit, sondern nur die Änderungen.