Basic Backup Basic Backup

[tokon]

Nach was richtet sich die Anzeige der laufenden Jobs?

Läuft eigentlich gerade nur die 2. Aufgabe, die erste nicht.

 

[Tommes]

Warum kommt ihr mit sowas eigentlich immer erst, wenn ich grade ein Update bei CPHub hochgeladen und mein Laptop zugeklappt habe. Das ist echt verrückt. Tagelang (um nicht zu sagen Wochenlang) passiert in diesem Thread nüschts… ahhh ….

Ich schau mir das morgen mal an. In der Theorie wird der laufende Prozess des ausgeführten Auftrages abgefragt und solange er noch aktiv ist, wird auch der Auftrag mit einem läuft… gekennzeichnet. Ist der Auftrag durchgelaufen, sollte die Anzeige wieder umspringen. Tut sie das nicht müsstest du die Seite evtl. mal von Hand aktualisieren. Den entsprechenden Button findest du im Bereich der Systemumgebung, ganz rechts. Kann leider grade kein Screenshot machen.

Aber wie gesagt, ich schaue mir das morgen nochmal an und kann dann sicherlich mehr dazu sagen.

Tommes

 

[tokon]

Warum kommt ihr mit sowas eigentlich immer erst, wenn ich grade ein Update bei CPHub hochgeladen und mein Laptop zugeklappt habe.

Weil ich erst seit gestern teste

Ist der Auftrag durchgelaufen, sollte die Anzeige wieder umspringen. Tut sie das nicht müsstest du die Seite evtl. mal von Hand aktualisieren.

Bis jetzt bringt ein manuelles aktualisieren noch nichts. Mal morgen schauen, wenn der Job fertig ist, wie dann der Status bei beiden ist.

 

[tokon]

Mal morgen schauen, wenn der Job fertig ist, wie dann der Status bei beiden ist.

Nun haben beide den normalen Status.

Lasse ich den ersten Job laufen, wird nur dieser mit "läuft" angezeigt. Beim zweiten Job wird der erste hingegen reproduzierbar ebenfalls mit "läuft" angezeigt.

 

[Tommes]

Ich konnte den Fehler bei mir ebenfalls reproduzieren und dadurch das Problem beheben.

Der Grund liegt an einer etwas unglücklichen Programmierung zur Auswertung laufender Prozesse, in Verbindung mit fast gleich lautenden Auftragsnamen, so wie du sie verwendet hast. Bei der Auswertung kam es teilweise zu Überschneidungen, da u.a. nach Teilzeichenketten gesucht wurde und nicht nach ganzen Wörten.

Das hatte zur folge, das wenn du den Auftrag BackupNAS720 ausführst, auch nur dieser korrekt ausgewertet wurde. Sobald du aber den Auftrag BackupNAS720enc ausgeführt hast, erkannte das System beide Aufträge, da in BackupNAS720enc auch der Name BackupNAS720 steckt.

Ich habe den grep Befehl einfach den Optionsschalter -w angehangen, damit nicht mehr nach Teilzeichenketten gesucht wird, sondern nach ganzen Wörtern. Soweit konnte ich das Problem schon mal beheben. Jedoch muss ich mir noch ein paar Gedanken darüber machen, wie ich die Auswertung laufender Prozesse noch besser von einander trennen kann, um möglichen weiteren Seiteneffekten zuvor zu kommen.

Es bleibt also noch offen, wann ich den Fix veröffentlichen werde, aber ich kümmer mich.

Tommes

 

[pelumu]

Autorun kann unter DSM 7 die USB-Festplatte nicht mehr auswerfen. Kann das Basic Backup erledigen?

Güße
Peter

 

[Tommes]

Das kann ich dir aktuell leider (noch) nicht beantworten, da ich autorun noch keinem Test unter DSM 7 unterzogen habe. Auf meiner Liste mit Dingen, die ich noch erledigen wollte steht aber auch eine eigenständige Implementierung einer "autorun" Funktion ziemlich weit oben. Ich hatte bisher aber noch nicht die Zeit gefunden, mich näher damit auseinander zu setzen.

Ich versuch mal, mich zeitnah drum zu kümmern...

Tommes

 

[tokon]

@Tommes
Hab glaub nochmal nen Bug gefunden:
Gibt man beim Zielordner am Ende auch noch einen / ein, landen die Daten unter /root
Also vielleicht bald wieder ein User der sich die Systempartition vollschreibt

Der Ordner test wird zwar erstellt, jedoch sind keine Daten drin.

 

[Tommes]

Echt jetzt?

Ich habe es selber noch nicht getestet, aber eigentlich wird im rsync Script genau das geprüft - nämlich, ob ein Slash am Ende des Datensicherungspfades steht oder nicht.

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

Sollte dort kein abschließender Slash sein, wird dieser angefügt, da rsync diesen abschließen Slash benötigt um den Zielordner zu erstellen indem dann die Datensicherungsquellen abgelegt werden.

Aber ich schau mir natürlich auch das an und danke dir für deinen Bug Report. Ich meld mich…

Tommes

 

[Tommes]

Ach Gottchen… ich glaub ich weiß den Grund schon… ahhhhh… das darf man echt keinem erzählen. Ich bin manchmal aber auch zu dämlich…

Ich kann das Aber erst morgen Abend testen und ggfl. fixen. Eigentlich müsste es wohl so heißen…

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

 

[Jagnix]

Wo gehobelt wird fallen Spähne.

 

[Tommes]

Der Fehler war jetzt aber echt dämlich. Solang man aber keinen abschließenden Slash setzt, funktioniert ja erstmal alles. Wahnsinn…

 

[Jagnix]

Ich sage in solchen Fällen immer TdT = Tücken der Technik.

 

[Benares]

@Tommes, hab dein Code-Schnipsel grad mal in ein Script kopiert. Ich versteh die Syntax nicht ganz, aber ich erhalte Fehler, wenn target bereits ein / am Ende enthält. Probier's mal aus.

Vielleicht macht ja einfach

[ "${target: -1}" != "/" ]  && target="${target}/"

das, was du willst. Achte auf das Leerzeichen hinter dem Doppelpunkt.

Teste aber bitte den Teil, getrennt vom Rest, nochmal aus.

 

[Tommes]

Hey @Benares
Vielen Dank für deine Teilname an meinen Problemen und der Suche nach entsprechenden Lösungen. Ich weiß das zu schätzen. Dieser Codeschnipsel trägt nicht meine Handschrift, sondern habe diesem im Zuge meiner Recherchen in mein Script eingebaut. Da meine Tests mit diesem Codeschnipsel zur damaliger Zeit erfolgreich verliefen, habe ich diesen nicht weiter hinterfragt.

Deine Erkenntnisse machen mich natürlich stutzig, weshalb ich das morgen alles mal selber durcharbeiten werde. Das ist halt immer das blöde, wenn man sich woanders irgendwelche Codeschnipsel klaut ohne diese genau unter die Lupe zu nehmen.

 

[Benares]

Ich hatte das mit folgendem Script (xxx) probiert

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

erst mit deinem Code, dann mit dem modifizierten (auch geklaut )

Bei deinem gabs mit / am Ende immer eine Fehlermeldung, aber das Ergebnis war ok, und ohne kam / heraus. Die Ergänzung des else-Zweigs hat daran auch nichts geändert.

root@DS415:~# ./xxx abc/
abc/
./xxx: line 5: abc/: syntax error: operand expected (error token is "/")
abc/
root@DS415:~# ./xxx abc
abc
/

Mit dem modifizierten Code sah's dann so aus:

root@DS415:~# ./xxx abc/
abc/
abc/
root@DS415:~# ./xxx abc
abc
abc/

Das ist doch, was du willst, oder?

 

[Tommes]

Genau. Am Ende muß in jedem Fall ein abschließender Slash stehen.

 

[tokon]

Aber nochmal doof gefragt, weshalb willst du eigentlich beim Ziel zwingend einen / am Ende stehen haben? Beim Ziel ist es dem rsync Syntax doch egal, einen Unterschied macht rsync nur wenn bei der Quelle ein / am Ende steht oder eben nicht (direkt ins Ziel oder Unterordner im Ziel).

 

[Tommes]

Eine richtig Antwort auf die Frage…

weshalb willst du eigentlich beim Ziel zwingend einen / am Ende stehen haben?

… habe ich nicht, nur einen Link, wo das Problem thematisiert wird.

https://itectec.com/unixlinux/why-add-a-trailing-slash-after-an-rsync-destination/

In meinen Augen kann es also nicht schaden, wenn am Ende des Zielordners ein Slash steht, auch wenn man den Nutzen durchaus in Frage stellen kann.

 

[Tommes]

Hey @Benares

Ich habe das jetzt nochmal getestet und bei mir funktioniert beides. Zurerst mein ursprünglicher Code mit angehangener "else" Anweisung...

#!/bin/bash

var[target]=$1
echo "${var[target]}"

# Make sure that the target path ends with a slash
# ----------------------------------------------------------------
[ "${var[target]:${#var[target]}-1:1}" != "/" ] && target="${var[target]}/" || target="${var[target]}"

echo "${target}"

Ergibt bei mir...

root@Diskstation:~# ./test.sh abc
abc
abc/
root@Diskstation:~# ./test.sh abc/
abc/
abc/

Zu dem selben Ergebnis kam ich dann auch mit deinem Codeschnipsel...

#!/bin/bash

var[target]=$1
echo "${var[target]}"

# Make sure that the target path ends with a slash
# ----------------------------------------------------------------
[ "${var[target]: -1}" != "/" ]  && target="${var[target]}/" || target="${var[target]}"

echo "${target}"

Es funktionieren demnach beide Wege. So jedenfalls meine Erkenntnisse.

Tommes