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

 

[Tommes]

jarss Version 1.0-300 vom 22.03.2025​

Release Notes

• Hinweis: Die Konfigurationsdateien bleiben auf dem Stand der Version 1.0-200 und können weiterhin verwendet werden, da hier keine Änderungen vorgenommen wurden.
• Schrägstrich am Ende des Zielpfads (nach dem Zeitstempel) in der Logmeldung hinzugefügt, wenn eine inkrementelle Sicherung verwendet wird.
• Ein doppelter Schrägstrich, der in einer Protokollmeldung enthalten war, wurde entfernt.
• Die inkrementelle Datensicherung brach mit einer rsync-Fehlermeldung ab, wenn der Zielpfad ein Leerzeichen enthielt. Der Fehler wurde behoben.
• Weitere kleinere Probleme bei der Behandlung von Leerzeichen behoben.

GitHub Repository
​

jarss (just another rsync shell script)​

Weiterhin viel Spaß mit jarss

Tommes

 

[Tommes]

Ich habe im hiesigen Wiki eine ausführliche Anleitung für jarss geschrieben, die ich euch hiermit präsentieren möchte.

• jarss (just another rsync shell script)
  • jarss herunterladen
  • jarss einrichten
  • jarss ausführen

Später werde ich noch den Eingangs-Beitrag dieses Thread entsprechend anpassen, ebenso wie die README.md meines GitHub Repositorys.

Weiterhin viel Spaß mit jarss

Tommes

 

[FWin]

Meine ersten Erfahrungen mit jarss (und ein Hinweis auf einen eventuellen Bug):

Vorgeschichte: Auf meiner DS218j unter DSM7 läuft Dein voriges Projekt "Basic Backup" problemlos mit Pull von einer anderen DS (danke nochmals für die letzte Korrektur bezüglich Versionierung, nachdem der Projektsupport eigentlich schon beendet war!). Nun wollte ich Dein neues "jarss" auf einer weiteren älteren DS (noch mit DSM6) ebenfalls als Pull-Backup laufen lassen. Und was soll ich sagen, das klappte auf Anhieb! Ausdrücklich herzlichen Dank dafür!

Trotzdem ist mir bei jarss noch etwas seltsames aufgefallen: Konfiguriert ist ein Pull-Backup von einer anderen DS als Quelle, inkrementell mit Versionierung und automatischem Löschen alter Versionen. Insgesamt sind 4 Quellverzeichnisse (Parameter "sources" in der Konfigurationsdatei) angegeben, die rsync laut Protokoll auch alle brav abgearbeitet hat. Bei genauerer Durchsicht der Sicherung fehlten aber dann einige der Quellverzeichnisse, andere waren da. Also die Sicherung noch einmal manuell angestoßen (nicht nur als "--dryrun" sondern real), rsync sicherte wieder alle Quellverzeichnisse (auch die, die beim vorigen Mal fehlten), was während des rsync-Laufs auch zu verfolgen war (über FileStation auf der DS). Aber am Ende fehlten die betreffenden Verzeichnisse wieder, obwohl sie definitiv unmittelbar vorher gesichert worden waren! Also offenbar ein Problem bei der Versionsbereinigung am Schluss. Dafür spricht auch, dass die in der Sicherung fehlenden Quellverzeichnisse, wie ich dann herausgefunden hatte, alle ein Datum hatten, das länger zurücklag als der eingestellten Anzahl an Versionen entsprach (Parameter "versions" in der Konfigurationsdatei).

Habe mir daraufhin mal "jarss.sh" näher angesehen und versucht zu verstehen. Wenn ich es richtig sehe, erfolgt das Löschen alter Versionen beim Pull-Backup im Script ab Zeile 576:

# Rotation cycle for deleting versions when /@recycle is switched off
if [ -d "${target%/*}" ]; then
find "${target%/*}/"* -maxdepth 0 -type d -mtime +${versions} -print0 | xargs -0 rm -r 2>/dev/null

Das verstehe ich so, dass aller Inhalt im Verzeichnis, das die Variable "target" bezeichnet, gelöscht wird, sofern das Datum länger zurückliegt als in der Variable "versions" angegeben. "target" enthält zu Beginn das Zielverzeichnis (also quasi das "Stammverzeichnis" für die Sicherung), "versions" das maximale Alter der Sicherungen in Tagen, bevor sie automatisch gelöscht werden. Soweit klar, aber: Beim inkrementellen Backup wird in "jarss.sh" die Variable "target", die ursprünglich das "Stammverzeichnis" für das Backup enthält, vor Beginn der eigentlichen Sicherung wie folgt überschrieben (im Script ab Zeile 292):

# Rewrite target folder and temporarily linked folder
init_target="${target}"
target="${init_target}${datetime}/"

Danach zeigt "target" auf den gerade neu erstellten datierten Ordner mit der aktuell gesicherten Version. Die abschließende Versionsbereinigung (siehe oben) greift somit auf diesen und nicht auf den übergeordneten Ordner zu, was das eingangs genannte Verhalten (Quellverzeichnisse mit älterem Datum fehlen in der Sicherung) erklären würde.

Obwohl ich mich bei Bash-Scripten hinsichtlich meiner Programmierkenntnisse auf sehr dünnem Eis bewege, trotzdem eine Idee zur Abhilfe: Wenn im oben zitierten Code der Versionsbereinigung in den Zeilen 577 und 578 nicht "${target%/*}", sondern "${init_target%/*}" stehen würde, müsste es funktionieren. Denn "init_target" enthält ja weiterhin das ursprüngliche "Stammverzeichnis" für die Sicherung, in dem auch die Versionsbereinigung durchzuführen ist. Ich habe das bei mir testhalber mal probiert, scheint zu laufen.

Allerdings überblicke ich noch nicht die gesamte Logik Deines (zugegebenermaßen ziemlich genialen) Scripts, daher weiß ich nicht, ob die vorgeschlagene Änderung zu Problemen an anderer Stelle führen könnte. Aber falls ich Recht haben sollte, wäre wohl die gleiche Änderung auch noch im Code-Zweig für Push-Backup (Zeilen 606 und 607) anzubringen.

Unabhängig davon, nochmals höchsten Respekt für Deine Arbeit und danke für jarss!

Winfried

 

[Tommes]

Moin!
Es ist noch früh und ich bin noch müde. Auch muss ich mir das alles erst in Ruhe anschauen und bestenfalls rekonstruieren um eine fundierte Antwort geben zu können. Nichtsdestotrotz danke ich dir für den Hinweis, deine Analyse sowie einem möglichen Lösungsvorschlag. Daher auch von mir höchsten Respekt, zumal du dich nach eigenen Angaben hier auf sehr dünnen Eis bewegst.

Gib mir aber bitte ein wenig Zeit, da ich mich grad auf ein anderes Projekt konzentriere. Ich hab’s auf jeden Fall auf dem Zettel und versuche mich zeitnah drum zu kümmern. Deine Analyse hilft dabei schon ungemein. Ich meld mich…

 

[Tommes]

Hey Winfried,
da ich selbst seit einiger Zeit ein regelmäßiges, versioniertes Backup mit jarss erstelle, konnte ich das von dir beschriebene Verhalten auch bei mir feststellen. In der Tat sind über die Zeit immer mehr Ordner innerhalb eines Versionsstandes verschwunden, sobald sie älter wurden, als die in der Konfiguration angegebene Zeit in Tagen.

Oh. Mein. Gott! Dieser Fehler ist mir absolut unangenehm und peinlich zugleich und weiß überhaupt nicht, wie ich das entschuldigen kann. Das ist echt bitter und bitte vielmals um Verzeihung.

Dich hingegen kann ich nur in den höchsten Tönen loben und dir meinen Dank aussprechen. Denn du hast mit der Erkennung des Problems, deiner Analyse und der hier präsentierten Lösung ganze Arbeit geleistet. Chapeau, sag ich da nur. Wirklich... super gemacht und tausend Dank.

Ich habe mir vor der eigentlichen Änderung in einem Testdurchlauf die Variablen ${target} und ${init_target} vorsichtshalber noch mal ausgeben lassen und ja, du lagst absolut richtig. Nach der Änderung wurde mir ein komplett neuer Versionsstand mit allen Ordnern erstellt und im Anschluss daran wurden alte Versionsordner, so wie es eigentlich sein soll, gelöscht. Bei mir waren das einige. Somit konnte ich das Verhalten vor und nach deinen Anpassungen reproduzieren.

Ich habe die Änderungen bereits auf GitHub hochgeladen und stelle hier im folgenden noch die Release-Notes ein.

Nochmals vielen, vielen Dank.

Tommes

 

[Tommes]

jarss Version 1.0-400 vom 22.05.2025​

Release Notes

• Nach der Ausführung einer versionierten, inkrementellen Datensicherung löschte die anschließende Versionsbereinigung nicht die älteren Versionsordner, die in der Konfiguration als Tage angegeben waren. Stattdessen wurden im aktuell erstellten Versionsordner alle Ordner gelöscht, die älter als die angegebene Anzahl an Tagen waren. Dadurch wurden mit der Zeit immer weniger Daten gesichert, sodass die Versionsvorhaltung nicht mehr gewährleistet war. Aus diesem Grund wird dringend empfohlen, die bisherige versionierte, inkrementelle Datensicherung vollständig neu zu erstellen – selbst wenn sich mit der Zeit automatisch ein neuer, vollständiger Versionsstand ergibt. Ich bitte, die Unannehmlichkeiten vielmals zu entschuldigen.
• HINWEIS: Um das Problem zu lösen, muss lediglich das aktualisierte Skript „jarss.sh” heruntergeladen und anstelle des alten Skripts verwendet werden.

GitHub Repository
​

jarss (just another rsync shell script)​

​

Weiterhin viel Spaß mit jarss

Tommes

 

[FWin]

Hallo Tommes,
und wieder bestätigt sich der Spruch von dem blinden Huhn und dem Korn! Wie ich eingangs schrieb, Bash ist (war) bisher nicht so mein Ding, aber programmiert hatte ich schon das eine oder andere. Nur halt in anderen Sprachen, aber wenn man etwas algorithmisch denken kann, ist es dann ja "nur" eine andere Syntax (die es bei Bash aber ziemlich in sich hat). Langer Rede kurzer Sinn, das Überschreiben vemeintlich nicht mehr benötigter Variablen im Programmablauf ist mir aus eigener leidvoller Erfahrung durchaus bekannt und passierte mir meist bei einer schrittweisen Erweiterung von Programmen, wenn ich dieses Überschreiben dann aus den Augen verloren hatte. Es dauerte lange, solche Fehler zu finden, diverse Bissspuren am unteren Rand meiner Tastatur zeugen davon... Egal, es freut mich, wenn ich helfen konnte.

Bei der Gelegenheit noch zwei kleinere Anmerkungen bzw. Fragen: Erstens ist mir aufgefallen, dass meine automatisch gestarteten Pull-Backups gelegentlich mit einem SSH-Fehler abgebrochen wurden, obwohl die passwortlose Verbindung "von Hand" (also per SSH auf der lokalen Ziel-DS einloggen, auf der jarss laufen soll, dann von dort aus per SSH-Befehl auf die entfernte Quell-DS verbinden) stets funktionierte. Mir war allerdings eine gewisse Verzögerung der Antwort der entfernten DS beim SSH-Handshake aufgefallen. In jarss ist der Timeout für die SSH-Verbindung auf 2 s gesetzt (im Abschnitt "Establish SSH connection" in Zeile 223), möglicherweise ist das in meinem Fall etwas knapp. Ich habe das testhalber bei mir mal auf 5 s erhöht, also in Zeile 223:

${ssh} -q -o BatchMode=yes -o ConnectTimeout=5 "echo -n 2>&1"

Danach sind bislang alle Backup-Läufe ohne SSH-Fehler durchgelaufen, das eingangs erwähnte Problem trat nicht mehr auf. Offenbar ist meine Quell-DS (eine schon etwas betagte DS115 mit DSM 7.1.1) beim SSH-Handshake etwas lahm. Dies vielleicht als Tipp, wenn jemand ähnliche Probleme haben sollte.

Zweitens ist mir aufgefallen, dass die Anwendung "File Station" auf der lokalen DS im Sicherungsverzeichnis den von jarss korrekt angelegten Link "latest" für die jüngste Sicherung nicht anzeigt, obwohl er definitiv vorhanden ist und auch korrekt funktioniert (getestet im Terminal). Aus meiner Sicht nur ein kosmetisches Problem, für das ich die "File Station" im Verdacht habe (konkret läuft das hier auf einer alten DS212+ mit DSM 6.2.4-25556, das "Update 8" ist aber immerhin von Ende 2024). Vielleicht liegt es an der alten Version von "File Station" (DSM 6), möglicherweise übersehe ich aber auch nur eine Einstellung bei "File Station". Hat jemand eventuell ähnliches festgestellt?

Danke nochmals an Dich Tommes für das kleine Goldstück "jarss" (und auch für das ältere "Basic Backup", das auf meiner "großen" DS weiterhin unauffällig und zuverlässig vor sich hin läuft)!

Winfried