Replizierung gescheitert: cannot unmount '/var/db/system': Device busy

[Susanne Jaeckel]

Hallo,

mein Hauptsystem ist ein FreeNAS 9.3 und mein Backup ist ein FeeNAS 11.1-U4. zwischen denen ich nun eine Replizierung laufen lassen wollte.

Leider ist mir die Replizierung mit dem Fehler "Replication of <snapshot-bezeichnung> failed with cannot unmount '/var/db/system': Device busy" abgebrochen. Nachdem ich auf dem Zielsystem/Backup das System-Dataset auf den Boot-USB-Stick gemoved habe, ging der Replizierungs-Job ganz kurz danach im GUI auf "Succeeded", hat aber - anscheinend - nichts gemacht.

Jetzt habe ich ja gelesen, das es eine ganz schlechte Idee ist, das System-Dataset auf den Boot-USB-Stick zu legen.

Meine Frage wäre jetzt, was mache ich evtl. falsch. Die Snapshots auf dem Zielsystem habe ich schon mal gelöscht, da ich in /var/log/messages auch schon eine Fehlermeldung bzgl. 'Snapshot existiert bereits' gesehen hatte.

 

[MrToddsFriends]

mein Hauptsystem ist ein FreeNAS 9.3 [...]. Leider ist mir die Replizierung mit dem Fehler "Replication of <snapshot-bezeichnung> failed with cannot unmount '/var/db/system': Device busy" abgebrochen.

Hier hatte jemand allem Anschein nach ein ähnliches Problem (wenn nicht sogar das selbe), das sich dann aber beim zweiten Versuch von selbst gelöst zu haben scheint. Vom Datum des Postings her möglicherweise eine frühe 9.3er Version.
https://forums.freenas.org/index.php?threads/error-when-replicating-between-2-freenas-boxes.27853/

Jetzt habe ich ja gelesen, das es eine ganz schlechte Idee ist, das System-Dataset auf den Boot-USB-Stick zu legen.

USB-Sticks sind der dauernden Schreiblast nicht gewachsen, die das Logging im System Dataset verursacht. Sollte man unbedingt vermeiden.

 

[Susanne Jaeckel]

Ich will jetzt gleich mal schauen, was eine Replizierung sagt, wenn ich die "von Hand" anstoße.

Was mir aber noch in den Sinn gekommen ist, meine Snapshots mache ich auf "Pool-1" und die Replizierung wird mir aufgrund dessen auch nur auf Pool-1 angeboten. Da liegt aber dann das system-dataset mit drin.

Frage jetzt, muß ich die Replizierung für jedes Dataset einzeln machen, oder kann ich - da mir im GUI ja auch nichts anderes angeboten wird - auf Pool-1 lassen?

Ach ja, die Pools heißen bei mir auf beiden Systemen gleich, falls das noch ein Problem ist...?

Hier hatte jemand allem Anschein nach ein ähnliches Problem (wenn nicht sogar das selbe), das sich dann aber beim zweiten Versuch von selbst gelöst zu haben scheint. Vom Datum des Postings her möglicherweise eine frühe 9.3er Version.
https://forums.freenas.org/index.php?threads/error-when-replicating-between-2-freenas-boxes.27853/

Bin mal gespannt, was bei meiner "händischen" Replizierung herauskommt...

 

[Susanne Jaeckel]

Hilfe! :-(

irgendwas mache ich falsch, oder verstehe ich nicht richtig.

Folgendes ist jetzt bei meinen Versuchen passiert:

Wenn ich "zfs send Pool-1 | ssh -i /data/ssh/replication 192.168.2.102 zfs recv Pool-1"
bekomme ich die Meldung "Pool-1" existiert bereits, bitte -F benutzen.

Nutze ich nun auf der receiving Seite -F, funktioniert der erste Lauf ohne Fehler, (aber auch ohne das die Datasets übertragen werden) und beim 2. mal bekomme ich die Meldung "destination has snapshots, must destroy them to overwrite it".

Übrigens, wenn auf dem Zielsystem das System-Dataset auf Pool-1 liegt, bricht er auch ab mit dem zuvor genannten Fehler...

Wenn ich das gleiche nun mit den Datasets probiere, also:

zfs send Pool-1/administration@auto-20180510.0000-7d | ssh -i /data/ssh/replication 192.168.2.102 zfs recv -F Pool-1/administration

funktioniert das beim 1. mal und auch die Daten sind in den Datasets und der Snapshot wurde angelegt unter .zfs/snapshot etc.
beim 2. Mal kommt dann für das Dataset auch wieder die Fehlermeldung, das Snapshots existieren.

Kann ich nicht den ganzen Pool mit den Datasets replizieren?
Wenn nicht, warum werden mir die Datasets dann in der GUI nicht zum replizieren angezeigt...?

Wie bekomme ich den 2. send mit dem nächsten Snapshot hin?

Hoffentlich könnt Ihr mir da weiterhelfen.

 

[Susanne Jaeckel]

So, im Moment läuft anscheinend die Replizierung über das GUI. Morgen oder Montag weiß ich mehr.
Im Moment liegt aber das system-dataset des Zielsystems noch auf dem USB-Stick, nach erfolgreicher Replizierung werde ich das Montag mal wieder auf den Pool legen und beobachten ob es funktioniert.

Vielleicht war es ja nur ein kleiner blöder Denkfehler bei mir. Den Snapshot Eintrag habe ich damals als Rekursiv eingetragen, bei dem Replizierungsjob hatte ich das nicht. Vielleicht war es das ja schon.

Ich gebe dann noch einmal bescheid!

 

[MrToddsFriends]

Was mir aber noch in den Sinn gekommen ist, meine Snapshots mache ich auf "Pool-1" und die Replizierung wird mir aufgrund dessen auch nur auf Pool-1 angeboten. Da liegt aber dann das system-dataset mit drin.

Anmerkungen grundsätzlich dazu: Wenn man in FreeNAS einen Pool Namens Pool-1 anlegt, wird automatisch auch ein gleichnamiges Dataset Pool-1 erzeugt. Es ist ungünstig, direkt mit diesem Dataset zu arbeiten. Stattdessen legt man besser eigenhändig Kind-Datasets an, die nach Bedarf gesnapshottet und repliziert werden können. Wenn man lediglich eine Ebene solcher Kind-Datasets anlegt, spricht man von einer flachen Dataset-Hierarchie (im Gegensatz zu "nested Datasets").

In genannten Beispiel würde eine Ausgabe von zfs list -o name -r -d 1 Pool-1 dann in etwa so aussehen:

Code:

NAME
Pool-1
Pool-1/Bob
Pool-1/Jane
Pool-1/Common
Pool-1/.system

Bob, Jane und Common sind in diesem Beispiel vom Admin angelegte Datasets, die wie erwähnt nach Bedarf gesnapshottet und repliziert werden können (rekursive Snapshots in diesem Beispiel nicht notwendig). .system ist in diesem Beispiel das im selben Pool liegende System-Dataset, das von den genannten Snapshots und Replikationen nicht betroffen ist.

Dies ist natürlich nur ein Beispiel. Genauso gut könnte man unter Pool-1 auch nur ein einziges Dataset anlegen und Bob, Jane und Common als Verzeichnisse in diesem Dataset realisieren. Von verschachtelten (bzw. "nested") Datasets rate ich allerdings ab, dabei geht mit rekursiven Snapshots oder nicht funktionierendem Recycle Bin oder WasAuchImmer bei anderen Anwendern zu oft irgendwas schief.

 

[Susanne Jaeckel]

Ah!

Code:

zfs list -o name -r -d 1 Pool-1

sieht bei mir genauso aus (ok, natürlich andere Namen ;-) )

Snapshots mache ich allerdings auf Pool-1 rekursiv (damit ich nicht jedes Dataset einzeln "snapshotten" muß), hab aber "exclude system-dataset" angekreuzt!
Dadurch gibt es dann bei der Replikation dann auch nur "Pool-1".
Das sollte ich dann vielleicht noch einmal überarbeiten... :-/

Replikation läuft noch tapfer, habe mit Rekursion und Initialisierung gemacht, dadurch hat er mir aber wohl den Share-Type "Windows" auf "Unix" umgesetzt, na hoffentlich gibt das keine Probleme... hoffentlich kann ich die hinterher noch problemlos auf windows wieder umsetzen.
Er überträgt aber alle Snapshots die ich auf dem Source-System habe, das finde ich ja cool!

 

[MrToddsFriends]

Replikation läuft noch tapfer, habe mit Rekursion und Initialisierung gemacht, dadurch hat er mir aber wohl den Share-Type "Windows" auf "Unix" umgesetzt, na hoffentlich gibt das keine Probleme... hoffentlich kann ich die hinterher noch problemlos auf windows wieder umsetzen.

Den Share Type eines replizierten Datasets nachträglich von Unix nach Windows umsetzen musste ich bisher noch nicht, da dieses Problem nicht auftritt, wenn man die einzelnen Datasets (im obigen Beispiel Bob, Jane, ...) repliziert und nicht das übergeordnete, mit dem Pool gleichnamige (welches den Share Type Unix besitzt).

Ich gehe allerdings davon aus, dass beim Replizieren eines Kind-Datasets vom Share Type Windows auf eines vom Share Type Unix die ACLs verloren gehen, die man dann nachträglich wieder hinzufügen muss, z.B. durch Umkopieren der Daten auf Datasets vom Share Type Windows. :-(
https://forums.freenas.org/index.ph...setting-on-dataset-edit-options-dialog.30186/
https://forums.freenas.org/index.ph...-permissions-type-from-unix-to-windows.49900/

 

[Susanne Jaeckel]

Den Share Type eines replizierten Datasets nachträglich von Unix nach Windows umsetzen musste ich bisher noch nicht, da dieses Problem nicht auftritt, wenn man die einzelnen Datasets (im obigen Beispiel Bob, Jane, ...) repliziert und nicht das übergeordnete, mit dem Pool gleichnamige (welches den Share Type Unix besitzt).

Wow! Share-Type umsetzen brauchte ich jetzt auch nicht!

Als ich mir heute die Replizierung angeschaut habe, standen die Share-Types bei den entsprechenden Datasets auch auf Windows. Insofern gehe ich davon aus, das das funktioniert hat, da die ja dann automatisch umgesetzt wurden. (auch mit ls auf der commandline sehen die Verzeichnisse entsprechend aus *mit +*)

Habe jetzt gerade noch das System-Dataset wieder auf den Pool migriert. Meine Befürchtung ist jetzt, das Montag dann die letzten "Sends" vom Wochenende nicht geklappt haben werden, aber vielleicht täusche ich mich ja.
(irgendwie möchte ich umgehen, für jedes Dataset ein eigenes Snapshot-Set [7*täglich, 5*wöchentlich, 12*monatlich] erstellen zu müssen, deswegen würde ich mich freuen, wenn mein Snapshot auf Pool-1 auch mit der Replikation funktionieren würde...)

Ich gebe Montag wieder bescheid!

 

[Susanne Jaeckel]

Wie befürchtet ist natürlich die Replizierung nun mit Fehlerhinweisen auf /Pool-1/.system/* fehlgeschlagen :-(

Code:

Cannot open Pool-1/.system/configs-db12345 dataset does not exist
Cannot open Pool-1/.system/rrd-db12345 dataset does not exist
Cannot open Pool-1/.system/syslog-db12345 dataset does not exist
Cannot open Pool-1/.system/samba4 dataset does not exist

Eine Option, das auf dem Zielsystem zu umgehen habe ich ja nicht gefunden.

Ich werde gleich noch einmal schauen, ob ich noch Platz in dem Backup-Server habe, das ich 2 SATA-SSD's da noch einbauen kann, die ich dann als neuen Pool (gespiegelt) einsetzen würde, auf den dann nur das system-dataset kommen würde.

Falls da etwas gegen spricht, würde ich mich freuen wenn mir dann jemand früh genug auf die Finger haut ;-)

 

[MrToddsFriends]

Ich werde gleich noch einmal schauen, ob ich noch Platz in dem Backup-Server habe, das ich 2 SATA-SSD's da noch einbauen kann, die ich dann als neuen Pool (gespiegelt) einsetzen würde, auf den dann nur das system-dataset kommen würde.

Falls da etwas gegen spricht, würde ich mich freuen wenn mir dann jemand früh genug auf die Finger haut ;-)

Keine Problem, wenn man dafür zwei SSDs (und zwei SATA-Ports) opfern will. Ein wenig mehr Aufwand wäre, gleich komplett freenas-boot inklusive des System Datasets auf den Spiegel von SSDs umzuziehen. Habe ich seinerzeit so gemacht, beim Umstieg von freenas-boot auf vormals zwei gespiegelten USB-Sticks hin zu zwei gespiegelten SSDs.

Wenn ich mich recht erinnere, muss man dabei beachten, dass bei freenas-boot das ZFS Feature autoexpand nicht aktiv ist und deswegen ein bisschen Handarbeit investieren (kann ich bei Bedarf nochmal 'rauskramen).

Viele Forenteilnehmer sehen einen Spiegel aus SSDs für freenas-boot als überdimensioniert an, in dem Sinne dass eine SSD durchaus genügt. Wenn man weder seine vorhandenen Boot-Environments (aufgrund Neuinstallation bei einem Defekt) verlieren will noch die Daten seines System-Datasets und beides zusammenlegt finde ich das aber durchaus nicht übertrieben.

 

[Susanne Jaeckel]

Keine Problem, wenn man dafür zwei SSDs (und zwei SATA-Ports) opfern will. Ein wenig mehr Aufwand wäre, gleich komplett freenas-boot inklusive des System Datasets auf den Spiegel von SSDs umzuziehen. Habe ich seinerzeit so gemacht, beim Umstieg von freenas-boot auf vormals zwei gespiegelten USB-Sticks hin zu zwei gespiegelten SSDs.

Mensch, stimmt! Da hätte ich beinahe zu kurz gedacht! Lt. Dokumentation scheint das ja auch ganz simpel zu sein, einfach beide SSD's im Installationsprozess markieren.

Wie ist das dann bei einem Ausfall einer der Boot-HD's, heißt es dann runterfahren, umstecken, booten oder nur Platte austauschen und hochfahren?

Der Backup-Server hat übrigens gerade noch Platz und ich warte auf das Angebot...

Für die Pool-Seite heißt das dann:

1. Speicher->Datenträger->Volume aushängen
2. Neu installieren
3. Speicher->Datenträger->importiere Datenträger

oder?

 

[MrToddsFriends]

Mensch, stimmt! Da hätte ich beinahe zu kurz gedacht! Lt. Dokumentation scheint das ja auch ganz simpel zu sein, einfach beide SSD's im Installationsprozess markieren.

Eine Neuinstallation auf die SSDs als Mirror ist die einfachste Möglichkeit. Heißt dann im Wesentlichen nach der Installation die bereits vorher gesicherte Konfiguration wieder einzuspielen.

1. System -> General -> Save Config
2. Neuinstallation (sehr viele ältere FreeNAS Versionen findet man übrigens hier, falls es die selbe wie die bisher verwendete sein soll)
3. System -> General -> Upload Config

Alternativ könnte man auch eine bestehende Installation von einem Mirror aus USB-Sticks auf einen Mirror von SSDs umziehen. Das braucht wie erwähnt ein klein wenig Handarbeit da das ZFS Feature autoexpand beim Boot-Pool den Wert off hat ( zpool online -e führt zum Ziel).
https://forums.freenas.org/index.php?threads/replacing-8gb-usb-with-2x-64gb-usbs.57384/
Etwas mehr Hintergrund:
https://forums.freenas.org/index.php?threads/boot-vol-upgrade-autoexpand.42533/

Wie ist das dann bei einem Ausfall einer der Boot-HD's, heißt es dann runterfahren, umstecken, booten oder nur Platte austauschen und hochfahren?

Bei einem mit FreeNAS Bordmitteln gespiegelten Boot-Medium heißt dass, dass man beim Ausfall des ersten im BIOS/UEFI Setup als Bootmedium eingetragenen die Bootreihenfolge ändern muss, falls man dort nicht von vornherein beide eintragen kann.

Einer der Forenadmins hier (joeschmuck) verwendet zum Booten deswegen einen HW Raid Controller, um dieses manuelle Umstellen zu vermeiden. Und zwar ausschließlich für den Boot Pool, die Datenplatten natürlich ohne HW Raid.

Für die Pool-Seite heißt das dann:

1. Speicher->Datenträger->Volume aushängen
2. Neu installieren
3. Speicher->Datenträger->importiere Datenträger

Aushängen und Importieren sollte nicht notwendig sein, siehe oben (Save Config, Neuinstallation, Upload Config).

 

[Susanne Jaeckel]

Aushängen und Importieren sollte nicht notwendig sein, siehe oben (Save Config, Neuinstallation, Upload Config).

Danke für den ganzen Beistand!
SSD's sind bestellt. Jetzt heißt es warten bis die da sind und dann noch einmal ein wenig herumwerkeln.

Aber ich denke mit dem gespiegelten Boot-Dataset und wenn ich da noch das System-Dataset draufpacke, sollte bei der Replizierung ja nichts mehr schiefgehen können. Ich werde in diesem Thread berichten! (Und ich brauche dann auch nur die 3 Snapshot-Jobs auf Pool-1, da freue ich mich echt drüber.)

Vielen Dank!

 

[Susanne Jaeckel]

Tja, wenn doch alles nur einfach wäre... :-(

Einbau, Installation und zurückspielen der Config hat alles geklappt. Leider hatte ich bei dem Config-Backup vorher die Checkbox mit Password-Seed nicht angehakt und so war dann wohl mein zusätzlicher User weg. Aus Vorsicht habe ich dann die Replication-Task gelöscht und neu angelegt, da ich mir dann auch nicht sicher war, ob nicht der ssh-key neu angelegt worde ist (ok, ich hätte nachsehen können, habe ich aber irgendwie verpeilt...)

Leider bekomme ich nun die Meldung:

cannot receive new filesystem stream: destination has snapshots (eg. Pool-1@auto-20180429.0000-12m) must destroy them to overwrite it Error 33: Write error: cannot write compressed block

Das heißt, ich darf jetzt die Replication wieder mit "initialize" laufen lassen...

Da ich den Backup-Server in einigen Monaten an das andere Ende der Stadt verlegen werde, fürchte ich, das mich dann das ganze wieder erwarten würde. (Dann lege ich wohl besser im lokalen DNS-Server mal einen Eintrag für den Backup-Server an, damit ich darüber dann die IP ändern kann.)

Meine Frage aber jetzt: Kann man nicht auf ein bestehendes System nach einer Änderung wieder weiter replizieren?

 

[MrToddsFriends]

Da ich den Backup-Server in einigen Monaten an das andere Ende der Stadt verlegen werde, fürchte ich, das mich dann das ganze wieder erwarten würde. (Dann lege ich wohl besser im lokalen DNS-Server mal einen Eintrag für den Backup-Server an, damit ich darüber dann die IP ändern kann.)

Meine Frage aber jetzt: Kann man nicht auf ein bestehendes System nach einer Änderung wieder weiter replizieren?

Hast Du hierzu schon nützliche Informationen finden können? Bis jetzt musste ich noch keinen Umzug durchführen, auch bin ich über keine weiteren Änderungen gestolpert, die dem Weiterführen einer Replizierung entgegenstehen.

 

[Susanne Jaeckel]

Hallo @MrToddsFriends ,

es hat ein wenig gedauert, da ich mir noch ein wenig Urlaub über die Feiertage gegönnt habe.

Speziell etwas gefunden habe ich nichts außer einem Posting, das nach einer IP-Umstellung jemand auch Probleme mit der Synchronisation hatte. Vielleicht - leider habe ich das nicht ausprobiert - lag es aber auch nur daran, das die alte Backup-Server IP ja in der known-hosts steht. Aber ganz sicher bin ich mir da nicht. Wenn ich den Replizierungsjob neu angelegt hatte, hat er sich dann immer beschwert, das schon Snapshots existieren.

Ich habe jetzt für den Backup-Server einen DNS-Eintrag angelegt und spreche ihn mit Namen an. Später wenn er umzieht wird er über ein VPN-Verbundenes Netzwerk erreichbar sein und da stelle ich mir das momentan so vor, das ich nur die IP ändere und alles weiterläuft. (Der Replizierungsjob bleibt gleich und die known-hosts auch...)