jarss – (just another rsync shell script)

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.932
Punkte für Reaktionen
1.923
Punkte
314
Hi!

Ich hab da mal was vorbereitet...

Wie unlängst bekannt sein sollte, habe ich den Support und die damit verbundene Weiterentwicklung für Basic Backup zum 01.09.2024 eingestellt *siehe hier*. Sei’s drum…

Dennoch ist mir ein einfaches, gut funktionierendes und leicht zu administrierendes Backup-Script immer noch sehr wichtig. Genauso wichtig ist für mich aber auch der plattformunabhängige Einsatz und wer in letzter Zeit meine Posts ein wenig verfolgt hat, wird vielleicht mitbekommen haben, das ich mich mittlerweile von Windows weitestgehend losgesagt und mich stattdessen Linux Mint gewidmet habe. Und genau für diesen Zweck brauchte ich ein, auf meine Bedürfnisse angepasstes und unabhängiges Backup-Script, welches sowohl unter Linux Mint als auch unter dem DSM läuft und dabei weiterhin die SSH-Public-Key-Authentifizierung unterstützt.

Daher habe ich mir das eigentliche rsync-Script von Basic Backup vorgeknöpft, den ganzen Klicki-Bunti-Quatsch mit schöner GUI über Bord geworfen und es zu einem reinen CLI-Shell-Script umgeschrieben, sodass es nun theoretisch auf so ziemlich jedem unixoiden Betriebssystem lauffähig sein sollte. Wie gesagt… theoretisch. Naja, und wie das halt so ist, kommt dann oft eins zum anderen und schwuppdiwupp ertappe ich mich dabei, wie ich bereits ein neues GitHub Repository erstelle um andere an meinen Ausdünstungen teil haben zu lassen.

Lange Rede, kurzer Sinn, denn heute möchte ich euch das Ergebnis meiner Arbeit präsentieren und dabei eigentlich keine großen Worte mehr verlieren. Alles Wissenswerte findet ihr auf der nachfolgend verlinkten GitHub-Resporitory. Natürlich soll und darf dieser Thread auch dazu genutzt werden, jegliches Feedback von euch zu diskutieren und mögliche Unstimmigkeiten zu beheben. Was ich jedoch nicht tun werde ist, das Script wieder mit unnötigen Funktionen und speziellen Wünschen eurerseits vollzustopfen. „Back to the roots“ lautet das Motto und deckt sich damit mit meinem Vorsatz „Keep it simple“.

Für all diejenigen, die mein Script im DSM ausführen wollen und eine Alternative zu Basic Backup suchen...
  • Das CLI-Shell-Skript kann weiterhin über den DSM-Aufgabenplaner als root oder als Administrator (mit gewissen Einschränkungen) ausgeführt werden.
  • Das mitlaufende Protokoll kann man sich über den DSM-Aufgabenplaner per E-Mail zuschicken lassen.
  • Die inkrementelle Datensicherung verwendet nun im Vergleich zu Basic Backup eine Kombination aus Symlinks, Hardlinks und Delta-Kodierung, um Dateien und Verzeichnisse über Dateisystemgrenzen hinweg effektiver verarbeiten zu können.
Genug der Worte, hier der Link zum GitHub-Repository und viel Spaß damit.

 
Zuletzt bearbeitet:

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.932
Punkte für Reaktionen
1.923
Punkte
314
This was exactly the kind of feedback I was hoping for, as I had briefly considered offering the script only in German. But thanks to DeepL and DeepL Write, the translation was easy in the end. :sneaky:
 
  • Like
Reaktionen: DaveR

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.932
Punkte für Reaktionen
1.923
Punkte
314

jarss Version 1.0-100 vom 05.12.2024​


Release Notes
  • In den Konfigurationsdateien wurden "Wichtige Hinweise" hinzugefügt, die darüber informieren, welche Einstellungen für ein lokales, Pull- oder Push-Backup vorgenommen werden müssen.
  • Im jarss Backup-Skript wurde eine Abfrage hinzugefügt, die zu einem Abbruch führt, wenn in der Konfiguration sowohl ein Pull- als auch ein Push-Backup ausgewählt wurde, d.h. wenn sowohl die Variable sshpull als auch die Variable sshpush Werte enthalten.

GitHub Repository


Weiterhin viel Spaß mit jarss

Tommes
 

TB-UB

Benutzer
Mitglied seit
21. Mrz 2017
Beiträge
65
Punkte für Reaktionen
9
Punkte
8
Danke für dieses script, ist mal wieder sehr hilfreich. (Ich bin jetzt nicht DER scrip-Schreiber, schon gar nicht mit ellenlangen Zeilen).

Ein paar Hinweise (keine Wünsche oder so), deren Berücksichtigung evtl weiteren Nutzern das Leben einfacher machen könnten.

a)
Die Zeile 386 (${ionice} \) führt bei mir laut Ausgabe zu einem rsync Fehler 127, vermutlich weil die Auswertung in Zeile 346 (if ! command -v . ./ionice 2>&1 >/dev/null; then) in den else-Zweig abbiegt und ionice setzt. Nur dass ich kein ionice auf meiner DS habe.
Ohne diese Zeile 386, also das rsync ohne das ionice läuft anscheinend durch (habs bisher nur dry ausprobiert).
Wie gesag, ich weiß nicht was die Zeile 346 im Detail bedeutet und ob die richtig auswertet, oder ob das nur ein Problem auf meiner DS ist ....
Möglicherweise könnte die Auswertung ob ionice vorhanden ist überprüft werden.

b)
in diesem Zusammenhang ist mir aufgefallen, dass die Zeile 457 (echo "${txt_rsync_error_line_1}" | tee -a "${logfile}") vermutlich statt der Meldung _1 ein zweites mal, eher die Meldung _2 ausgeben sollte , oder?!

c)
in dem Beispiel im github-README:
--job-name="[DATEINAME]" Hier den Dateinamen dieses Auftrages eintragen um das Backup auszuführen.
Beispiel: --job-name="[jarss_Konfiguration_GER]"
...sind vermutlich die eckigen Klammern um den "echten" Dateinamen störend. Mit Klammern kommt es zu einem Fehler. Wenn man die Klammern weg läßt, so wie bei den anderen optionalen Parametern auch, läufts.
Möglicherweise könnten einfach die beiden eckigen Klammern bei [jarss_Konfiguration_GER] entfernt werden.

d)
in der Konfiguration kann man die Tage für recycle einstellen. Ich weiß nicht ob es eine andere Lösung gibt für das was ich versuche mit recycle=99999 zu lösen, nämlich dass backup-Ordner angelegt werden, aber nicht automatisch gelöscht werden. Evtl wäre ein Wert recycle=-1 denkbar?

e)
ebenfalls in der Konfiguration ist der Parameter versions beschrieben. Hier könnte man zunächst ergänzen, dass der Wert nur (?) bei incremental relevant ist. Außerdem ist ein max versions mit 365 beschrieben, was glaube ich durchaus erhöht werden kann (ich zumindest probiers mal aus). Sprich: möglicherweise könnte die Beschreibung angepasst werden und das max 365 verschwinden.
 
  • Like
Reaktionen: Tommes

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.932
Punkte für Reaktionen
1.923
Punkte
314
Hallo und vielen Dank für dein Feedback!

Ich werde das zu einem späteren Zeitpunkt alles noch mal genau durchtesten, für den Moment möchte ich es mir jedoch nicht nehmen lassen, dir kurz zu antworten.

Zu a)
Die Zeile 386 (${ionice} \) wird nur dann mit Leben gefüllt, wenn das Programm auf deiner DS lokalisiert wurde. Die Zeile 346 (if ! command -v . ./ionice 2>&1 >/dev/null; then) besagt, das wenn das Kommando -v ionice NICHT (das Ausrufezeichen steht für NICHT bzw. NOT) ! erfolgreich ausgeführt werden konnte, dann verwende die Variable bandwidth, sollte ein Speedlimit angegeben worden sein, ansonsten… also wenn das Kommando -v ionice erfolgreich ausgeführt wurde, dann … also ELSE … lege in der Variabel ionice die Aufrufparameter für ionice fest.

Mögliche Lösung für dein rsync 127 Error könnte sein, das du in der Konfiguration gar kein Wert für das Speedlimit eingetragen hast. Aber das müsste ich, wie anfangs erwähnt, zu einem späteren Zeitpunkt genauer durchtesten.

Zu b)
Korrekt. Mein Fehler. Wird korrigiert.

Zu c)
Die eckigen Klammern verwende ich bei Platzhaltern immer und du wirst diese Schreibweise in vielen anderen Beschreibungen finden. Klar könnte ich diese entfernen, aber ich habe mich mittlerweile so sehr daran gewöhnt, das ich diese doch lieber weiterverenden würde. Ich bin bei meinen neueren HowTo‘s dazu übergeganzen, folgenden Hinweis zu geben:


Hinweis: Texte in Großbuchstaben innerhalb eckiger Klammern dienen als Platzhalter und müssen durch eigene Angaben ersetzt werden, können aber an einigen Stellen auch nur der Information dienen. Es ist zu beachten, dass die eckigen Klammern Teil des Platzhalters sind und beim Ersetzen durch eigene Angaben ebenfalls entfernt werden müssen.

Daher würde ich wohl eher diesen Hinweis an den ensprechnden Stellen platziere, als auf die eckigen Klammern zu verzichten. Wie gesagt… reine Gewohnheit aber auch „gängige Praxis“ in solchen Beschreibungen.

Zu d)
Muss ich mir anschauen. Es wird aber sicherlich Möglichkeiten geben, das umzusetzen.

Zu e)
Interessanter Hinweis. Ich bin mir grad nicht mal sicher, ob die Grenze von 365 überhaupt greift, oder das nur ein Überbleibsel einer alten Programmierung ist. Spontan finde ich jedenfalls keinen entsprechenden Begrenzer im Script. Aber auch das schaue ich mir an.

Ich meld mich, sobald es Neuigleiten gibt… wann auch immer das sein wird.

Tommes
 
  • Like
Reaktionen: DaveR

TB-UB

Benutzer
Mitglied seit
21. Mrz 2017
Beiträge
65
Punkte für Reaktionen
9
Punkte
8
Danke für die schnelle Antwort und dass Du Dir das anschauen möchtest.
Nur um sicher zu gehen, dass wir uns nicht missverstehen:

zu a)
ja, das ist ja das "komische", dass die Vorbelegung von ionice in Zeile 346 bzw 357 erfolgt (weil die Logik anscheinend "sagt" ionice wäre gefunden, aber unten dann beim Ausführen wird vor dem rsync entsprechend ein "ionice -c 3" gesetzt und das geht dann schief.
(Für mich kein Problem, ich lebe seit ihr UB nach TimeBackup gemacht habt mit dem rsync-Speed und habe die Zeile auskommentiert und ist gut so für mich)
Vorbelegung ist bei mir noch aktiv: speedlimit="62500"

zu c)
ja, das mit den eckigen Klammern in Beschreibungen ist schon gut und habe ich auch so verstanden.
Im Readme (direkt in der Datei) und in der Anzeige der selbigen auf github steht ein konkretes Bespiel; wörtlich:
Beispiel: --job-name="[jarss_Konfiguration_GER]" (<- ist doch ein Beispiel für einen konkreten Aufruf, oder)
Und da jarss_Konfiguration_GER ja genau der konkrete Dateiname im Archiv ist, gehen evtl noch andere davon aus, dass die eckigen Klammern beim tatsächlichen Aufruf benötigt würden.
 

TB-UB

Benutzer
Mitglied seit
21. Mrz 2017
Beiträge
65
Punkte für Reaktionen
9
Punkte
8
Habe nochmal über diese Zeile zu a) nachgedacht (versucht nachzudenken ;o)
if ! command -v . ./ionice 2>&1 >/dev/null; then

Was auch immer da am Ende mit stdout und stderr gemacht wird, ich bin mir nicht sicher ob die zwei Punkte nicht ein logisches Oder darstellen und da für den ersten . immer was gefunden wird, könnte evtl die Bedingung auch immer zutreffen, also immer und unabhängig von ionice in einen bestimmten Zweig abbiegen.

Obwohl ich folgende Seiten zu /dev/null bzw 2>&1 angeschaut habe, ind diese Umleitungen und die Abhängigkeiten von der Reihenfolge für mich ein Buch mit etlichen Siegeln.
Eine weitere Frage ist daraus entstanden: Wenn es da Abhängigkeiten gibt, kann dann die Zeile gleichermassen funktionieren, ob das script in einer shell/Konsole aufgerufen wird ODER per Aufgabenplaner in DSM?

Input zu /dev/null 2>&1 :
https://stackoverflow.com/questions/818255/what-does-21-mean
https://stackoverflow.com/questions/10508843/what-is-dev-null-21
https://unix.stackexchange.com/questions/591904/how-does-dev-null-21-work
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.932
Punkte für Reaktionen
1.923
Punkte
314
Okay... ich war schon fleißig und habe die Punkte b), c), d) und e) bereits abgearbeitet und auf GitHub hochgeladen. Da ich mich aber noch um a) kümmern muss, verbleibe ich zunächst auf der aktuellen Versionsnummer von jarss. Ich fange zwar gleich mal an, mich um a) zu kümmern, weiß aber noch nicht, wie weit ich heute noch komme.

Für alle, die es interessiert, hier schon mal die bisherigen Änderungen...
  • In den Konfigurationsdateien wurde irrtümlich ein Höchstwert von 365 Tagen für die Aufbewahrung von Versionen angegeben. Die Angabe wurde entfernt und die betreffenden Textstellen überarbeitet.
  • Anzeigefehler in der rsync-Fehleranalyse nach rsync-Lauf in der jarss.sh Datei behoben.
  • Die Konfiguration der Papierkorb-Funktion (/@recycle) lässt neben numerischen Werten nun auch die Werte "true" und "false" zu.
    recycle="false" - Zwischenzeitlich gelöschten Daten der Sicherungsquelle( n ) werden auch im Sicherungsziel unwiderruflich gelöscht.
    recycle="30" - Zwischenzeitlich gelöschten Daten der Sicherungsquelle( n ) werden in den Ordner /@recycle, des Sicherungsziels verschoben.
    Daten aus dem Ordner /@recycle, die älter als 30 Tage waren, wurden gelöscht.
    recycle="true" - Zwischenzeitlich gelöschte Daten der Sicherungsquelle( n ) werden in den Ordner /@recycle des Sicherungsziels verschoben.
    Aus dem Ordner /@recycle werden keine Daten mehr gelöscht.
  • Bei einem Push-Backup trat ein Verarbeitungsfehler bei der Ermittlung zu löschender Daten aus dem Ordner /@recycle auf, wesahlb keine Daten gelöscht wurden. Fehler wurde behoben.
Theoretisch solltet ihr eure Konfigurationsdateien weiter nutzen können, ohne sie zu aktualisieren. Besser wäre natürlich, das alles zu aktualisieren, auch wenn das ein wenig Arbeit ist. Da ich aber nur Änderungen an den letzten drei Konfigurationspunkten (recycle, incremental und versions) vorgenommen habe, reicht es auch, wenn ihr nur diesen Abschnitt durch "Copy and Paste" aktualisiert.

@TB-UB um deine Frage bezüglich 2>&1 >/dev/null zu beantworten.
2>&1 leitet den Standardfehler (2) auf die Standardausgabe (1) um > schreibt die Standardausgabe nach /dev/null wo das ganze verworfen wird bzw. im Nirvana verschwindet.

./ionice führt das Programm im relativen Pfad aus, also genau an dem Ort, wo auch das jarss.sh Script ausgeführt wird.

. ./ionice führt das Programm in derselben Shell aus, wo auch das jarss.sh Script ausgeführt wird. Würde ich den vorderen Punkt weglassen, würde das Programm in einer Subshell ausgeführt werden und ich bekäme kein Feedback bzw. kein Ergebnis mehr, um meine Abfrage auszuwerten.

Aber wie gesagt... ich schau mir das gleich mal an, Verspreche aber noch nichts.

Dein Video [...] ist absolut toll gemacht.
Vielen Dank, sowas hört man natürlich gerne. Vielleicht reichen (oder helfen) dir ja auch meine HowTo's auf GitHub zum Thema.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: maxblank und DaveR

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.932
Punkte für Reaktionen
1.923
Punkte
314
@TB-UB

Könntest du anstatt...
if ! command -v . ./ionice 2>&1 >/dev/null; then
... bei dir bitte mal...
if ! command -v ionice 2>&1 >/dev/null; then
... testen und mir sagen, ob die Abfrage jetzt richtig arbeitet? Zur Sicherheit nach der Änderung dasTerminalfenster einmal schließen und einen neuen Terminal starten um anschließend den Test durchzuführen.
 

DaveR

Benutzer
Sehr erfahren
Mitglied seit
30. Mrz 2022
Beiträge
514
Punkte für Reaktionen
901
Punkte
164
When I rename ionice to -ionice to simulate it not existing:

Bash:
~# which ionice
~# if ! command -v . ./ionice 2>&1 >/dev/null; then echo nein; fi
~# if ! command -v ionice 2>&1 >/dev/null; then echo nein; fi
nein
 
  • Like
Reaktionen: Tommes

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.932
Punkte für Reaktionen
1.923
Punkte
314
I get the same result on my VirtualDSM without ionice
Bash:
~$ which ionice
~$ if ! command -v . ./ionice 2>&1 >/dev/null; then echo nein; fi
~$ if ! command -v ionice 2>&1 >/dev/null; then echo nein; fi
nein

On my DS224+ with ionice, however, I get this (note that the query is exactly the opposite)
Bash:
~$ which ionice
/usr/local/bin/ionice
~$ if command -v . ./ionice 2>&1 >/dev/null; then echo ja; fi
ja
~$ if command -v ionice 2>&1 >/dev/null; then echo ja; fi
ja

Here I also get a positive response using . ./ionice and this is probably where my error lies.
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.932
Punkte für Reaktionen
1.923
Punkte
314
Thanks for the test and confirmation. I'll test it again with jarss this afternoon and if it works, I'll modify the script accordingly. Maybe I'll change the "if !" query to an "if“
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.932
Punkte für Reaktionen
1.923
Punkte
314

jarss Version 1.0-200 vom 21.01.2025​


Release Notes
  • In den Konfigurationsdateien wurde irrtümlich ein Höchstwert von 365 Tagen für die Aufbewahrung von Versionen angegeben. Die Angabe wurde entfernt und die betreffenden Textstellen überarbeitet.
  • Anzeigefehler in der rsync-Fehleranalyse nach rsync-Lauf in der jarss.sh Datei behoben.
  • Die Konfiguration der Papierkorb-Funktion (/@recycle) lässt neben numerischen Werten nun auch die Werte "true" und "false" zu.
    • recycle="false" - Zwischenzeitlich gelöschte Daten der Sicherungsquelle( n ) werden auch im Sicherungsziel unwiderruflich gelöscht.
    • recycle="30" - Zwischenzeitlich gelöschte Daten der Sicherungsquelle( n ) werden in den Ordner /@recycle, des Sicherungsziels verschoben. Daten aus dem Ordner /@recycle, die älter als 30 Tage waren, wurden gelöscht.
    • recycle="true" - Zwischenzeitlich gelöschte Daten der Sicherungsquelle( n ) werden in den Ordner /@recycle des Sicherungsziels verschoben. Aus dem Ordner /@recycle werden keine Daten mehr gelöscht.
  • Bei einem Push-Backup trat ein Verarbeitungsfehler bei der Ermittlung zu löschender Daten aus dem Ordner /@recycle auf, weshalb keine Daten gelöscht wurden. Fehler wurde behoben.
  • Es gab einen Fehler bei der Auswertung, ob das Programm ionice auf dem System verfügbar ist oder nicht, was je nach Ergebnis zu einem rsync-Fehler 127 führte. Fehler wurde behoben.
  • In den Konfigurationsdateien wurde ein Hinweis auf die Verwendung von Platzhaltern und Optionen in eckigen Klammern aufgenommen, um Eingabefehler zu minimieren.

GitHub Repository


Weiterhin viel Spaß mit jarss

Tommes
 
Zuletzt bearbeitet:
  • Like
Reaktionen: DaveR und maxblank

TB-UB

Benutzer
Mitglied seit
21. Mrz 2017
Beiträge
65
Punkte für Reaktionen
9
Punkte
8
@TB-UB
Könntest du anstatt...

... da war ich dann wohl zu spät und DaveR hat das besser gemacht als ich es tun hätte können, da ich kein ionice habe.
Wollte hiermit nur kurz auf die Anfrage von oben antworten, um Respekt zu zollen.
Nochmal danke für die neue Version von jarss.
 
  • Like
Reaktionen: DaveR

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.932
Punkte für Reaktionen
1.923
Punkte
314
… in der Hoffnung, das bei dir nun alles wie gewünscht funktioniert, du keinen rsync Error 127 mehr erhältst und das die Erweiterung der Papierkorb-Funktion für dich brauchbar ist. ;)
 
  • Like
Reaktionen: TB-UB

TB-UB

Benutzer
Mitglied seit
21. Mrz 2017
Beiträge
65
Punkte für Reaktionen
9
Punkte
8
Danke, die Änderungen hören sich gut an.
Habe jetzt die neue Version -200 noch nicht wirklich ausprobiert (weil ich die -100 bereits an meine Bedrürfnisse angepasst habe).
Nur ein erster gefundener möglicher Minibug der -200: in Zeile 105 des jarss.sh scheint ein txt_re am Textanfang zu fehlen.


ps: Natürlich ist es Deine Entscheidung, aber ein kleines aber hätte ich: Du verwendest GPLv3, das ist meiner Ansicht nach nicht wirklich "freie" Software, sondern schränkt vielmehr die Nutzungsbedingungen so ein, so dass ein Verwender/Weitergebender schnell einen Lizenzverstoß machen kann ohne dass er das wollte. Es gäbe "permissivere" OSS Lizenzen, die Nutzern (privat oder gewerblich) das Leben einfacher machen würden.

ps2: Ich kenne mich mit github nicht wiklich gut aus, denke aber dass zusätzlich zu den einzelnen commits noch ein tag für eine bestimmte konsistente Version sinnvoll sein könnte (ohne es genau zu wissen, aber ich meine mit tags kann man die einzelnen Versionen des Paketes "snapshotten" und später zusätzlich zum laufenden main herunterladbar machen).
 

DaveR

Benutzer
Sehr erfahren
Mitglied seit
30. Mrz 2022
Beiträge
514
Punkte für Reaktionen
901
Punkte
164
I like the MIT license as it's only 21 lines and easy to read and easy to understand. It basically says:
  1. Who the copyright holder is.
  2. Do what you want with the software.
  3. Include a copy of the MIT license with the original copyright in all copies or substantial portions of the software.
  4. Don't blame the author if things go wrong. :)
The GPLv3 is 647 lines and I suspect that 99% of people have never read the whole thing. And of those who have read it many probably didn't fully understand what they can and can't do.

On GitHub, to create a release (a downloadable zip file of the repo) it needs a tag. The tag is like a snapshot from when the tag was created.

I always create a release for each version change so:
  1. Users can download whichever version they.
  2. So I can download old versions if I need to compare them to the current version.
 
  • Like
Reaktionen: TB-UB


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat