jarss – (just another rsync shell script)

[Tommes]

Über eine mögliche Anpassung der Lizenz muss ich noch Gedanken machen und ein paar Nächte drüber schlafen. Trotzdem sag ich schon mal Danke für diesen Denkanstoß.

Was die Sache mit den Tags angeht, so habe ich das für meine Apps bzw. Pakete für ein Synology NAS bisher auch immer so gehandhabt. Da jarss für mich zunächst aber „nur“ ein einfaches Script ist, kam mir der Gedanke bisher nicht in den Sinn, entsprechende Tags bei Versionsprüngen anzulegen. Es stellt für mich aber absolut kein Problem dar, dies zukünftig anzubieten.

Ist ja bald Wochenende…

 

[Tommes]

Nun denn...

• Den fehlerhaften Variablennamen in der Zeile 105 habe ich korrigiert.
• Man kann sich ab sofort ein aktuelles Release in Form einer ZIP-Datei oder als .tar.gz Archiv herunterladen
  (wobei ich mir nicht erklären kann, woher dieser Contributors Link gekommen ist, geschweige denn, wie ich den wieder weg bekomme. Hast du vielleicht eine Erklärung dafür @DaveR )
  
• Ich habe die GPL-3.0 Lizenz durch eine MIT-Lizenz ersetzt (auch wenn ich erst eine Nacht darüber geschlafen habe ), da ich es für absolut vertretbar halte. Meine Pakete AutoPilot, LogAnalysis sowie das bereits stillgelegte Paket Basic Backup werden bis auf Weiteres auch weiterhin unter der GPL-3.0 Lizenz veröffentlicht. Was aus meinem Paket DSM7DemoSPK wird, lasse ich noch offen, daher änder’ ich an dieser Lizenz zunächst auch erstmal nichts.

 

[DaveR]

On Github any time you type /@something or @something it will create a link to any GitHub user with the username something. Your release notes contain 10 instances of /@recycle so GitHub thinks you were crediting the user recycle in the release notes. This also happens in issues and discussions, except that user gets an email because they were mentioned.

To avoid this I always enclose the @something in the grave accent ( ` ), also known a backtick or or backquote, like `/@recycle`

 

[Tommes]

Really?

 

[TB-UB]

Also wirklich nochmal Hut ab, ich versteh das script ja noch nicht wiklich.
Das mit dem synchron/inkrement/rotate/--link-dest/rm -rf/ln -s usw..., da muss ich mich nochmal reinfuchsen.


U.a. bei den Bedingungen bei den if's ist mir nicht klar, weshalb mal 2 Paar eckige Klammern gebraucht wird und wo anders nicht (vermutlich hängt es an der Art des Tests?!):
if [ -z "${language}" ] || [[ "${language}" == "enu" ]]; then
if [[ ${exit_code} -eq 0 ]]; then
if [[ "${whoami}" != "root" ]]; then
Würde es schaden bei den Bedingungen die im script bisher nur ein [] haben da nochmal ein zweites Paar [] rumzubauen?

Bei ein paar Abfragen frage ich mich, ob die jeweils erste Bedingung nicht weggelassen werden könnte (nur um es übersichtlicher zu machen), da m.E. die erste Bedingung true/wahr ist wenn es die zweite auch ist (laienhaft(!) gedacht) und das dann bei einem && überflüssig sein könnte (oder braucht man das um sowohl Zahlen als auch String als Variableninhalt abzudecken?):
elif [ -n "${recycle}" ] && [[ "${recycle}" == "true" ]]; then
if [ -n "${incremental}" ] && [[ "${incremental}" == "true" ]]; then
elif [ -n "${speedlimit}" ] && [[ "${speedlimit}" -gt 0 ]]; then
if [ -n "${recycle}" ] && [[ "${recycle}" -ne 0 ]] && [[ "${recycle}" =~ ${is_number} ]]; then
elif [ -n "${recycle}" ] && [[ "${recycle}" == "true" ]]; then
elif [ -n "${recycle}" ] && [[ "${recycle}" == "false" ]]; then
if [ -n "${incremental}" ] && [[ "${incremental}" == "true" ]]; then

 

[Tommes]

Versteh mich nicht falsch, aber du stellst echt komische Fragen. Es gibt durchaus do‘s and dont‘s die man beim Scripten beachten sollte, aber nicht zwingend muss und jeder entwickelt über die Zeit und die Erfahrung, die er sammelt, seinen eigenen Stil. Wenn dir also mein Stil nicht gefällt, ist das zunächst dein Problem und nicht meins und wenn dich das triggert, musst du es halt ändern, verbessern, optimieren oder was weiß ich. Dank der Änderung der Lizenz hast du doch alle Möglichkeiten. Also tu, wozu immer du Lust hast. Oder nutze mein Script so wie es ist. Es funktioniert ja…

Ich verwende auch geschweifte Klammern um meine Variablen zu Kennzeichen, schreibe sie dabei aber klein und nicht komplett in Großbuchstaben, so wie manch anderer. Auch setzte ich nach einem if einen Trenner und hänge das ; then in die gleiche Zeile, anderer machen es klassisch richtig und schreiben das then in die nächste Zeile ohne den Trenner. Von daher weiß ich jetzt wirklich nicht, was deine Fragen sollen.

Das mit dem synchron/inkrement/rotate/--link-dest/rm -rf/ln -s usw..., da muss ich mich nochmal reinfuchsen.

Dafür hatte ich dir im anderen Thread einen Link an die Hand gegeben, wo das alles erklärt wird inkl. Beispielscript

 

[Tommes]

Neuer Tag! Gestern war ich wohl etwas angefasst, als ich meinen Beitrag geschrieben hatte. Egal…

bei den Bedingungen bei den if's ist mir nicht klar, weshalb mal 2 Paar eckige Klammern gebraucht wird und wo anders nicht

Die Verwendung einer eckigen Klammer reicht für einen einfachen Test und stellt den Quasi Standard in allen POSIX-Shells dar. Unter BASH verwendet man doppelte eckige Klammern als Erweiterung des test-Begehls, da man hier mehr Möglichkeiten hat. Unter anderem wäre das ein Mustervergleich von zwei Stings [[ "${stingA}“ == "${stingB}“ ]] .

Das ich die unterschiedlichen Schreibeisen vermische liegt einfach daran, das ich einen einfachen Test von einem Mustervergleich trennen möchte. Sicherlich kann man aber auch überall doppelte eckige Klammern verenden wenn als Shebang Bash ausgewählt wurde. Unter Verwendung von sh geht das glaub ich nicht.

Was das weglassen von Bedingungen angeht, so hat mir die Erfahrung gezeigt, das es immer besser ist, etwas doppelt oder auch dreifach zu prüfen, außer man ist sich hundertprozentig sicher, das eine einfache Prüfung keine Seiteneffekte nach sich zieht.

Unterm Stich ist es also tatsächlich so, das die Scheibweise einerseits das Ergebnis aus Wissen mal Erfahrung ist, anderseits entwickelt jeder Programmierer oder von mir aus Script‘er seinen eigenen Stil. Das mag der ein oder andere dann gut oder schlecht finden, ändert aber nichts daran, ob ein Script funktioniert oder nicht.

Optimieren lässt sich natürlich immer was und wenn ich mir in zwei Jahren ein Script anschaue, was ich heute geschrieben habe, würde ich sicherlich auch vieles ändern.

 

[TB-UB]

Falls ihr auch noch an das gute allte TimeBackup zurückdenkt....

Es schaut fast so aus, als wäre das Ergebnis.....

mit den Einstellungen
recycle="99999"
incremental="true"
versions="99999"
und einer kleinen Formatänderung im script Zeile 155:
statt date +"%Y-%m-%d %H:%M:%S" in etwa das hier setzt date +"%Y%m%d-%H%M%S"
und die Zeile 250 datetime=$(date "+%Y-%m-%d_%Hh-%Mm-%Ss") ersetzt durch datetime=$(timestamp)

....sehr ähnlich dem was TimeBackup hinterlassen hatte (wenn man mal TimeBackup tasks für einen share betrachtet; bei TB hat man ja auch mehrer shares in einen Zielordner sichern können). Ich kann mich an die Einstellungen bei TB nicht mehr erinnern, bei mir scheint es jedenfalls sehr sehr ähnlichen Output zu geben.

Möglicherweise könnte man sogar alte TimeBackups mit diesem script weiter betreiben....
Vermutlich müsste man dann noch vorher den Link für latest (auf den letzten TB-Ordner) manuell anlegen.
Und möglicherweise könnte man sogar mehrer Quellordner in einen Zielordner packen, so wie bei TB; müsste man halt ausprobieren.

 

[TB-UB]

Noch ein kleines finding (für alle die das script mit den unterschiedlichen Fällen verstehen wollen und so wie ich das Ausführungs-log durchschauen und sich fragen, weshalb da an einer Stelle ein slash mehrl oder an anderer Stelle weniger ist).

Die Zeile 369:
echo "${txt_rsync_write_log_target} ${target}/${source##*/}" | tee -a "${logfile}"
gibt in einem der möglichen Fälle einen slash zu viel aus (der nach dem ${target}/ )

Dies ist nicht wirklich relevant, da es nur eine echo Ausgabe ist, jedoch im anderen Fall führt es dazu, dass das rsync mit einem target ohne abschließenden slash gefüttert wird. Auch das ist wohl nicht relevant, da hier mit Verzeichnissen und nicht mit Dateien gearbeitet wird und damit spielt der slash beim target keine Rolle so wie ich es verstanden habe.

Man könnte diese irrelevante Inkonsistenz (echo-Ausgabe und rsync Parameter der unterschiedlichen Fälle) lösen durch zwei Miniänderungen:
Zeile 369 ändern in echo "${txt_rsync_write_log_target} ${target}${source##*/}" | tee -a "${logfile}"
und für den einen Fall den dann fehlenden slash hinzufügen:
Zeile 297 ändern in target="${init_target}${datetime}/"

 

[Tommes]

Was TimeBackup angeht, so kann ich nur sagen, das ich das Programm bisher noch nie verwendet habe. Somit habe ich auch keine Ahnung, wie es arbeitet. Sollte jarss.sh Ähnlichkeiten mit TB aufweisen, so ist das absolut unbeabsichtigt und damit reiner Zufall.

Der Slash in der Zeile 369 gehört da wirklich nicht hin, auch wenn es sich dabei, wie du bereits festgestellt hast, nur um einen Anzeigefehler handelt und somit keine Relevanz hat!

Was die Zeile 297 betrifft, bin ich jedoch anderer Meinung, da von Zeile 255 bis Zeile 258 festgelegt wird, das die Variable ${target} in jedem Fall mit einem abschließenden Slash versehen wird.

# Make sure that the target path ends with a slash
if [[ "${target:${#target}-1:1}" != "/" ]]; then
    target="${target}/"
fi

Genau aus dem Grund wird dir in Zeile 369 ein doppelter Slash ausgegeben. Fügst du in Zeile 297 nun einen Slash hinzu, dann wird dir auch hier ein doppelter Slash ausgegeben. Glaubst du nicht? Dann füge spaßeshalber ab Zeile 290 den nachfolgenden Codeschnipsel in die Datei jarss.sh ein, indem dein Vorschlag mit dem hinzugefügten Slash enthalten ist...

test_init_target="${target}"
test_target="${test_init_target}/${datetime}"
echo
echo "DAS IST EIN TEST: ${test_target}"

Nachdem dem speichern und erneuten Ausführen des Scripts erhalte ich als Ergebnis...

DAS IST EIN TEST: /volume1/NetBackup/Einzeldateibackup//2025-02-16_08h-59m-23s

 

[Tommes]

BTW:

mit den Einstellungen
recycle="99999"
incremental="true"
versions="99999"

Die beiden Variablen ${recycle} und ${versions} schließen sich gegenseitig aus. Das bedeutet, das wenn du eine inkrementelle Datensicherung (incremental="true") ausführst, die Papierkorbfunktion (recycle="99999") überhaupt nicht verwendet wird. Steht auch so im Kommentar zur inkrementellen Datensicherung...

...Die Papierkorb-Funktion (/@recycle) steht hier nicht zur Verfügung.

 

[TB-UB]

....

Nachdem dem speichern und erneuten Ausführen des Scripts erhalte ich als Ergebnis...

Genau an dieser Stelle (wo das target um datetime ergänzt wurde Z297; was nur im Fall incremental="true" passiert) ist es eben so, dass nun das neue target (das nach Zeile 257 nocheinmal verändert wurde) keinen slash mehr am Ende hat.
Deshalb könnte man wie von mir vorgeschlagen in Z297 dafür sorgen, dass auch hier ein abschließender slash dran kommt.

Damit dann in der späteren Ausgabe in Z369 für diesen Fall (incremental="true") kein doppel/ ausgegeben wird (was ja im bisherigen Original für den anderen Fall (incremental="false") immer passiert), könnte man in der Z369 den slash weglassen was den positiven Effekt hätte, dass für keinen der beiden Fälle von incremental ein doppel/ ausgegeben wird.

Wie gesagt, nur so ne Idee, für die Funktion nicht wichtig.


ps: möglicherweise wurde mein Vorschlag falsch verstanden; ich schlage einen zusätzlichen slash in Z297 nach dem ${datetime} vor und nicht davor (siehe letzte Zeile in #29)

ps2: ich bin nach wie vor voll begeistert von Deiner Arbeit.
Ich arbeite mich da nur rein, weil ich soweit möglich eine wirklich dauerhafte Lösung für meine "Backupstrategie" suche. Denn leider wurde das synology-eigene TimeBackup mit einem DSM Update einfach weggelassen, somit war meine Lösung von heute auf morgen unbrauchbar. Danach kam UltimateBackup, das ich genutzt habe um eine vermeintlich dauerhafte Lösung selbst zusammenzubauen (was ich ohne solche Beispiele nie geschafft hätte). Leider kam meine Lösung an seine Grenzen, da es pro Lauf ca 100GB verbraucht hatte. Ich muss mir also wieder was neues suchen. Wieder mit dem Ziel, einmal Aufsetzen und nicht mehr dran denken müssen, möglichst speichereffizient und dabei keine Änderung verlieren.
Mit dem Vorteil es selbst in der Hand zu haben und nicht wieder eine Lösung verwenden, die synology einfach abkündigt... ich hoffe nämlich, dass man wenigstens den Aufgabenplaner behält (etwas wie es anscheinend bei QNAP nicht gibt), um eigene scripte ziemlich einfach einbinden kann.

 

[Tommes]

möglicherweise wurde mein Vorschlag falsch verstanden

Ähm... vermutlich! Ich hatte wohl noch Schlaf in den Augen, als ich das hier gelesen habe...

Zeile 297 ändern in target="${init_target}${datetime}/"

... da in meinem Kopf immer noch der Slash hinter dem Target schwirrte und ich dachte, du meinst auch hier, das der Slash hinter das Target gehört und nicht, wie es ja da steht, hinter dem Datetime. Schimpf und Schande über mich!

Von daher, ja, du hast vollkommen recht. Wenn man den Slash in der Zeile 369 (hinter dem Target) entfernt und in Zeile 297 (hinter dem Datetime) hinzufügt, dann passt das.

Vielen Dank für den Hinweis und das du gleich die Lösung präsentiert hast. Ich werde das gleich mal ändern und auf GitHub hochladen.

EDIT:



Tommes