RTRR Backup mit Sicherungs Manager dauert ewig

    Ich musste mein Backup neu aufbauen.

    Da es sich um eine größere Datenmenge (größer als 6TB) handelt wollte ich nicht alles von meiner TS-563 über das Netzwerk auf meine TS219 PII übertragen.

    Also habe ich die externen Platten genommen und diese als Beginn mal übertragen.


    Wenn ich nun den Sicherungs Manager mal auf einen Teil der Daten einrichte auf der TS-219 PII gibt er nach kurzer Zeit aus, dass er noch mehr als 4000 Stunden braucht.

    Das kann doch nicht sein?


    Wenn ich ein normales rsync auf einer Raspberry anstoße, läuft das mit dem gleichen Verzeichnis wie beim Sicherungs Manager in ein paar Minuten durch.


    Ich will das aber automatisieren und nicht immer den Raspberry dafür nehmen.


    Ein Rsync Script wie ich bei Normalen Linux Maschinen beruflich verwende, schlägt mit auth failed immer fehl.

    Also hält sich das QNAP Linux nicht an das normale rsync.

    Ein TS-219 ist ein uraltes NAS mit ARM Prozessor. Ich hatte vor Jahren ein TS-419, das lief auch nur als Backup NAS.

    Das war so langsam, das man nicht mal richtig in die GUI kam, wenn ein Job lief.

    Ich habe das dann mit einem TS-459 ersetzt, das bis heute problemlos läuft.


    Mit anderen Worten: ein TS-x19 ist so schwachbrüstig, dass das durchaus sein kann.


    Gruss

    Danke, aber dass die TS 219 alt und langsam ist, ist mir bewusst.


    Ich frage mich nur warum ein rsync script in der Konsole vieles schneller ist der Sicherungsmanager.

    Weiters frage ich mich, warum ich im QNAP Linux kein normales rsync Script starten kann.


    Wenn ich die Fehler in Bezug auf QNAP suche, kommen finde ich keine Lösungen.

    Also heißt das für mich das das QNAP Linux ein Closed Source ist.

    Zitat von maci23

    Weiters frage ich mich, warum ich im QNAP Linux kein normales rsync Script starten kann.

    Das frage ich dich auch.


    Ein Qnap-NAS kann sehr wohl das Ziel eines rsync-Aufrufes sein.


    Qnap stellt auf dem NAS rsync zur Verfügung, und das kann auch genutzt werden.


    Wo liegt jetzt dein Problem mit der Authentifizierung? Das sollte sich lösen lassen.

    jedes normale rsync Aufruf mit Rsync Server (der auch auf der NAS läuft) schaut so aus:

    Code
    /usr/bin/rsync -aP --password-file=/share/Download/scripts/rsyncpassword --delete [Quelle] rsync://admin@[ip_Adresse]/[Zielverzeichnis lt. rsyncd.conf]

    Wenn ich das zwischen den beiden Qnap's laufen lasse, kommt der Fehler "Segmentation fault".


    Lösung lt. einem Forum: "--sever-mode=0" einfügen.


    Also Aufruf geändert auf:

    Code
     /usr/bin/rsync -aP --sever-mode=0 --password-file=/share/Download/scripts/rsyncpassword --delete [Quelle] rsync://admin@[ip_Adresse]/[Zielverzeichnis lt. rsyncd.conf]


    Code
    @ERROR: auth failed on module [Defintion in der rsyncd.conf]
rsync error: error starting client-server protocol (code 5) at main.c(2625) [sender=3.0.7]

    Hier stehe ich dann an, denn es immer wieder dieser Fehler.

    Ich habe die rsyncd.conf auch ergänzt im die Angabe des secrets File und dieses auch angelegt.

    Update:

    habe nun den ssh Key der backup-nas in meiner hauptnas hinterlegt.

    Somit ist ein ssh Login von der Backup-Nas auf meiner Hauptnas möglich.


    Rsync läuft mit ssh Login und dadurch ohne Passwort abfrage.

    Somit lasse ich nun mein Backupscript in der Konsole über crontab einmal täglich laufen.

    Nach dem Backup schalte ich die Backup NAS wieder ab.


    Ich werde nun den Rsync Server auf beiden NAS abdrehen, da ich den nicht nutze.

    Einmal editiert, zuletzt von maci23 () aus folgendem Grund: Ein Beitrag von maci23 mit diesem Beitrag zusammengefügt.

    Ich hatte ssh-Keys schon vorschlagen wollen, aber da bist du selbst drauf gekommen :thumbup: . Beim Passwortfile kann es sein, dass irgendetwas im Format nicht stimmt, ein Problem, dass mit ssh-Keys nicht besteht. Und von der Sicherheit her sind ssh-Keys ohnehin zu bevorzugen.

    Dann läuft das Backup auf der alten Kiste mit Transportverschlüsselung?

    Dann wird es super langsam, mit SMB 1 hatte es max 45MB/s im Benchmark hingelegt.


    Die CPUs aus dieser Zeit konnten noch kein AES in Hardware.

    Ich habe das gleiche Problem mit Rsync, erst seit ein paar Wochen, früher war das mit gleicher Hardware anders. Siehe auch mein Beitrag dazu hier im Unterbereich.


    Habt Ihr hier eine Lösung gefunden?

    Hallo zusammen,


    bin zwar grad erst hier angekommen, aber schon auf bekannte Probleme gestoßen. RTRR-Sicherung eingestellt, dauert sehr lange und gefühlt werden da trotz Versionierung (10 Versionen) gefühlt Unmengen an Daten gesichert, sodass eine Gesamtmenge an zu sichernden Daten von ca. 3.5 TB und wenig Veränderung nach 2 Durchläufen bereits über 5 TB auf dem Ziel sind. Das kann irgendwie nicht so ganz stimmen – wenn es 4 TB gesamt wären, könnte ich es evtl. noch verschmerzen.


    Leider hab ichs im HBS3 nicht hinbekommen – und scheint auch nicht möglich zu sein – via rsync eine Versionierung einzurichten.


    Jetzt hab ich mit viel Rumgesuche und Rumgebastel ein Skript zusammengestellt (u.a. hat mir KI da auch geholfen) und aktuell bekomme ich es nicht gelöst, mich von Haupt NAS (TS-473A mit aktuellem QTS 5.1.5) zu Backup-NAS (TS-469L mit letzten QTS 4.3.4) zu verbinden. Entweder mache ich da grundsätzliche Fehler – bin noch nicht wirklich lange in der Thematik drin – oder aber da gibts andere Hürden. Auf dem Haupt-NAS ist admin deaktiviert und mein Account (hier mal als dummy bezeichnet) aktiv als Admin eingerichtet. Auf dem Backup-NAS ist admin ebenfalls deaktiviert und auch hier dummy mit gleichem Passwort eingerichtet.


    Wenn ich der Anleitung hier Folge: https://wiki.qnap.com/wiki/SSH…To_Set_Up_Authorized_Keys, kann ich zwar den SSH-Key erstellen, aber rüberkopieren aufs andere NAS geht schon mal nicht. Also zippen, downloaden, uploaden, entpacken und im Ordner .ssh des Users dummy einfügen.

    Wenn ich mich dann verbinde, wird wieder nach dem Passwort gefragt und wieder und wieder… Scheinbar isses doch nicht so easy für einen Nicht-Profi.


    Jemand einen guten Rat? Wäre wirklich sehr dankbar über Hilfe.


    Herzliche Grüße

    Ralf

    Zitat von derkolarsky

    Auf dem Haupt-NAS ist admin deaktiviert u

    Auf dem Backup-NAS ist admin ebenfalls deaktiviert

    Hallo,


    ich würde es mit dem "richtigen" admin versuchen. ;)


    Das Deaktivieren des admin bringt in der Regel nur Probleme, die man sonst icht hätte.

    Becker2020: vielen Dank für die Antwort. Ich dachte, es wäre eine „Sicherheitsmaßnahme“, die echten admin-Accounts zu deaktivieren und dafür eigene User mit eben admin-Rechten zu versehen. Dann versuche ich das mal… VIelen Dank.

    Sollte aber in diesem Fall nicht das Problem sein, ist der SSH Key an die richtige Stelle kopiert?

    Was gibt z.B. ssh -vvv dummy@IP aus?

    Läuft bei mir mit Key auch ohne den echten Admin.


    Gruss

    Also ich werde morgen das Ganze nochmal aus admin-Sicht durchexerzieren. Ich hoffe, dass ich nicht grobe Schnitzer im Erstellen, Platzieren und Rechte einstellen habe. Aber ich werde mir das morgen nochmal anschauen… Bin jetzt aus dem Netzwerk raus – Schicht für heute! ;)

    Aber vielen Dank schon mal für die Unterstützung.

    Zitat von derkolarsky

    RTRR-Sicherung eingestellt, dauert sehr lange und gefühlt werden da trotz Versionierung (10 Versionen) gefühlt Unmengen an Daten gesichert,

    Was ist sehr lange? Und ja, die Backups dauern.


    Wo machst du die Versionierung? Beim Kopieren auf das andere NAS? Das führt meiner Erfahrung nach zu einer längeren Backupdauer. Besser kann es sein, nur eine normale Synchronisierung zu machen (was dann noch kein echtes Backup ist!) und mit einem zweiten Job auf dem fernen NAS (dort angelegt) ein lokales Backup mit Versionierung zu erstellen. Das kannst du mal probieren.


    Dann ganz wichtig, "Dateiinhalte prüfen" darf nicht(!) ausgewählt sein, da sonst alle Dateien jedesmal komplett übertragen werden. Das erhöht die Zeit und das Transfervolumen ganz gewaltig. Ist die Option nicht ausgewählt, wird über Datum und Größe (und natürlich den Dateinamen) geprüft, was fast immer reicht. (Die Beschriftung der Option ist etwas irreführend.)

    Zitat von derkolarsky

    Das kann irgendwie nicht so ganz stimmen – wenn es 4 TB gesamt wären, könnte ich es evtl. noch verschmerzen.

    Wie hast du den Wert gemessen? Verbrauchsanzeige in der Fritzbox? Die ist irreführend. Als ich ein großes externes Backup initial neu erstellen musste (mehrmals, da ich was falsch gemacht hatte), hatte ich bereits nach drei Tagen einen Wert erreicht, der oberhalb des theoretischen Maximums des Internetanschlusses für den ganzen Monat lag.

    Zitat von derkolarsky

    kann ich zwar den SSH-Key erstellen, aber rüberkopieren aufs andere NAS geht schon mal nicht

    Am einfachsten: Auf beiden NAS den Editor öffnen, einmal id_rsa.pub, einmal authorized_keys, in einem Editor markieren, kopieren (ctrl-C), im anderen Editor einfügen (ctrl-V) und abspeichern.


    Bitte den geheimen Schlüssel id_rsa niemals kopieren.

    Zitat von derkolarsky

    Wenn ich mich dann verbinde, wird wieder nach dem Passwort gefragt und wieder und wieder…

    ssh ist sehr kleinlich, was die Rechte der Dateien betrifft.


    Folgende Rechte sind zwingend:

    Code
    ll .ssh
drwx------  Benutzer Gruppe  .      (also das Verzeichnis .ssh selbst)
-rw-------  Benutzer Gruppe  id_rsa
-rw-r--r--  Benutzer Gruppe  id_rsa.pub
-rw-------  Benutzer Gruppe  authorized_keys

    "Benutzer" und "Gruppe" sind Benutzer- und Gruppennamen desjenigen Benutzers, der sich anmeldet, also in dessen Home-Verzeichnis das .ssh-Verzeichnis steht.


    Wenn der Benutzer von Verzeichnis oder Datei falsch ist, oder falls auch andere Benutzer Lese- oder Schreibrechte haben (also zu viel Rechte), werden die ssh-Keys ohne weitere Fehlermeldung einfach nicht benutzt, und es kommt zu genau dem Verhalten, dass du siehst.


    Hinweis: Die Dateien id_rsa und id_rsa.pub sind möglicherweise nur auf deinem lokalen Rechner, von dem aus du dich anmeldest, vorhanden, die Datei authorized_keys möglicherweise nur auf dem fernen Rechner. Das ist in Ordnung und behindert die Funktion nicht.

    Hallo Anthracite,


    vielen Dank für die vielen Infos. Ich habe mit ein wenig Testen jetzt folgende Lösung für mich erarbeitet (auch wenns vielleicht etwas gegen die SSH-Key-Variante und rsync läuft):

    Vor-Ort-Situation: beide NAS (stehen direkt nebeneinander – ist auch so gewollt) sind nun über den 2. Ethernet-Port direkt per Netzwerkkabel verbunden, IPs 10.10.0.1 und 10.10.0.2, Dienstbindung fürs RTRR ist auf den zweiten Ethernet-Port eingerichtet.

    Hab noch einige Tests im kleineren Stil laufen lassen, bevor ich dann wieder das „große Backup“ aktiviere.


    Als Backup nutze ich HBS3 RTRR (Versionierung auf 20 Versionen - wird 2x am Tag ausgeführt) mit diesen Einstellungen:


    Bildschirmfoto 2024-02-13 um 13.51.33.pngBildschirmfoto 2024-02-13 um 13.51.52.pngBildschirmfoto 2024-02-13 um 13.52.05.pngBildschirmfoto 2024-02-13 um 13.52.18.png


    Damit hab ich verschiedene Szenarien getestet (verschoben/umbenannt/gelöscht/neue Dateien hinzugefügt) und durch die Versionen sind die Vorgänger wunderbar erreichbar und als "latest" ist dann quasi der aktuelle Spiegel von der Quelle auf dem Ziel zu finden.

    Tempo ist halt echt fein, weil das Maximum ausgereizt werden kann und den normalen Server-Zugriff aus dem Netzwerk eigentlich nicht wirklich beeinträchtigt, außer evtl. ein klein wenig Prozessor/Speicher-Ressourcen.


    Somit hab ich das für mich (als Nicht-Profi) etwas unklare Thema der SSH-Schlüssel-Thematik (jetzt gefühlt) aus dem Kreuz und das Ergebnis entspricht den Vorstellungen…


    Aber nochmals vielen Dank Leute für eure Erklärungen und Hinweise. Ich werde mir das auf alle Fälle nochmal in Ruhe zu Gemüte führen.


    Sonnige Grüße

    Ralf