RTRR bricht ab

    Guten Tag,

    nachdem ich mit rsync ebenfalls gescheitert bin, habe ich nochmal versucht ein Backup über RTRR von einem QNAP-NAS zu einem anderen QNAP-NAS durch zu führen. Beide QNAP haben die aktuelle Firmware und beide haben das jeweils aktuelle HBS installiert.

    Beide Internetverbindungen haben Download100Mbit und Upload ca. 50 Mbit.

    Das Backup ist recht groß, ca 1,5 TB. Es ist genug Speicherplatz auf beiden NAS frei (noch ca. 2 TB frei).


    Wenn ich RTRR starte, beginnt es ganz normal. Nach einigen Stunden bekomme ich jedoch die Fehlermeldung

    Code
    "-53"

    RTRR wird dann scheinbar erneut gestartet und versucht erneut, das Backup zu machen.

    Wenn ich zu Testzwecken einen Testordner nehme (mit ca. 5 MB), dann läuft das Backup mit RTRR problemlos durch.

    Wo ist der Fehler? Kann RTRR ein so großes Backup nicht verarbeiten? Oder muss ich in den Einstellungen etwas verändern?

    So Leute,

    nachdem es mit RTRR nicht vorwärts geht und auch keine Lösung in Sicht ist, habe ich als letzten Versuch eine "One-way-Syncronisation" gestartet.

    Das soll wieder von einem lokalen QNAP-NAS auf ein entferntes QNAP-NAS erfolgen.

    Wenn das auch nicht funktioniert, gebe ich auf. Die Software-Lösungen von QNAP sind scheinbar auf einen stark reduzierten Einsatzzweck ausgelegt. Das gefällt mir bisher gar nicht.

    So ganz nebenbei habe ich auch heraus gefunden, dass man in der GUI rsync über SSH nur mit Passwort einrichten kann. Key-Files werden gar nicht angeboten.

    Das ist fast so kurios wie die "Einschränkung" von SSH auf root.

    Was denken sich diese Entwickler???

    Mit den Datenmengen von 1,6TB kommt Rsync (und vermutlich auch RTRR) klar. Das Problem könnte sein, dass irgendwann die Internetverbindung Aussetzer hat und dadurch der ganze Job abbricht. Du kannst versuchen, für das initiale Backup das ferne NAS in dein LAN zu holen. Die späteren inkrementellen Backups, bei denen dann wesentlich weniger Daten bewegt werden, laufen dann meistens problemlos auch über das Internet.


    Zitat von postschlumpf

    Key-Files werden gar nicht angeboten.

    Die funktionieren aber (zumindest mit Rsync, RTRR habe ich nicht probiert).

    Die Passphrase für den ssh-Key lässt du leer, und in der HBS-Konfiguration ebenfalls leeres Passwort. Das dadurch entstehende Sicherheitsrisiko reduzierst du, indem du mehrere ssh-Key-Dateien nimmst, die Standard-Datei ausschließlich für das Backup, und diese schränkst du in authorizedKeys auf den notwendigen Rsync-Befehl ein.

    So,

    ich habe es nochmals versucht aber es funktioniert nicht.

    Auch der Sync-Auftrag läuft krötenlangsam und nach 24 Stunden fängt er wieder von vorne an.

    Ich versuche es jetzt nochmal über rsync. Das ist zumindest schneller.

    Vielen Dank für Eure Hilfe aber diese QNAP-NAS sind offensichtlich nicht geeignet für meinen Einsatzzweck.

    Zitat von postschlumpf

    Auch der Sync-Auftrag läuft krötenlangsam und nach 24 Stunden fängt er wieder von vorne an.

    Welche Geschwindigkeit hast du denn erwartet? Grob überschlagen dauern deine 1,6TB ca. 3,8 Tage.

    Sollte deine Verbindung alle 24 Stunden getrennt werden, wird der Auftrag nie fertig.

    Moin!


    Mit 3,8 Tagen wäre ich hoch zufrieden gewesen. Selbst mit 14 Tagen wäre ich zufrieden gewesen : )

    Ich bin einfach enttäuscht, dass die QNAP-Backup-Software (HBS 3), nach einem Verbindungsabbruch nicht genau an dem Punkt weiler macht wo die Verbindung unterbrochen wurde, sondern tatsächlich jedes Mal wieder am Anfang beginnt. Das kann ja sogar rsync besser. Und da ich sowieso vermute, dass hinter dieser schicken GUI irgendwo ein rsync rein gefummelt wurde, kann ich noch weniger verstehen, warum der Schalter "-P" oder" --partial" nicht mit dazu genommen wirde.

    Wie auch immer. Ich werde mir jetzt leider eine andere Lösung suchen müssen.

    Hast du denn HBS mit Rsync ausprobiert?

    Bei mir funktioniert es, auch mit ähnlichen Datenmengen, sehr stabil. Das initiale Backup habe ich allerdings gemacht, als die beiden Geräte nebeneinander im LAN standen.

    Ja, ich habe auch versucht HBS mit rsync zu benutzen.

    Das ist aber schon daran gescheitert, dass ich im QNAP leider nur ein Passwort für den SSH Zugang eingeben konnte. Der Backup-Server erlaubt aber nur ein SSH-Login über Pub_Key. Und das möchte ich auch nicht ändern!
    Tja, und so bin ich die ganze Zeit in Sackgassen rein gelaufen.

    Ich versuche es jetzt nochmal im Terminal mit rsync, ssh und Pub_Key.

    Zitat von postschlumpf

    Das ist aber schon daran gescheitert, dass ich im QNAP leider nur ein Passwort für den SSH Zugang eingeben konnte. Der Backup-Server erlaubt aber nur ein SSH-Login über Pub_Key. Und das möchte ich auch nicht ändern!

    Das geht. Passphrase des ssh-Keys leer lassen. In #3 weiter oben hatte ich das schon skizziert inkl. Bemerkung zur Sicherheit. Wenn du dazu Fragen hast, nur zu.

    Aha, ja dazu habe ich noch Fragen...

    Ich habe im QNAP-NAS im Terminal ein SSH-Schlüsselpaar erstellt, ohne Passwort.

    Der SSH-Login vom QNAP-NAS zum Backup-Server funktioniert im Terminal auch, ohne Passworteingabe, nur mit SSH-Key.

    Wie muss ich jetzt in der GUI weiter vorgehen? Das ist mir nicht klar.

    In HBS Speicherplatz erstellen/bearbeiten:


    Typ = "Rsync Remote Server" (im Dialog heißt es stattdessen bei Servertyp "NAS-basierter Rsync-Server")

    Name: egal, ist informativ für dich.

    IP-Adresse/Hostname: Wie üblich, darf ein dyn. DNS-Name sein.

    Port: Vorgabe (873) lassen, wird nicht verwendet, da der Verschlüsselungsport Vorrang hat,

    Benutzername: Dein Login-Name auf dem fernen NAS

    Passwort: leer lassen

    "Verschlüsselungsport anwenden" muss angekreuzt werden. Der Port ist derjenige, der im Router für den ssh-Zugang auf das ferne NAS als Portweiterleitung definiert wurde.


    Darunter sind die Buttons "Verbindung testen" und "Geschwindigkeitstest". Wenn die beiden nach Aufruf keinen Fehler ergeben, dann sieht es auch mit dem Backup gut aus.


    Bei mir ist das ferne NAS übrigens kein Qnap, sondern ein Synology. Das sollte keinen Unterschied machen. ("sollte" - in der IT weiß man es nie ;) )

    Ich habe es gerade nach Deiner Anleitung versucht. Ich habe sogar alle angebotenen Servervarianten durch probiert. Bei mir klappt das nicht.

    Ist aber auch nicht schlimm. Im Terminal funktioniert es ja und dort kann ich rsync auch viel feiner einstellen.

    Ich mache jetzt also einfach wieder wie früher :)

    Hier sind ca. 7,5TB im RTRR Job und der abgleich ohne Änderungen dauert ca. 30min.

    Das Backup schafft ca. 20GB/h durch den VPN Tunnel.

    Das ist aber einer der über IPv6 läuft und eine sauber gesetzte MSS mitliefert.


    Damit laufen dann dauerhaft die 50Bit Upload durch, sogar über Tage.


    Schaue also im Router mal nach der mittlerweile nicht mehr notwendigen 24h Trennung.

    Ggf. läuft es bei dir ja dann auch bis zum Ende ohne Unterbrechung durch, hat der Provider keine technische Störung.

    Hallo!

    Ich danke Euch für die Antworten.

    Aber ich habe es leider nicht hin bekommen.

    Jetzt übernimmt ein kleiner Linux-Server das Backup über SSH.

    Und das funktioniert bisher fehlerfrei und problemlos.

    Und das Ganze läuft sehr sehr schnell!

    Eine kleine Notiz zur Synchronisierung über rsync.


    Nach einem Update von HBS3 stellte ich fest, dass einer meiner Synchronisierungsaufträge nie beendet, immer wieder abgebrochen und neu gestartet wurde.


    Der Fehler hat sich bei der Prüfung der Dateiinhalte gezeigt, es brauchte ewig und 2 Tage um eine Datei von >100GB zu prüfen. Irgendwann wurde dann der Vorgang abgebrochen und neu gestartet mit dem selben Resultat. Die kleinen Dateien wurden geprüft und synchronisiert. Sobald die Grosse an der Reihe war... ENDE.


    Da ich den rsync-Zielserver (Synology NAS) erst kurz vor dem auftauchen des Fehlers von DSM 6.2 auf DSM 7 umgestellt habe, hatte ich dieses als Ursache im Verdacht.


    Es hat sich gezeigt, dass ausschliesslich Probleme beim Test von Dateien ab einer gewissen Grösse entstehen.


    Die Synchronisierung von Ordnern mit geringer Dateigrösse liefen und laufen Problemlos.


    Ich habe das Problem nun umgangen. Die angesprochene Synchronisierung sollte alle täglichen (7 Stück) Snap-Schüsse einer VM auf ein zweites Ziel synchronisieren. Hier wurden nun 7 Synchronisierungsaufträge ohne Überprüfung der Dateien erstellt, für jeden Tag 1 Auftrag.


    Seither rattern alle Aufträge durch und es kommt zu keinen Abbrüchen und Neustarts der Aufgaben.


    Für mich hat sich das Problem erledigt. Leider kann ich nicht sagen ob das Fremdsystem oder HBS für den beschriebenen Fehler verantwortlich waren/sind.

    Hallo Xydoc,


    sehr interessant. Diese Erfahrung habe ich (unter Anderem) auch gemacht.

    Vielleicht liegt es ja wirklich an HBS. DSM habe ich zumindest nicht verändert. Ich weiß gar nicht was das ist : )

    Wie auch immer. Mein kleiner Linux-Server läuft jetzt und verrichtet seine Arbeit klaglos...


    Ich muss aber noch etwas richtig stellen.

    Obwohl ich die schnellste hier verfügbare Internetverbindungen habe (an Quelle und Ziel), schaffe ich nur ca. 4 GB pro Stunde über das Internet. Das sind in 24 Sunden also 96 GB. Wenn eine Datei größer ist, z.B. ein VM-Image, dann schafft rsync oder HBS das scheinbar nicht. Nach 24 Stunden kommt dann das nächste Backup mit neuen Daten und Rsync bzw. HBS fängt wieder von vorne an. Es liegt also zumindest bei mir auch an der Internetverbindung.

    hallo postschlumpf


    DSM ist das Betriebssystem von Synology.


    Ich habe nochmals in die verbliebenen Berichte der Synchronisierungen durchgeschaut. Betroffen waren nur die Verbindungen von Qnap zu Fremdprodukt. Die Synchronisierungen von Qnap (QuTS hero) zu Qnap (QTS) liefen immer stabil durch. Hier gibt es nur eine wöchentliche Synchronisierung der VM (ca. 290GB in 18Std.)


    So weit ich weiss, startet der Backup- resp. Synchronisierungsauftrag nicht solange er nicht abgeschlossen wurde.