Buildlog 📋 Synology DS2xx+ "Ersatz" - Eigenbau (TrueNAS)

Was sagt ihr eigentlich dazu?
Ich persönlich kann da gar nicht so viel beitragen, da du definitiv der Experte in der Thematik bist. Von daher verfolge ich deinen Thread ja bereits von Anfang an mit großem Interesse und ziehe mir selbst Input und Inspiration.
Daher eher eine Frage als ein Denkanstoß: Wäre es nicht denkbar, dass du Proxmox verwendest und TrueNAS als VM betreibst? SATA und LAN könntest du ja durchreichen, der Performance dürfte das kaum schaden, oder? Gleichzeitig könntest du auf der NVMe performant die Container betreiben.
Habe ich einen Denkfehler?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich persönlich kann da gar nicht so viel beitragen, da du definitiv der Experte in der Thematik bist.
Ich und Experte, schön wärs :LOL:

Von daher verfolge ich deinen Thread ja bereits von Anfang an mit großem Interesse und ziehe mir selbst Input und Inspiration.
Finde ich super (y)

Daher eher eine Frage als ein Denkanstoß: Wäre es nicht denkbar, dass du Proxmox verwendest und TrueNAS als VM betreibst? SATA und LAN könntest du ja durchreichen, der Performance dürfte das kaum schaden, oder? Gleichzeitig könntest du auf der NVMe performant die Container betreiben.
Ich habe aktuell ja sowieso einen Docker Host auf meiner Proxmox Maschine laufen. dort läuft auch die Firewall (als Vm nicht als Docker Container :LOL:)
Daher habe ich mir gedacht, ggf. den Storage getrennt von den Apps laufen zu lassen.

Natürlich könnte man das auch so machen, wie du beschrieben hast 😉

Habe ich einen Denkfehler?
Nein, alles korrekt (y)
 
Tag 29:
Staubfilterei ei ei ei

Eigentlich wollte ich einen fertigen Staubfilter vor den Lüfter der NAS Systeme hängen,
leider gibt es keine passende Lösung für 92mm Lüfter :cry:

So exotisch sind die doch nicht?

Also Lösung hatte ich mir so etwas ausgesucht:

Da wird der Filter magnetisch auf dem Rahmen gehalten und kann einfach zum Reinigen abgenommen werden.
Leider nur für 120er Lüfter verfügbar.


Jetzt werde ich mir wohl aus diesem 3D Modell eine eigene Variante bauen, welche auch magnetisch gehalten wird und damit leicht zu reinigen ist.

Die Filtergitter aus Nylon gibt es zum Glück günstig zu kaufen :-)




Zum Thema Docker, werde ich zu 90% auf die Variante mit NFS setzen.
Damit habe ich alle Docker Container auf einer VM auf meinem Proxmox Host laufen, schön zentral verwaltet.

Den ersten Test werde ich mit der wichtigsten Application machen, miniDLNA 8-)
 
Tag 30:
USV Akku hinüber?

Habe eben mal die USV sowie die Email Notifications testen wollen.

Nur war das Verhalten anders als gedacht, folgende Settings sind eingestellt:
Screenshot_20230502_195325.png

Nur hat die USV das NAS nicht die eingestellten 30 Sekunden versorgt, sondern nach 10 Sekunden war Zappenduster :oops:

Ist der Akku der USV (Eaton 3S 550) hinüber?
Ich werde aus dem Emails nicht ganz schlau :confused:

1. Mail:
Screenshot_20230502_195422.png

2. Mail:
Screenshot_20230502_195440.png

Aktueller Status der USV:
Code:
battery.charge: 100
battery.charge.low: 20
battery.runtime: 1312
battery.type: PbAc
device.mfr: EATON
device.model: Eaton 3S 550
device.serial: 000000000
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.data: MGE HID 1.40
driver.version.internal: 0.41
input.transfer.high: 264
input.transfer.low: 184
outlet.1.desc: PowerShare Outlet 1
outlet.1.id: 2
outlet.1.status: on
outlet.1.switchable: yes
outlet.2.desc: PowerShare Outlet 2
outlet.2.id: 3
outlet.2.status: off
outlet.2.switchable: yes
outlet.desc: Main Outlet
outlet.id: 1
outlet.switchable: no
output.frequency.nominal: 50
output.voltage: 230.0
output.voltage.nominal: 230
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.firmware: 02
ups.load: 16
ups.mfr: EATON
ups.model: Eaton 3S 550
ups.power.nominal: 550
ups.productid: ffff
ups.serial: 000000000
ups.status: OL
ups.timer.shutdown: 0
ups.timer.start: 0
ups.vendorid: 0463

Was will mir TrueNAS hier sagen?
 
Tag 31:
ZFS Replication

Mit dem Problem der USV, werde ich mich die nächsten Tage beschäftigen.
Zuerst wollte ich endlich das automatische Backup einrichten.

Da die Snapshot Replication in TrueNAS (glaube allgemein bei ZFS) nur einen Wert für die Speicherdauer eines Snapshots zulässt (Data Rentention),
habe ich erstmal einen manuellen Snapshot ohne Ablaufdatum auf dem Quell-NAS erstellt.

Hintergrund ist der, das alle Snapshots inkrementell auf einem kompletten Snapshot aufbauen, also nur die Änderungen zu diesem speichern.
Sollte der initiale Snapshot aber automatisch nach z.B. 2 Wochen gelöscht werden, fängt der nachfolgende Snapshot wieder bei Null an und muss zuerst alle Daten komplett neu rüberkopieren.

Das ist über eine Deutsche Internetleitung mit nur 50MBit/s Upload nicht so geil :fresse:

Deshalb mache ich die initialen Snapshots noch Lokal im Heimnetz und danach geht das 2. NAS erst Offsite.


Weitere wichtige Info am Rande:
Diese ist eigentlich nirgens dokumentiert und hat mir einige Stunden Problemsuche verursacht.
Und zwar muss als Ziel logischerweise der gewünschte Pool ausgewählt werden, und es darf kein vorhandendes Dataset ausgewählt werden.
Sondern es muss der Name des Quell Datasets auf dem Ziel eingetragen werden.

Also:
Quelle: datenpool/dataset1
wird zu Ziel: backuppool/dataset1

Dieses Dataset darf auf dem Ziel auch noch nicht vorhanden bzw. erstellt sein.
Das macht der Replication Task selbst!
 
Tag 31:
ZFS Replication

Mit dem Problem der USV, werde ich mich die nächsten Tage beschäftigen.
Zuerst wollte ich endlich das automatische Backup einrichten.

Da die Snapshot Replication in TrueNAS (glaube allgemein bei ZFS) nur einen Wert für die Speicherdauer eines Snapshots zulässt (Data Rentention),
habe ich erstmal einen manuellen Snapshot ohne Ablaufdatum auf dem Quell-NAS erstellt.

ZFS macht hier garnichts. Wie lange man einen Snapshot aufhebt liegt nur am Replikations oder Autosnap Scropt.
Hintergrund ist der, das alle Snapshots inkrementell auf einem kompletten Snapshot aufbauen, also nur die Änderungen zu diesem speichern.
Sollte der initiale Snapshot aber automatisch nach z.B. 2 Wochen gelöscht werden, fängt der nachfolgende Snapshot wieder bei Null an und muss zuerst alle Daten komplett neu rüberkopieren.

Jein, eigentlich nein. Ein Snapshot speichert nicht wie inkrementelle Backups geänderte Daten zum vorherigen Snap. Jeder Snap zeigt das komplette Dateisystem mit allen Daten zum Snapzeitpunkt. Ein ZFS Snapshot speichert generell nichts. ZFS funktioniert anders: Wegen Copy on Write werden keine Daten überschrieben sondern immer neu angelegt. Der Platz den die vorherigen Daten belegt hatten wird dann freigegeben. Legt man einen Snap an, so wird der vorherige Stand gesperrt. ZFS Snaps verbrauchen also keinen Platz sondern verhindern dass ältere Datenbereiche überschrieben werden können.

Für eine inkrementelle ZFS Replikation benötigt man auf Quelle/Ziel ein identisches Snapshotpaar. Das liegt daran dass eine ZFS Replikation keinen Datenvergleich wie rsync durchführt, sondern das Zieldateisystem per rollback auf den letzten gemeinsamen Snap zurücksetzt und dann den neuen Snap mit den geänderten Daten als Stream sendet (mehrfach so schnell wie rsync). Diesen gemeinsamen Snap darf man nicht löschen sonst kann man die inkrementelle Replikation nicht fortsetzen.

Weitere wichtige Info am Rande:
Diese ist eigentlich nirgens dokumentiert und hat mir einige Stunden Problemsuche verursacht.

ZFS ist eigentlich sehr gut dokumentiert, angefangen von der Oracle Solaris ZFS Originaldokumentation die auch bei Open-ZFS in den Grundlagen zu >90% gültig ist. Für "ZFS Neulinge" gilt es aber umzudenken. ZFS mach vieles anders, meist besser.

Und zwar muss als Ziel logischerweise der gewünschte Pool ausgewählt werden, und es darf kein vorhandendes Dataset ausgewählt werden.
Sondern es muss der Name des Quell Datasets auf dem Ziel eingetragen werden.

Stimmt so nicht. Als Ziel wählt man ein ZFS Dateisystem. Das zu übertragende Dateisystem wird darunter angelegt. Dieses neue Dateisytem darf noch nicht existieren.

Also:
Quelle: datenpool/dataset1
wird zu Ziel: backuppool/dataset1

Dieses Dataset darf auf dem Ziel auch noch nicht vorhanden bzw. erstellt sein.
Das macht der Replication Task selbst!
 
ZFS macht hier garnichts. Wie lange man einen Snapshot aufhebt liegt nur am Replikations oder Autosnap Scropt.
Dann ist das also ein Thema von TrueNAS :unsure:
Hier lässt sich für den Snapshot Task nur eine Speicherzeit (mir fällt jetzt nicht der passende Begriff ein) konfigurieren.
Also z.B. 2 Wochen. Damit würde es nach 2 Wochen den ersten Snapshot wegwerfen, was eigentlich keinen Sinn macht, da es ja der initiale ist.

Jein, eigentlich nein. Ein Snapshot speichert nicht wie inkrementelle Backups geänderte Daten zum vorherigen Snap. Jeder Snap zeigt das komplette Dateisystem mit allen Daten zum Snapzeitpunkt. Ein ZFS Snapshot speichert generell nichts. ZFS funktioniert anders: Wegen Copy on Write werden keine Daten überschrieben sondern immer neu angelegt. Der Platz den die vorherigen Daten belegt hatten wird dann freigegeben. Legt man einen Snap an, so wird der vorherige Stand gesperrt. ZFS Snaps verbrauchen also keinen Platz sondern verhindern dass ältere Datenbereiche überschrieben werden können.
Ja, das ist mir auch klar das es ein CoW Dateisytem ist. Da habe ich mich wohl etwas blöde ausgedrückt 😅
Ich wollte das so einfach wie möglich erklären.

Für eine inkrementelle ZFS Replikation benötigt man auf Quelle/Ziel ein identisches Snapshotpaar. Das liegt daran dass eine ZFS Replikation keinen Datenvergleich wie rsync durchführt, sondern das Zieldateisystem per rollback auf den letzten gemeinsamen Snap zurücksetzt und dann den neuen Snap mit den geänderten Daten als Stream sendet (mehrfach so schnell wie rsync). Diesen gemeinsamen Snap darf man nicht löschen sonst kann man die inkrementelle Replikation nicht fortsetzen.
Genau, das ist das Problem das ich meinte. Der erste Snapshot braucht eine "Speicherzeit" von unendlich.

ZFS ist eigentlich sehr gut dokumentiert, angefangen von der Oracle Solaris ZFS Originaldokumentation die auch bei Open-ZFS in den Grundlagen zu >90% gültig ist.
In der TrueNAS Scale Doku war dieses Thema überhaupt nicht dokumentiert. Da bringt mir die Oracle Dokumentation gar nichts, da diese ja nicht der GUI von TrueNAS entspricht. Von der CLI sollte man unter TrueNAS die Finger lassen, da macht man mehr kaputt als das es hilft.

Stimmt so nicht. Als Ziel wählt man ein ZFS Dateisystem. Das zu übertragende Dateisystem wird darunter angelegt. Dieses neue Dateisytem darf noch nicht existieren.
Der Pool ist im Falle eines TrueNAS System das Dateisystem. Alle Datasets werden darunter erstellt.
 
Dann ist das also ein Thema von TrueNAS :unsure:
Hier lässt sich für den Snapshot Task nur eine Speicherzeit (mir fällt jetzt nicht der passende Begriff ein) konfigurieren.
Also z.B. 2 Wochen. Damit würde es nach 2 Wochen den ersten Snapshot wegwerfen, was eigentlich keinen Sinn macht, da es ja der initiale ist.

Man muss da zwischen "normalen" Snapshots und denen die man für Replikation braucht unterscheiden. In meinen Scripts benenne ich die unterschiedlich.

Genau, das ist das Problem das ich meinte. Der erste Snapshot braucht eine "Speicherzeit" von unendlich.

Gerade nicht. Der erste Snapshot ist unerheblich. Man braucht den letzten gemeinsamen. Alle älteren kann man löschen.

In der TrueNAS Scale Doku war dieses Thema überhaupt nicht dokumentiert. Da bringt mir die Oracle Dokumentation gar nichts, da diese ja nicht der GUI von TrueNAS entspricht. Von der CLI sollte man unter TrueNAS die Finger lassen, da macht man mehr kaputt als das es hilft.

Auch wenn man bei TrueNAS (leider) keine ZFS Befehle absetzen sollte (manchmal sehr nützlich, war mir bei meiner GUI sehr wichtig), so ist es doch sehr hilfreich ZFS zu verstehen. Letztendlich machen alle ZFS Server lediglich Gebrauch von den Möglichkeiten der beiden Befehle zfs und zpool. Eine GUI kann Abläufe automatisieren oder Extras jenseits der ZFS Optionen hinzufügen (HA, Autolock/unlock etc)

Der Pool ist im Falle eines TrueNAS System das Dateisystem. Alle Datasets werden darunter erstellt.

Ein Pool z.B. tank ist auch ein ZFS Dateisystem, genau wie z.B. tank/data. Dataset ist übrigens der Oberbegriff für Dateisysteme, Snaps und Zvols. Es ist hilfreich das jeweils exakt zu benennen um Missverständnisse zu vermeiden.
 
Zuletzt bearbeitet:
Ich habe das bei ZFS noch nie "tank" benannt.
 
In den ZFS Originaldokus von Sun/Oracle heißt der Beispielpool immer tank (tank wie Pool/Becken, nicht wie Panzer)
 
Erstmal sorry, für die späte Antwort 😅

Man muss da zwischen "normalen" Snapshots und denen die man für Replikation braucht unterscheiden. In meinen Scripts benenne ich die unterschiedlich.
Also ich habe stündlich einen Snapshot auf NAS 1. Dieser wird einmal Täglich von NAS 2 gezogen (Pull Modus).
Zumindest ist das die aktuelle Konfiguration.

Gerade nicht. Der erste Snapshot ist unerheblich. Man braucht den letzten gemeinsamen. Alle älteren kann man löschen.
Das verwirrt mich.
Ich verstehe das so:
Erster Snapshot z.B. 2TB groß, alle weiteren nur wenige MB groß wie die Änderungen.
Die sind alle per Replication auf das 2. NAS gezogen.
Wenn ich jetzt den ältesten, also den ersten, lösche fehlt doch der Großteil der Daten.

Oder verstehe ich das einfach komplett falsch?

Auch wenn man bei TrueNAS (leider) keine ZFS Befehle absetzen sollte (manchmal sehr nützlich, war mir bei meiner GUI sehr wichtig), so ist es doch sehr hilfreich ZFS zu verstehen. Letztendlich machen alle ZFS Server lediglich Gebrauch von den Möglichkeiten der beiden Befehle zfs und zpool. Eine GUI kann Abläufe automatisieren oder Extras jenseits der ZFS Optionen hinzufügen (HA, Autolock/unlock etc)
Glaub ich dir, nur will ich nicht in der CLI rumfummeln und mir ggf. was von der TrueNAS Config zerschießen.
Am ZFS verstehen bin ich dran, versuche permanent was dazu zu lernen.

Ein Pool z.B. tank ist auch ein ZFS Dateisystem, genau wie z.B. tank/data. Dataset ist übrigens der Oberbegriff für Dateisysteme, Snaps und Zvols. Es ist hilfreich das jeweils exakt zu benennen um Missverständnisse zu vermeiden.
Dann benennt das TrueNAS wohl falsch :rofl:
Dort erstelle ich auf dem Pool ein Dataset, das ich z.B. freigeben kann per Share oder Snapshots von erstellen kann.
Das wird quasi wie ein Ordner behandelt.
 
Wenn ich jetzt den ältesten, also den ersten, lösche fehlt doch der Großteil der Daten.

Oder verstehe ich das einfach komplett falsch?
Ich bin mir sehr sicher, dass du das falsch verstehst. In dem Moment in dem du den ältesten Snapshot löschst, verlierst du nur die Möglichkeit diesen ältesten Zustand wiederherzustellen. Man kann sich ausgeben lassen wie viel Platz ein Snapshot benötigt. In dem Moment in dem du den ältesten Snapshot löschst, müsste der neue älteste (ehemals zweitälteste) Snapshot im Platzbedarf wachsen.
 
Wenn der älteste Snapshot aber der "Hauptsnapshot" ist und alle nachfolgenden nur inkrementell darauf basieren?

Ich stehe echt auf dem Schlauch 😅
 
Erstmal sorry, für die späte Antwort 😅


Also ich habe stündlich einen Snapshot auf NAS 1. Dieser wird einmal Täglich von NAS 2 gezogen (Pull Modus).
Zumindest ist das die aktuelle Konfiguration.

Snapshots kann man zum Versionieren benutzen. Jeder Snap (auch die kleinen Folgesnaps) zeigt den kompletten Datenstand also nicht nur geänderte Daten. Man kann die daher beliebig löschen und verliert nur die Version zu dem Zeitpunkt.

Will man fortlaufende inkrementelle Replikationen haben darf man allerdings das gemeime letzte Snappaar nicht löschen.

Das verwirrt mich.
Ich verstehe das so:
Erster Snapshot z.B. 2TB groß, alle weiteren nur wenige MB groß wie die Änderungen.
Die sind alle per Replication auf das 2. NAS gezogen.
Wenn ich jetzt den ältesten, also den ersten, lösche fehlt doch der Großteil der Daten.

Oder verstehe ich das einfach komplett falsch?

Ja. Bei einem klassischen Backup macht man ein Vollbackup mit allen Daten und danach inkrementelle Backups. Diese halten dann nur geänderte Daten. ZFS Snaps sind anders. Jeder Snap (auch bei size=0) zeigt die kompletten 2 TB (wird halt bei Copy on Write nichts kopiert sondern nur vorhandene Daten vor Überschreiben geschützt.)

Glaub ich dir, nur will ich nicht in der CLI rumfummeln und mir ggf. was von der TrueNAS Config zerschießen.
Am ZFS verstehen bin ich dran, versuche permanent was dazu zu lernen.

In meiner GUI lese ich den ZFS Status bei jedem Menüaufruf ein und puffere den allenfalls kurz. Damit kann man auch außerhalb der GUI was ändern. Nachteil ist eine geringere Menüperformance. Alternnativ kann man ZFS Sachen dauerhaft speichern. Dann darf man allerdings nichts außerhalb der GUI machen.

Dann benennt das TrueNAS wohl falsch :rofl:
Dort erstelle ich auf dem Pool ein Dataset, das ich z.B. freigeben kann per Share oder Snapshots von erstellen kann.
Das wird quasi wie ein Ordner behandelt.

Nein, schon richtig. Lediglich die Benennung ist nicht ganz präzise. Ein Pool ist das "Eltern" Dateisystem auf dem weitere Dateisysteme angelegt werden können. Dataset ist allerdings etwas unpräzise. Dateisystem ist besser da Snaps und Zvols auch datasets sind.

Da Linux und BSD aber immer mit SAMBA arbeiten, gibt es keine strikte Zuordnung von ZFS Dateisystem mit SMB Share. SAMBA weiß nichts von ZFS sondern sieht nur einfache Ordner. Da Snaps und manche Eigenschaften wie Zeichensatz oder Groß/Kleinschreibung strikt zu einem ZFS Dateisystem gehören muss man dann bei der SAMBA Konfiguration achtgeben. Ganz schön blöd, wenn ein ZFS Dateisystem im SMB Share zwischen Groß und Kleinschreibung unterscheidet und ein anderes nicht.

Solaris mit dem OS/ZFS eigenen SMB Server arbeitet da anders. Da ist ein NFS oder SMB Share tatsächlich und ausschließlich eine Eigenschaft eines ZFS Dateisystems
 
Zuletzt bearbeitet:
Snapshots kann man zum Versionieren benutzen. Jeder Snap (auch die kleinen Folgesnaps) zeigt den kompletten Datenstand also nicht nur geänderte Daten. Man kann die daher beliebig löschen und verliert nur die Version zu dem Zeitpunkt.
Also ist das so zu verstehen?
Ich hab jetzt z.B. die zwei Snapshots, den ersten mit den vollen 2TB und den zweiten mit den geänderten 5MB. Wenn ich jetzt den ersten lösche, dann wird (vereinfacht erklärt) die 2TB in den 2. Snapshot integriert, nur eben mit den geänderten 5MB?


Will man fortlaufende inkrementelle Replikationen haben darf man allerdings das gemeime letzte Snappaar nicht löschen.
Was meinst du mut dem letzten gemeinsamen Snappaar?
das von NAS1 und NAS2 oder beide auf NAS2?

Mir geht es darum die Daten wieederherstellen zu können wenn das 1. NAS geklaut, abgebrannt oder sonstwas ist.


Ja. Bei einem klassischen Backup macht man ein Vollbackup mit allen Daten und danach inkrementelle Backups. Diese halten dann nur geänderte Daten. ZFS Snaps sind anders. Jeder Snap (auch bei size=0) zeigt die kompletten 2 TB (wird halt bei Copy on Write nichts kopiert sondern nur vorhandene Daten vor Überschreiben geschützt.)
Gilt das auch für die replizierten Snapshots die auf dem 2. NAS liegen?
 
Also ist das so zu verstehen?
Ich hab jetzt z.B. die zwei Snapshots, den ersten mit den vollen 2TB und den zweiten mit den geänderten 5MB. Wenn ich jetzt den ersten lösche, dann wird (vereinfacht erklärt) die 2TB in den 2. Snapshot integriert, nur eben mit den geänderten 5MB?
Vereinfacht ja.
Es wid jedoch nichts integriert da keine Daten verschoben oder kopiert werden. Ein ZFS Snap schützt vorhandene Datenblöcke vor Überschreiben, egal welcher Snap für diesen Schutz verantwortlich ist. Erst wenn kein Snap mehr einen Datenbereich blockiert, kann dieser Bereich neu beschrieben werden.

Was meinst du mut dem letzten gemeinsamen Snappaar?
das von NAS1 und NAS2 oder beide auf NAS2?

ZFS Replikation ist ein Verfahren um ein Dateisystem 1:1 zu kopieren. Man kann beide dann mit weiteren inkrementellen Replikationen syncron halten wobei nur geänderte Daten übertragen werden. Dabei werden auch offene Dateien aus dem Snapshot mit übertragen. Im Gegensatz zu z.B. rsync findet dabei aber kein Dateivergleich statt. Das Verfahren ähnelt eher einem Hörbuch dessen einzelne Kapitel per Radio gesendet und aufgezeichnet werden sollen. Damit das Ergebnis korrekt ist, muss bei jeder neuen Folge die Aufzeichnung am Ende des vorherigen Kapitels fortgesetzt werden.

Erstreplikation:
ZFS macht einen Snap des Quelldateisystems Q1 und übertägt diesen. Nach erfolgreicher Übertragung wird auf dem Ziel auch ein Snap Z1 erstellt. Diese beiden Snaps sind exakt identisch und bilden ein Snappaar für eventuelle Folgereplikationen.

Folgereplikation
ZFS macht einen Snap des Quelldateisystems Q2 und übertägt die geänderten Datenblöcke von Q1 als Datenstrom. Dieser Datenstrom wird in das Zieldateisystem integriert. Damit das zum gleichen Ergebnis führt wie der Stand von Q2 muss das Zieldateisystem vor der Übertragung einen identischen Stand zu Q1 haben z.B. per ZFS rollback. Nach erfolgreicher Übertragung gibt es einen neuen Zielsnap Z2. Q2 und Z2 bilden damit die Basis der nächsten Replikation.

Warum so und nicht anders?
Ein Sync auf Basis eines Dateivergleichs ist viel viel langsamer als ein Datenstrom geänderter Dtenblöcke. Ein rsync eines großen Dateisystems kann Tage dauern, per inkrementellem ZFS sync kann man Terabytes eines Hochlastservers bis herunter zu einer Minute Verzögerung syncron halten.


Mir geht es darum die Daten wieederherstellen zu können wenn das 1. NAS geklaut, abgebrannt oder sonstwas ist.

Ein repliziertes Dateisystem ist eine exakte Kopie des Originaldateisystems.

Gilt das auch für die replizierten Snapshots die auf dem 2. NAS liegen?

Ja und nein. Da das Ziel vor jeder Folgereplikation ein rollback macht, werden dabei ältere Zielsnaps gelöscht sofern nicht das Replikationsscript dafür sorgt dass diese erhalten bleiben. Bei meinem Script kann man einstellen dass z.B. für einen Tag, Woche, Monat, Jahr eine Anzahl von Snaps auf dem 2.NAS erhalten bleiben. Ich vermute mal dass TrueNAS was ähnliches kann.
 
Vereinfacht ja.
Es wid jedoch nichts integriert da keine Daten verschoben oder kopiert werden. Ein ZFS Snap schützt vorhandene Datenblöcke vor Überschreiben, egal welcher Snap für diesen Schutz verantwortlich ist. Erst wenn kein Snap mehr einen Datenbereich blockiert, kann dieser Bereich neu beschrieben werden.
Top, endlich habe ich es verstanden (y)

ZFS Replikation ist ein Verfahren um ein Dateisystem 1:1 zu kopieren. Man kann beide dann mit weiteren inkrementellen Replikationen syncron halten wobei nur geänderte Daten übertragen werden. Dabei werden auch offene Dateien aus dem Snapshot mit übertragen. Im Gegensatz zu z.B. rsync findet dabei aber kein Dateivergleich statt. Das Verfahren ähnelt eher einem Hörbuch dessen einzelne Kapitel per Radio gesendet und aufgezeichnet werden sollen. Damit das Ergebnis korrekt ist, muss bei jeder neuen Folge die Aufzeichnung am Ende des vorherigen Kapitels fortgesetzt werden.

Erstreplikation:
ZFS macht einen Snap des Quelldateisystems Q1 und übertägt diesen. Nach erfolgreicher Übertragung wird auf dem Ziel auch ein Snap Z1 erstellt. Diese beiden Snaps sind exakt identisch und bilden ein Snappaar für eventuelle Folgereplikationen.

Folgereplikation
ZFS macht einen Snap des Quelldateisystems Q2 und übertägt die geänderten Datenblöcke von Q1 als Datenstrom. Dieser Datenstrom wird in das Zieldateisystem integriert. Damit das zum gleichen Ergebnis führt wie der Stand von Q2 muss das Zieldateisystem vor der Übertragung einen identischen Stand zu Q1 haben z.B. per ZFS rollback. Nach erfolgreicher Übertragung gibt es einen neuen Zielsnap Z2. Q2 und Z2 bilden damit die Basis der nächsten Replikation.

Warum so und nicht anders?
Ein Sync auf Basis eines Dateivergleichs ist viel viel langsamer als ein Datenstrom geänderter Dtenblöcke. Ein rsync eines großen Dateisystems kann Tage dauern, per inkrementellem ZFS sync kann man Terabytes eines Hochlastservers bis heruntzer zu einer Minute Verzögerung syncron halten.
Ah, jetzt hab ichs kapiert. Ich brauche auf beiden Geräten den "gleichen" Ausgangssnapshot um die geänderten Datenblöcke übertragen zu können.
Aber dieser Ausgangssnapshot muss nicht der erste sein, sondern nur identisch.

Hatte jetzt die Angst, das wenn NAS1 fehlt, auch die Daten auf NAS2 futsch sind. Da hatte ich das falsch verstanden.
Es geht helt eben nur nicht mehr, Snapshots zu ziehen. Das ist ja nicht weiters schlimm 😅

Ein repliziertes Dateisystem ist eine exakte Kopie des Originaldateisystems.
Genau das möchte ich (y)

Ja und nein. Da das Ziel vor jeder Folgereplikation ein rollback macht, werden dabei ältere Zielsnaps gelöscht sofern nicht das Replikationsscript dafür sorgt dass diese erhalten bleiben. Bei meinem Script kann man einstellen dass z.B. für einen Tag, Woche, Monat, Jahr eine Anzahl von Snaps auf dem 2.NAS erhalten bleiben. Ich vermute mal dass TrueNAS was ähnliches kann.
Ja, ich kann einstellen, mache täglich eine Snapshot Replikation und hebe die Snaphots 2 Wochen auf z.B.
 
Tag 32:
Snapshot Setup für dataset1

Auf dem Quell-NAS (NAS1):
Snapshot1.png

1. Snapshot wird stündlich durchgeführt und für eine Woche aufgehoben
2. Snapshot wird täglich durchgeführt und für drei Monate aufgehoben
3. Snapshot wird monatlich durchgeführt und für 1 Jahr aufgehoben


Auf dem Ziel-NAS (NAS1):
Snapshot1_Replication.png

Hier werden einmal täglich die Snapshots repliziert.
Wobei diese vom NAS2 gezogen "Pull" und nicht vom NAS1 gesendet "PUSH" werden.

Der Hintergrund ist, das so durch dem Umzug des NAS2 an einen anderen Standort, keine IP Konfiguration notwendig wird.
Die IP des Quell NAS ist immer gleich.
 
Tag 33
Docker und NFS

Wie ich es schon bei Tag 28 geschrieben hatte, bin ich aktuell mit TrueNAS Scale sehr zufrieden.
Und auch mit Docker in Verbindung mit TrueNAS, habe ich mich nun einige Zeit beschäftigt.


Wie ja bekannt ist, hat TrueNAS nicht so richtig eine native Docker Unterstützung. Man kann zwar Docker Container in Kubernetes „irgendwie“ integrieren. Aber das geht eher in die Richtung einer Bastellösung.
Auch die TrueNAS Scale Apps „behelfen“ sich diesem Trick. Des Weiteren haben diese noch einen signifikanten Nachteil → man kann diese nicht auf einem verschlüsselten Dataset ablegen.

Das nachträgliche Installieren von Docker ist auch keine praktikable Lösung. Da nicht sichergestellt werden kann, dass dies nach einem Update noch zuverlässig funktioniert.


Meine ersten Lösung war, die Container in meiner Docker VM auf meinem Proxmox System laufen zu lassen und die Daten per NFS auf dem NAS abzulegen. Um das ganze robuster zu gestalten, sollten die NFS Shares immer über Docker Volumes in den Container eingebunden werden.

Das geht soweit gut, bis:
  • der Container Benutzer- und Gruppenrechte ändern möchte
  • das Netzwerk einen „Schluckauf“ hat
  • das NFS Share nicht mehr verfügbar ist


Nach einigem probieren und testen sowie dem kurzzeitigen produktiven Betrieb, musste ich feststellen dass dies nicht die Endgültige Lösung sein kann.
Durch einiges an Recherche in diesem Bereich, hat mich dann schlussendlich Level1Techs auf die wohl richtige Lösung geführt.

Vorab zwei Begriffserklärungen:
  • br0 = Netzwerkbrücke zwischen Host und Gast
  • enp1s0 = Netzwerkkarte des Hosts

Im angehängten Video, wird genau auf das Problem eingegangen und mit einer eigentlich genialen Lösung behoben:



Man nutzt die von TrueNAS Scale zur Verfügung gestellte VM Funktionalität und richtet sich damit ein Docker Host direkt auf dem Storage System ein.

Die im Video beschriebene Netzwerklösung, ist aber nicht zu empfehlen. Diese wurde durch eine simplere und clevere Variante in der folgenden ergänzenden Anleitung unter „Stage 6“ ersetzt.


Des Weiteren wird das NFS Share nicht mehr über Docker Volumes gemountet, sondern direkt im Docker Host, also der VM auf dem TrueNAS Scale System.

Dieses ganze Konzept hat folgende Vorteile:
  • die virtuelle Festplatte der VM kann auf einem verschlüsselten Dataset abgelegt werden
  • die Daten der Docker Container werden auf einem NFS Share abgelegt, welches auf einem verschlüsselten Dataset liegt
  • es ist für die Container problemlos möglich Benutzer- und Gruppenrechte des NFS Mounts zu ändern
  • es gibt ein dediziertes internes Netzwerk „br0“ zwischen dem Host und Gast (externe Verbindung zum Heimnetzwerk ist für die Container parallel möglich)
  • die VM und die resultierende NFS Verbindung läuft immer nur dann, wenn auch der Host und damit das NFS Share verfügbar ist.

Natürlich gibt es auch Nachteile:
  • etwas aufwändigere Erstkonfiguration
  • das Betriebssystem der VM muss zusätzlich gepflegt werden


Die Einrichtung der VM war nicht viel anders als unter Proxmox, wobei eine Sache extrem auffiel.
Die Schreib- und Leserate der virtuellen Festplatte war extrem langsam, so langsam das sich Ubuntu Server nicht installieren lies.
Dies schien ein bekanntes Problem unter TrueNAS Scale zu sein, was schon seit einiger Zeit nicht behoben ist.

Witzigerweise ist dies aber kein Bug oder Softwarefehler, vielmehr ist es eine falsche Default Einstellung im VM Wizard von TrueNAS.
Dort wird standardmäßig eine AHCI Emulation ausgewählt, welche extrem langsam ist.
Einfaches umstellen auf VirtIO behebt das Problem sofort!


Die Installation von Ubuntu Server braucht keiner weiteren Erklärung, davon gibt's genug im Netz.
Das einzige was es zu beachten gilt ist, das man noch die Netzwerkbrücke (welche man vorher unter TrueNAS eingerichtet hat, beschrieben im verlinkten Guide) als weitere Netzwerkkarte hinzufügt, sodass man im Gast zum Schluss zwei Netzwerkkarten, einmal nach draußen und einmal für internen Verkehr einrichtet.


Anbei habe ich mal eine einfache Grafik erstellt, welche den aktuellen Softwareaufbau verdeutlicht:
Aufbau-1_Grafik-1.png
 
Tag 33 Update 1

Hier mal ein paar Screenshots der oben beschriebenen Konfiguration

enp1s0 ist der physikalische Netzwerkport, br0 wiederum ist die interne Netzwerkbrücke zwischen Host (TrueNAS) und Gast (Ubuntu Server).
Wichtig dabei ist, das bei beiden DHCP deaktiviert wurde, dazu muss natürlich auch der physikalischen Netzwerkkarte eine feste IP im Bereich des Heimnetzwerkes vergeben werden. Und bei der Bridge sollte man einen Netzwerkaddresbereich wählen, welcher nicht im Heimnetzwerk verwendet wird!

Netzwerk1.png



Hier ist die Oonfiguration der VM mit beiden Netzwerk(karten) zu sehen. Eine NIC verbindet auf den enp1s0 Port und die andere auf die br0.

VM1.png



Folgerichtig muss natürlich auch die Netzwerkkonfiguration im Gast vorgenommen werden. Das geht mit Ubuntu am einfachsten, wenn man netplan verwendet.

Netzwerk2.png



Zum Thema langsame Datenträger I/O:
Wie schon im Vorpost beschrieben, muss man den Disk Modus von AHCI auf VirtIO umstellen.

Disk1.png
 
Tag 34
NAS2 spart Strom

So, da aktuell alles super läuft, habe ich angefangen die ersten Optimierungen durchzuführen.
Diese fangen mit dem 2. NAS an.

Dieses NAS hat die Aufgabe 1x am Tag an einer festgelegten Uhrzeit, die Snapshots von NAS1 zu replizieren.
Daher müssen hier die Festplatten nicht 24/7 laufen. TrueNAS Scale unterstützt HDD Spindown, dieses lässt sich direkt über die GUI einstellen.


Anbei die Verbrauchsmessungen in den verschiedenen Betriebszuständen mit den 2x Seagate Exos X20 18TB:

HDDs laufen (NAS Idle)HDDs geparkte Köpfe (NAS Idle)HDDs Spindown (NAS Idle)
16W12W5W


Ich denke der Verbrauch kann sich für einen Eigenbau sehen lassen (y)

Hinweis:
TrueNAS Scale hat leider einen seltsamen Bug!
Wenn SMART in den Einstellungen aktiviert ist, startet es die HDDs alle ca. 10-30min um die gleich wieder schlafen zu legen.
Ich habe jetzt vorrübergehend deaktiviert und teste die Platten monatlich manuell.
 
Tag 35
Kein Bug

Wie im letzten Beitrag schon erwähnt, weckt der eingeschaltete SMART Dienst immer wieder die Festplatten auf.
Meine erste Vermutung war nun, das es sich um einen Bug handelt.

Dem ist wohl nicht so, es scheint glücklicherweise eine Einstellungssache zu sein!
Smart1.png

In den Einstellungen des SMART Dienstes, gibt es eine Einstellung namens "Power Mode".
Diese sagt dem Dienst, wann er seine Tests machen darf:

Mit der Option "standby" kann man wohl den Dienst anweisen, nur den Test durchzuführen, wenn die Platten laufen.


Was mich dagegen irritiert, ist diese Beschreibung von TrueNAS Scale:
Smart2.png
 
Tag 36
Erfolg und Fehlschlag

Erfolg
Die oben genannte Einstellung war wirklich die Ursache, des ständigen Festplatten aufweckens.
Nach umstellen auf den Power Mode "Standby" belieben die Platten aus, wenn SMART aktiviert ist.
Somit sollten auch die automatischen Tests funktionieren.


Fehlschlag
Meine Kunstruktion für den Staubfilter, war ein Griff ins Klo :poop:
Nicht nur das es echt blöd zu kleben war, nach Anbau fiel mir ein signifikates Problem auf:

Zwischen Filter und Lüfter ist ein Spalt, durch den problemlos Staub dringen kann

Staubfilter1.jpg Staubfilter2.jpg

Somit kann ich nicht die Standard 3D Modelle von Lüftergittern verwenden.
Ich muss da wohl mein eigenes Designen. Ich denke da an einen Einschub in den man den Filter von oben einschieben kann.
Dabei könnte man sich auch direkt die Magnete sparen, welche das Gitter an den Schrauben halten.

Wer sich übrigens fragt, was für ein Lüfter mit dem Neon Gelb das ist, das ist ein Coolink Swif Lüfter, den ich noch rumliegen hatte.
Lt. Webseite ist es eine taiwanesische Firma. Garantie Austausch läuft aber über Noctua, zumindest war bei mir das damals so (das Teil ist schon älter).
 
@RaptorX
Das hatte ich mir auch schon angeschaut, hat aber einige Nachteile:
- der Filter ist ziemlich dicht und bremst den Luftstrom recht stark
- Die Befestigung mit einfacher Reinigungsmöglichkeit ist schwierig

Ich habe inzwischen eine Lösung, die gut funktioniert.
Gestern den ersten Prototypen gedruckt, siehe hier:

Und hier:

Edit:
Nicht vom Linktext irritieren lassen, die Forensoftware schreibt da Mist 😳
 
Das ist natürlich noch besser, Vorteil wenn man einen 3D Drucker hat. (y)
 
Ja klar, das ganze Gehäuse ist ja 3D gedruckt 👍
 
Tag 37
Staubfilter die zweite

Ich habe mir die Mühe gemacht einen neuen Filterhalter + Filter zu designen.
  • leicht montierbar
  • ohne Magnete
  • leicht zu reinigen
Dafür habe ich einen Rahmen designed, welcher auf den Lüfter geschraubt wird.
In dieses Rahmen kann der Filter einfach eingeschoben und herausgezogen werden.

Das Filtergitter aus Nylon wird während des 3D Druckes einfach eingelegt und verbindet sich dadurch mit dem 3D Druck zu einem Teil.

So sieht das dann aus:

Lüfter ohne Filter.jpg
Gummies auf der Vorderseite des Lüfters entfernt, für bündige Rahmenmontage


Lüfter mit Filterrahmen.jpg
Rahmen auf dem Lüfter


Lüfter mit Rahmen und Filter.jpg
Filter in den Rahmen eingeschoben
 
Zuletzt bearbeitet:
Tag 38
der Lüfter und sein Anschluss

Eigentlich wollte ich heute Bilder vom fertigen NAS2 mit Lüfter und Staubfilter posten,
daraus wirda aber erstmal nichts.

Nach anschließen des Noctua NF-A9 am NAS2 mit dem Odroid H2+ Board, ist mir aufgefallen das sich dieser nicht über PWM regeln ließ.
Er drehte mit ungefähr 50-100U/min egal welche BIOS Eisntellung.

Durch abklemmen der PWM Leitung erhöhte sich die Drehzahl auf ca. 880U/min, wurde aber nicht geregelt.
Alles in allem ein seltsames Verhalten :unsure:

Nach einigen Nachforschungen, soll der Lüfter Anschluss dieses Boards nur 5V Ausgangsspannung besitzen.
Schnell nachgemessen ergab, da liegen wirklich nur 5V an :oops:

Das erklärt warum sich der Lüfter so seltsam verhält.

Jetzt muss ich mir erstmal überlegen wie ich das Problem löse.
Das einfachste wird wohl sein, 12V irgendwo auf dem Board zu klauen und das PWM Signal des Lüfteranschlusses zu nutzen.


Update:
Den Noctua Lüfter gibt es glücklicherweise auch in einer 5V Version.
Diese habe ich jetzt bestellt:


Zur Info welches Board welche Spannung hat:
Odroid H2/H2+ => 5V
Odroid H3/H3+ => 12V
 
Zuletzt bearbeitet:
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