30 2 * * *Felder
| Minute | 30 | 30 |
|---|---|---|
| Stunde | 2 | 2 |
| Tag des Monats | * | beliebig |
| Monat | * | beliebig |
| Wochentag | * | beliebig |
Wo du ihn verwendest
| crontab | 30 2 * * * /path/to/script.sh |
|---|---|
| GitHub Actions | - cron: "30 2 * * *" (on.schedule) |
| Kubernetes CronJob | schedule: "30 2 * * *" |
crontab läuft in der Zeitzone des Servers; GitHub Actions verwendet immer UTC.
Gut zu wissen
30 2 * * * läuft jeden Tag um 02:30 Serverzeit, ein klassischer Zeitpunkt für Backups, weil dann wenig Traffic herrscht. In vielen Zeitzonen fällt er in die Zeitumstellung: In der Frühjahrsnacht gibt es 02:30 lokal nicht, und im Herbst kommt es zweimal vor. Vixie cron und Debian cron gleichen das aus, indem sie einen übersprungenen Job direkt nach dem Sprung und einen wiederholten nur einmal ausführen, andere Scheduler aber womöglich nicht.
Umgeh das Problem, indem du außerhalb von 01:00 bis 03:00 planst, den Server in UTC betreibst oder in cronie CRON_TZ=UTC setzt. Kubernetes-CronJobs nutzen die Zeitzone des Controllers, solange du spec.timeZone nicht setzt, und GitHub Actions nutzt immer UTC. Nächtliche Backups können lange dauern, also nutze flock -n, logge die Ausgabe mit Zeitstempeln und teste Wiederherstellungen, nicht nur Exit-Codes. Ein benachbarter Zeitpunkt ist 30 3 * * *.