jarss – (just another rsync shell script)

[Tommes]

Moin Winfried,
ich komm gleich zur Sache und gehe auf deine beiden Anmerkungen ein.

Bisher hatte ich mit dem eingestellten Timeout-Wert von 2 Sekunden keine Probleme gehabt, aber natürlich lässt sich dieser Wert nach Belieben erhöhen. Vermutlich sollten 5 Sekunden aber wirklich ausreichen, um das Ergebnis des Handshakes abzuwarten. Ich werde den Wert entsprechend anpassen und in das nächste Release miteinfließen lassen. Vielen Dank für den Tipp.

Was das Anzeigen des SymLinks "latest" angeht, so scheint es wirklich an der File Station zu liegen. Daher habe ich der GitHub Beschreibung zu jarss u.a. geschrieben...

Unmittelbar danach wird mittels Symlinks ein Image der aktuellen Sicherung erstellt, das auf den i.d.R. nicht sichtbaren Ordner ~latest verweist, der sich ebenfalls im Zielverzeichnis befindet.

Auf meinem UGRREN-NAS wird der SynLink in der "Dateien" App zwar angezeigt, jedoch lässt sich damit nichts weiter anstellen.



Auf der Konsole meines Synology-NAS (ebenso wie auf meinem UGREEN-NAS) sieht das dann übrigens so aus

latest -> /volume1/NetBackup/jarss_LinuxMint-Versionsbackup/2025-05-25_06h-59m-00s/

das kleine Goldstück "jarss"

... Danke

Tommes

 

[Tommes]

Noch eine Ergänzung!

(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)

Die Arbeitsweisen beim Erstellen und Verarbeiten von Versionsständen sind bei Basic Backup und jarss vollkommen unterschiedlich aufgebaut. Basic Backup arbeitet z.B. nur mit Hardlinks, die über den Befehl cp -al erstellt, mittels mv verschoben und über rm gelöscht werden, wohingegen jarss mit einer Kombination aus Hard- und Symlinks sowie dem rsync Flag --link-dest und dem Befehl ln arbeitet. Wenn du mehr darüber erfahren möchtest, wie jarss Versionsstände verarbeitet, dann schau dir diese Seite an. Dies war mit ein Grund, warum ich Basic Backup damals eingestampft hatte. Der Umbau auf die neue Vorgehensweise wäre einfach zu umfangreich gewesen.

 

[framp]

Ich habe mal angefangen jarss bei mir zu konfigurieren und bekomme eine ssh Setupfehlermeldung. Ist irgendwo dokumentiert wie man den ssh Setup macht? Ich weisst zwar wie das geht - aber ich denke es wäre ganz gut wenn beim jarss entweder noch eine Beschreibung dazu gegeben wird oder ein Link. Oder habe ich den übersehen?

Admin@synology:~$ sudo bash $PWD/jarss.sh --job-name="jarss_Configuration_USB" --dry-run
---------------------------------------------------------------------------------------------------
jarrs (just another rsync shell script)
 - Config Script Version : 1.0-200
 - Rsync Script Version: 1.0-400
---------------------------------------------------------------------------------------------------

The job configuration [ jarss_Configuration_USB ] is being loaded
 - Doing a push backup to a remote server. Checking the connection...
Warning: Identity file /root/.ssh/id_rsa not accessible: No such file or directory.
usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface]
           [-b bind_address] [-c cipher_spec] [-D [bind_address:]port]
           [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11]
           [-i identity_file] [-J [user@]host[:port]] [-L address]
           [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
           [-Q query_option] [-R address] [-S ctl_path] [-W host:port]
           [-w local_tun[:remote_tun]] destination [command]
 - The SSH connection test failed. Please check your SSH connection.

---------------------------------------------------------------------------------------------------
2025-06-08 18:41:35 The backup job will be cancelled!
 - Warning: The backup job [ jarss_Configuration_USB ] failed or was cancelled.
---------------------------------------------------------------------------------------------------

Ansonsten finde ich die Beschreibung sehr ausführlich und gut zu lesen

 

[Tommes]

Hm, okay! Ich habe zwar bereits an mehreren Stellen beschrieben, wie man eine SSH Public Key Verbindung einrichtet, nicht jedoch explizit für jarss. Ich überleg mir was.

Solange du aber nur lokal (auf interne Volumes oder externe Datenträger) sicherst, muss bei SSH nichts angegeben werden. Und scheinbar möchtest du ja auf einen lokal angeschlossenen USB-Datenträger sichern, richtig?

--job-name="jarss_Configuration_USB"

 

[framp]

Und scheinbar möchtest du ja auf einen lokal angeschlossenen USB-Datenträger sichern, richtig?

Habe ich final angedacht, aber nein, ich habe ja auch ein Hyperbackup Task aufgesetzt der auf den rsync Server meiner Raspberry sichert. Deshalb wird auch vorerst auf dieselbe Raspberry per jarss gesichert. So läßt sich beides besser vergleichen.

PS: jarss läuft schon und sichert auf meine Raspberry Ich denke Du möchtest auch dass Nutzer die sich nicht mit ssh und keys auskennen jarss nutzen können sollen. Deshalb meine Frage denn der Setup ist zwar einfach - aber natürlich nur wenn wann weiss wie

 

[framp]

PS: Eine -h/--help Option wäre - jedenfalls für mich - ganz nützlich

 

[Tommes]

Wie gesagt. Ich überleg mir was.

 

[framp]

Eben ist mir aufgefallen dass ein CTRL-C bei mehreren angegebenen zu sichernden Ordnern dazu führt dass der rsync für den aktuellen Ordner beendet wird und danach mit dem nächsten Ordner in der Liste fortgefahren wird statt das Script ganz abzubrechen.

Das ist nicht schlimm, aber inconvenient. Ich muss bei mir dadurch 4 Mal CTRL-C eingeben. Speziell beim testen bzw Überprüfen ob und welche Dateien gesichert werden auf der Commandline ist das etwas störend. Ich habe mir den Code nicht angesehen aber das liegt wohl an den & als Trennungszeichen zwischen den Foldernamen. Wie geschrieben kein severe Problem aber wenn es ein low hanging fruit ist könntest Du das vielleicht noch ändern

 

[Tommes]

Ich habe mir den Code nicht angesehen aber das liegt wohl an den & als Trennungszeichen zwischen den Foldernamen.

Ganz genau. Das Trennzeichen & zwischen den einzelnen Quellordner formt ein Array welches in einer Schleife einzeln ausgelesen und dem rsync Befehl übergeben wird. Jeder Quellordner wird somit einzeln in einem separaten rsync Befehl abgearbeitet. Mit CTRL + C brichst du nur die aktuelle Schleife ab, nicht jedoch das Script selbst.

 

[framp]

Ist es Dir lieber meine Kommentare hier weiter zu platzieren oder im github? Leider hast Du aber dort keine Discussions enabled denn Probleme/issues sind das ja nicht

 

[Tommes]

Wir können hier gerne weiter darüber diskutieren. Für sowas ist der Thread ja gedacht.

 

[framp]

Alles klar. Ich habe es bei mir lieber verschiedene Dinge in Issues bzw Discussions zum Tracken damit ich sie übersichtlich abarbeiten kann. Das ist für mich ein Vorteil von github.

In einem Thread verliert sich einfach für mich leicht die Übersicht wenn verschieden Dinge angesprochen werden.

 

[framp]

Sorry für den späten Reply ... ich habe gerade ziemlich viel um die Nase

Dein Tool funktioniert perfekt Per Hyperbackup geht ja nur ein lesbares rsync Backup. Ich denke ich werde es für mein 3er Backup einsetzen (3-2-1 Prinzip)

 

[Tommes]

Das freut mich natürlich zu hören. Zu meiner Schande muss ich aber gestehen, das ich mich noch nicht weiter um deinen Vorschlag gekümmert habe. Aber ich habe dich nicht vergessen. Dauert ber wohl noch ein wenig, da ich selbst grade viel um die Ohren habe.

 

[framp]

Um sowas nicht zu vergessen nutze ich bei meinen Tools github issues. Wenn Du willst erstelle ich da bei Dir gerne einen

 

[Tommes]

Nein, alles gut. Ich hab das auf meinem imaginären Zettel mit Dingen, die ich noch erledigen wollte, längst notiert.

 

[FWin]

Noch ein Nachtrag/ Erfahrungsbericht zu Beitrag #40:

Ich hatte dort festgestellt, dass das ursprünglich auf 2 s eingestellte Timeout beim Test der SSH-Verbindung in meinem Setup offenbar etwas knapp bemessen war (häufige Fehlermeldungen zu SSH-Fehlern). Nachdem ich den Wert erst auf 5 s, dann später sogar auf 10 s vergrößert hatte, schien es besser geworden zu sein. Aber leider zu früh gefreut! Ab Anfang Juni hatte ich dann wieder gelegentliche SSH-Fehler, zuverlässige nächtliche Sicherung: Fehlanzeige! Daraufhin habe ich aus lauter Verzweiflung den Wert auf jetzt 60 s eingestellt, und was soll ich sagen, seitdem läuft jarss seit nunmehr 2 Wochen problemlos. Zur Erklärung: Es geht im Script "jarss.sh" im Abschnitt "Establish SSH connection" in Zeile 223 um den Eintrag

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

Damit wartet das Script jetzt eine ganze Minute auf eine Antwort des Remote-Servers (bei mir auch eine Synology-Diskstation), erst wenn bis dahin keine SSH-Verbindung zustande kommt, erfolgt ein Abbruch mit Fehlermeldung.

Natürlich habe ich mich gefragt, warum (bei meinem Setup) der Wert so hoch sein muss. Wenn meine Vermutung stimmt, ist die Ursache schon fast peinlich banal: Die entfernte Quell-DS war/ ist im DSM so konfiguriert, dass sich die HDD in den Energiesparmodus begibt (also den Motor und dann auch die Stromversorgung abschaltet), wenn eine bestimmt Zeit lang keine Zugriffe mehr erfolgt sind. Wenn jetzt jarss von der Backup-DS aus eine SSH-Verbindung aufbauen möchte, wird durch diese Verbindungsanfrage die HDD der Quell-DS offenbar wieder geweckt, aber bis diese hochgefahren ist und stabil arbeitet, dauert es offenbar meist doch etwas länger als 10 s. Erst dann antwortet die Quell-DS auf die SSH-Verbindungsanfrage. Ich habe versucht, das zu verifizieren, indem ich bei definitiv ruhender HDD "von Hand" über ein Terminalprogramm eine SSH-Verbindung zur Quell-DS initiiert habe. Dabei war eine deutliche Verzögerung der Antwort festzustellen, wenn die schlafende HDD erst aufgeweckt werden musste. Ich habe die Zeit nicht mit der Stoppuhr gemessen, aber gefühlt waren das meist deutlich mehr als 10 s. Mit meinen jetzt eingestellten 60 s bin ich offenbar endlich auf der sicheren Seite.

Ich weiß nicht, ob dieses Verhalten auch bei neueren Diskstations (bzw. auch bei anderen Servern) auftritt, plausibel wäre es aus meiner Sicht aber durchaus. Da ein aktivierter Energiesparmodus von HDDs bei NAS-Systemen sicherlich nicht so selten sein dürfte (vor allem bei privat genutzten), würde ich daher anregen, den Wert für "ConnectTimeout" in jarss.sh in einer nächsten Version standardmäßig deutlich höher als 2 s einzustellen, dann sollte das beschriebene Problem nicht mehr auftauchen. Aus meiner Sicht sehe ich keine Nachteile dadurch, das Script wartet dann nur etwas länger, bevor es gegebenenfalls mit Fehlermeldung abbricht, die grundsätzliche Funktion sollte aber weiterhin gegeben sein.

Vielleicht ist das für den einen oder anderen hilfreich, der ähnliche Probleme hat, ich freue mich natürlich über Rückmeldungen (auch für den Fall, dass ich mich mit meinen Vermutungen komplett auf dem Holzweg befinden sollte).

Weiterhin erfolgreiches Sichern allerseits (und der fast schon obligatorische Dank an Tommes für sein tolles Projekt)!
Winfried

 

[Tommes]

Hi!
Vielen Dank für dein Feedback. Alternativ zu einer fixen Zeit von z.B. 60 Sekunden, könnte man den Verbindungstest auch z.B. 6 mal alle 10 Sekunden als Schleife ausführen lassen. Sobald der Test erfolgreich war, wird die Schleife beendet.

Ich schau mir das gerne an, hab aktuell aber keine Zeit dafür.

Tommes

 

[FWin]

Es eilt ja auch nicht. Meinen Workaround-Vorschlag kann jeder Interessierte bei Bedarf problemlos in jarss implementieren und ausprobieren (und falls es nicht funktioniert, wieder zurücksetzen), das ist wahrlich keine Raketenwissenschaft. Sollte nur eine Anregung für ein späteres Release sein.

Ich sehe übrigens keinen wesentlichen Unterschied in der Funktionalität, egal ob man den Timeout-Wert gleich auf 60 s hochsetzt oder das in 6 Schleifen zu je 10 s versucht. Bei erfolgreicher SSH-Verbindung läuft das Script in beiden Fällen sofort weiter, ohne Erfolg gibt es ebenfalls in beiden Fällen nach 60 s eine Fehlermeldung.

Aber wie gesagt, das ist nicht eilig.

Winfried