Basic Backup Basic Backup

[Tommes]

Steht in der Übersicht hinter dem jeweiligen Auftragsnamen ein UPDATE? Falls ja, dann fahr mal mit der Maus über den Schriftzug, Klick drauf und lies, was dort steht…

 

[StefanH.]

Jetzt wird es total crazy. Ich wollte mir gerade mal anschauen wo genau im Script der Fehler auftaucht. Dazu also das Script auf der Console ausgefuehrt und geschaut was ausgegeben wird. Dann fokussiert auf die letzte Logmeldung, die vor dem eigentlichen Fehler angezeigt wird. Dafür das Script nochmal ausgeführt. Dann festgestellt, dass der Logeintrag aus der Variable txt_rsync_loop_log geladen wird. Währenddessen hab ich immer mal wieder das Script ausgeführt und natürlich klappte es nie. Bis auf einmal. Habs gefühlt zum vierten mal gestartet und jetzt läufts. Hä!? Ich hab sonst nichts verändert. Kann das eventuell was damit zu tun haben, dass die Platten auf dem ZielNAS im Ruhezustand waren und erst "hochfahren" müssen?

PS: Nein da stand kein "Update".

 

[StefanH.]

übrigens, eine eMail gibts immer noch keine ;-) Im Log steht zum Schluss nur:

sent 13.59G bytes  received 21.37K bytes  29.71M bytes/sec
total size is 21.26T  speedup is 1,563.85
-------------------------------------------------------------------------------------------------------------------
Note: The DSM system configuration and the configuration of the Basic Backup job have been saved.
Note: A new entry has been added to the version history.
-------------------------------------------------------------------------------------------------------------------
2021-11-22 12:17:31 - The backup job share_public is now complete.
 - Note: The backup log was successfully sent via email!

 

[Tommes]

Kann das eventuell was damit zu tun haben, dass die Platten auf dem ZielNAS im Ruhezustand waren und erst "hochfahren" müssen?

Da bin ich grade überfragt und müsste das erst mal testen. Kann mir das aber eigentlich nicht wirklich vorstellen... aber man weiß ja nie. Ansonsten kann ich dir grad auch nicht sagen, was du getan hast, das es zu Beginn nicht funktionierte, nun aber schon. Oftamls ist es halt so - und das ist jetzt überhaupt nicht bös gemeint - das der Benutzer eine ganz andere Vorstellung von all dem hat als der Programmierer und daher an die Dinge auch ganz anders heran geht. Das immer alles nachzuvollziehen ist nicht ganz einfach. Aber ich geb mir Mühe.


Zum Thema E-Mail Versand.
Zuerst einmal... bei mir funktioniert der E-Mail Versand, egal ob dieser immer oder nur bei Problemen ausgelöst wird. Von daher kann ich den Fehler bei mir grad nicht reproduzieren. Das Einzige, was ich mir vorstellen könnte wäre eine abweichende Absenderadresse als die, die in der DSM Systemsteuerung hinterlegt wurde. Im Idealfall setzt Basic Backup hier gleich die passende(n ) E-Mail Adresse(n ) ein. Um hier eventuelle Ungereimtheiten auszuschließen poste ich mal eben ein Screenshot, wie das im Idealfall aussehen sollte...

DSM Hauptmenü > Systemsteuerung > Benachrichtigung > E-Mail​

Basic Backup > Auftrag erstellen ​

Schau mal, ob dich das weiter bringt, oder ob du das bereits genau so umgesetzt hast. Falls letzters der Fall ist, muss ich mir etwas überlegen, wie ich dem Fehler auf die Schliche kommen könnte.

Tommes

 

[StefanH.]

Hallo,

EDIT: Ich habs, das Problem ist dein Aufruf:

ssmtp "${var[emailfrom]}" < "${email_log}"

Es muss anstattl emailfrom die Variable emailto gentutz werden.

Alter Text:

heute hatte ich nochmal ein wenig Zeit zum testen. Meine Situation is folgende:

Auf dem Mailserver existieren 2 Accounts.
1. Mein persoenlicher Account
2. Ein Account der nur zum senden von Server Benachrichtigungen verwendet wird.

Es soll also von Basic Backup eine eMail von Account 2 an Account 1 gesendet werden. Genau so ist es auch in der Synology eingetragen.

Jetzt habe ich herausgefunden, dass die eMails nicht bei Account 1 landen, sondern bei Account 2. Dieses Postfach wird eigentlich nie überprüft, deshalb bin ich erst jetzt darauf aufmerksam geworden. Nun wird es noch kurioser, wenn ich mir den Quelltext der eMail anschaue dann sind die Werte FROM und TO korrekt ausgefuellt. Trotzdem steht ganz oben in der eMail Source sinngemaess sowas wie: Delivered-To Account2

Ich hab dann mal testweise einfach über einen Mailclient eine eMail von Account 2 an Account 1 gesendet um zu pruefen, ob das überhaupt funktioniert. Es klappt, wie erwartet, ganz oben steht dann auch Delivered-To Account1.

Dann hab ich mir mal angeschaut wie dein Script die eMail versendet. Das ganze hab ich dann auf der CommandLine ausgefuehrt um zu sehen was passiert, mit -v:
Also sinngemaess:
ssmtp -v sender < maillog

Interessant!!!

[->] EHLO schoofinas
[<-] 250 DSN
[->] AUTH LOGIN
[<-] 334 xxxxxxxxxxxxxxxxx
[->] xxxxxxxxxxxxxxxxx
[<-] 334 xxxxxx
[<-] 235 2.7.0 Authentication successful
[->] MAIL FROM:<mailserver@%meinedomain%>
[<-] 250 2.1.0 Ok
[->] RCPT TO:<mailserver@%meinedomain%>
[<-] 250 2.1.5 Ok
[->] DATA
[<-] 354 End data with <CR><LF>.<CR><LF

...

Man sieht also, hier sind Mail From und RCPT TO beide gleich!!
In der BasicBackup UI sind jedoch beide verschieden.
Und auch in der email.log sind To und From korrekt eingetragen.
Also wird einfach der falsche Wert bei der smtp Verbindung uebermittelt.

Dann hab ich ssmpt komplett manuell aufgerufen und alles ueber die Console eingegeben:

ssmpt absender
To: empfaenger
From: absender
Subject: test
test

Ergebnis, voellig egal was ich bei To: als Adresse angebe, es wird immer im Postfach vom Absender landen.
Dann hab ich an der Synology Konfiguration gezweifelt. Da gibts einen Test Button. Alles wie erwartet, die eMail wird von Account 2 an Account 1 gesendet. Langsam bin ich mit meinem Latein am Ende.

 

[StefanH.]

Noch was zum remote shutdown. Da ist auch noch ein Bug drin.

Nur zur Erklärung, ich mache ja ein push backup. Mein Remote User ist in der Synology Gruppe "administrators", also hab ich in der /etc/sudoers einfach folgendes eingefuegt, damit per sudo ein shutdown gemacht werden darf.

%administrators ALL=(ALL) NOPASSWD: /sbin/poweroff, /sbin/reboot, /sbin/shutdown

In deinem Script hab ich den Befehl:

${ssh} "/sbin/shutdown"

geaendert in

${ssh} "sudo /sbin/shutdown"

Dann hab ich festgestellt, dass der Befehl gar nicht ausgefuehrt wurde. Der Grund ist, dass die Variable ${is_online} nicht existierte.
Du machst naemlich im Script einen unset. Sobald dieser auskommentiert wurde ging es, allerdings noch nicht einwandfrei. Das Script meldet, dass der shutdown Vorgang nicht korrekt ausgefuehrt wurde, was aber nicht richtig ist.

Der Grund liegt in im Exit code. Du pruefst gegen 0. Aber bei mir wird 255 zurueck gegeben. Man sieht auch eine Info/Warnmeldung. Das ist vermutlich der Grund:

root@schoofinas:/usr/syno/synoman/webman/3rdparty/BasicBackup# ssh schoofi@192.168.2.11 sudo /sbin/shutdown
Failed to talk to shutdownd, proceeding with immediate shutdown: No such file or directory
### Das Remote NAS wird trotzdem heruntergefahren!

root@schoofinas:/usr/syno/synoman/webman/3rdparty/BasicBackup# echo $?
255

 

[Tommes]

Hey @StefanH.

Es muss anstattl emailfrom die Variable emailto gentutz werden.

Vielen Dank für dein Feedback und der passenden Lösung dazu.

Das mit dem Shutdown werde ich mir die Tage mal anschauen, bin aktuell aber im Weihnachtsstress. Das mit dem sudo funktioniert aber wohl auch nur, wenn du Änderungen in der sudoers durchführst. So hatte ich es jedenfalls in Erinnerung. Kannst du also gerne so machen, jedoch gehe ich erstmal nicht davon aus, das das etwas für die breite Masse ist. Ich schau mir das aber mal in Ruhe an und finde vielleicht eine Lösung, die alle zufrieden stellt.

Nochmals vielen Dank für dein Feedback. Ich kümmer mich

Tommes

 

[Tommes]

Hi @StefanH.

Bezüglich des Shutdown Problems.
Primär ist es ja so, das auf einem Remote Server ein Shutdown nur dann über eine SSH Verbindung ausgelöst werden kann, wenn der SSH-Benutzer über entsprechende root Rechte verfügt bzw. root ist. Daher würde ein vorangestelltes sudo im rsync-Script erstmal nichts bringen, außer man pflanzt sich die benötigten Rechte in der /etc/sudoers ein, so wie du es getan hast. Ob dein Vorgehen so korrekt ist, kann ich aber nicht sagen, da ich bisher immer einen großen Bogen um die sudoers gemacht habe. Hier wäre also zu klären, ob ein vorangestelltes sudo im rsync-Script eher nützlich oder gar hinderlich sein könnte.

Den Fehler mit der Variable ${is_online} hast du sehr gut gesehen und habe unset is_online ... gleich mal auskommentiert. Vielen Dank dafür.

Das ich den Exit-Code des Shutdown Befehls jedoch gegen 0 prüfe ist schon korrekt. Denn nur bei einen exit 0 wurde der Befehl ordnungsgemäß ausgeführt, was mich zu deinem nächsten Hinweis bringt. Zumindest bei einer Synology DiskStation ist es wohl so, das sich das System mit einem einfachen /sbin/shutdown nicht zufrieden gibt. Bei mir wird hier ein exit 1 ausgeworfen. Das System verlangt hier also noch den Optionsschalter -h sowie eine genaue Zeitangabe, in diesem Fall wäre es now! Zusammengefast müsste der Befehl also lauten...

${ssh} "/sbin/shutdown -h now"

... erst dann wird mir ein exit 0 ausgegben, aber auch nur dann, wenn ich als root angemeldet bin. Zu Testzwecken kannst du hier auch den Optionsschalter -k dem Shutdown Befehl hinzufügen, damit der Shutdown nur simuliert, aber nicht ausgeführt wird, also z.B. so...

${ssh} "/sbin/shutdown -k -h now"

Des Weiteren habe ich zu Testzwecken das rsync-Script ein wenig erweitert. Vielleicht kopierst du dir das mal in dein Script und spielst noch ein wenig damit rum. Vielleicht kommen wir so auf eine gute Lösung.

function shutdown_server ()
{
    if [[ "${is_online}" == "true" ]]; then
        ${ssh} "/sbin/shutdown -k -h now"
        shutdown=${?}
        echo 'Shutdown Exit-Code:' ${shutdown}''
       
        ...
        ..
        .

Schau mal, ob dich das weiter bringt und ob es mir hilft, eine brauchbare Lösung für das Problem zu finden.

Tommes

 

[StefanH.]

leider gibt er mir immer noch exitcode 255 aus. ist aber nicht schlimm. vielleicht haette ich besser von anfang an auf ssh pull eingestellt. dann kann ich ja lokal auch mit root rechten runterfahren. der ssh pull würde dann automatisch beim boot getriggert werden.

 

[Tommes]

Kann es vielleicht sein, das der Exit-Code 255 gar nicht vom Shutdown Befehl ausgelöst wird, sondern durch die SSH Verbindung?

 

[StefanH.]

ja das ist richtig. dabei sollte aber ssh den exit code des aufgerufenen Befehls zurueckgeben. ich fahre hier schon pausenlos mein NAS hoch und runter und komme nicht drauf, wie ich das korrigieren kann. um ehrlich zu sein ignoriere ich nun einfach den exit code

 

[Tommes]

Hi

…ich fahre hier schon pausenlos mein NAS hoch und runter…

Daher habe ich hier immer den Optionsschalter -k an den shutdown Befehl gehangen. Aber gut…

Dein Problem hat meines Erachtens aber weniger mit Basic Backup an sich zu tun, sondern eher mit den DSM 7 Restriktionen. Ich bin mir auch nicht sicher, ob dich die Änderungen in der sudoers ans Ziel bringen werden. Jedoch habe ich hier selber keine Erfahrungswerte und möchte auch nur ungern zu Testzwecken meine sudoers verändern. Von daher…

Ich bin natürlich an der Lösung interessiert, nur bekomme ich hier bei mir immer nur einen Error 1 zustande, jedoch keinen Error 255. Daher vermute ich mal, das bei dir noch irgendwas anderes schief läuft. Die Frage ist nur - was? Ich befürchte, das du dir die Antwort selber erarbeiten musst, da ich den Fehler hier nicht reproduzieren kann bzw. durch ändern der sudoers - will!

Mehr fällt mir für den Moment auch nicht ein. Solltest du aber zu einer Lösung kommen, würde ich mich freuen, wenn du diese hier mit mir teilen würdest. Bis dahin bleibt mir nur zu sagen…

Viel Erfolg

Tommes

 

[TJones]

Hallo allerseits! Danke für die viele Mühe und das schöne Programm / skript, das wirklich schon ganz wunderbar funktioniert. Allerdings scheint ein Zusammenhang damit zu bestehen, dass ich seit der Installation und Nutzung (gestern) keine weiteren Apps mehr installieren kann, weil offenbar der Platz auf der Systempartition nicht mehr ausreicht (so die Warnmeldung). Ist das schon einmal aufgetreten? Landen vielleicht irgendwelche Logs oder verirrte Sicherungen auf der Systemplatte? VG TJ

 

[Tommes]

Hallo @TJones und willkommen im Forum!

Ich möchte zwar nichts ausschließen, halte es aber für eher unwahrscheinlich, das Basic Backup für das Überlaufen deiner Systempartition verantwortlich ist. Daher kann ich dir erstmal nur einen Link an die Hand geben, der dich dabei unterstützen könnte, dem Problem auf die Spur zu kommen. Hier mal der Link…

https://www.synology-forum.de/threads/systempartition-voll-letzte-handlungsschritte.83851

… und im zweiten Posting des verlinkten Threads findest du noch einen weiteren Link, den du evtl. mal folgen solltest. Schau mal ob dich das weiter bringt. Sollte es am Ende so sein, das Basic Backup der Verursacher war, wäre es natürlich super, wenn du mir diesbezüglich Feedback geben könntest.

Tommes

 

[TJones]

Hallo und vielen Dank für die freundliche Aufnahme! Ich hatte diesen Link schon gesehen, mir das noch nicht zugetraut, SSH ist nicht so mein Revier ... Ich habe den Synology Support da gerade dran, die schauen jetzt, was die Systemplatte so füllt. Sollte das irgend etwas mit BB zu tun haben, sage ich natürlich Bescheid! VG TJ

 

[StefanH.]

Ich klinke mich mal ein. Also bei mir sehe ich nichts Ungewöhnliches. Auf der DS920+ sind 1,3GB vom System belegt:

root@schoofinas:/# du -hs /* --exclude=mnt --exclude=volume1 --exclude=proc
0       /bin
0       /config
120K    /dev
3.7M    /etc
2.4M    /etc.defaults
4.0K    /initrd
0       /lib
0       /lib32
0       /lib64
4.0K    /lost+found
16K     /opt
124K    /root
41M     /run
0       /sbin
0       /sys
2.0M    /tmp
1.1G    /usr
143M    /var
5.8M    /var.defaults

Das größte Verzeichnis ist /usr

root@schoofinas:/# du -hs /usr/*
97M     /usr/bin
20K     /usr/etc
64K     /usr/include
278M    /usr/lib
13M     /usr/lib32
0       /usr/lib64
20K     /usr/libexec
263M    /usr/local
24M     /usr/sbin
134M    /usr/share
220M    /usr/syno

 

[Benares]

Und was ist dein Problem? Fang mal mit "du -h" an.

root@DS415:~# df -h
Filesystem              Size  Used Avail Use% Mounted on
/dev/md0                2.3G  1.4G  860M  62% /
...

1,2-1,4GB von 2,3GB belegt ist völlig normal.

 

[StefanH.]

meinst du mich? Ich hab kein Problem. Genau das habe ich ja beschrieben. Die Vermutung stand im Raum, dass Basic Backup die Systempartition vollmüllt. Sowas kann ich bei mir NICHT beobachten.

 

[TJones]

Der Support hat mir gerade wie folgt geantwortet:

"Über den Fernzugang konnte ich erkennen, dass wohl bei der Konfiguration eines Drittanbieter-Pakets etwas falsch angegeben wurde und somit die Daten auf die Systempartition geschrieben wurden.

Anstelle von "/volume1/Daten" wurde hier "/root/Daten" angegeben sodass die Daten nicht auf dem Volumen sondern der Systempartition abgelegt wurden."

Ich habe als Drittanbieter-Paket nur BB installiert. Kann es sein, dass das bei einer Sicherung passiert ist, bei der ich beim Datensicherungsziel den Zielordner nicht definiert hatte? ich hatte da nur probeweise / angegeben. Vielleicht hat das Programm das interpretiert als "Sichere auf root".

Verzeiht meine laienhaften Vermutungen ...

 

[StefanH.]

würde jetzt auch mal vermuten, dass du selbst auf /root gesichert hast ;-)