Freigegebener Ordner mit Remote-Ordner synchronisieren

[Brendianer]

Hallo!
Ich habe einen Remote-Ordner in die Synoology eingebunden. Jetzt möchte ich einen freigegebenen Ordner der Synology auf diesen Remote-Ordner (nur in eine Richutng) synchronisiern?
Wie mache ich das?
Vielen Dank.

 

[plang.pl]

Das geht m.W. nicht mit Boardmitteln.
Wo kommt der Remote Ordner her?
Kannst du auf diesen vielleicht direkt beschreiben per WebDAV oder rsync? Dann könnte man das mit Hyper Backup oder CloudSync machen.
Ich denke aber, dass dein Vorhaben auch mit der 3rd Party App names "Basic Backup" abgebildet werden könnte.

 

[synfor]

Doch mit RSync sollte das schon gehen. Man muss nur aufpassen, dass der Remote Ordner auch eingehängt ist.

 

[Brendianer]

Ich schaffe es nicht, den eingebundenen Remote-Ordner mit einem Backup Tool zu beschreiben.
Zur Verdeutlichung:
Ich möchte einen shard folder meiner Synology (music) auf diesen Pfad
\\10.100.5.70\Data\Storage\InternalStorage\
kopieren oder noch lieber synchronisieren.

 

[ottosykora]

Du musst zuerst wissen mit was man den remote beschreiben kann. Also ob es mit rsync geht oder webdav oder mit was auch immer. Dann können die Kollegen hier was konkretes antworten.

 

[Brendianer]

Das weiss ich auch nicht.
Es handelt sich um einen "Roon Optimized Core Kit" (gemäss Beschreibung: Roon OS is a custom Linux based operating system, tailored for running Roon Server and providing a best-in-class, appliance-type user experience.)
Diesen Musikserver habe ich seit einem Jahr und habe jetzt aus Performancegründen einen internen Speicher eingebaut, auf den die Musikfiles kopiert werden sollen. Der Master soll aber eben die Sammlung auf der Synology bleiben.
In der Beschreibung findet sich zu diesem internen Speicher nur dies (NUCLEUS wäre dann die IP des Servers):

SMB Connection (Alternate Option)​

You can copy music to this drive by visiting the network share:

1. From a Windows PC
   1. Open File Explorer
   2. Enter \\NUCLEUS\Data\Storage\InternalStorage
   3. If you have issues connecting, please see this article for additional help
2. From a Mac
   1. Open Finder
   2. Press Command + K
   3. Enter smb://NUCLEUS/Data/Storage/InternalStorage

 

[Nixnuzz]

Die DS-eigenen Tools, die ich bisher kenne (Hyperbackup und Snapshot Replication), weigern sich generell, SMB-Freigaben als Ziel zu akzeptieren - warum weiss ich auch nicht.

Am einfachsten erscheint mir "rsync [optionen] quellverzeichnis zielverzeichnis" auf der DS als Aufgabe im Aufgabenplaner anzulegen - wobei du sicherstellen must, dass der Nucleus tatsächlich im Zielverzeichnis gemountet ist.

... aber besser wäre, auf den Nucleus direkt zu rsyncen. Dort ssh freischelten - dann funktioniert "rsync -e ssh quellverzeichnis/ ich@nucleus:/pfadzumziel" - und nach diesem Schema arbeitet auch die "Synchronisierung freigegebener Ordner"

 

[Brendianer]

Oh, das tönt schon mal verhiessungsvoll.
Wie schaltet man ssh frei?
Und würde denn mein Befehl so lauten?

rsync -e ssh music/ 10.100.5.70:/Data/Storage/InternalStorage/

 

[Nixnuzz]

... habe gerade nach deinem Nucleus geschaut, das wird nix mit ssh und rsync - muss also alles auf der DS passieren.
Mal Schritt für Schritt:

1) ssh einschalten
- Systemsteuerung -> Terminal & SNMP -> SSH-Dienst aktivieren -> Häkchen setzen
- ssh-Client für deinen PC/Mac besorgen, mit deinem NAS (IP oder Namen) verbinden
- Benutzernamen und Kennwort eines admin-Kontos (auf der DS) angeben
- beim der ersten Verbindung wirst du gefragt, ob du der Gegenstelle vertraust -> Ja bzw Yes
-> du hast eine Kommandozeile

2) Auf der DS Remote-Ordner bereitstellen
- in irgendeinem freigegebenen Ordner erzeugst du ein leeres Unerverzeichnis, zB nukleus
- das darf neben, aber keinesfalls IN deinem music-Ordner stehen
- File-Station -> Extras -> Remoteordner bereitstellen -> Freigegebener CIFS-Ordner

Ordner: \\NUCLEUS\Data\Storage\InternalStorage
Kontoname: leer lassen
Kennwort: leer lassen
anhängen an: -> auf Durchsuchen gehen, und dich bis zum frisch erstellten nukleus-Ordner durchklicken
Verbindung beim Start herstellen: Haken setzen -> Anhängen
--> nun sollte auf der DS unter nukleus der Inhalt von deinem NUKLEUS sichtbar sein

3) Syncen
- ssh-client starten, mit der DS verbinden
- "rsync -n -v -r --progress --exclude=@* /volume1/.../music/ /volume1/.../nucleus/"

die Optionen:
-n Trockenlauf, es wird nicht wirklich was geschrieben
-v ein bisschen mehr Outout
-r rekursiv, taucht in Unterverzeichnisse ein
--progress Fortschrittsanzeige
--exclude=@* schliesst die DS-eigenen @directorys und Dateien aus (bin nicht sicher, ob das in Hockkommas oder Anführungszeichen eingeschlossen werden muss)
--> Pfade must du anpassen, wie sie auf deiner DS tatsächlich sind, die slashes am Ende nicht vergessen
---------------------------------------------------------

Wenn das soweit funktioniert, kannst du den -n Parameter rausnehmen - dann wird der gesamte Inhalt deines music-Ordners auf den Nucleus gespiegelt, das gilt auch für Album-Cover etc. Beim ersten Mal dauert es ne Weile, je nach Datenbestand - beim nächsten Mal geht es VIEL schneller.

... und dann kommt der Punkt, wo du das als Aufgabe anlegen kannst, und kein ssh mehr brauchst (--progresss dazu rausnehmen)

 

[Brendianer]

Also ich muss sagen @Nixnuzz : du bist der Champ des Tages. Das funktioniert perfekt. Vielen Dank!
Job läuft im Moment, was aber sicher noch eine ganze Weile dauern wird bei rund 90.000 Files.
Nicht verstanden habe ich: "-v ein bisschen mehr Outout"
Und noch eine Frage: dieser Job synced dann nur noch die Differenz? Nicht mehr alle Files.

 

[Brendianer]

...habe noch den "Schalter" --delete ergänzt, damit gelöschte Files am Zielort auch entfernt werden.

 

[Nixnuzz]

Danke für die Blumen, freut mich dass es funktioniert

-v steht für verbose und gibt Infos raus zu Verbindungsaufbau, Dateianzahl, ... vor allem dann interessant, wenn es NICHT funktioniert. Das Gegenteil wäre -q bzw --qiet, wo ausser Fehlermeldungen nichts ausgegeben wird.

- richtig, beim nächsten Lauf wird nur noch die Differenz weggebügelt

-- delete ... ich meinte das wäre das Standardverhalten, kann mich aber irren, vielleicht unterscheidet es sich auch bei verschiedenen Implementationen. Aber Bravo, du fummelst dich durch
-------------------------------------------------------

Für eine "richtige" Automation müsste ein Scipt her, das testet, ob der remote-Ordner auch eingehängt ist, genug Platz bietet, ggf eine Benachrichtigung verschickt ... aber da sind die Forenkollegen mit Sicherheit fitter, ich schwitz da immer Blut und Wasser.

Was mir noch einfällt - möglicherweise verwendet der Nucleus (ähnlich der DS) versteckte Dateien für die interne Verwaltung - die von rsync natürlich plattgemacht würden. Wäre clever gewesen, da vorher nachzuschauen ... ich hoffe, der Nucleus ist robust genug, die im Zweifelsfall selbst wieder anzulegen. Würde aber auf jeden Fall beim Hersteller nachfragen, um sie ggf. vom Löschen auszuschliessen.
------------------------------------------------------

Auch wenn der sync noch läuft - eigentlich müsstest du über den Nukleus schon was abspielen können ... geht?

 

[Brendianer]

So. Die 90.000 Files sind kopiert. Die Einrichtung auf dem ROCK problemlos und es lässt sich alles wie gehabt abspielen.
Dann wollte ich den zukünftigen "Workflw" testen und habe drei neue CDs gerippt, auf das NAS abgelegt und die "Aufgabe" wieder gestartet.
So wie es scheint, wird erneut alles kopiert? Der Job läuft nun schon wieder seit 2,5 Stunden und die Timestamps der Folder und Files erhalten ein heutiges Datum und die aktuelle Zeit.
Könnte man hier noch etwas am "Script" ändern?

 

[Nixnuzz]

So wie es scheint, wird erneut alles kopiert? Der Job läuft nun schon wieder seit 2,5 Stunden und die Timestamps der Folder und Files erhalten ein heutiges Datum und die aktuelle Zeit.
Könnte man hier noch etwas am "Script" ändern?

Das sollte auf keinen Fall so sein, besonders wegen der timestamps

Eigentlich bleibt der Zeitstempel der Quelldatei bei der rsync-Übertragung erhalten... das ist schräg.

Ich seh zwei Möglichkeiten:

a) die DS macht irgendwas mit den Musikdateien, so dass sie Zeitstempel von heute bekommen (zB taggen mit Metadaten) - was dann neuere Dateien sind, die neu synronisiert werden.
a1) ... was sich evtl. sogar auf den bereitgestellten Remote-Ordner erstreckt (ganz schlecht)

b) der Nucleus macht irgendwas in der Art, was dann ebenfalls zu "unterschiedlichen" Dateien führt.
--------------------------------------------------

In allen Fällen lässt sich was machen, wenn man herausbekommt, was eigentlich los ist.
a1) lässt sich warscheinlich ausschliessen, in dem man den Remote-Ordner in einer Freigabe einhängt, die NICHT zu den "Indizierten Ordnern" gehört.

Ich würde dich bitten, einen kleines Experiment zu machen - morgen - wegen der timestamps von heute:

1) die Synchronisation auf einen kleinen, schonmal syncronisierten Unterordner beschränken - dazu die Pfade im rsync-Kommando anpassen
2) VOR dem Sync eine Auflistung Dateien samt Zeitstempel machen:
ls -al /pfad/quellordner/
screenshot machen, oder den Output kopieren und in eine Textdatei schreiben
3) dasselbe für den Zielordner
4) Den sync durchführen
4) Punkt 2) und 3) wiederholen
5) Das Ganze hier posten für einen Vorher-Nacher-Vergleich

Ps: jetzt wird der -v Parameter interessant - da sagt rsync recht detailliert was es macht, (oder machen würde mit -n)

 

[Brendianer]

Ok. Mache das am Wochenende.
Die Aufgabe hat von 06.45 bis 19.15 gedauert.
Ich habe jetzt einmal den Freigabeordner "music" aus dem Index entfernt. Was auch noch mitgespielt haben könnte: der Freigabeordner "music war vorher auf dem ROCK als Musikquelle eingebunden. Der ROCK sucht da regelmässig nach neuer Musik.
Dieser ist nun entfernt.

 

[Brendianer]

So. Bin gespannt...

 

[Nixnuzz]

Ah ok. Lass bitte den sync nochmal mit -u Paramenter laufen - das müsste es lösen.
(Und mit -v, um zu sehen was tatsächlich kopiert wird)

Aus der manpage von rsync:

-u, --update skip files that are newer on the receiver

PS: noch besser mit -t UND -u

Erklärung: -t bewirkt, dass die Datei im Ziel den selben Zeitstempel erhält wie in der Quelle - damit arbeitet der Abgleichmechanismus effektiver. Ohne -t bildet rsync Checksummen über die Dateien, um festzustellen, ob sie gleich sind, was ziemlich lange dauern kann.

Etwas dauern kann es bei einem vollsync trotzdem - auch wenn nur neue Dateien übertragen werden - wenn über SMB 90000 Dateien nach Namen, Länge und Datum verglichen werden.

 

[Brendianer]

Hier ein weiteres Phänomen. Files mit z. b. Fragezeichen werden speziell behandelt.

 

[Nixnuzz]

Hmmm ... anscheinend nicht nur Fragezeichen, sondern deutsche Sonderzeichen allgemein

Da kann ich jetzt die Gründe nur vermuten. Samba (der SMB-Server) setzt warscheinlich die Linux-Dateinamen (auf dem Nucleus) in eine andere Kodierung (oder Codepage) um - oder der SMB-Client macht das beim Bereitstellen des Remote-Ordners ... gibt noch den --iconv Parameter, um damit umzugehen ... aber da komm ich ins Schwimmen.

Meld mich später nochmal.

 

[Nixnuzz]

Hab versucht, das mit 2 Diskstations nachzustellen. Auf DS1 einen Testordner und einen remote-Ordner von DS2 bereitgestellt - per Windows-VM auf dem Testordner ein paar Dateien mit Umlauten angelegt - allerdings weigerte sich Windows Dateien mit Fragezeichen im Namen anzulegen. Dasselbe von einem Linux-Client aus.

Die Darstellung der Umlaute im Terminal ist einwandfrei. Rsync Testordner -> Remoteordner auch einwandfrei. Verhält sich alles wie erwartet.

Die Dateien auf der DS scheinen mit einem falschen Zeichensatz angelegt worden zu sein, die Frage ist, mit welchem. Ich glaube, dass es die DS ist, weil die Falschdarsstellung ja die Quelldateien betrifft, während die gelöschten Zieldateien ja richtig angezeigt werden.

Was du versuchen kannst - im Ssh-client verschiedene Zeichensätze durchprobieren, und eins der betroffenen Quell-Verzeichnisse auflisten - bis die Darstellung der Sonderzeichen korrekt ist.

Falls ich mich irre, und die Darstellung im Quellverzeichnis ist auf Anhieb korrekt - dasselbe im Zielverzeichnis durchführen. Dann sehen wir weiter - wär ja gelacht, wenn wir das nicht hinbekommen