rsnapshot: Was ist los mit meiner Crontab?

639
Danijel

Ich verwende Rsnapshot für Backups (Linux CentOS 6).

Hier ist mein /etc/cron.d/rsnapshot:

30 11 * * * root /usr/bin/rsnapshot nowandthen > /backups/rsnapshot_cron.txt 2>&1 15 11 * * 4 root /usr/bin/rsnapshot weekly > /backups/rsnapshot_cron.txt 2>&1 00 11 24-31 * 4 root /usr/bin/rsnapshot monthly > /backups/rsnapshot_cron.txt 2>&1

Das monatliche Backup sollte jeden letzten Donnerstag eines Monats ausgeführt werden.

Die monatliche Sicherung wurde jedoch heute, Donnerstag, 18. Februar 2016, um 11:00 Uhr ausgeführt. Heute ist nicht letzter Donnerstag in einem Monat.

Was ist los mit meinem Crontab?

1
Was sehen Sie in Ihren Protokollen? Jakuje vor 8 Jahren 0
Ihr Crontab scheint richtig zu sein. Haben Sie das richtige Datum auf Ihrem Computer? Was ist die Ausgabe von "Datum"? Gibt es irgendetwas, was in `grep CRON / var / log / syslog` relevant ist? agtoever vor 8 Jahren 0
Ich kann nicht erklären, warum es am 18. lief, aber bedenken Sie, dass es mehrere `crontab` -Dateien gibt: Neben` / etc`-Einträgen gibt es für jeden Benutzer eine, einschließlich `root`. Unabhängig davon wird Ihr Skript nicht das tun, was Sie möchten: Wenn der letzte Tag eines 31-Tage-Monats ein Donnerstag ist, läuft er sowohl am 24. als auch am 31. Tag. Wenn der letzte Tag im Februar ein Mittwoch ist, läuft er überhaupt nicht. AFH vor 8 Jahren 0

1 Antwort auf die Frage

3
AFH

Laut dieser Site bedeutet Ihre Zeichenfolge "Um 24 Uhr, am 25., 26., 27., 28., 29., 30. und 31. Tag jeden Monats und jeden Do um 11:00 Uhr " (meine Betonung). Wenn die Site korrekt ist, würde dies erklären, warum sie am 18. lief.

Der Beispieleintrag man 5 crontabfür den 2. Samstag ist:

0 4 8-14 * * test $(date +\%u) -eq 6 && echo "2nd Saturday"

(dh jeden Tag der zweiten Woche ausführen und den Wochentag als Teil des Befehls prüfen) - Dies unterstützt die Ansicht, dass der Wochentag ein zusätzlicher alternativer Filter ist und keine weitere Qualifizierung, obwohl die Manpage dies nicht tut klar.

In Ihrem Fall würde ich also Folgendes verwenden:

00 11 * * 4 root test $(date -d @$((`date +\%s`+604800)) +\%m) -ne $(date +\%m) && /usr/bin/rsnapshot monthly > /backups/rsnapshot_cron.txt 2>&1

Prüfen Sie, ob Ihre dateUnterstützung gilt -d 'next Thursday': Wenn ja, können Sie die etwas einfachere verwenden:

00 11 * * 4 root test $(date -d 'next Thu' +\%m) -ne $(date +\%m) && /usr/bin/rsnapshot monthly > /backups/rsnapshot_cron.txt 2>&1

Dieser wird jeden Donnerstag ausgeführt und überprüft, ob das Datum einer Woche (604800 Sekunden) ab jetzt im selben Monat liegt: Wenn nicht, muss es der letzte Donnerstag sein, sodass der Sicherungsbefehl ausgeführt wird.

Sie müssen Prozentzeichen entziehen, wie im Beispiel vom 2. Samstag. tripleee vor 8 Jahren 0
Wenn Sie ein GNU-Datum haben, wird `-d" next donnerday "+% m` unterstützt, sodass Sie einen verschachtelten Unterbefehl überspringen können. tripleee vor 8 Jahren 0
@tripleee - Ich habe den Befehl mit `bash` auf Ubuntu getestet, und es war kein Fluchtweg notwendig, obwohl ich ihn nicht in` crontab` eingecheckt habe, weil das Testen zu schwierig wäre. Ich kann mir vorstellen, dass dies in einer GNU / Windows-Umgebung notwendig wäre, aber ich werde meine Antwort ändern, da sie keinen Schaden anrichten kann. Danke für den "nächsten Donnerstag" -Tipp: Es funktioniert auf Ubuntu, also werde ich es einbauen. AFH vor 8 Jahren 0
Das Entkommen von Prozentzeichen ist eine Anforderung, die für die Crontab-Syntax spezifisch ist. ja, es würde an der Eingabeaufforderung funktionieren, ohne zu entkommen. tripleee vor 8 Jahren 0
Keine Zeit zum Testen ... Warten auf den nächsten Donnerstag. :) Danijel vor 8 Jahren 0
@Tripleee - OK, danke. Ich habe jetzt die Diskussion über Prozentzeichen in der Handbuchseite gefunden. Ich hatte irrtümlich angenommen, dass der Befehl wortwörtlich an eine Shell übergeben würde. Wir leben und lernen. AFH vor 8 Jahren 0
@Danijel - Ich schlage vor, dass Sie einen zusätzlichen Dummy-Befehl (z. B. zum Echo in einer Datei) mit derselben Uhrzeit und Testsyntax einfügen, aber eine Uhrzeit in unmittelbarer Zukunft angeben. Dadurch wird sichergestellt, dass es nicht unerwartet ausgeführt wird. Sie müssen bis nächsten Dienstag warten, um sicherzustellen, dass _does_ ausgeführt wird, wenn dies erwartet wird. Wenn Sie jedoch das lange Formular verwenden und sichergestellt haben, dass es heute nicht ausgeführt wird, ändern Sie den Sekundenversatz in "+ 604800 * 2" und es sollte dann ausgeführt werden. Dies wird ein guter Scheck sein, bevor nächste Woche kommt. Beachten Sie meine Bearbeitung, um den Prozentzeichen nach @ tripleee's Kommentaren zu entgehen. AFH vor 8 Jahren 0
Oh, und tatsächlich ist das "$ ((...))" - Zeug eine Bash-Erweiterung, also ist es in "crontab" nicht streng erlaubt, was "sh" immer läuft. Sie können sagen: "bash -c" ... Ihr Skript ... "" oder hoffen, dass "sh" ein "bash" ist, der im POSIX-Modus nicht zu streng ist. tripleee vor 8 Jahren 0
@tripleee - Ich habe es tatsächlich in `sh` ausprobiert, obwohl es unter Ubuntu mit` bash` verknüpft ist, aber es läuft mit `sh`-Syntax. Es ist auch im `sh`-Handbuch dokumentiert, obwohl es nicht Bourne-kompatibel ist. Ich habe mich gefragt, ob ich vorschlagen sollte, den Test in ein Skript einzufügen, das das Testergebnis zurückgibt: Dem könnte dann `#! / Bin / bash 'vorangehen. Alternativ ist es möglich, die Umgebungsvariable "SHELL" vor dem Starten von "cron" festzulegen, um anzugeben, welche Shell verwendet werden soll. AFH vor 8 Jahren 0

Verwandte Probleme