[Sammelthread] ZFS Stammtisch

Man sollte immer das grundsätzliche Problem im Hinterkopf haben:

ZFS ist ein Unix Dateisystem bei dem die Dateirechte gegenüber dem Betriebssystem ausschließlich über UID und GID Kennungen betrachtet werden. Das betrifft Solaris genauso wie andere Unix Abkömmlinge wie OSX/ BSD oder das unixoide Linux.

Wenn man nun darauf Fileservices wie AFP, NFS oder SMB aufsetzt, so ergeben sich daraus zwei Anforderungen. Erstens muss das entsprechende Protokoll unterstützt werden, also AFP (melde dich im Netz so wie ein Mac), NFS (kein Problem, wurde von Sun unter Solaris entwickelt) oder SMB (verhalte dich im Netz so wie ein Microsoft SMB Server).

Das zweite ist die Frage der Datei-Permissions. Solange es sich um Unix-Services wie AFP oder NFS handelt, ist das recht problemlos. Die kennen ja auch auf dem Ursprungssystem nur UID/GID Dateisysteme und Strukturen. Bei SMB sieht das ganz anders aus. Windows geht mit NTFS weit über die Möglichkeiten von herkömmlichen Unix Dateisystemen hinaus. Das betrifft die viel feineren Rechte, die ganzen Vererbungssachen und bei Gruppen z.B. die Möglichkeit von Gruppen in Gruppen. Der einfache Ansatz wäre jetzt, nur die Unixoptionen anzubieten. SAMBA geht diesen Weg.

Solaris versucht jedoch mit dem eigenen SMB Server die Optionen des NTFS Dateisystems anzubieten. Dazu brauchts eine zusätzliche SMB Gruppenverwaltung, die Speicherung von Windows SID als erweiterte ZFS Attribute, die weitgehende Unterstützung der Windows ntfs ACL (gelungen bis auf Deny Rules, die werden anders gehandhabt) und eine "Übersetzung" der Windows SID in die tatsächlichen UID/GID Dateiattribute beim SMB Zugriff. Die Unixrechte müssen ja auch für Solaris SMB gelten, auch wenn der auf die Windows SID schaut.

Der Schlüssel dazu ist idmapping . Wenn man eine Active Directory hat, passiert das temporär/ automatisch mit ephemeral Mappings im Hintergrund. Man hat damit als User nichts zu tun. Selbst ein Backup/ Restore auf einen anderen Server erhält alle Rechte bei. Das tut einfach ohne dass man etwas machen muss.

Im Workgroup Mode ist das schwieriger. Da ist es ähnlich wie bei Windows. Wenn man Windows neu aufsetzt und eine Platte importiert, passen die Rechte auch meist nicht mehr und müssen neu gesetzt werden (unbekannte SID). Unter Solaris sollte das klappen wenn man den Hostname beibehält und alle User und Groupsettings (sowohl Unix wie SMB) exakt gleich neu anlegt. Waren nur User-Rechte gesetzt, genügt es, die User mit der gleichen UID/GID neu anzulegen. SMB Groups machen es da etwas schwieriger da man die Option hat über ein festes Mapping Windows Group => Unixgroup zu arbeiten oder das zu ignorieren und nur mit SMB Groups zu arbeiten (default Verhalten).
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hab gerade gesehen, dass es die open-vm-tools für Omnios im Repo gibt. Spricht etwas dagegen die zu nehmen, statt die vmware tools von Hand drauf zu machen?
 
SMB Groups machen es da etwas schwieriger da man die Option hat über ein festes Mapping Windows Group => Unixgroup zu arbeiten oder das zu ignorieren und nur mit SMB Groups zu arbeiten (default Verhalten).

Hallo Gea,

dank für Deine Erklärungen. Das Nappit arbeitet wohl standartmäßig mit festem Mapping, da beim Anlegen von SMB-Gruppen die Unix-gruppen automatisch mit angelegt und verknüpft werden. Würde es die Sache vereinfachen, dieses Verhalten zu ändern und nur mit SMB-Groups zu arbeiten? Oder wie ist Deine Aussage zu verstehen?
Auf alle Fälle ist die nachträgliche Zuordnung unter Unix/Solaris einfacher zu lösen als bei einem Windowsserver.
Die SMB-gruppen stimmen jetzt wieder, das Filesystem muss wohl nicht mehr angefasst werden.
 
Hallo Gea,

dank für Deine Erklärungen. Das Nappit arbeitet wohl standartmäßig mit festem Mapping, da beim Anlegen von SMB-Gruppen die Unix-gruppen automatisch mit angelegt und verknüpft werden. Würde es die Sache vereinfachen, dieses Verhalten zu ändern und nur mit SMB-Groups zu arbeiten? Oder wie ist Deine Aussage zu verstehen?
Auf alle Fälle ist die nachträgliche Zuordnung unter Unix/Solaris einfacher zu lösen als bei einem Windowsserver.
Die SMB-gruppen stimmen jetzt wieder, das Filesystem muss wohl nicht mehr angefasst werden.

Tja
Der Solaris SMB Server kennt nur SMB Gruppen, Solaris selber nur Unix Gruppen. Daran kommt man nicht vorbei.

- - - Updated - - -

Hab gerade gesehen, dass es die open-vm-tools für Omnios im Repo gibt. Spricht etwas dagegen die zu nehmen, statt die vmware tools von Hand drauf zu machen?

Ja, es fehlt (bisher) der vmxnet3 Treiber.
 
Hallo Gea,

dann ist die Aussage von Dir im von mir zitierten Ausschnitt wohl missverständlich gewesen. Also hat man keine Option.
 
Eine Frage zum Thema napp-it autosnap: include ESXi hot snaps in ZFS snaps on NFS datastores

Ich habe das bisher noch nicht getestet. Gilt im Prinzip folgendes Vorgehen?


- create a hot ESXi snap with memory state (remotely via SSH)
- create a ZFS snap
- delete ESXi snap


in case of problems
- restore ZFS snap
- restore hot ESXi snap with Vsphere

Reicht es wenn ich nur den ZFS snap sichere, um in einem Problemfall ESXi wieder aufsetzen zu können? Es gibt ja einen Unterschied zwischen ESXi Snapshots und ZFS Snapshot. ESXi Snapshots sind ja lediglich Delta Snapshots, wenn ich das richtig verstehe. Im ZFS Snap sollte dann aber alles drin sein, oder?

Kleiner Nachtrag: Funktioniert das auch bei der Napp-it AllInOne Lösung, also wenn OmniOS virtualisiert ist?
 
Zuletzt bearbeitet:
Kleiner Nachtrag: Funktioniert das auch bei der Napp-it AllInOne Lösung, also wenn OmniOS virtualisiert ist?

Ja, allerdings dann logischerweise nur für VMs, deren Daten auf dem NFS-Share von napp-It liegen und nicht für Napp-It selbst. Am besten erstellt man für die einfach keine Zyklischen Snapshots.
 
Napp-it selber hat ja bootbare Snapshots (bootenvironments) die man beim Booten anwählen kann.
Dazu würde ich ab und an die napp-it VM als Template für ein Restore sichern.

Insgesamt sollte man aber auf die Storage VM eh nichts kritisches legen.
Dann verliert auch eine komplette Neuinstallation jeglichen Schrecken.
 
Hallo Gea,

hast Du schon Erfahrungen mit OmniOS r151017? Seit Umstellung auf diese Version erscheint der Fileserver nicht mehr in der Netzwerkumgebung der Windowsclients. Einen Konfigurationsfehler meinerseits kann ich aber nicht finden. Ehe ich umsonst weitersuche - gibt es da einen Bug in der neuen Bloody-Version?
Ist da schon etwas bekannt? Ich suche in der Regel den Fehler immer zuerst bei mir, aber diesmal kann ich nichts finden....
 
Ist bei mir auch so obwohl mein Testerver in der AD Domäne ist und dieser damit als Masterbrowser die Liste der Rechner in der Netzwerkumgebung bereitstellt.

Also eher noch ein Bug, konfigurieren lässt sich da ja nichts.
 
Danke für die Rückmeldung, dann kann ich mich zurücklehnen. Mit Konfigurationsfehler meinte ich eher falsche Workgroup oder nicht aufgepasst wegen Casesensitiv.
 
Ich schreibe es mal hier mit rein, aber eigentlich ist es denke ich mehr ein Napp-IT Thema. Gibts dafür keinen eigenen Thread? Viele Fragen hier drehen sich doch darum, oder?

Also ich habe nun auf meinem Backup Server ebenfalls die aktuelle omniOS mit Napp-IT und teste gerade die replication-Erweiterung. Scheint soweit gut zu klappen und vor allem schneller, als mit send/receive an FreeNAS bei mir.
Doch so einiges ist mir nicht klar. Vorab: dafür gibt es irgendwie keine echte Doku, oder?

- der erste Replikations Job ohne "rekursiv"-Option war sehr schnell fertig. Da wurde also leider nicht alles übertragen. Rekursiv hatte ich nicht genutzt, weil in den Tipps davon abgeraten wurde. Aber es soll ja für den Ausfall alles auf dem Backup Server liegen. Also habe ich noch einen 2. Job aufgesetzt, der nun alles zu kopieren scheint. Soweit so gut. Nur soll dieser ja auch in der Zukunft laufen ... wie bekomme ich die rekursiv-Option wieder raus? Oder ist das Unsinn wie ich mir das denke? ein 2. Job würde ja denke ich mal andere Snapshots senden, da die JOB-ID mit im Namen steht.

- Wenn ich im schlimmsten Fall ein Rollback vom Backupserver machen müsste (quasi ein komplettes Backup zurückspielen), dann gibt es dafür keine Funktion, oder? Kann ich das also nur machen, indem ich den ganzen Pool per shell wieder zurück sende?

- Snapshots öfter als Replikation: da ich meinen Backup-Server ja leider nicht mehr per WOL starten kann, würde ich das zur Not manuell alle paar Tage machen. Generell sollte auf der Quelle aber auch ein kürzerer Snapshot-Rhytmus laufen, für ein evtl. zeitnahes Rollback bei Problemen ohne Hardwareausfall. Also das übliche Kleinkram: Datei versehentlich gelöscht etc. Der Replikations-Job würde aber eigene Snapshots daneben stellen (mit eigener ID). Macht das Sinn? Denn nach meinem Verständnis werden ja nur Differenzen gespeichert und das zwischen allen Snapshots. Dann hätte die Replikation gar nicht alle Daten?

Ich verstehe, dass ich hier ein absoluter Heimanwender bin und die Probleme in einem Firmenumfeld, wo die Server alle ständig laufen nicht aufkommen würde. Lässt sich das also überhaupt für mich lösen?

Vielen Dank für Eure Unterstützung.
 
Ich schreibe es mal hier mit rein, aber eigentlich ist es denke ich mehr ein Napp-IT Thema. Gibts dafür keinen eigenen Thread? Viele Fragen hier drehen sich doch darum, oder?

Also ich habe nun auf meinem Backup Server ebenfalls die aktuelle omniOS mit Napp-IT und teste gerade die replication-Erweiterung. Scheint soweit gut zu klappen und vor allem schneller, als mit send/receive an FreeNAS bei mir.
Doch so einiges ist mir nicht klar. Vorab: dafür gibt es irgendwie keine echte Doku, oder?

Prinzipiell stellt man zfs send Optionen ein. Die Bedeutung dieser Optionen kann man den Oracle Dokus entnehmen. https://docs.oracle.com/cd/E18752_01/html/819-5461/gbchx.html#gfwqb

- der erste Replikations Job ohne "rekursiv"-Option war sehr schnell fertig. Da wurde also leider nicht alles übertragen. Rekursiv hatte ich nicht genutzt, weil in den Tipps davon abgeraten wurde. Aber es soll ja für den Ausfall alles auf dem Backup Server liegen. Also habe ich noch einen 2. Job aufgesetzt, der nun alles zu kopieren scheint. Soweit so gut. Nur soll dieser ja auch in der Zukunft laufen ... wie bekomme ich die rekursiv-Option wieder raus? Oder ist das Unsinn wie ich mir das denke? ein 2. Job würde ja denke ich mal andere Snapshots senden, da die JOB-ID mit im Namen steht.

Prinzipiell kann man eine rekursive Replikation (z.B. ganzen Pool) starten und dann inkrementell fortsetzen. Ich rate aber davon ab, da rekursives zfs send auf die Nase fällt, wenn z.B. ein neues Dateisystem angelegt wird und dafür dann keine Snaps vorliegen. Ein einmaliges rekursives Übertragen eines kompletten Pools ist aber immer ok. Ansonsten bevorzuge ich einen Job per Dateisystem.

- Wenn ich im schlimmsten Fall ein Rollback vom Backupserver machen müsste (quasi ein komplettes Backup zurückspielen), dann gibt es dafür keine Funktion, oder? Kann ich das also nur machen, indem ich den ganzen Pool per shell wieder zurück sende?

Dazu auf dem Hauptserver einen Replkationsjob anlegen und komplett zurück replizieren.
Für einzelne Restore Vorgänge kann man einen Evalkey nutzen.

- Snapshots öfter als Replikation: da ich meinen Backup-Server ja leider nicht mehr per WOL starten kann, würde ich das zur Not manuell alle paar Tage machen. Generell sollte auf der Quelle aber auch ein kürzerer Snapshot-Rhytmus laufen, für ein evtl. zeitnahes Rollback bei Problemen ohne Hardwareausfall. Also das übliche Kleinkram: Datei versehentlich gelöscht etc. Der Replikations-Job würde aber eigene Snapshots daneben stellen (mit eigener ID). Macht das Sinn?

Replikationssnaps werden immer als Paar mit identischem Stand auf dem Quell und Zielserver benötigt. Das Ziel wird dann vor dem Replikationslauf darauf zurückgesetzt, dann auf dem Quellserver ein neuer Snap erstellt und die Änderungen dazwischen übertragen. Dann werden alte Replikationssnaps gelöscht. Replikationssnaps müssen daher unabhängig von anderen Snaps sein und dienen nur der Replikation. Für die normale Versionierung macht man davon unabhängige Snaps per autosnap z.B. jede Stunde einen Snap, behalte die 1 Tag und jeden Tag einen Snap um 22 Uhr - behalte 30, etc.

Denn nach meinem Verständnis werden ja nur Differenzen gespeichert und das zwischen allen Snapshots. Dann hätte die Replikation gar nicht alle Daten?

Bei ZFS werden keine Differenzen gespeichert wie z.B. bei ESXi Snaps oder z.B. bei Timemachine.
Ein ZFS Snap basiert auf dem CopyOnWrite Dateisystem. Dabei wird bei einer Änderung jeder Datenblock neu geschrieben. Nur wenn dieser Schreibvorgang gültig und komplett ist, wird dieser neue Datenblock gültig. Der bisherige Datenblock mit dem alten Datenstand wird dann zum Überschreiben freigegeben. Ein Snap bedeutet damit, dass der alte Datenstand nicht freigegeben wird. Das Anlegen fortlaufender Snaps bedeutet also nicht dass Differenz-Daten geschrieben wurden sondern dass verschiedene Versionsstände eingefroren wurden. Auf jede dieser Versionen kann man unabhängig von Versionen davor oder danach zugreifen. Dadurch dass die Snaps nicht durch Kopieren erzeugt wurden, sind die auch garantiert readonly und damit sicher vor unbeabsichtigten Änderungen, egal ob beabsichtigt oder durch Viren. Daher läuft auch die Replikation wenn danach normale Snaps angelegt wurden.

Dieses CopyOnWrite Prinzip ist übrigens auch dafür verantwortlich, dass ZFS immer valide ist und es daher auch kein "chckdsk" gibt, um Metadaten zu reparieren.
 
Zuletzt bearbeitet:
Hey,

ich bin aktuell in meiner Firma ein neues Backup Storage System am planen. Genauer gesagt, soll es ein OffSite Backup Repository an unserem 2. Standort werden. Das Backup Repository soll auch mehr als Archiv und Sicherheits Backup gesehen werden, da im Normalbetrieb die Backups/Restores vom "OnSite" Backupserver in erster Linie abgewickelt werden. Als Backupsoftware setzen wir Veeam Backup & Replication ein.

Kurz ein paar Daten zum neuen Backupserver:

Supermicro SC846E16 / 24x SAS/SATA Hot-Swap / 1x Expander
1x AMD Opteron 6134
32GB ECC Ram
24x 4TB WD Red
2x 1TB WD Black (System intern)
Areca 1883i Raid-Controller mit BBU (Alle WD Red Platten werden via Pass-Throuh einzeln durchgereicht)

Zu Beginn habe ich mir eigentlich nur Gedanken über den Aufbau eines klassischen Raid's gemacht und habe mich im Internet über diverse Foren gelesen, wie man ein 24 Disk Array am sinnvollsten aufsetzt. Dabei bin ich dann auf das Thema ZFS on Linux gestoßen. Also habe ich mich nun in das Thema ein wenig eingelesen und auch diesen Thread hier mit großen Interesse verfolgt. Vor zwei Wochen habe ich mir nun auch einen Testserver aufgesetzt, um einfach ein paar praktische Erfahrungen zu sammeln.

Nun hätte ich noch ein paar grundsätzliche Design Fragen, bei ich gerne eure Meinung wissen möchte.

Ist für mein Vorhaben der Einsatz von ZFS (ZoL) überhaupt geeignet? Hat zufällig wer solch ein System für Veeam backup & Replication im Einsatz?

Für mich aktuell die wichtigste Frage, welcher Aufbau wäre am sinnvollsten. Zuerst hatte ich überlegt, einen ZPool zu erstellen und dort dann 2 vDev's mit jeweils 12 Festplatten im RaidZ2 zu konfigurieren. Ich habe dann aber gelesen, dass für RaidZ2 pro vDev eher 10 Festplatten wegen der Performance empfohlen werden. Was mache ich also am besten mit den 4 übrigen Festplatten? Ist es zu empfehlen ein 3. vDev mit 4 Festplatten im RaidZ2 dem ZPool hinzuzufügen? Oder wären die Performanceinebaußen für meinen Einsatz als Archiv eher zu vernachlässigen?

Würde ich durch den Einsatz eines ZIL Log's auf einem SSD Mirror irgendwelche Performancevorteile haben? Bringt beim sequentiellen Schreiben großer Datenmengen überhaupt ein separates SSD ZIL etwas?

Vielen Dank schon mal
 
Nur ein paar persönliche Einschätzungen

1. Hardware
Ist eigentlich unpassend für ZFS.
Insbesondere der Areca ist nicht tauglich. Auch würde ich keinen Expander mit Sata Platten nehmen.
Professionelle Storagefirmen würden teilweise schon deshalb Support verweigern.

Ich würde stattdessen ein System mit
- passiver Backplane (kein Expander)
- 3 HBA wie LSI 9207 oder 3008 ohne Raid Funktionalität (IT Firmware)
- als Systemplatte 1-2 kleine SSDs ca 50-80GB (z.B. Intel S3500) mit Powerloss Protection, alternativ Sata DOM
- 10 GbE vorsehen
- je nach case, eventuell bessere Platten (HGST Ultrastar, WD Pro/Re4 etc wg Vibrationen)
Die SuperMicro oder Chenbro Cases sind aber so massiv, dass das nicht ganz so wichtig ist.

- Ich würde vermutlich eher ein Mainboard mit Intel CPU ab G4400, 10G Ethernet und LSI HBA onboard
bevorzugen

im Prinzip sowas (mit passiver 3,5" Backplane und eine Single CPU System reicht auch)
Supermicro | Products | SuperServers | 2U | 2028R-ACR24L

Vom Pool Layout dann 2 Z2 vdevs, idealerweise 2 x 10 Disks und eine oder zwei Hotspare Platten.
Man kann auch 12 Platten pro vdev nehmen. Performancetechnisch hat das keine Einbußen. Es gibt halt mehr "Verschnitt" das heißt die Nutzkapazität steigt nicht ganz auf das erhoffte Niveau. Das Einschalten von sicheres Sync Write und damit ein Slog ist für das Backupsystem nicht nötig/sinnvoll


Für das Backup braucht man lediglich NFS oder alternativ iSCSI. SMB Zugriff ist wünschenswert.
Das bietet grundsätzlich jede Option.

Vom OS her gibt es sicher unterschiedliche Meinungen. Meine ist:

Für reines Storage ist Solaris/ OmniOS unschlagbar. Da kommt ZFS und NFS her, alle Dienste wie iSCSI, NFS oder SMB sind Solaris eigene Kerneldienste und alles arbeitet perfekt zusammen. Ist unschlagbar schnell und alles tut einfach out of the box

BSD wäre für mich die nächstbeste Option. Vor allem wenn man weitere Dienste vor allem im Homebereich (z.B. Plex Mediasserver etc) möchte, hat das seine Vorteile.

ZoL sehe ich nur als interessant wenn es unbedingt Linux sein muss oder man Hardware hat die nur hier unterstützt wird oder Anwendungen die es nur hier gibt. Nachteil ist dass ZFS hier ein Dateisystem unter vielen ist und dass es nicht per default dabei ist. Man kriegt es zum Laufen fällt aber bei jedem Update gerne auf die Nase. Es ist aber nicht das "installieren, zweimal ok drücken, tut einfach" von Solaris.
 
Zuletzt bearbeitet:
ZoL sehe ich nur als interessant wenn es unbedingt Linux sein muss oder man Hardware hat die nur hier unterstützt wird oder Anwendungen die es nur hier gibt. Nachteil ist dass ZFS hier ein Dateisystem unter vielen ist und dass es nicht per default dabei ist. Man kriegt es zum Laufen fällt aber bei jedem Update gerne auf die Nase. Es ist aber nicht das "installieren, zweimal ok drücken, tut einfach" von Solaris.

In diesem Zusammenhang will es Canonical mit der nächsten Ubuntu-Version 16.04 wohl mal drauf ankommen lassen und diese inklusive ZFS mit direkter Kernelunterstützung ausliefern:
Diskussionen über ZFS-Dateisystem in Linux-Distribution Ubuntu 16.04*LTS | heise open
 
BSD wäre für mich die nächstbeste Option. Vor allem wenn man weitere Dienste vor allem im Homebereich (z.B. Plex Mediasserver etc) möchte, hat das seine Vorteile.
Könnte man nich dann eher virtualisieren? Dann mache ich das Storage OS direkt auf der Hardware, und erstelle mir eine VM mit Ubuntu Server für Plex. Ich meine Plex unter BSD zu installieren, geht zwar, ist aber auch net ganz so einfach.
 
Zuletzt bearbeitet:
Könnte man nich dann eher virtualisieren? Dann mache ich das Storage OS direkt auf der Hardware, und erstelle mir eine VM mit Ubuntu Server für Plex. Ich meine Plex unter BSD zu installieren, geht zwar, ist aber auch net ganz so einfach.

Geht auch, wenn man virtualisieren will. Läuft bei mir ähnlich mit ESXI und Napp-IT. Dann gibts eine XPEnology-VM mit Plex drin. Plex greift auf eine Freigabe vom ZFS-Filesystem zu und spielt direkt davon ab. Spart Platz in der VM und ich habe das Beste aus beiden Welten. Geht mit anderen Diensten natürlich dann auch.



Dann schiebe ich mal eine Frage von mir hier hinterher: wenn ich Jobs habe (in diesem Fall Replikationsjobs) scheinen die sich gegenseitig zu blockieren. Ich habe den ersten "run" manuell gestartet und wollte gerne das im Anschluss direkt das nächste ZFS-Dateisystem mit eigenem Job startet (per automatic). Von anderen Systemen kenne ich das só, dass ein neuer Job auf "warten" geht und das Ende des aktuell laufenden eben abwartet. Bei mir ist der dann aber auf Fehler gegangen und nicht gestartet. Wie bekomme ich das denn sinnvoll hin, das quasi um 18:00 Job1 startet und Job2 nach dessen Ende sauber anläuft? Ich weiss ja nicht wie lange Job1 braucht?
Kann mir da jemand einen Tipp geben?
 
wenn ich Jobs habe (in diesem Fall Replikationsjobs) scheinen die sich gegenseitig zu blockieren. Ich habe den ersten "run" manuell gestartet und wollte gerne das im Anschluss direkt das nächste ZFS-Dateisystem mit eigenem Job startet (per automatic). Von anderen Systemen kenne ich das só, dass ein neuer Job auf "warten" geht und das Ende des aktuell laufenden eben abwartet. Bei mir ist der dann aber auf Fehler gegangen und nicht gestartet. Wie bekomme ich das denn sinnvoll hin, das quasi um 18:00 Job1 startet und Job2 nach dessen Ende sauber anläuft? Ich weiss ja nicht wie lange Job1 braucht?
Kann mir da jemand einen Tipp geben?

Jede Replikation legt seine eigenen Snapshots an. Da blockiert sich zunächst nichts, man kann alle Jobs prinzipiell zum gleichen Zeitpunkt starten. Ich würde aber dennoch nicht viele Replikationen gleichzeitig sondern versetzt starten da dann jeweils doch viele Aktivitäten, snapshot anlegen oder auflisten verbunden ist. Mit sehr vielen Snaps kann vereinzelt sogar ein Timeout entstehen.

Insgesamt ist das aber bei ZFS unkritisch.
Das schlimmste was passieren kann ist dass man eine Replikation neu starten muss oder im Extremfall den neuesten Snap auf dem Zielsystem vorher löschen muss (ganz selten, bei Unterbrechungen bei der letzten Übertragung)
 
Versetzt starten ist auch meine Wahl, ich möchte möglichst dass jeder Job mit max. Leistung zu Ende läuft. Daher hätte ich gerne so etwas wie eine Warteschlange, denn:

1. soll der Backup Rechner nicht den ganzen Tag laufen.
2. weiss ich ja nie wie lange welcher Job läuft.
3. Möchte ich möglichst die Jobs nicht manuell starten müssen ;) Ich stehe auf funktionierende Automatismen.

Ein einziger Replikationsjob wäre zwar ideal dafür, aber da der rekursiv sein müsste und das nicht empfohlen wird, fällt das ja aus.
 
Da die Replikation bis aufs erste Mal inkrementell arbeitet, gehen Folgereplikation sehr schnell
Also einfach gleichzeitig starten.
 
Habe OmniOS+Nappit auf meinem Server laufen und ein Problem mit VirtualBox:

Wenn ich den Netzwerk Adapter einer VM auf Bridge stelle kommt immer die Fehlermeldung
Failed to open/create the internal network 'HostInterfaceNetworking-bge0' (VERR_SUPDRV_COMPONENT_NOT_FOUND). Failed to attach the network LUN (VERR_SUPDRV_COMPONENT_NOT_FOUND)

Ich habe bei meinem Server nichts verändert, nur die IP gewechselt und seitdem funktioniert es nicht mehr. Sowohl neue VMs zeigen diesen Fehler an, als auch alte die vorher problemlos liefen.

Ist da vielleicht noch irgendwie die alte IP wo eingetragen?
 
Zuletzt bearbeitet:
Ich kann jetzt zu Virtualbox nichts beitragen da ich das nicht nutze.
Eine Bridge arbeitet aber auf osi level 2 wie ein Switch oder Hub.
Die Fehlermeldung meckert dann ja auch Probleme mit open/connect Interface bge0 an und kein ip connect Problem

Wurde an den Links/Interfaces was geändert?
Gibt es einen BE/ bootfähigen Snap als es noch funktioniere?
 
Habe OmniOS+Nappit auf meinem Server laufen und ein Problem mit VirtualBox:

Wenn ich den Netzwerk Adapter einer VM auf Bridge stelle kommt immer die Fehlermeldung

Ich habe bei meinem Server nichts verändert, nur die IP gewechselt und seitdem funktioniert es nicht mehr. Sowohl neue VMs zeigen diesen Fehler an, als auch alte die vorher problemlos liefen.

Ist da vielleicht noch irgendwie die alte IP wo eingetragen?

Versuche mal Folgendes als root:
Code:
rem_drv vboxflt
add_drv vboxflt

Danach VM im Bridged-Mode starten.
 
Kann mir jemand mal den Unterschied zwischen keep und hold erklären?
Meine Snapshots laufen gerade so:

snaps.jpg

z.B. alle 15 Minuten einer - keep 4 dachte ich ok, die letzten 4 x 15 minuten bleiben stehen. danach wird der erste der 15 minuten gelöscht.
Hold sagt ja aber 30 Tage behalten.

Irgendwie will mir gerade der Unterschied nicht ins Hirn, vll. weil es Sonntag ist.
Aber meine 15min. Snaps sind seit gestern (da hab ich gestartet) halt noch alle da und werden wohl auch die kommenden 30 tage bleiben? Aber wofür dann das keep?
 
Hatte endlich wieder etwas Zeit am Backup weiterzumachen. Hab OmniOS r151016 auf meinen HP Microserver gemacht. WoL scheint zu funktionieren. Wollte nun meine 151014 LTS VM auf 151016 hochziehen aber das Upgrade bricht immer ab. Jemand schon das Problem gehabt? Irgendwas mit OpenSSL scheint wohl das Problem zu verursachen.
 
Zuletzt bearbeitet:
Hatte endlich wieder etwas Zeit am Backup weiterzumachen. Hab OmniOS r151016 auf meinen HP Microserver gemacht. WoL scheint zu funktionieren.

Welchen Microserver hast Du und wie hast Du das mit WOL hinbekommen? Gibt es eigentlich generell unterstütze NICS mit WOL für OmniOS?
 
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