Backup Pool zu Pool

[emk2203]

Just use 127.0.0.1 (or localhost) as the IP address of the "remote" system. Works for me.

Doh. I feel stupid now for never trying this.

Gesendet von meinem SM-G930F mit Tapatalk

 

[fiesta_xr2i]

Leider konnte ich die englischen Kommentare nicht alle nachvollziehen. Ist dabei etwas relevantes für mich enthalten?
Zurzeit habe ich in meinem Vorhaben - automatisieren des Backups - Pause, da ich in den nächsten Tagen Semesterprüfungen habe.
Anschliessend werde ich es weiter versuchen.

 

[MrToddsFriends]

Die Quintessenz für Dich könnte sein, dass Du mit Snapshots und Replikationen genau so vorgehen kannst wie im Handbuch beschrieben.

http://doc.freenas.org/9.10/freenas_storage.html#periodic-snapshot-tasks
http://doc.freenas.org/9.10/freenas_storage.html#replication-tasks

Konfiguration bei Replikation mit PUSH und PULL auf ein und dem selben System:
Remote hostname: 127.0.0.1 (alternativ localhost)

Desweiteren sieht's bei mir so aus:
Remote port: 22
Remote hostkey: [public key of PULL] aus SSH Key Scan

Möglicherweise habe ich in diesem Thread verpasst, was Dir an den Möglichkeiten der FreeNAS GUI fehlt bzw. welche Gründe Du hattest die Kommandozeile zu verwenden. Es lohnt sich, sich durch das FreeNAS Manual zu beißen, am Besten dann nach Deinen Prüfungen.

 

[fiesta_xr2i]

Vielen Dank für deinen Hinweis. Da ich nicht vom Fach bin gibts halt oftsmals Sackbahnhof - aber im Forum findet man dann einen Ausweg :D

 

[Kartoffel]

Die Quintessenz für Dich könnte sein, dass Du mit Snapshots und Replikationen genau so vorgehen kannst wie im Handbuch beschrieben. Konfiguration bei Replikation mit PUSH und PULL auf ein und dem selben System: Remote hostname: 127.0.0.1 (alternativ localhost)

Desweiteren sieht's bei mir so aus: Remote port: 22

Ich habe ein ganz ähnliches Problem wie Fiesta. Zwei HDs, eine mit den Daten (in mehren Datasets), die andere soll als BackUp dienen.

Als erstes habe ich regelmäßige Shnapshot auf den Datasets eingerichtet (per GUI). Dann wollte passende Replizierunmgsaufgaben für jedes Dataset einrichten. Alles ganz ähnlich wie bei MrToddsFriends (localhost, Port 22), aber hier hapert's:

Remote hostkey: [public key of PULL] aus SSH Key Scan

Ich verstehe nicht, was eigentlich gemeint ist. Den Knopf "SSH Key Scan" drücken (dann erscheint ja was unter "Hostkey") reicht wohl nicht. Damit bekomme ich nur Fehler: "Failed: Permission denied (publickey,password)". Dort gar nichts eintragen bring das selbe Ergebnis.

Da hat mir auch das Lesen des Handbuchs nicht viel geholfen. Was muss ich tun, damit das Teil funktioniert? Oder ist schon der Ansatz verkehrt?

 

[MrToddsFriends]

Ich verstehe nicht, was eigentlich gemeint ist. Den Knopf "SSH Key Scan" drücken (dann erscheint ja was unter "Hostkey") reicht wohl nicht. Damit bekomme ich nur Fehler: "Failed: Permission denied (publickey,password)". Dort gar nichts eintragen bring das selbe Ergebnis.

Bei 9.10.1-U1 hat sich ein Fehler in Sachen Replikation eingeschlichen, der mit dem bald zu erwartenden Update 9.10.1-U2 behoben sein wird. Ich kann aber nicht sagen, ob Dein Problem damit zusammenhängt.

https://bugs.freenas.org/issues/17826
https://bugs.freenas.org/projects/freenas/issues?query_id=273

Davon abgesehen: Existieren bei Dir die Dateien /data/ssh/replication.pub und /data/ssh/replication? Hast Du eventuell irgendwann eine bestehende Konfiguration auf ein neues Boot-Medium eingespielt?

https://forums.freenas.org/index.ph...d-permission-denied-publickey-password.45801/

Eventuell hilft auch eine Google-Suche wie

https://www.google.de/#q=site:forum...ailed:+Permission+denied+(publickey,password)

 

[snaptec]

Den Host key hast aber unter Benutzer, wie in der doc beschrieben, eingetragen?


Gesendet von iPhone mit Tapatalk

 

[Kartoffel]

Den Host key hast aber unter Benutzer, wie in der doc beschrieben, eingetragen?

Vermutlich nicht, weil ich die Dokumentation nicht verstehe. Mir ist nicht klar, woher ich den Hostkey bekommen. Genauer, wo ich in der Weboberfläche draufklicken muss, damit das gewünschte erscheint. Vielleicht hätte ich sagen müssen, dass ich über 30 Jahre Mac verdorben bin und deshalb interlektuell etwas eingeschränk bin...

Bei 9.10.1-U1 hat sich ein Fehler in Sachen Replikation eingeschlichen, der mit dem bald zu erwartenden Update 9.10.1-U2 behoben sein wird. Ich kann aber nicht sagen, ob Dein Problem damit zusammenhängt.

Das problem hatte ich auch schon unter 9.3 – dieses System hatte ich installiert und leztens zu 9.10 gewechselt, weil das irgendo angezeit wurde. Ansonsten habe ich immer nur die angezeigten Updates installiert.

Davon abgesehen: Existieren bei Dir die Dateien /data/ssh/replication.pub und /data/ssh/replication?

Wie komme ich überhaut an die Pfade und dateien heran? Von Netzwerk-Client? Muss ich das Bootmedium freigeben per AFP?

https://forums.freenas.org/index.ph...d-permission-denied-publickey-password.45801/

Der Linkt hilft vielleicht. Im ersten posting steht dort "In Storage > Replication Tasks on PUSH click the View Public Key button and copy the contents" – heiß dass, den Hostkey bekommt man, wenn man direkt unter Replizierungsaufgaben "Offentlichen Schlüssel anzeigen" anklickt, nicht "SSH Key Scan" im Einstelldialog der Replizierung? Einfach den ganzen Text, der dann erscheint? Auf jeden Fall bekomme ich so mal 'ne andere Fehlermeldung präsentiert: "Failed: No ECDSA host key is known for localhost and you have requested strict checking. Host key verification failed."

Und in dem genannten Posting steht noch "Users modify the replication user (root)" – heißt dass, ich muss einen andere User in der Replizierungsaufgabe einstellen? Im Moment ist nicht angekreuz (= root).

 

[Kartoffel]

Wenn man weiss, das ist kein Baum, dann sieht man ihn nicht und fährt hinein...

Ich hatte nicht verstanden, dass man die öffentlichen Schlüssel beim User Root einfügen muss (hatte diesen User auch noch nicht unter Benutzer gefunden...). Jetzt wo ich das nachgeholt habe und den entfernten Hostkey per "SSH Key Scan" in der Replizierungsaufgabe einrichten konnte, starten die Replizierungsaufgaben tatsächlich.

Allerdings produzieren alle Sicherungen auch nur wieder reihenweise Fehler: "The replication failed for the local ZFS Daten/Daten1 while attempting to send snapshot auto-20160903.0500-1m to localhost" Und "Replication Big-pool/Big-Beutel -> localhost:Pool-BackUp failed: Failed: Data/Data1 (auto-20160903.0500-1m)"

Leider sagen mir diese Meldungen garnichts (außer dass es nicht klappt. Es scheinen auch keinerlei Daten im Backup angekommen zu sein. Jetzt ist zwar Backup/Data1 vorhanden, belegt aber praktisch keinen Speicherplatz.

 

[snaptec]

Die Pfade die du eingetragen hast als Ziel existieren aber und keine typos?



Gesendet von iPhone mit Tapatalk

 

[MrToddsFriends]

Falls die Ursache Deiner zuletzt geposteten Fehlermeldungen falsch gesetzte Pfade sind, hilft vielleicht eine Beschreibung wie ich die Pfade konfiguriert habe. Ich repliziere mehrere (nicht verschachtelte) Datasets aus meinem Hauptpool volume0 in den Zielpool volrep. In der FreeNAS GUI ist jede der Replikationen so konfiguriert (Beispiel!):
Volume/Dataset: volume0/dokumente
Remote ZFS Volume/Dataset: volrep

Das vor dem Erstellen des Replikations-Jobs nicht vorhandene Ziel-Dataset dokumente ist nicht angegeben, das wird vom Replikations-Job erstellt.

Wie komme ich überhaut an die Pfade und dateien heran? Von Netzwerk-Client? Muss ich das Bootmedium freigeben per AFP?

Freigaben auf systemeigene Verzeichnisse einzurichten ist keine gute Idee. Man kommt hier entweder mit der "Shell" in der FreeNAS GUI dran oder per Remote Login via SSH. Shell-Befehle sind meist hauptsächlich zu diagnostischen Zwecken nützlich. Bei Eingriffen, die Veränderungen bewirken, sollte man sehr genau wissen was man tut, da man so evtl. FreeNAS aus dem Tritt bringen kann.

Code:

scr@blunzn:~ % ls -al /data/ssh
total 7
drwxr-xr-x  2 root  wheel  4 Dec 29  2014 ./
drwxr-xr-x  7 www  www  15 Oct  3 06:00 ../
-rw-------  1 root  wheel  1675 Dec 29  2014 replication
-rw-r--r--  1 root  wheel  401 Dec 29  2014 replication.pub

Und in dem genannten Posting steht noch "Users modify the replication user (root)" – heißt dass, ich muss einen andere User in der Replizierungsaufgabe einstellen? Im Moment ist nicht angekreuz (= root).

Bei mir laufen alle (lokalen) Replikations-Jobs als root. Ich sehe keine Notwendigkeit, hierfür einen anderen User anzugeben (oder gar extra dafür einzurichten).

 

[snaptec]

Definitiv bei Root lassen. Ein extra user macht dir hier mehr Probleme als das er hilft!


Gesendet von iPhone mit Tapatalk

 

[Kartoffel]

Falls die Ursache Deiner zuletzt geposteten Fehlermeldungen falsch gesetzte Pfade sind, hilft vielleicht eine Beschreibung wie ich die Pfade konfiguriert habe. Ich repliziere mehrere (nicht verschachtelte) Datasets aus meinem Hauptpool volume0 in den Zielpool volrep. In der FreeNAS GUI ist jede der Replikationen so konfiguriert (Beispiel!):
Volume/Dataset: volume0/dokumente
Remote ZFS Volume/Dataset: volrep

Das vor dem Erstellen des Replikations-Jobs nicht vorhandene Ziel-Dataset dokumente ist nicht angegeben, das wird vom Replikations-Job erstellt.

Genauso ist es bei mir gewesen. Die zu sichernden Datasets waren nicht im Backupziel angelegt. Sie erschienen im Backup-Pool erst, als ich den öffentlichen Schlüssel im User root eingefügt hatte und die Replizierung zum ersten Mal startete. Soweit scheint alles richtig zu sein – oder?
Das einzige, was mir auffällt, ist die Anzeige unter Datenträger. Dort werden die durch die replizierung entstandenen Datasets als readonly angezeigt. Aber vielleicht muss das so sein, damit nur die Replizierung dort hineinschreiben kann...?
Nachdem ich jetzt gesehen habe, wie meine Shnapshots heißen, erkenne ich auch, dass die letzten fehlermeldungen der Replizierungsaufgaben gar keinen Hinweis geben (außer dass es nicht geklappt hat). Schlägt nun der weiter oben im Thread beschriebene Fehler der Version 9.10.1 zu? Wo könnte ich denn nach aussagekräftigeren Fehlermeldungen schauen? Gibt es Log-Dateien?

 

[MrToddsFriends]

Das einzige, was mir auffällt, ist die Anzeige unter Datenträger. Dort werden die durch die replizierung entstandenen Datasets als readonly angezeigt. Aber vielleicht muss das so sein, damit nur die Replizierung dort hineinschreiben kann...?

Genau, das macht FreeNAS deswegen so.

Schlägt nun der weiter oben im Thread beschriebene Fehler der Version 9.10.1 zu?

Ich vermute, dass meine Erwähnung von Problemen in 9.10.1-U1 eher zur Verwirrung beigetragen hat, kann aber nichts Bestimmtes sagen, da ich diese Version überspringe. 9.10.1-U2 sollte aber bald verfügbar sein.

Wo könnte ich denn nach aussagekräftigeren Fehlermeldungen schauen? Gibt es Log-Dateien?

Ich würde zuerst in /var/log/messages nachsehen. In einer Shell, mit einem Pager wie more oder less. Grundlegendes zur Bedienung:
http://www.linux-community.de/Inter...ore-Less-Head-und-Tail-Textdateien-betrachten

 

[MrToddsFriends]

Nochmal zwei User mit Problemen bei der Replikation in 9.10.1-U1:

https://forums.freenas.org/index.ph...ting-after-only-150gb-to-500gb-of-data.46485/

Ich würde an Deiner Stelle doch erst mal auf in 9.10.1-U2 warten und nach einem Update weitermachen.

 

[MrToddsFriends]

9.10.1-U2 ist verfügbar und auf meinem System bereits eingespielt. Wenn ich mich im Lauf des Tages in diesem Thread nicht mehr melde, dann laufen die Replikationen auf meinem System mit dieser Version.

 

[Kartoffel]

:):):) Läuft :):):)

Gestern konnte ich hier nicht reinschauen. Aber ich habe die Mail über das Update erhalten und dieses gleich installiert. Eine eine Replizierungsaufgabe wieder aktiviert und auf die bekannten Fehlermeldungen gewarte. Kam aber nichts. Und der Backup-Pool füllt sich fleißig – ganz herzlichen dank für Eure Hilfe und Geduld!! ;)

Abschließend möchte ich nochmal kurz erklären, warum ist ursprünglich die replizierung nicht richtig konfiguriert hatte (obwohl es doch eigentlich doch im Guide genau erklärt wird): Ich konnte mir nicht vorstellen, dass der "allmächte" User root tatsächlich den (eigenen?) öffentlichen Schlüssel braucht, um sich selbst Daten von einer auf den anderen Pool zu senden. Damit hätte ich nicht gerechnet und vielleicht habe auch andere ein ähnliches Verständnisproblem...

Dass ich dann noch genau in dem Moment von einen echten Bug betroffen war, ist auch ein toller Zufall. Aber schön das sowas innerhalb weniger tage ausgebügelt wird!

 

[snaptec]

Replication nutzt immer ssh. Auch bei localhost, daher der Schlüssel.
Natürlich könnten die Entwickler auch eine Logik einbauen wenn das Ziel localhost ist dann schlicht zfs send xxx | zfs receive zu nehmen.


Gesendet von iPhone mit Tapatalk