Kopieren mit Shell-Scrip und Volumes

[AndiHeitzer]

Hallo Gemeinde

Vorgeschichte:
Auf meiner DS Habe ich u.a. viele Bilder gespeichert, auch in einem kleinerem Format (800*600).
Das kleinere Format verwende ich, um diese in die Cloudstation zu kopieren, damit diese Offline auf den Mobilgeräten dabei zu haben.

Dazu verwende ich ein Shell-Script das in etwa so aussieht:

cp /volume1/bilder/kleinformat /volume1/cloudverzeichnis/bilder

Das mag im Detail nun keine korrekte Syntax sein, um die geht es mir nicht.

Ich bin auf die Schnappsidee gekommen, den shared Folder bilder (/volume1/bilder) auf ein anderes Volume umzuziehen. => /volume2/bilder
Wie zu erwarten, tut das Script bzw. der CP-Befehl natürlich seine arbeit nicht mehr richtig.

Unter Windows würde ich mit COPY \\DSxxx\bilder \\DSxxx\cloudverzeichnis von der Umzugsaktion praktischerweise nichts mitbekommen. Das möchte ich jedoch nicht umsetzen, weil der PC nicht regelmäßig an ist, bzw. genutzt wird.

Nun zu meinem konkreten Anliegen:
Wie kann ich sowas komfortabel auf der Konsole einer DS bewerkstelligen, ohne jedes Script anpassen zu müssen?
Meines Wissens gibt es unter LINUX kein \\SERVER\SHARE?
Mit Mountpoints möchte ich nicht hantieren, weil ich eigentlich kein grosser LINUX-Freak bin.

Über hilfreiche Antworten würde ich mich freuen.

 

[dil88]

Kennst Du die File Station im DSM-Webfrontend? Wenn nicht, schau Dir die doch bitte einmal an.

 

[AndiHeitzer]

Hallo dil88

Ja, die Filestation kenne ich
Ich muss gestehen, im Anfangsposting fehlt noch eine wichtige Angabe

==>> Ich kopiere die Daten mittels Shell-Script und Aufgabenplaner, also vollautomagisch

 

[dil88]

Und Du willst die Daten nicht synchronisieren - da würde sich rsync anbieten - sondern verschieben, richtig?

 

[AndiHeitzer]

Hallo dil88

So, hier mal mein Original-CODE etwas abgespeckt, weil in diesem Script noch etlich mehr gesynct/kopiert wird.

ALT:

export RUNPAR='rsync -ruxt --delete-before --ignore-errors'
export SOURCE='/volume1/HOME_andreas/Dropbox_Bilder/'
export DESTIN='/volume1/CLOUD_Andreas/PIX.Allgemein/'
$RUNPAR $SOURCE $DESTIN

NEU:

export RUNPAR='rsync -ruxt --delete-before --ignore-errors'
export SOURCE='/volume3/HOME_andreas/Dropbox_Bilder/'
export DESTIN='/volume1/CLOUD_Andreas/PIX.Allgemein/'
$RUNPAR $SOURCE $DESTIN

Hier bitte die roten Bezeichnungen beachten.

Mein Ziel wäre es gewesen, nicht mit absoluten Pfaden arbeiten zu müssen, sonder mit "Freigabe"-Namen, wie das unter Windows machbar/komfortabel wäre ...
Immer wenn ich nun einen Gemeinsamen Ordner auf ein anderes Volume umziehe, dann muss ich in den Scripten die Pfade anpassen, das wollte ich mir eigentlich sparen.

Der Hintergrund des Umzuges ist ja noch viel "umständlicher"
Die DS415 habe ich mittels DSM6 jungfräulich aufgesetzt, es aber versäumt, anstelle von EXT4 gleich auf BTRFS zu setzen.
Unter DSM5 war es möglich, dass ein User bei dem filebasierendem TimeBackup durch seine Filehistorie zu browsen. Dabei bekam er nur seine Files zu sehen, auf die er vorher schon berechtigt war.
Beim Hyperbackup-Explorer bekommt der User stets Zugriff auf alle Files, und das ist ja vollkommen blöde. TT bei SYNO ist offen, aber noch ohne Reaktion. Gut, ich könnte für jeden User einen eigenen Backupjob basteln ... aber auch das ist mir zu umständlich.
Nun beschäftige ich mich mit BTRFS (mein /volume3), weil damit Snapshots möglich sind. Dem User gebe die Möglichkeit, die Snapshots zu Browsen. Dann wäre ich wieder dort wo ich unter DSM5 schon war.
Wenn ich die DS nochmal plätten sollte, dann täte ich heute gleich mit BTRFS arbeiten ... das habe ich mittlerweile gelernt

 

[dil88]

Du kannst auch mit fixen Pfaden arbeiten, musst die dann aber per mount bind vorher bestücken. Einfacher ist das aber nicht, als das Skript zu bearbeiten.

 

[AndiHeitzer]

Hmmmm, oder mit Links?

ln -s /volume3/HOME_andreas /volume1/HOME_andreas

Werde ich heute abend antesten, wenn ich Zugriff auf die Konsole habe ...
Hätte ich nur ein Script, dann wäre das kein Thema, aber im Moment suche ich mir halt nen Wolf, wenn ich umziehe

Das mit dem mount/bind ist nicht so mein Ding ... kenne ich überhaupt nicht.

Bis hierher schon mal vielen Dank für Deine Aufmerksamkeit

 

[AndiHeitzer]

Also
Wenn ich ein gemeinsames Share von /volume1 nach /volume3 umziehe, genügt es, wenn ich auf /volume1 einen symbolischen Link auf das neue Verzeichnis setze.
Damit würde ein "Kopier-Mechanismus" seine Arbeit tun

Ob das nun der Weisheit letzter Schluss ist, da bin ich mit mir selber noch nicht im Reinen ...