Probleme mit Backup-Script und Cron

Registriere dich jetzt, um exklusive Vorteile zu genießen! Als registriertes Mitglied kannst du Inhalte herunterladen und profitierst von einem werbefreien Forum.
Mach mit und werde Teil unserer Community!
  • Hallo, liebe Forenteilnehmer,


    ich habe Probleme mit der Ausführung eines Backup-Programmes mittes eines Cron-Jobs


    Zunächst die Grundinfos:

    Model : Raspberry Pi 3 Model B Rev 1.2

    PRETTY_NAME="Raspbian GNU/Linux 10 (buster)" = Legacy (Buster) ohne Desktop vom 2022-09-22

    Verwendetes Backupprogramm: rPi_backup.sh


    Nun zum Problem:
    Das Backup-Programm läuft ohne Probleme, wenn es als root in der Konsole gestartet wird.


    Wenn ich aber einen root-cronjob mittels crontab -e anlege, um das Backup-Programm zeitgesteuert ablaufen zu lassen, klappt es nicht.


    Die dd-Zeile wird anscheinend nicht ausgeführt. Hier der entsprechende Programm-Ausschnitt:

    Bash
    ...
    echo "Backing up SD card to: $OFILE"
    echo "This will take some time depending on your SD card size and read performance. Please wait..."
    SDSIZE=`blockdev --getsize64 /dev/mmcblk0`;
    /usr/bin/pv -tprIeb /dev/mmcblk0 -s $SDSIZE | /usr/bin/dd of="$OFILE.img" bs=1M conv=sync,noerror iflag=fullblock
    ...

    Das Programm pv ist installiert.

    Ich tippe auf die Pipe-Ausführung, bei der sich Cron verhaspelt. Jedenfalls wird die /usr/bin/pv .... Zeile schlicht übersprungen und das Backup-Programm mit den anschließenden Befehlen fortgesetzt. Der Variablenwert für $SDSIZE wird ordnungsgemäß erstellt und übernommen (getestet mit echo)


    Ich hoffe, ich habe den Fehler einigermaßen klar beschrieben und hoffe, dass mir jemand einen Hinweis geben kann, wie ich ihn beheben könnte.

    Schon im Voraus Danke für eure Mühe!


    Christian

  • Go to Best Answer
  • Versuche mal, alles in eine .sh zu packen und diese dann auszuführen.

    Danke fred0815

    Sorry, vergessen zu schreiben, dass ich das schon probiert hatte - selbes Ergebnis

  • Danke auch an hyle !

    Ich melde mich per ssh als pi an, wechsle per sudo -i  auf das root-konto.

    Dort starte ich crontab -e , verändere also wirklich den root-Cronjob (erkennbar mit cat /var/spool/cron/crontabs/root)

    Das Script ist ausführbar und hat den erforderlichen Shebang. Die erste Zeile ist bei mir (abweichend vom Github-Script) der Shebang.


    Das Script läuft ja wirklich ab (im Cronjob auch, allerdings ohne die oben gezeigte /usr/bin/pv .... Zeile auszuführen)


    Trotzdem Danke schonmal!


    Christian

  • Hast Du die Ausgabe des Skripts / Cronjobs mal in eine Datei umgeleitet, damit man sehen kann ob oder was für eine eventuelle Fehlermeldung kommt?


    z.B. nur als Orientierung

    Code
    30 * * * * /Pfad/zum/Skript.sh > /home/pi/cronausgabe.txt 2>&1

    Es geht hauptsächlich um das was nach den Skript.sh kommt.

  • Setze zusätzlich zum Logging im Script selbst mal:


    Bash
    #!/bin/bash
    set -euo pipefail
    set -x
    .....

    Es ist imho lesbarer und besser wartbar $(command) statt Backticks `command` zu benutzen. Sollte für dein Problem aber nicht relevant sein.

    Wenn du nichts zu sagen hast, sag einfach nichts.

  • 30 * * * * /Pfad/zum/Skript.sh > /home/pi/cronausgabe.txt 2>&1

    Kleiner Hinweis: Mit &> werden sowohl Stdout als auch Stderr redirected. Erspart sich ein wenig Tipperei und liest sich - sofern man die Syntax kennt - auch leichter.

    :no_sad: Kein Backup - kein Mitleid :no_sad:
    :) Nutze lieber raspiBackup bevor Du in die Luft gehst :)
    • Best Answer
    Code
    SDSIZE=`blockdev --getsize64 /dev/mmcblk0`;

    Was soll das Semikolon am ende der Zeile?

    Hierbei musst du für den Befehl "blockdev" den Pfand angeben, in dem er liegt. Bei den anderen Programmen, welche du n diesem Crontab-Skript aufrufst, hast du das ja gemacht.

    Computer ..... grrrrrr

  • Aber wenn #!/bin/bash am Anfang steht wird die bash genutzt. Egal wie der Default ist. D.h. sobald diese Zeile am Anfang steht kann man &> nutzen.

    Ja, aber dazu müsste TO in der crontab SHELL=/bin/bash als aufzurufende Shell setzen, da die Ausgabeumlenkung in cron und NICHT in seinem Script (dort wird Bash genutzt) geschieht.

    Wenn du nichts zu sagen hast, sag einfach nichts.

  • Perfekt gesucht :thumbup: War mir echt entfallen :blush:


    Ich bewege mich wie Du denken kannst die meisste Zeit in ein paar Scripts die #!/bin/bash am Anfang haben und mittlerweile ist mir die Schreibweise &>>$LOG_FILE am Ende von Befehlen ins Blut uebergegangen. Irgendwann denkt man das ist der Standard :lol:

    :no_sad: Kein Backup - kein Mitleid :no_sad:
    :) Nutze lieber raspiBackup bevor Du in die Luft gehst :)
  • @ all

    Herzlichen Dank für die vielen Ratschläge :bravo2:

    Ich melde mich später nochmal mit der Übermittlung von Script und dem crontab. Ich glaube, dann seht ihr klarer ;)

    LG Christian

  • Was soll das Semikolon am ende der Zeile?

    Hierbei musst du für den Befehl "blockdev" den Pfand angeben, in dem er liegt. Bei den anderen Programmen, welche du n diesem Crontab-Skript aufrufst, hast du das ja gemacht.

    Das Semikolon stammt aus dem Original-Script! (Keine Ahnung, was es bewirkt. Aber das Script läuft mit und ohne das Semikolon, hatte ich ausprobiert)


    So jetzt aber mal "Butter bei die Fische":

    Code
    cat /var/spool/cron/crontabs/root
    Bash
    #  auch schon mal ausprobiert:
    #0 3 * * 7 /bin/bash /root/backup-domoticz-neu.sh >>/root/backup-vollzug.txt


    Und jetzt das Backup-Script:

    Code
    cat /root/backup-domoticz-neu.sh

    Bitte hängt euch nicht an der (Teil-)Übersetzung und an dem mangelhaften Fehlerabfangen am Schluss auf - das kommt später dran!!!

    Das vers=2.0 beim Mounten des Fritzbox-NAS-Verzeichnisses war nötig, weil sonst (z.B. mit vers=default oder vers=3.1.1 ein Mount verweigert wurde. (Ist erstmal egal)


    Hier noch die Ergebnisse in

    Code
    cat /root/backup-vollzug.txt

    Nach Please wait... müsste die Ausgabe von pv bzgl. des Fortschritts von dd erfolgen. Alles nach dem Neustart des service ist Makulatur!


    LG Christian

    Edited once, last by msol ().