Sicherung Dateien von Raspi auf NAS

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Code
    # wikibackup  wöchentliches Backup des Dokuwiki
    SHELL=/bin/sh
    PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
    10 0 * * 1 root [ -d /mnt/nas-usb/Backup/Dokuwiki ] && /usr/bin/rsync -av --delete /var/www/html/dokuwiki/ /mnt/nas-usb/Backup/Dokuwiki/ >> /home/pi/backup_dokuwiki.log &

    Der Ausdruck in eckigen Klammer testet ob das Zielverzeichnis vorhanden ist. Wenn ja, Backup starten.

    Wird hier nur geprüft, ob es "lokal" vorhanden ist, oder ob auch das entfernte Ziel vorhanden ist?

    Hier habe ich nämlich noch ein kleines Problem, da die HDDs ein bisschen brauchen, bis diese Hochgefahren sind.

    Hätte das aber mit einem anderen Skript gelöst, dass nur eine Datei schreibt. Das gibt dann Befehl zum hochfahren. 2 Min später hätte ich dann es Backupskript gestartet.

  • Es testet nur auf Existenz und Art, testet aber "sofort", also ohne Delay.

    aus "man ["

    -d FILE FILE exists and is a directory

    Pack einfach noch eine Zeile ins File, die bewirkt dass eine Minute vorher auf den Pfad zugegriffen wird:

    09 0 * * 1 root /usr/bin/touch /mnt/nas-usb/Backup/Dokuwiki/wakeup

    Wenn du nichts zu sagen hast, sag einfach nichts.

    Einmal editiert, zuletzt von llutz (27. August 2018 um 15:04)

  • Werde hier irgendwo Logs geschrieben, wenn es zu einem Fehler kommt? Unabhängig von meinem >> backuplog?

    Habe unter /etc/cron.d/ das wikibackup angelegt, und alle 5 min starten lassen, damit ich sehen, ob etwas passiert.

    Bis jetzt ist allerdings noch kein >> backuplog angelegt.

    Edit:

    War zu schnell. Jetzt ist die Log-Datei vorhanden

  • journalctl -u cron -n 25

    zeigt dir die letzten 25 cron-betreffenden Zeilen aus dem Journald-Log an.

    Wenn du einen Mailserver installiert hast (nullmailer o.ä.), schickt cron dir auch sämtliche Ausgaben deiner Jobs per Mail zu. Adresse kannst du per MAILTO='foo@bar.de' setzen.

    Bis jetzt ist allerdings noch kein >> backuplog angelegt.

    Hast du das genau so eingetragen? Dann müsste das Log in /root/backuplog sein. In crontabs besser immer mit absoluten Pfaden arbeiten.

    Einfacher Testjob:

    */5 * * * * pi /bin/date >> /tmp/crontest

    Wenn du nichts zu sagen hast, sag einfach nichts.

    Einmal editiert, zuletzt von llutz (27. August 2018 um 14:17)

  • Muss hier nicht ein neues File angelegt werden?

    Kann das sicher in das selbe File (/etc/cron.d/wikibackup)?

    nein, ja ;)

    Du kannst viele komplett verschiedene Jobs in einer solchen Datei unterbringen. Meist dienen sie dazu, Jobs thematisch zu ordnen. Du brauchst auch nicht auf die Reihenfolge der Einträge (Ausnahme MAILTO-Zeilen) achten, das macht cron schon für dich.

    Bitte beachte, dass Dateien in /etc/cron.d/ keine Extension haben dürfen, bzw. korrekter: Der Name darf keinen Punkt enthalten.

    Wenn du nichts zu sagen hast, sag einfach nichts.

    Einmal editiert, zuletzt von llutz (27. August 2018 um 14:45)

    • Offizieller Beitrag

    Pack einfach noch eine Zeile ins File, die bewirkt dass eine Minute vorher auf den Pfad zugegriffen wird:

    09 * * 1 root /usr/bin/touch /mnt/nas-usb/Backup/Dokuwiki/wakeup

    Und dieser Cronjob wird wann gestartet?! ;)

  • Na, eine Minute vor dem anderen :)

    Korrigiert, danke hyle

    wusa Bitte Obacht, in der Zeile fehlte die Stundenangabe. Sowas fällt einem schneller auf, wenn man nach Erstellen einer solchen Datei ein journalctl -u cron -n5 nachschiebt. Das gibt dann z.B. folgendes aus:

    ...Error: bad day-of-week; while reading /etc/cron.d/testcron

    (*system*testcron) ERROR (Syntax error, this crontab file will be ignored)

    Wenn du nichts zu sagen hast, sag einfach nichts.

    Einmal editiert, zuletzt von llutz (27. August 2018 um 15:10)

  • Habe noch eine Frage dazu, ich habe bereits einiges über "Crontab -e" laufen.

    "Beißen" sich die beiden (Crontab -e und /etc/cron.d/) oder funktioniert das ohne Probleme?

    Jeder Cronjob läuft in seiner eigenen Shell, sie beeinflussen sich daher nicht.

    Wird ein Cronjob mit & beendet, bleibt er im Hauptspeicher liegen, so gesehen beisst er den anderen Prozessen langsam den Hauptspeicher (bis zum Kernek-Panic) weg.

    Beissen kann rsync aber auch, wenn am Zielverzeichnis die Fileattribute (u-g-o rwx) verloren gehen , z.B. wenn das Zielverzeichnis nicht auf einer NFS gemounteten *nix Partition liegt.


    Sevus !

    RTFM = Read The Factory Manual, oder so

  • Wird ein Cronjob mit & beendet, bleibt er im Hauptspeicher liegen, so gesehen beisst er den anderen Prozessen langsam den Hauptspeicher (bis zum Kernek-Panic) weg.

    Gibt's dafür eine belastbare Quelle?

    crons Standardverhalten bestätigt es jedenfalls nicht - das "&" wird einfach ignoriert. Cronjobs, mit oder ohne abschliessendes "&", laufen ohnehin im Hintergrund und werden nach Beendigung aus der Prozessliste/Speicher entfernt, wie jeder andere normal gestartete Prozess auch.

    Wenn du nichts zu sagen hast, sag einfach nichts.

    Einmal editiert, zuletzt von llutz (27. August 2018 um 19:28)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!