RSYNC-Problem

[defcon999]

Hallo,

ich habe gerade gesehen, dass RSYC bei mir Probleme macht.

Ich habe einen "lokalen" Rsync-Task laufen, der die Daten meines Datasets "zfs" auf eine eine andere Platte "zfs_backup" im HP-Gen8 synchronisiert. Das klappt beim Hinzufügen neuer Daten auf "zfs" hervorragend. Wenige Sekunden später sind die Daten auf dem "zfs_backup" sichtbar.

Leider funktioniert das Löschen der Daten auf dem "zfs_backup" nicht

Die Option "Lösche Dateien auf der Empfängerseite die beim Sender nicht existieren" ist natürlich gesetzt. Beim Setzen dieser Option werden verschiedene Varianten des Löschens angeboten. Mit keiner Option funktioniert das Löschen.

Ich habe den Task als "root" ausgeführt und auch als Nutzer mit Admin-Rechten .... beides ändert Nichts.

Hat Jemand einen Tipp??

defcon999

[kreuzberger]

Hi defcon999,

hat root auch wirklich ALLE Rechte auf "zfs_backup"?
Kann root auch "zu Fuß" (im Dateimanager vom WebGui zb.) in "zfs_backup" löschen?
Ggf. solltest du das mal Kontrollieren.

Kreuzberber

[defcon999]

Ja, root darf Alles ... und das manuelle Löschen über den Dateimanager geht auch .....

[kreuzberger]

hast du mal probiert eine den rsync entsprechende befehlszeile auf der systemkonsole abzusetzen?

[defcon999]

Nein, DAS habe ich noch nicht probiert .... ich bin mit dem Befehlszeilen-Modus, was Rsync angeht, auch nicht so sehr vertraut

[kreuzberger]

https://www.ostc.de/howtos/rsync-HOWTO.pdf

[defcon999]

Danke für die Doku ... ich bin dabei zu testen .. und melde mich mit konkreten Ergebnissen

[kreuzberger]

ggf richtest du dir zwei probierirdner ein, bevor du rsync auf deine Daten los lässt. beim löschen ist es gnadenlos.

Kreuzberger

[defcon999]

Sooo .... erste Tests abgeschlossen: Über die Konsole funktioniert das Ganz perfekt. Sowohl das Hinzufügen von Dateien als auch das Entfernen von Dateien auf "zfs" wird kurz danach auf "zfs_backup" umgesetzt. Scheint also ein Problem beim Aufruf über die GUI zu sein ....

Über die Konsole habe ich das Standardparameter "--delete" genutzt.

Dann sollte ich wohl den Aufruf über einen Cron-Job erledigen, oder?!

Danke noch mal für Deinen Hilfe, Kreuzberger

[Princo]

Hinweis dazu:

Für den Abgleich zwischen zwei ZFS-Dateisystemen ist rsync nur bedingt geeignet. Dafür sollte man zfs send/receive verwenden.
Die meisten Anleitungen zu rsync sind leider falsch, da auf den wichtigsten Parameter (-c) nicht eingegangen wird. Dieser Parameter ist für das exakte Kopieren wichtig, denn in den Grundeinstellungen berücksichtigt rsync nur Dateien, welche eine unterschiedliche Größe, und ein unterschiedliches Dateidatum aufweisen. Dateien, welche die gleiche Größe, das gleiche Datum, aber einen unterschiedlichen Inhalt haben, werden von rsync nicht erkannt, wenn der Parameter -c nicht gesetzt ist.

Wird der Parameter -c jedoch gesetzt, dann wird rsync sehr sehr langsam.

Ein zusätzliches Problem tritt auf, wenn bei dem zu sichernden ZFS-Dataset (und dazu gehört bereits der gesamte Pool) beispielsweise die Eigenschaft "Snapshot visibility" verwendet wird (welche z.B. für die Schattenkopien von Windows relevant ist).

Leider beschäftigen sich viele Leute nicht mit den Funktionen von ZFS (z.B. den Snapshots), und hämmern dann mit den alten Werkzeugen (wie rsync) darauf herum, weil sie gar nicht wissen, daß es mittlerweile viel einfachere, schnellere, und zuverlässigere Methoden gibt.

Übrigens: ein automatisiertes Backup via rsync ist generell keine besonders gute Idee.

Grüße
Princo

[defcon999]

Hallo Princo,

erst einmal wieder vielen Dank für Deine ausführliche und offenkundig sehr kompetente Rückmeldung.

Ich bin eher "normaler Anwender" als Hardcore-Netzwerk-ZFS-Spezi und Du hast mich schon vor Monaten auf Schwächen in den Snapshot-Scripts von FRITZ hingewiesen, auf die ich (und wohl auch die Mehrzahl anderer Nutzer) niemals gekommen wäre.

Insofern nehme ich Deinen Hinweis gern zum Anlass mich intensiver mit "zfs send und receive" auseinander zu setzen.

Ich bin froh, dass man hier im Forum genau diese Experten trifft, die einen in die richtige Richtung bringen.

Ich hatte die große Hoffnung über einen lokalen Rsync-Task Alles richtig gemacht zu haben ... zumal es ja auch (zumindest zu 90%) gut funktioniert und leicht über das WebGUI eingerichtet werdenn kann.

"zfs send/receive" ist mir zwar in diesem Forum und in der Dokumentation auch schon aufgefallen, aber Du hast Recht: Genau damit beschäftigt habe ich mich nicht.

Ich war bis dato der Meinung, dass diese Funktion dafür gedacht ist, um über das Netzwerk auf *physikalisch getrennte* Server zu sichern.

Ich möchte jedoch meinen zfs-pool auf der 4. Platte im HP-Gen8 sichern .... und da erschien mir die RSync-Lösung perfekt. Nun werde ich mir erst einmal die entsprechende Dokumentation zu "zfs send/receive "reinziehen"

Schönes WE .... defcon999

[defcon999]

Sooooo .... nach diversen Versuchen mit "zfs send/receive" bin ich dann doch wieder zu Rsync-lokal zurückgekehrt.

Das fehlerhafte Löschen von Dateien, die nicht mehr auf der Quelle vorhanden sind, auf dem Ziel-Pool, habe ich durch einen eigenständigen Rsync-Cron-Job gelöst. Das funktioniert nun einwandfrei und zu meiner vollsten Zufriedenheit.

Hier scheint es tatsächlich einen Bug im WebGUI von Rsync zu geben.

Hardcore-Netzwerk-Admins mögen jetzt zwar die Haare zu Berge stehen, aber für den ambitionierten Anwender reicht das völlig aus.

@Princo
Bei mir kommt es definitiv nicht vor, dass Daten weder ihre Größe noch ihr Speicherdatum ändern, aber dennoch im *Inhalt* geändert wurden, insofern brauche ich die Option -c" nicht. Deine Ausführungen in einem anderen Thread zu diesem Umstand habe ich sehr aufmerksam gelesen.

Und mit "zfs send/receive" bin ich nicht so wirklich klar gekommen. Das liegt aber ganz sicher an meiner Inkompetenz

Insofern kann dieser Thread geschlossen werden ... Danke an kreuzberger und Princo für die Mühe und Hilfestellung.

defcon999