Troubleshooting Numero 2
Fortsetzung vom ersten Versuch eine fehlerhafte Datei zu bereinigen. Hier ist mir aufgefallen, dass ich eine falsche Konfiguration von UID (user identifier) GID (group identifier). Sowohl UID als auch GID sollten bei meinem Setup den Wert 3006 aber, aber der GID war auf 3002 gesetzt. Das hat zu einer Fehlkonfiguration der ACL geführt.
Zusätzlich war das Dataset als “Read Only” eingestellt, so habe ich sowieso nichts ändern können. Beide Probleme waren unabhängig voneinander, aber haben effektiv die Problemlösung behindert.
Nachdem die Probleme gelöst waren, habe ich die kaputte Datei manuell löschen können und durch eine funktionierende Kopie ersetzen können. Danach Scrub.
Und dann ist es über Nacht zu weiteren Problemen gekommen:
Und bei den “Replication Tasks” schaut es auch nicht rosig aus:
Mit sudo zpool status -v gibt folgende Infos raus:
“DEGRADED” schaut nicht gut aus. Ich glaube das Dataset muss fast noch einmal frisch übertragen werden.
Probleme mit Snapshots
Direkt am Remote-Standort die externe Festplatte mit einem Backup des Pools an Proxmox Rechner anschließen und wie hier beschrieben durchreichen.
Dann in diesem Fall nicht einen neuen Pool erstellen, sondern den bestehenden importieren…
… und gewünschten Pool auswählen:
Wenn, wie hier, verschlüsselt, muss man bestätigen…
… und die Passwortdatei oder das Passwort eingeben. Der erste Versuch scheitert jedoch mit dieser Fehlermeldung:
Dann funktioniert es:
Mit dem bereits im April 2024 erstellten “Replication Task” die Platte auf neuen Stand bringen:
Und bestätigen:
Und dann wieder der gleiche Fehler:
Error: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/middlewared/job.py", line 469, in run await self.future File "/usr/lib/python3/dist-packages/middlewared/job.py", line 511, in __run_body rv = await self.method(*args) ^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/middlewared/schema/processor.py", line 187, in nf return await func(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/middlewared/plugins/replication.py", line 484, in run await self.middleware.call("zettarepl.run_replication_task", id_, really_run, job) File "/usr/lib/python3/dist-packages/middlewared/main.py", line 1564, in call return await self._call( ^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/middlewared/main.py", line 1428, in _call return await self.run_in_executor(prepared_call.executor, methodobj, *prepared_call.args) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/middlewared/main.py", line 1321, in run_in_executor return await loop.run_in_executor(pool, functools.partial(method, *args, **kwargs)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/concurrent/futures/thread.py", line 58, in run result = self.fn(*self.args, **self.kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/middlewared/plugins/zettarepl.py", line 401, in run_replication_task self._run_replication_task_job(f"task_{id_}", job) File "/usr/lib/python3/dist-packages/middlewared/plugins/zettarepl.py", line 461, in _run_replication_task_job raise CallError(make_sentence(message.error)) middlewared.service_exception.CallError: [EFAULT] No incremental base on dataset 'Plattenpool/Media' and replication from scratch is not allowed.
Snapshot kaputt, also externe neu bespielen
Es kann sein, dass durch mein Durchprobieren mit den Snapshots, wo ich die nicht zusammenpassenden Snapshots (bei mir in der Wohnung und am Alternativstandort) gelöscht habe um doch noch ein inkrementelles Synchronisieren zusammenzubringen. Wie auch immer, hier kann ich das vermaledeite Media-Dataset neu schreiben lasse. Also unter den Replication Task Einstellungen die Replikation von Grund auf aktivieren:
Und jetzt heißt es warten:
Achja, und so schaut das Nest aus:
Heimserver der Kategorie Krims-Krams mit Kabelsalat.
Doch über’s Netz synchonisieren?
Ich bin dann doch noch auf diesen Forumseintrag gestoßen, wo man manuell das Ziel-Dataset auf den Stand des sendenden TrueNAS-System bringen kann. Dort wurde auch dieser Beitrag auf der Seite programster verlinkt, wo gezeigt wird wie man manuell ZFS Pools und Datasets herumschicken kann.
In diesem Forumseintrag wird auch noch mein Problem mit möglicher Lösung beschrieben:
Normally, on the pool that is receiving stream, if system/user is making modification to the pool on the receiving end, it will cause ZFS to complain about it. If the pool being replicated isn’t expected to deal with the data causing it to be different from the source, the use of the “-F’ option on the “zfs receive …” side can be used. Strictly speaking, any changes done after the last snapshot on the recieving pool will be discarted in order to maintain integrity with the data previously received.
Die Überlegung ist also, es doch noch einmal übers Internet zu versuchen, da ich sowieso erst in nächster Zeit persönlich die externe Festplatte hinbringen kann.
Das ist der Originalbefehl aus dem ersten Forumsbeitrag zum Thema:
zfs send -i MainOne/Photos@auto-2022-03-12_00-00 MainOne/Photos@auto-2022-03-19_12-00 | ssh root@IP OF SYSTEM zfs recv -v MainOneBackUp/MainOne/PhotosDann habe ich GPT-4 veranlasst den Befehl zu erklären:
zfs send -i Plattenpool/Media@auto-2024-08-10_03-00 MainOne/Photos@auto-2022-03-19_12-00 | ssh root@IP_OF_SYSTEM "zfs recv -Fv MainOneBackUp/MainOne/Photos"Damit das funktioniert muss ich jedoch noch einen neuen Snapshot auf dem Quell-System erstellen. Wobei ich das erst machen kann sobald die Replication auf die externe Festplatte fertig ist:
Sind die beiden Datasets überhaupt identisch?
Da ich es jetzt sowieso nicht einfach so probieren kann, versuche ich manuell nach zu sehen, ob die beiden Datasets jetzt überhaupt gleich sind. Der Chatbot schlägt folgendes Werkel vor:
ssh user@source-system "zfs diff pool/dataset@snapshot1 pool/dataset@snapshot2" > source_diff.txt
ssh user@destination-system "zfs diff pool/dataset@snapshot1 pool/dataset@snapshot2" > destination_diff.txt
diff source_diff.txt destination_diff.txtNur das bringt halt nichts, da ich erstens nicht die Snapshots der jeweiligen Systeme vergleichen möchte, sondern wissen, ob der jeweils eine Snapshot auf den Systemen gleich ist, oder nicht. Aber ich habe so meine Zweifel, ob das funktioniert. Vielleicht sollte ich einfach beide Systeme via rsync auf den gleichen Stand bringen und dann erst noch einmal einen neuen “Haupt” Snapshot auf den jeweiligen System erstellen, von dem aus, dann zukünftige Änderungen aufbauen können.
Oder ich nehme doch eher den Zug.
Aus dem bereits zitierten Thread gibt es auch ein paar erklärende/warnende Worte für TrueNAS Privatnutzer:
My hunch is that the Replication Tasks (in the GUI) has a very narrow scope for enterprise customers. This is something that iXsystems is unlikely to play around with, especially in Core.
The tooltips are ambiguous (some of which I reported as bugs that were “kind of” fixed), and the flexibility on creating replications for a personal use-case is just not that feasible with the TrueNAS GUI. The official documentation doesn’t help much either.
If anything, TrueNAS could theoretically leverage syncoid, and build a GUI around it, for users who want simple “to the point” backups. I’ve used syncoid before and it works more intuitively as a straightforward ZFS “target → destination” backup solution for home users. Unfortunately, there’s no GUI of it in TrueNAS; let alone the program is not pre-installed.
Eventuell sind Alternativen, wie “Syncoid”, dazu zu bevorzugen. Aber das ist ein Thema für die Zukunft.
Manueller Import
In Proxmox durchreichen.
Dann in TrueNAS “import Pool” auswählen und dort sollte der Pool automatisch aufscheinen:
Dann Passwort eingeben:
Dann alten Pool löschen und neuen “Replication Task” hinzufügen:
Dort Als Quelle das Dataset auf der Backup-Platte auswählen und als Ziel die interne SSD. Beim “Schedule” einfach “Run Once” auswählen – achja und nicht “make destination dataset read only”, den Fehler habe ich leider gemacht, und man muss dann im nachhinein wieder auf “write” umstellen. Und dann heißt es warten, aber nicht so lange wie übers Internet:
Der Import war schließlich erfolgreich und jetzt ist der Pool wieder guter Dinge.
Lehre aus TrueNAS Troubleshooting
Man sieht wie komplex TrueNAS bzw. zfs sein kann. Die Lernkurve ist steil, aber insgesamt bin ich mit TrueNAS sehr zufrieden. Wenn einmal etwas korrekt eingerichtet ist, dann läuft alles stabil. In den letzten acht Monaten hat TrueNAS Scale als VM in Proxmox immer stabil funktioniert. Wenn etwas nicht funktioniert, dann liegt das, zumindest bei mir, an schleißiger Konfiguration. Die etwas unflexible Konfiguration über die grafische Oberfläche von TrueNAS ist zwar schade, aber aus der Business/Enterprise Ausrichtung von iXsystems zu erklären. Das schmälert aber die Qualität der Software nicht.