Timestamp bei rsync

  • Hallo,

    ich kopiere gerade größere Datenmengen von meinem QNAP auf ein Synology (DSM 7.x)
    Die Synology ist rsync-Server.
    Im QNAP verwende ich die HBS 3 und nutze den One-Way-Sync.
    (Anders kann man offenbar einen "fremden" rsync-Server nicht ansprechen ???)

    Funktioniert alles prima, allerdings ... egal was ich in den Regeln auch einstelle, der originale Timestamp der Dateien wird nicht übernommen.
    Alle kopierten Dateien sind quasi von "heute".
    Mache ich was falsch oder ist das einfach so?

    Bei Dateien, bei denen mir das wichtig ist, nutze ich jetzt an Windows Robocopy.
    Aber dann muss die Kiste halt über Nacht auch noch extra mit laufen.
    Eleganter wäre, wenn rsync das auch irgendwie könnte.

    Habe bestimmt nur irgendwas übersehen X/

    Danke für eine Info und viele Grüße ans Forum ...

  • RSYNC kann auch Dateiattribute wie Erstellungsdatum oder Änderungsdatum übertragen. Bei HBS3 muss dazu die Option "ACL und erweiterte Attribute beibehalten" aktiviert werden.


    Alternativ kann man auch rsync via SSH aufrufen. Dort gibt es dann die Option -a oder -t

  • Vielen Dank, Variag

    ich hatte es eigentlich schon mit dieser Option (ACL und erweiterte Attribute beibehalten) probiert.
    Werde das aber nochmals testen.
    Meld mich ... und vielen Dank nochmals!

  • Athos HBS3 sagt mir jetzt nichts...

    Ich schaufele gerade die Daten meines alten NAS auf das qnap und nutze dafür die Optionen -avrP bei rsync und es funktioniert wunderbar.

  • Mod: Unnötiges Direktzitat entfernt! :handbuch::arrow: Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

    Hybrid Backup Sync 3
    Die Sicherungs-Application von QNAP

    Leider kenne ich mich auf der Befehlszeile nicht so gut aus und wollte es mit den Standard-Bordmitteln erledigen.

    Aber wie gesagt ... ich probiere morgen noch den Haken: "ACL und erweiterte Attribute beibehalten"

    Möchte ich nur gerade nicht, da ich im Moment via Robocopy 4 TB an Dateien kopiere ...

    Gute Nacht allerseits ...

  • ich hatte es eigentlich schon mit dieser Option (ACL und erweiterte Attribute beibehalten) probiert.

    Das ist auch die falsche Option. Die hat damit nichts zu tun. Bei mir ist die abgewählt, und Dateidatum und -uhrzeit werden trotzdem im Ziel korrekt übernommen. Ziel ist auch Syno, aber mit DSM 6.2.


    Jetzt fragt mich nicht, was die richtige Option ist. Ich hatte da nie ein Problem.


    Um weiterzuhelfen: Folgende Richtlinien sind bei mir eingestellt:

    Geschwindigkeitsbeschränkungen: Nein

    TCB-BBR-Übertragung: Ja

    Zusätzliche Dateien entfernen: Ja

    Verstreute Dateien erkennen: Nein

    Dateiinhalte prüfen: Ja

    Dateien komprimieren: Nein

    ACL und erweiterte Attribute replizieren: Nein

    Keinen Snapshot aufnehmen: Ja, ist aber ausgegraut

    Zielberechtigungen anwenden: Nein


    Eine mögliche Fehlerursache kann auch auf dem Syno liegen.


    Hat der Benutzer, mit dem du dich in HBS extern anmeldest, das Recht, das Dateidatum zu ändern?


    DSM 7.0 gegenüber 6.2 kann auch einen Unterschied machen. Da hat sich ziemlich viel geändert, was den Root-User betrifft. (Der Grund, warum ich noch 6.2 nutze, ist allerdings schlichtweg, dass es für mein Syno kein 7.0 mehr gibt.)


    Ist der rsync-Server auf dem Syno korrekt konfiguriert? Siehe hier. Du kannst sogar eine benutzerdefinierte rsync-Konfiguration verwenden.


    HBS nutzt für rsync übrigens den Aufruf rsync --server --daemon .

    Wenn man ssh-Keys zur Anmeldung verwendet, kann man dem Aufruf weitere Parameter unterjubeln.


    und nutze den One-Way-Sync

    Ja, das muss man machen. Backup mit Historisierung funktioniert nicht. Wenn man eine Historisierung möchte, muss auf dem Syno ein weiterer Backup-Job laufen (lokal von interner Platte auf interne Platte), der historisiert. Das empfehle ich, denn wenn Dateien gelöscht oder zerstört werden, und der rsync-Job läuft, bevor du das merkst, sind die Daten auch im Backup weg (Ich hatte hier gerade die Tage einen Fall, wo das Mounten des Quellverzeichnisses schief gelaufen ist, und danach hat der Job das ferne Synchronisationsverzeichnis gelöscht.). Dann hältst du die Daten zwar einmal zusätzlich vor, aber dafür hast du dann auch auf dem Syno ein Backup, an das kein noch so gewiefter Verschlüsselungstrojaner auf dem Qnap ran kommt.


    Wenn beide NAS im gleichen LAN stehen, dann gibt es noch eine weitere Möglichkeit: Das Syno mounted die zu sichernden Verzeichnisse vom Qnap (wichtig: Nur lesend!) und macht von diesen ein lokales Backup. Das ist auch sicher gegen Verschlüsselungstrojaner. Eine solche Lösung habe ich mit einem WD NAS und dem Syno im Einsatz.

  • Vielen, vielen Dank für Deine ausführliche Antwort, Anthracite!

    Super hilfreich :thumbup:


    So weiß ich das nächste Mal Bescheid, auf was ich achten muss.

    Das war jetzt bei mir eine einmalige Aktion mit dem Verschieben von Dateien.


    Viele Grüße

  • Hallo Anthracite,


    ich habe das demnächst noch mal bei jemand anderem vor.
    Von QNAP auf Syno ...

    Wenn beide NAS im gleichen LAN stehen, dann gibt es noch eine weitere Möglichkeit: Das Syno mounted die zu sichernden Verzeichnisse vom Qnap (wichtig: Nur lesend!) und macht von diesen ein lokales Backup. Das ist auch sicher gegen Verschlüsselungstrojaner. Eine solche Lösung habe ich mit einem WD NAS und dem Syno im Einsatz.

    Magst Du bitte noch mal erklären, wie das gemacht wird?
    Finde die Funktion irgendwie nicht...

    File Station und dann Remote-Verbindung? Als FTP ?

    Danke noch mal für Hilfe und beste Grüße,
    Steffen

  • Auf Qnap (also der Quelle):

    Ganz normal eine Freigabe einrichten, einen Benutzer für das Backup, und dieser bekommt auf die Freigabe nur Leserechte.


    Auf Synology (also dem Ziel):

    Diese Freigabe muss gemountet werden. Ich habe dazu einen Eintrag in /etc/fstab angelegt (siehe die Linux-Doku dazu).


    Leider löscht Syno nach einem Reboot die fstab und ersetzt sie durch eine Standard-Datei, so dass der Mount dann leider wieder weg ist. Daher muss die Datei /etc/fstab beim Hochfahren wieder angepasst werden. Ich habe das mit diesem Skript

    Code
    grep _deine_Freigabe_ /etc/fstab >/dev/null
    if [ $? -eq 1 ]
    then
      cat /volume1/_dein_Verzeichnis_/fstab-extra >>/etc/fstab
      mount -a
    fi

    gemacht, wobei du Namen mit _ entsprechend deinen Werten ändern musst und die Datei fstab-extra muss die zusätzlichen Zeilen in fstab für deine Freigabe enthalten.


    Damit das Skript beim Hochfahren automatisch ausgeführt wird, muss es nach /usr/local/etc/rc.d kopiert werden.


    In dem Skript kann man statt über fstab zu gehen sicher auch direkt mounten. Ich habe es aber nicht ausprobiert.


    Das Backup auf der Syno legst du ganz normal an als Backup von lokal nach lokal.

  • Hallo Anthracite,


    vielen Dank für die ausführliche Antwort!
    Ok, geht also nur auf der Befehlszeile...

    Ich schau dann erst mal, ob es nicht vielleicht auch einfacher mit einem Backup-Job geht.
    Vielleicht hatte ich ja nur was falsch eingestellt, sodass der Zeitstempel nicht übernommen wurde.

    Ich probiere nächste Woche mal bissel rum und schreibe dann hier meine Erkenntnisse.

    Danke & Gruß,
    Steffen

  • Ok, geht also nur auf der Befehlszeile...

    Vielleicht geht es auch über die GUI (File-Station oder wie das bei Syno heißt wäre mein erster Ansatzpunkt), aber da das NAS nicht bei mir, sondern bei bekannten steht, komme ich über ssh besser dran und habe andere Möglichkeiten gar nicht erst probiert.

  • Hallo noch mal,


    ich hab das jetzt rausgefunden.

    Ist ganz simpel... peinlich, dass ich das nicht eher gecheckt habe ... :S8o

    Syno -> File Station

    Extras > Remote-Ordner bereitstellen > Freigegebener CIFS-Ordner


    Leeren Ordner erstellen in die QNAP-Freigabe dort mounten.


    Super Sache!


    Frohe Ostern an die Community :beer: