RTRR oder rsync - Übersicht

    Hallo!


    Ich weis, das Thema wurde schon oft angesprochen und ich glaube das ist der 400ste Eintrag dazu.
    Aber ich habe mich jetzt durch das Forum gelesen und bin mir immer noch nicht ganz sicher was besser ist.


    Überwiegend wird von RTRR "geschwärmt" und ist - so wie ich das richtig verstanden habe - für QNAP "optimiert", da das Protokoll von QNAP ist.
    Was mich nur stutzig macht ist, warum es als Möglichkeit die NAS to NAS synchroniseriung gibt. In den Einstellungen habe ich gesehen, dass das ein normaler rsync Auftrag sein muss.
    Nur warum nennt QNAP dann den rsync-Sync NAS to NAS und nicht den RTRR - QNAP kann doch nicht die erste Firma sein, die auch mit anderen Herstellern kompatibel sein möchte :)


    Darum hier einmal eine objektive Beschreibung:


    RTRR:
    Vorteile:
    - Protokoll von QNAP. Funktioniert also auch nur zwischen QNAP's bzw. per FTP auch mit anderen Geräten
    - Viele Konfiugrationmöglichkeiten, da man u.a. Daten nicht nur vom QNAP wegkopieren kann, sondern auch herkopieren kann (angesprochener Vorteil wenn ein starkes und ein schwächeres QNAP zur Verfügung steht).
    - Ausführung: Manuell, zeitgesteuert, oder auch real-time (wozu es gedacht ist)
    - Nachsynchronisationen funktionieren schneller, da nur neue und geänderte Datein kopiert werden. Datenübertragung kann verschlüsselt werden
    - Diverse Filtereinstellungen (z.B.: Datum, Dateigröße,Dateiart, etc.)
    - Datein im Zielordner können bei der Synchronisierung gelöscht (also sozusagen ein 1:1 Abbild vom Quellordner) oder beibehalten (es verbleiben also alle Datein im Zielordner, selbst wenn sie im Quellordner gelöscht/verschoben worden sind) werden
    - Daten können komprimiet übertragen werden (geringere Auslastung des Netzwerkes mit dem Nachteil der erhöhten Belastung des NAS)
    - Daten können vom NAS auf das gleiche NAS kopiert werden, ohne Netzwerk - interene Datenübertragung (mehr Speed)


    Nachteile:
    - Erstsynchronisation dauert länger
    - Sicherheit: Im Gegensatz zu rsync wird nur ein Passwort benötigt



    rsync:
    Vorteile:
    - Protokoll ist standartisiert (für SMB) und funktioniert somit auch mit anderen Geräten (z.B.: NAS von anderen Herstellern)
    - Ausführung: Manuell oder zeitgesteuert
    - Sicherheit: Bentuzername und Passwort wird benötigt. Es können dem Benutzer Rechte zugewiesen werden
    - Diverse Filtereinstellungen (z.B.: Datum, Dateigröße,Dateiart, etc.)
    - Datein im Zielordner können bei der Synchronisierung gelöscht (also sozusagen ein 1:1 Abbild vom Quellordner) oder beibehalten (es verbleiben also alle Datein im Zielordner, selbst wenn sie im Quellordner gelöscht/verschoben worden sind) werden
    - Daten können komprimiet übertragen werden (geringere Auslastung des Netzwerkes mit dem Nachteil der erhöhten Belastung des NAS)
    - Daten können vom NAS auf das gleiche NAS kopiert werden, jedoch nur über das Netzwerk


    Nachteile:
    - Langsamer als RTRR
    - Konfiguration ist weniger flexibel, da imme nur vom Gerät wegkopiert werden kann
    - Keine verschlüsselte Datenübertragung möglich



    Stimmt das so?
    Gibt es weitere Vor- bzw. Nachteile?
    Ansonsten wäre ich von den Möglichkeiten her bei RTRR da es einfach mehr kann und (hoffentlich) schneller ist.
    Beim rsync bin ich mir nur nicht sicher wie das mit der Sychronisation aussieht? Wie wird hier im Gegensatz zu RTRR synchronisiert?


    Zur Anmerkung:
    Zum Punkt Sicherheit: Es ist jedoch fraglich wie sinnvoll es ist wenn ich bei rsync Rechte vergeben kann/muss, da im Falle dass eine fremde Person die Zugangsdaten erhält, er Zugriff auf die Daten erhält die einem wichtig sind - deshalb auch der Sync...
    Außerdem nutzt es nicht viel, wenn die Datenübertragung unverschlüsselt ist...
    Zur Komprimierung: Ist meines Erachtens nur interessant, wenn man kein Gbit-Netzwerk hat (nur derjenige wird dann bei der Übertragungsrate auch kein NAS brauchen :) ) bzw. wenn die Daten über das Internet synchronisiert werden und der Internetanschluss von der Datenmenge her limitiert ist.
    Erstsynchronisierung RTRR: Finde ich jetzt nicht so problematisch dass die Erstsynchronisierung länger dauert, wenn die nachfolgenden Synchronisationen dadurch schneller sind.


    Hat jemand Erfahrung mit einer verschlüsselten Datenübertragung?
    Wie ist da die Performanz (Datenübertragung und QNAP-Auslastung)?


    Würde mich freuen wenn Ihr Eurer Wissen hier postet.
    Ich denke das ist einmal eine vernünftige Übersicht, die auch dem ein oder anderen unentschlossenen bzw. unwissenden weiterhilft.


    Danke

    Zitat von "q1n0a1p0"

    Ich denke das ist einmal eine vernünftige Übersicht, die auch dem ein oder anderen unentschlossenen bzw. unwissenden weiterhilft.


    Das denke ich auch! :thumb:



    Ein paar Anmerkungen von meiner Seite als erklärter RTRR-Fan:


    Ich denke, QNAP nimmt für NAS-NAS den RSync-Prozess, weil viele oder sogar alle anderen NAS über dieses Protokoll kommunizieren können.


    Der RTRR zwischen zwei QNAP-NASsen ist die schnellste Backup-Verbindung. Dies mag bei den stärkeren Modellen möglicherweise nicht ganz so deutlich zutreffen, wie bei den schwächeren Modellen. Ich habe unter der FW 3.7.x Versuche mit meiner TS-112 und TS-659proII gemacht, hierbei erreichte die TS-112 via RSync eine Datenrate von ca. 15 MB/sec und via RTRR eine Datenrate von 45 MB/sec von und zur 659proII, imho ein schon sehr deutlicher Unterschied.


    Erstsicherungen sind immer zeitaufwendiger als Nachsicherungen, weil die Datenmengen dabei üblicherweise höher sind. Dies gilt für alle Übertragungsarten, insofern kann ich hier keinen von Dir genannten "Nachteil" des RTRR erkennen.


    Der Vorteil der Option des RTRR via FTP ist ein "Highlight" von QNAP, nachdem Syno sich die Finger lecken würde. Dies, weil der RTRR hiermit quasi zu einer "Universalwaffe" wird, auch in der Kommunikation zu nicht RTRR-Server- oder nicht RSync-fähigen Geräten - und das mit höchstmöglichen Geschwindigkeiten. Dieser Vorteil kommt mir in Deiner obenstehenden Aufzählung noch nicht genug heraus, daher "widme" ich ihm diese ausdrückliche Anmerkung dazu nochmals. ;)


    GLG GBD

    Hallo GBD!


    Danke für Deine ausführliche Antwort und Zusatzinfos.


    Der RTRR "Nachteil" dass die Erstsynchronisation länger dauert ist für mich auch kein Problem - die macht man ja nur einmal :)
    Ich habe es nur als Nachteil angeführt, da dies eine objektive Beschreibung sein sollte, und objektiv gesehen ist dies halt ein Nachteil...


    Ich verwend jetzt auch nur RTRR und bin damit vollstens zufrieden!
    Es kann all das was es können muss. Das schöne ist auch, dass ich z.B.: meine externe Festplatte anhängen kann und die aufs QNAP synchronisieren kann. Und dass geht besser und schneller als über die File Station - vom über den PC kopieren brauchen wir garnicht reden :)

    Hallo!


    Weis jemand was diese folgende Funktionen machen:
    - Ignore symbolic links: Wenn das aktiviert ist, werden dann die Links selber kopiert, der Inhalt des Pfade jedoch nicht?
    - Extended attributes: Welche Attribute (Dateiinfos) werden hierbei noch kopiert?
    - Check file content: Derzeit habe ich diese Funktion nicht angehakt, jedoch wird ein Dokument am Sicherungsziel trotzdem durch das neue ersetzt. Was macht das nun?
    - Wird das RTRR-Passwort verschlüsselt übertragen oder wird das nur verschlüsselt übertragen wenn ich die SSL-Verschlüsselung beim RTRR-/rsync-Job aktiviere?

    Habe RTRR nie verwendet, was in der Übersicht fehlt: rsync überträgt überhaupt nur die geänderten Daten (auch innerhalb einer Datei). Also zB riesige ISO Datei, nur der veränderte Teil wird übertragen. Was weiters sehr schnell geht ist die Überprüfung, ob und was sich überhaupt geändert hat.
    Ich sichere täglich mit rsync via VPN über eine gemütliche Internetverbindung. Erstsynchronisation habe ich im LAN gemacht - da braucht man übrigens kein rsync, sondern kann die Dateien einfach kopieren (wie ist das bei RTRR)?
    Hat jemand Erfahrung mit der RTRR via ftp?
    lg
    virtualcai

    Hey, danke für die schöne Übersicht, habe aber eine Frage zu:


    Zitat

    - Viele Konfiugrationmöglichkeiten, da man u.a. Daten nicht nur vom QNAP wegkopieren kann, sondern auch herkopieren kann (angesprochener Vorteil wenn ein starkes und ein schwächeres QNAP zur Verfügung steht).


    Wie genau muss es denn konfiguriert werden, damit es am schnellsten ist? Soll der starke QNAP als Server und der schwache Client sein? Auf welchem Qnap soll der Syncjob angelegt werden? Mich verwirrt das noch etwas....


    Hintergrund ist dieser: eine TS412 soll sich nachts um 3 hochfahren, und mit einer TS469 syncen...
    Vordergründig ist mir Geschwindigkeit wichtig und nachts um 3 ist eh keine Last auf dem 469, weswegen er (falls man sich das aussuchen kann) auch gerne die Hauptlast übernehmen soll, falls das schneller sein sollte...


    Welche der zwei Szenarien ist schneller?
    (Kann das auf die schnelle nicht selbst testen, da ja anscheinend das Erste mal extra lang dazuert...)


    1.)


    QNAP 469 ----------------------------> QNAP 412
    SyncJob anlegen ----schiebt nach----> RTRR-Server aktiviert




    oder


    2.)


    QNAP 412 <---------------------------- QNAP 469
    SyncJob anlegen <-----zieht von----- RRTT-Server aktiviert


    -----EDIT-------


    Laut diesem Post von GDB in einem anderen Thread sollte bei dem von mir oben beschriebenen Szenario die 412 den Replikationsauftrag übernehmen... Ich habe jetzt mal Testweise, weil ich es für sinnvoller erhalten habe (die 412er ist doch schon etwas schwächer auf der Brust), den Replikationsauftrag auf der 469er erstellt und beim ersten mal rüberkopieren von 51GB an Daten (relativ viele Dokumente, 28k Dateien insgesamt) sind maximal 5MB/s drin... per SMB erreiche ich wie beworben 24-27MB/s... liegt das nun an den vielen Dokumenten?
    Die CPU der 412er liegt dabei auch immer zwischen 90-100% Auslastung.


    Konfig:
    469Pro, 4x3TB, Raid 5, 4.0.5
    412, 3x3TB, Single Disks, 4.1 beta



    ---------EDIT 2---------


    So, jetzt stimmt die Geschwindigkeit.
    Lag daran, dass ich SSL aktiviert hatte... Ohne rennt das wie Sau direkt bei der Erstsynchronisation...
    Konfiguration wie oben unter 1.) beschrieben


    Jetzt frage ich mich wie das sein kann, dass es SO schnell läuft... Durchschnittliche Übertragungsgeschwindigkeit von 48MB/s obwohl QNAP die maximale Schreibgeschwndigkeit beim 412er mit 32,8 MB/s angibt.... :shock:
    Naja, mir soll's recht sein :)

    Ich muss mich hier auch mal wieder einklinken und hoffe das es nicht zu sehr OT wird.


    Ich benutze auch viel RTRR und es klappt ganz gut. Firmware ist noch 3.7.3 da hier das RTRR mit mehreren Jobs noch geht. Ab 3.8 ging das nicht mehr, alle anderen Jobs wurden ignoriert. Ich habe hierzu auch einen thread im Forum: http://forum.qnapclub.de/viewtopic.php?f=166&t=22521


    Also habe ich auf 3.7.3 downgraded und arbeitet seit dem damit. Leider hat in der FW das RTRR einen groben Bug. Fällt die Leitung zwischen den Geräten aus (VPN fällt ab und zu mal aus wegen zu langer Anbindung zum Straßenverteiler) und der Retry Timeout wird erreicht, zerschießt sich die RTRR Job Config. Ich muss dann erst mal alles wieder mit WinSCP in die Config hochladen, die ich mir zum Glück immer sicher.


    Die Frage ist nun: ist das in den 4.x Firmwares noch immer so? Ich habe leider keine Testmaschinen zur hand und die Produktiv Kisten kann ich nicht dafür benutzen. Im Detail: geht wieder mehr als ein Job? Werden die Jobs beim erreichen des Timeouts noch immer zerstört?


    Gruß Andreas

    Der RTRR-Dienst ab QTS4.x ist mit dem RTRR-Dienst von 3.8 und älter nicht mehr 100% kompatibel. QNAP arbeitet seit über 6 Monaten daran.


    Gruß vom subitus

    ok, dann haben wir geklärt das V4.x mit pre 3.8x nicht kompatibel ist.


    Was ist aber mit meiner eigentlichen Frage? Wie viele Jobs können unter V4.x angelegt werden und wieviel Ordnerpaare pro Job sind möglich? Infos dazu kann ich leider nur sehr spärlich finden und die wiedersprechen sich teilweise. Wer hat genaue Angaben dazu und hat das auch getestet?

    Zitat von "subitus"

    Der RTRR-Dienst ab QTS4.x ist mit dem RTRR-Dienst von 3.8 und älter nicht mehr 100% kompatibel. ...


    Worin äussert sich diese Inkompatibilität?

    Du wirst das brauchbare Limit von anzulegenden Jobs sicher nicht erreichen.


    5-6 Ordernerpaare Pro Auftrag sind möglich.


    PS: Wieso probierst du es nicht einfach aus?

    Dinosaurier:
    Der RTRR-Bug wird sichtbar, wenn auf einem QNAP-System mit einer 3.x-Firmware ein RTRR-Job eingerichtet werden soll, bei der ein lokaler Ordner mit einem Remote-Ordner per Zeitplan synchronisiert werden soll. Während der Konfiguration/ Einrichtung im Wizard klappt alles wie beabsichtigt und sieht fehlerfrei aus. Sobald dieser Job erstmalig (i.d.R. direkt nach der Erstellung) ausgeführt wird, tritt ein Fehler auf: Der RTRR-Dienst interpretiert die eingestellten Verzeichnispfade des Remote-Systems als Pfadangabe eines externen Device - welches natürlich nicht existiert. Da die 4.x-Binaries des Backup-Dienstes mit neuen Bibliotheken übersetzt wurden, kann man die Binaries auch nicht einfach austauschen.


    Daher kann der RTRR-Dienst nicht genutzt werden, wenn:
    - auf dem Quellsystem (RTRR-Master) eine 3.x-Firmware läuft
    - auf dem Zielsystem eine 4.x Firmware läuft
    - RTRR mit Scheduling (Zeitsynchronisation) verwendet werden soll



    Auswege:
    (a) RTRR-Rollentausch der QNAP-Systeme (das 4.x-System führt die RTRR-Synchronisation durch)
    (b) RTRR via FTP
    (c) RSYNC verwenden


    Wenn man bedenkt, dass es durchaus aufwändig sein kann, die Infrastruktur ständig umzustellen, um Workarounds für vorhandene und neue Bugs zu finden (ich synchronisiere mehrere lokale und getunnelte QNAPs und Webserver regelmäßig), bleibe ich lieber bei einer funktionierenden Firmware und kann mich auf meine Konfiguration verlassen.



    Hoffe, geholfen zu haben.
    Gruß vom subitus

    Ich habe den RTRR von meiner 269pro (FW 4.1 RC1) "saugend" mit meiner 559pro (FW 3.7.2) durchaus ans Laufen bekommen.


    Seltsamerweise ist der Dateitransfer allerdings extrem langsam (nicht über 10MB/sec, teils nur 1-3MB/sec). Habe daher umgestellt auf RTRRviaFTP, das funktioniert wie gewohnt schnell (um 100MB/sec). Der RTRR von meiner 659proII (FW 3.7.2) zur 559pro zeigt solche Negativ-Effekte nicht, es stimmt also wirklich etwas nicht im Zusammenspiel der RTRR-Server zwischen älteren Versionen und der QTS4.


    GLG GBD

    Manchmal könnte man sich am ...... ähhhhh .... Kopf kratzen. Allerdings scheint es bei alternativen Anbietern auch heftige Probleme mit der aktuellen Firmware zu geben. Die Welt ist schlecht ...

    GorillaBD:
    Je nach individueller Systemumgebung (welche Systeme treffen aufeinander - exakte Firmwarebuilds, Anzahl und Reihenfolge vorangegangener Updates, usw.) kann es sein, dass der Dienst sogar sauber läuft - was aber nach Analyse des Fehlers eher Zufall sein dürfte. Von v3.7.x nach v4.02 wurde einiges im RTRR-Dienst mehrfach verändert und bereinigt. Dabei hat man aber die Regeln der Abwärtskompatibilität leider durchbrochen (man muss auch notfalls alte Fehler "mitschleifen" :) ). Man hat mir bestätigt, dies nicht hinreichend mit älterer FW getestet zu haben, daher habe ich QNAP in mehreren nächtlichen Sitzungen die Möglichkeit gegeben, das Problem auf meiner Maschine zu untersuchen. Damals "versprach" man mir, ernsthaft über eine gefixte 3.x-Firmware nachzudenken (woran ich allerdings nicht glaube - siehe Problematik Produktmanagement).


    Immerhin hat man das Performanceproblem des QTS4-AJAX-Frameworks aufgegriffen und hoffentlich auch die berichteten Leaks...



    Ich hätte nichts dagegen, wenn QNAP die Quellen der v3.x vollständig freigeben würde. Ich hätte einige Ideen, die den Weg in die FW finden würden... 8-)



    Gruß vom subitus

    Zitat von "HennesyNet"

    PS: Wieso probierst du es nicht einfach aus?


    wie ich berteits erwähnte sind die Geräte im Produktiveinsatz und laufen unter 3.7.x
    Ich kann es mir nicht erlauben mal so zum testen eine andere FW zu installieren um dann experimentell zu ermitteln was geht und was nicht. Deshalb noch mal meine Frage, ob jemand Exakte Werte zur Jobanzahl und der Anzahl der möglichen Ordnerpaare hat.

    Es sind nach wie vor 5 Ordnerpaare je Job möglich.
    Die Anzahl der Jobs selbst unterscheidet sich je nach verwendetem NAS-Modell, bei einer Atom-NAS sind es deutlich mehr, als bei einer ARM.
    Wo diese Informationen zu finden sind, wusste ich mal, seit den Änderungen auf der QNAP-Webseite finde ich es leider auf die Schnelle nicht mehr wieder.


    GLG GBD

    Das erste habe ich dir bereits beantwortet.


    In diesem Fall kann ich nur empfehlen: "never change a running...."


    PS: Danke an den Kollegen Dinonsaurier.

    2 Mal editiert, zuletzt von HennesyNet ()

    Steht alles im Handbuch. Mal aus dem Gedächtnis:


    - ARM: Max. 8 Jobs zu je 5 Ordnerpaaren
    - INTEL: Max. 32 Jobs zu je 5 Ordnerpaaren