[Sammelthread] ZFS Stammtisch

Ich habe FreeNAS mit zfs im Einsatz. Als Clients nur Windows. Ich bekomme beim Dateien kopieren oft eine Meldung, das irgendwelche Eigenschaften nicht übernommen werden können. Was hat das zu bedeuten? Welche Eigenschaften sind das und warum werden die nicht übernommen? Kann zfs das nicht oder woran liegt das? Kann man das ggf konfigurieren? Hier geht es hauptsächlich um mp3 und jpg Dateien.

gesendet von meinem Samsung Galaxy Note 4
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Von den Dateieigenschaften her, benutzt Windows für die Zuordnung der User und Gruppen eine Windows Security ID (SID) in der auch die Domäne oder eine Serverkennung enthalten ist. Als Dateiystem kommt NTFS zum Einsatz das zu diesen SID Rechte in Form von Windows ACLs verwaltet. Die können sehr fein eingestellt werden. Neben Rechten auf Dateien und Ordnern gibt es Rechte die von darüberliegenden Ordnern vererbt werden. Gruppen können Gruppen und User enthalten. Das ist momentan State of the Art.

ZFS ist ein Solaris/Unix Dateisystem. Unter Unix werden User und Gruppen über eine User und Group -ID (uid/gid) verwaltet. Das ist eine einfache Zahl ohne Referenz zum Server. Auch können Gruppen keine Gruppen enthalten und es gibt keine Vererbung von Rechten. Sun hat deshalb einen eigenen SMB Server entwickelt, der Windows SID als Referenz nutzt und Windows kompatible ACLs mit Vererbung kann. Bei einem Kopiervorgang können damit Windows ACLs mit der Einschränkung übertragen werden, dass Deny Regeln und der Owner anders gehandhabt werden. Windows SMB Gruppen bleiben erhalten da Solaris neben den Unix Gruppen auch Windows Gruppen kennt.

Nutzt man dagegen SAMBA (unter Solaris eine Option, unter BSD/ Linux die alleinige Möglichkeit, OSX nutzt zwar kein SAMBA verhält sich aber wie Unix) dann gehen die SID verloren und werden auf eine UID gemappt. Auch können die ACL und die Rechte Vererbung nicht übertragen werden. Zudem ist die Unix Gruppenverwaltung nicht Windows Kompatibel.

Das ist wohl hier das Problem.
 
OK, Dann hat das also was mit dem Berechtigungen zu tun und nichts mit den Eigenschaften der jpg Dateien, z. B. Erstellungsdatum, usw. Die Rechte spielen in meiner Umgebung eine untergeordnete Rolle. Mir sind eher mp3 Tags, Die exif Daten und sowas wichtig.

gesendet von meinem Samsung Galaxy Note 4
 
Ja, bitte den Ordner mit den Backups in p_arche/backup_appliance umbenennen.
Das Restore Menü blendet hier eine alte Vorgabe ein.

netbios_enable=true sorgt dafür, dass der Server in Windows unter Netzwerkumgebung erscheint

Umbenennen hat geklappt. Super.
Alles auf "YES" setzen, ausser ID user mappings, weil hier workgroup und keine Domain??
 
Danke für den erneuten Hinweis.

Was ich wissen wollte ist, ob ich bei ID user mapping auf YES setzen muss, wenn hier keine Domain, sondern eine Workgroup läuft?
 
Ist eigentlich egal.
Wenn keine ID-Mappings gesetzt sind, so bleibt das nach Backup > Restore genauso.

Ansonsten sind User ID-Mappings natürlich ausschliesslich bei Domänen sinnvoll,
Mappings von SMB-Gruppen auf Unix-Gruppen könnten aber eventuell auch bei Workgroups vorkommen.
 
Super hat fast geklappt.
Zuerst hatte ich diese Fehlermeldung:
-- delete current group failed to initialize: failed to initialize (cannot get the machine SID)
Nachdem ich bei einem FS SMB aktiviert hatte, war auch eine SID da.

Nur ich bin nicht mehr in der SMD-group "Administrators" und beim händischen Einfügen kommt folgende Meldung:
please wait.. layerbreak: name lookup failed
Und ich werde nicht admin
 
Vielleicht fehlt lediglich das SMB Passwort (Das hat ein anderes internes Format als Unix Passworte).
Im Menü User (oder Console passwd layerbreak) ein neues Passwort setzen (setzt gelichzeitig Unix und SMB Passwort).
 
Neben Rechten auf Dateien und Ordnern gibt es Rechte die von darüberliegenden Ordnern vererbt werden. Gruppen können Gruppen und User enthalten. Das ist momentan State of the Art.
.

Derartiges war in den 90igern "State of the Art", sowas wurde mit NT 3.5 als Alternative zu Netware verkauft. Selbst spätere Erweiterungen wie ABE hatten wir unter Novell schon 10 Jahre zuvor im Einsatz. State of the Art sind da schon eher diverse neuere Features in PIM mit neuen ABE Features mit dualen Gruppenzugehörigkeiten, Berechtigungen mit Ablaufdatum, Multifaktor Auth (User, Computerkonto, SC, Pin,..),..
 
Zuletzt bearbeitet:
Im Grunde beides. Diverse NTFS Erweiterungen hängen vom Fileshare Service ab, bzw erfüllen diese ja erst über einen entsprechenden Share den dafür angedachten Zweck.

Es würde mich jedoch wundern wenn ZFS keine "aktuellen" ACL Features mit Vererbung usw mitbringt, sowas ist ja auch bei ext3/4 möglich?
 
Zuletzt bearbeitet:
ZFS ist rechtemäßig ein ganz normales jedoch ziemlich altes Unix Dateisystem dessen Entwicklung ca 2001 bei Sun begann. Ext4 ist da mit Erscheinungsjahr 2008 eigentlich viel neuer allerdings ohne dessen revolutionär neue Konzeption mit CopyOnWrite, End to End Prüfsummen und integrierte Volume, Raid und Service Management Funktionen. Auf Ebene des Dateisystems werden bei ZFS neben herkömmlichen Unix Datei Attributen (Ich, meine Freunde und Rest der Welt) Posix oder nfs4 ACL unterstützt. Diese beziehen sich unixtypisch auf UID/GID Kennungen zur Identifizierung. Zusätzlich können weitere Attribute als erweiterte ZFS Eigenschaften wie z.B. beim Solaris SMB Server die Benutzung von Windows SID als Referenz oder NTFS Vererbung hinzugefügt werden.

Die letztendliche Funktionalität insbesondere im Vergleich zu einem Windows System unter NTFS ist jedoch nicht im Dateisysten angelegt sondern in der Kombination mit einem Sharing Dienst. ZFS bietet über erweiterte Attribute lediglich Vorraussetzungen, allerdings mit der Unterstützung von nfs4 ACL sehr gute da damit die rechtemäßige Flexibilität von NTFS abbildbar ist. Der tatsächliche Funktionsumfang was Rechte angeht ist dann je nach OS oder Sharing Service unterschiedlich. Nicht alles was Sun eingebaut hat ist auf jedem OS oder mit jedem Sharing Service verfügbar.

Auf manchen Systemen sind beispielsweise keine oder nur Posix ACL verfügbar. Damit lassen sich die Fähigkeiten von NTFS nicht abbilden. Teilweise ist auch SAMBA der limitierende Faktor. Immerhin soll das auf jedem Dateisystem und auf jedem X-Gerät laufen das 1 und 1 binär zusammenzählen kann. Die Besonderheiten von ZFS fallen dann unter den Tisch denn sie werden einfach ignoriert indem z.B. ZFS genauso gehandhabt wird wie z.B. ext4.
 
Zuletzt bearbeitet:
Ich schon wieder. :-[

Anfang der Woche hab ich Server-Backup komplett OmniOS und napp-it neu installiert, dann das napp-it Backup, alle Möglichkeiten auf YES gesetzt, wiederhergestellt.
Heute wurde per Update Server-Datengrab auf r151020 gebracht und napp-it/tools auf der console mit "wget -O - www.napp-it.org/nappit | perl" auf 16.11f gebracht.

Bei Server-Backup
Jetzt haben mir die angelegten User Probleme bereitet, da ihre Windows-SID nicht angezeigt wurde - Diese wird beim Erstmaligen Anmelden an dem System dann eingetragen --> gelöst.
Dann habe ich mich in die Gruppe der administrators aufgenommen und hier hab ich ein ungelöstes Problemchen. Bei Server-Backup werde ich so angezeigt "/layerbreak" und bei Server-Datengrab "layerbreak@datengrab.meineDomain.local". Egal, scheiß-egal oder doch nicht egal?? Kann ich das per Dateieintrag korrigieren und in welche?
Ich vermute jetzt, dass bei dem Restore von napp-it etwas nicht richtig übernommen wird, da dieses ja auf Uraltversion v0.9f6 basierte.
In welche Datei wird Dies eingetragen?
Beim Reimport des Datenpools, der "p_arche" heißt, schlägt mir napp-it unter "Unter einem ....importieren" nur "p" vor, eigentlich sollte hier "p_arche" stehen oder nicht? Leeres Feld wird nicht aktzeptiert

"netbios_enable" finde ich nicht in "man sharectl" weder auf meinem Server noch auf der Illumos-Webseite. Veraltet?? Hat es einen Grund/Vorteil, warum diese Variable standard-mässig auf FALSE steht?
Beim AIO-Server muss ich es dringend händisch machen, da so einige Programme auf den Clients AIO nicht mehr finden und ihren Dienst verweigern, noch auf v0.9f6. Auf der Console geb ich es so ein? #sharectl set -p netbios_enable=TRUE

Lizenz
Datengrab meldet mir beim Restore der napp-it Einstellungen sinngemäß keine Pro-Lizenz, in Extentions/Register/Edit steht aber meine Lizenz drinne, auch bei Appliance Group ist dieser Server noch enthalten.
Wie soll ich jetzt hier vorgehen um meine Lizenz wieder zu aktivieren?
 
Zuletzt bearbeitet:
Ich schon wieder. :-[

Anfang der Woche hab ich Server-Backup komplett OmniOS und napp-it neu installiert, dann das napp-it Backup, alle Möglichkeiten auf YES gesetzt, wiederhergestellt.
Heute wurde per Update Server-Datengrab auf r151020 gebracht und napp-it/tools auf der console mit "wget -O - www.napp-it.org/nappit | perl" auf 16.11f gebracht.

Bei Server-Backup
Jetzt haben mir die angelegten User Probleme bereitet, da ihre Windows-SID nicht angezeigt wurde - Diese wird beim Erstmaligen Anmelden an dem System dann eingetragen --> gelöst.
Dann habe ich mich in die Gruppe der administrators aufgenommen und hier hab ich ein ungelöstes Problemchen. Bei Server-Backup werde ich so angezeigt "/layerbreak" und bei Server-Datengrab "layerbreak@datengrab.meineDomain.local". Egal, scheiß-egal oder doch nicht egal?? Kann ich das per Dateieintrag korrigieren und in welche?
Ich vermute jetzt, dass bei dem Restore von napp-it etwas nicht richtig übernommen wird, da dieses ja auf Uraltversion v0.9f6 basierte.

Napp-it is da weniger das Problem da es nicht ins Verhalten des Betriebssystems eingreift. Es ist eher der Sprung über 4 Stable Versionen von OmniOS. Im Zweifel einfach den Benutzer löschen und mit gleicher uid wieder anlegen

Beim Reimport des Datenpools, der "p_arche" heißt, schlägt mir napp-it unter "Unter einem ....importieren" nur "p" vor, eigentlich sollte hier "p_arche" stehen oder nicht? Leeres Feld wird nicht aktzeptiert

Beim Import einfach den alten Poolnamen oder einen beliebig anderen eintragen (Hier kann man einen Pool auch umbenennen)

"netbios_enable" finde ich nicht in "man sharectl" weder auf meinem Server noch auf der Illumos-Webseite. Veraltet?? Hat es einen Grund/Vorteil, warum diese Variable standard-mässig auf FALSE steht?
Beim AIO-Server muss ich es dringend händisch machen, da so einige Programme auf den Clients AIO nicht mehr finden und ihren Dienst verweigern, noch auf v0.9f6. Auf der Console geb ich es so ein? #sharectl set -p netbios_enable=TRUE

Nexenta hat das halt so gemacht (Die pflegen SMB bei Illumos).
Der CLI Befehl ist ok, die manpage vermutlich noch nicht auf SMB2 upgedatet.

Lizenz
Datengrab meldet mir beim Restore der napp-it Einstellungen sinngemäß keine Pro-Lizenz, in Extentions/Register/Edit steht aber meine Lizenz drinne, auch bei Appliance Group ist dieser Server noch enthalten.
Wie soll ich jetzt hier vorgehen um meine Lizenz wieder zu aktivieren?

Die Lizenz hängt am hostname.
Der muss gleich bleiben. Der FQN Hostname (inkl. Domain) scheint jetzt anders zu sein (erklärt auch Problem beim User)
 
Zuletzt bearbeitet:
Bei Server-Backup hab ich ja eine Neuinstallation gemacht.
Bitte sag mir, wie muss der smb-groups/admin richtig angezeigt werden. benutzername@servername.domain.local oder nur /benutzername.

Reimport des Pools war als Hinweis gedacht.

Na dann bin ich echt mal gespannt, wie das weiter gehen soll, wenn jetzt Oracle Solaris einstellt und die dann ihre Hilfeseiten offline nehmen.

Ist mir schon klar und ich habe auch Hostname=Lizenz. War auch nur als Hinweis gedacht, weil mir scheint, dass die Lizenzüberprüfung nicht durchgängig funzt.

- - - Updated - - -

Ich hab jetzt die Lizenz erneut eingegeben.
In /etc/host steht
127.0.0.1 arche.meinedomain.dom loghost arche
nappit-key.JPG nappit-key-edit.JPG

Trotzdem komm ich nicht mehr rein.
nappit-key-benutzer.JPG

Vorschlag?
 
Bei Server-Backup hab ich ja eine Neuinstallation gemacht.
Bitte sag mir, wie muss der smb-groups/admin richtig angezeigt werden. benutzername@servername.domain.local oder nur /benutzername.

Microsoft nutzt zur Benutzeridentifizierung username@domain oder username@host
Aus Kompatibilitätsgründen geht auch die alte Variante domain\username bzw host\username

Na dann bin ich echt mal gespannt, wie das weiter gehen soll, wenn jetzt Oracle Solaris einstellt und die dann ihre Hilfeseiten offline nehmen.

Momentan sind ja alles Gerüchte.
Natürlich sind die Sun/Oracle Docs zu ZFS und Solaris unschlagbar und die Referenz auch für Open-ZFS. Würden die wegfallen müsste bei Open-ZFS oder Illumos Ersatz geschaffen werden. Bei OpenIndiana tut sich da gerade einiges. Auch bei BSD und Zol gibts sehr viel insbesondere was die jeweilige Einbettung von ZFS angeht, da gibts ja durchaus Unterschiede, Abstriche aber auch Erweiterungen zu Solarish.

Ist mir schon klar und ich habe auch Hostname=Lizenz. War auch nur als Hinweis gedacht, weil mir scheint, dass die Lizenzüberprüfung nicht durchgängig funzt.

- - - Updated - - -

Ich hab jetzt die Lizenz erneut eingegeben.
In /etc/host steht
127.0.0.1 arche.meinedomain.dom loghost arche
Anhang anzeigen 384529 Anhang anzeigen 384530

Trotzdem komm ich nicht mehr rein.
Anhang anzeigen 384531

Vorschlag?

2016.11f = Free Version
Da ist nicht alles enthalten was in 2018.11pro = Pro Version enthalten ist.
 
Zuletzt bearbeitet:
Microsoft nutzt zur Benutzeridentifizierung username@domain oder username@host
Aus Kompatibilitätsgründen geht auch die alte Variante domain\username bzw host\username
Also ich hab jetzt in etc/hosts die folgenden Einträge gesetzt:
Code:
# IP/6
::1		localhost
# IP/4
127.0.0.1	arche.meinedomain.dom	loghost	arche
Sonst gibt keine Einträge jetzt mehr und ja ich weis, dass ich .dom noch ändern muss.
Jetzt hoffe ich, dass es so richtig ist.
Morgen gehts nochmals auf null zurück und ein neuer Versuch. Dann mal schauen, wie dann smb-admin layerbreak aussieht.

2016.11f = Free Version
Da ist nicht alles enthalten was in 2018.11pro = Pro Version enthalten ist.

OH MANN, wirf mir mal eine Motorsäge über den Aasrücken - ich seh vor lauter Bäumen den Wald nicht mehr. :mad:
PRO installiert und alles geht.
 
Zuletzt bearbeitet:
Guten Abend an alle,

ich hatte mal wieder etwas Zeit mich mit meinem Solaris 11.3 Storage-Server zu beschäftigen und bin jetzt an einem Punkt angekommen, wo ich ohne Hilfe nicht weiter komme.
Ich habe einen RAIDz2 Pool (tank) mit einer Größe von 40,8T angelegt. Auf diesen habe ich ein mit aes-256-ccm verschlüsseltes und mit lz4 komprimiertes Filesystem (data) abgelegt.
Jetzt habe ich ein smb share Backup und ein smb share Media wie folgt erstellt:
zfs create -o share.smb=on -o nbmand=on -o share.smb.csc=disabled -o share.smb.guestok=on tank/data/Backup
zfs create -o share.smb=on -o nbmand=on -o share.smb.csc=disabled -o share.smb.guestok=on tank/data/Media
Für diese beiden Freigaben habe ich chown und chmod angepasst.
Die Freigaben wurden von meinen beiden Clients gefunden und ich konnte dort hinein Dateien speichern.

Das System ist aus den verschiedensten Gründen mehr aus als an und so bin ich nun auf das Problem gestoßen,
das Solaris meine Einstellungen vergessen hat. Nach dem Boot mounte ich immer zuerst einmal manuell data - das
möchte ich so haben. Aber Solaris hat mir bisher jedes mal die chown und chmod Einstellungen wieder auf root
zurück gesetzt. zfs list offenbart das die Daten noch da sind, also es wird immer noch Speicherplatz belegt, aber
ich kann sie nicht sehen. In etc/dfs/sharetab fehlen die beiden Einträge für Backup und Media auch nach dem reboot.
Bei zfs get all stimmt komischerweise noch alles?

Meine beiden Clients sind Windows und dumpen in unregelmäßigen abständen ihre Daten jeweils ohne separate Anmeldung (desswegen guestok und chown/chmod)
Mein alter Debian Storage Server (ZoL und dm-crypt) läuft auf die gleiche Weise seit Jahren ohne Probleme.

Wäre echt toll, wenn mir vielleicht jemand einen Tip geben könnte, warum Solaris sowas macht, und ob ich das irgendwie beheben kann.

Vielen Dank und freundliche Grüße
L0rD_LuCk
 
Ich hab da mal eine Frage: Wie kopiere/verschiebe ich am einfachsten Daten von einem NAS aufs andere?
Es handelt sich um zwei FreeNAS Maschinen und ich will die Daten von der kleineren auf die größere Maschine verschieben, damit ich bei der kleineren danach alle Platten gegen größere austauschen kann. Mittels Windows und zwei SMB Shares habe ich es zu erst versucht, aber das dauert bei knapp 7TB dann fast 2 Tage, weil dazwischen nur eine 1Gbit Leitung liegt und alles über den PC geschleift wird. Momentan probiere ich mich an rsync zwischen den beiden. Das läuft auch recht flott laut Network Monitor (so um die 800MBit/s), allerdings wurden jetzt schon mehr Daten kopiert, als eigentlich vorhanden sind. Die kleine Maschine zeigt mir an, dass da 6,8TB an Daten drauf liegen. Auf der der zweiten Kisten sind aber inzwischen schon fast 8TB belegt...

Ist das normal? Es ist aber auch noch nicht alles kopiert worden.
Was mich auch irgendwie irritiert: Auf NAS1 liegen die Daten unter /mnt/Storage. Da liegen dann 4 Ordner. Auf NAS2 sollten die dann unter /mnt/Storage/NAS1 liegen, was sie auch tun. Aber im NAS1 Ordner gibt es dann einen Ordner Storage unter dem nochmal die 4 Ordner liegen... Was hab ich falsch gemacht oder ist das normal?
 
Sofern Du ZFS nutzt: ZFS-Snaps anlegen und mit "zfs send / receive". Geht via SSH oder NC direkt vom Quell- zum Zielsystem.

Btw, genau diese Datenmengen backuppen war bei mir der Grund, in 10Gbit-Lan einzusteigen (was natürlich nicht unbedingt billig ist).
 
Zuletzt bearbeitet:
Auf beiden ist ZFS am laufen. Das send/receive mach ich dann über das Terminal?
Kenn mich mit den Snaps nicht wirklich aus. Geht das auch, wenn Quelle und Ziel unterschiedlich groß sind? Quelle hat 5x2TB in nem RaidZ1 und Ziel 6x8TB in nem RAIDZ2. Das RaidZ1 wird dann durch 5x3TB ersetzt und soll dann vom großen auch wieder zurück wandern. Es sind also noch ein paar TB, die da fließen werden :d

Für 10GB kopiere ich diese Mengen zu selten hin und her. Aber dann lass ich das jetzt mal weiterlaufen, weil nochmal komplett von vorne anfangen, dauert ja wahrscheinlich noch länger. Aber ich könnte es dann bei den folgenden Kopieraktionen berücksichtigen. Die 5x3TB müssen nämlich dann auch erst noch rüberkopiert werden...
 
Guten Abend an alle,

ich hatte mal wieder etwas Zeit mich mit meinem Solaris 11.3 Storage-Server zu beschäftigen .
..
Nach dem Boot mounte ich immer zuerst einmal manuell data..
In etc/dfs/sharetab fehlen die beiden Einträge für Backup und Media auch nach dem reboot.

In Solaris geht das Mounten von Dateisystemen über ZFS Eigenschaften wie mounted, canmount oder mountpoint https://docs.oracle.com/cd/E18752_01/html/819-5461/gaynd.html nicht über /etc/vfstab oder ähnliches

Bei zfs get all stimmt komischerweise noch alles?

Mounts haben nichts mit dem Vorhandensein eines ZFS Dateisystems zu tun

Meine beiden Clients sind Windows und dumpen in unregelmäßigen abständen ihre Daten jeweils ohne separate Anmeldung (desswegen guestok und chown/chmod)

Solaris nutzt ausschließlich Windows ntfs artige NFS4 ACL mit Vererbung.
Wenn man da Unix Rechte mit dem normalen chmod drüberbügelt, werden die ACLs und die Vererbung gelöscht.

Daher immer /usr/bin/chmod nutzen (kann Solaris ACL, chmod aus Linux kann das nicht) und ACL z.B. everyone@ setzen
 
Geht das auch, wenn Quelle und Ziel unterschiedlich groß sind? Quelle hat 5x2TB in nem RaidZ1 und Ziel 6x8TB in nem RAIDZ2. Das RaidZ1 wird dann durch 5x3TB ersetzt und soll dann vom großen auch wieder zurück wandern. Es sind also noch ein paar TB, die da fließen werden

Und warum gehst du nicht einfach her und tauscht die erste alte gegen eine neue aus, wartest bis der pool ein resilver fertig hat, dann die Zweite ..., Dritte usw. Achso den Pool noch auf autoexpand setzen und alles ist gut.
 
@gea

Vielen vielen Dank!
Ich hab den Wald vor lauter Bäumen mal wieder nicht gesehen und du hast mich zurück auf den rechten Pfad geführt!
Jetzt ist alles so wie ich es möchte und brauche kann ich die Daten vom alten Debian Server auf den neuen Solaris Server umziehen lassen.
Für meine Zwecke reichen die einfachen Zugriffsrechte voll und ganz aus, auf die ACL kann ich gut verzichten. Ich lege dort nur meine Daten/Backups ab.

Nochmals vielen vielen Dank!!!
 
Zuletzt bearbeitet:
Und warum gehst du nicht einfach her und tauscht die erste alte gegen eine neue aus, wartest bis der pool ein resilver fertig hat, dann die Zweite ..., Dritte usw. Achso den Pool noch auf autoexpand setzen und alles ist gut.

Weil ich naiverweise davon ausgegangen bin, dass es so schneller geht. Um mir "Arbeit zu ersparen", habe ich mich für einen Ringtausch entschieden:
Alter Stand:
NAS1 = 5x2TB Z1
NAS2 = 5x3TB Z1
Neuer Stand:
NAS1 = 5x3TB Z1
NAS2 = 6x8TB Z2

Irgendwann hätte ich eine Kiste eh umbauen müssen, um das Z2 rein zu bekommen. Und ich bin einfach davon ausgegangen, dass rüberkopieren schneller geht, als 5 Platten zu tauschen. Und für das Z2 hätte ich es eh komplett neu machen müssen oder kann ich doch von einem Z1 auf ein Z2 migrieren? Bin einfach von ausgegangen, dass das eh nicht geht und hatte nicht groß danach gesucht.

Die Zeit, die es dauert, ist mit im Grunde auch wumpe. Mich irritiert nur, dass rsync da so komische Sachen macht. Es wurden jetzt schon 9.8TB kopiert, obwohl NAS1 nur 6.8TB Daten besitzt und die Ordner irgendwie zweimal auftauchen. Ich schau einfach mal, was er morgen Nachmittag sagt. Wenn er da noch fleissig weiter synced, dann werde ich mich wohl doch nochmal in das ZFS send/receive einlesen müssen.
 
Bei den Replications-Jobs habe ich bei Source Pool einmal "Key" und an einem anderen Server "Member" in dem Pull-down diese Einträge.

Was will mir napp-it damit sagen?
 
.. Dass die zwei Server zwischen denen repliziert werden sollen

- keine Appliance Group (mehr) bilden
- der Key den die beiden beim Aufbau der Gruppe getauscht haben, nicht mehr stimmt.

Kontrollieren kann man das im Menü Extension > Appliance Group
wenn man bei einer remote Maschine auf "zfs" oder "snaps" klickt.
Entweder kommt ein zfs list oder eine Fehlermeldung

Beheben kann man das, indem man den anderen Server (erneut) in die Appliance Group aufnimmt
Menü Extension > Appliance Group > ++add appliance


Ein Problem kann noch auftreten, wenn man einen Host umbenennt oder eine andere IP vergibt.
Dann muss man ungültige Appliance group members löschen:
Menü Extension > Appliance Group > delete group members
 
.. Dass die zwei Server zwischen denen repliziert werden sollen

- keine Appliance Group (mehr) bilden
- der Key den die beiden beim Aufbau der Gruppe getauscht haben, nicht mehr stimmt.

Kontrollieren kann man das im Menü Extension > Appliance Group
wenn man bei einer remote Maschine auf "zfs" oder "snaps" klickt.
Entweder kommt ein zfs list oder eine Fehlermeldung

Beheben kann man das, indem man den anderen Server (erneut) in die Appliance Group aufnimmt
Menü Extension > Appliance Group > ++add appliance


Ein Problem kann noch auftreten, wenn man einen Host umbenennt oder eine andere IP vergibt.
Dann muss man ungültige Appliance group members löschen:
Menü Extension > Appliance Group > delete group members

Danke, der Key stimmt nicht mehr - erst zu sehen, wenn man zfs oder snaps anklickt - in der Tat.
Und nein IP und Hostname ist gleich geblieben, aber wie geschrieben eine komplette Neuinsstallation. Auch beim napp-it-restore wird offensichtlich dieser Key nicht mitgesichert bzw. hier nicht wiederhergestellt.
Bei allen Server die gesamte Gruppe aufgelöst, sicherheitshalber group-buffer gelöscht und Appliance-Group neu angelegt und -- ich kann wieder Replication-Jobs anlegen. :hail:

Vorschlag für eine der kommenden Versionen:
Neben 'Online' eine neue Spalte 'Appliance Group Valid' die anzeigt, dass der Key noch in Ordnung ist.
 
Zuletzt bearbeitet:
Ich muss auf die Replikations-Jobs nochmals zurück kommen, da ich ungern jetzt nach dem Update meine Sicherungen verlieren möchte.


Im Replikationsjob kann man aber per keep und hold die Anzahl der Snaps auf dem Backupsystem je Dateisystem einstellen, z.B.
hold=8 bedeutet, lösche bei der nächsten Replikation Snaps dieses Jobs älter als 8 Tage
hold=8s bedeutet, lösche bei der nächsten Replikation Snaps dieses Jobs bis auf die letzten 8

keep=100 bedeutet dass jeder hunderste Snap umbenannt wird und dauerhaft aufgehoben wird

Einstellungen:
keep=Anzahl Snaps
hold=Mindestalter Tage

Snaps werden gelöscht, wenn beide Regeln diese erlauben (Sowohl als auch/und)
Keep=10 und hold=10 bedeutet also dass Snaps gelöscht werden die älter als 10 Tage sind. Es werden aber in jedem Fall mindestens 10 behalten.

Replikations Job:
Damit werden zwei Dateisysteme über Snapshots syncronisiert.
Einstellungen siehe oben (keep and hold)

AIO=Source
Ripley= Target

Auf AIO hab ich 3 zugehörige Snaps, auf Ripley sind es über 250 Snaps. ==> für mich ist es so OK, so kann ich bis zum 01.10.2015 zurückgehen. :d
In den Job-Parametern ist aber zu sehen, dass keep und hold so belegt sind:
keep=
hold=30
Nach deinen beiden Posts vom 11.12. dürften aber nur die 30 jüngsten (Tages-)Snaps auf dem Target-System sein.
Meine Vermutung ist, dass es bei der v0.9 noch nicht optimal so gelaufen ist und dadurch die ältesten 230 Snaps nicht gemäß Einstellungen gelöscht wurden - kann das sein?

Muss ich, um die 250 Target-Snaps zu behalten in keep einen . Punkt eintragen und Variable hold leer lassen?
Die Anzahl der Repli-Snaps auf dem Source-System ist von dir per hardcoded auf 3 Stk. festgelegt?
 
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