30 2 * * *Campos
| Minuto | 30 | 30 |
|---|---|---|
| Hora | 2 | 2 |
| Día del mes | * | cualquiera |
| Mes | * | cualquiera |
| Día de la semana | * | cualquiera |
Dónde usarla
| crontab | 30 2 * * * /path/to/script.sh |
|---|---|
| GitHub Actions | - cron: "30 2 * * *" (on.schedule) |
| Kubernetes CronJob | schedule: "30 2 * * *" |
crontab usa la zona horaria del servidor; GitHub Actions siempre usa UTC.
A tener en cuenta
30 2 * * * se ejecuta todos los días a las 02:30, hora del servidor, una franja clásica para las copias de seguridad porque hay poco tráfico. En muchas zonas horarias cae dentro del cambio de horario de verano: la noche del cambio de primavera las 02:30 no existen en hora local, y en otoño ocurren dos veces. Vixie cron y el cron de Debian lo compensan, ejecutando una tarea omitida justo después del salto y una repetida solo una vez, pero puede que otros planificadores no lo hagan.
Evita el problema programando fuera de la franja de 01:00 a 03:00, ejecutando el servidor en UTC o definiendo CRON_TZ=UTC en cronie. Los CronJobs de Kubernetes usan la zona horaria del controlador a menos que definas spec.timeZone, y GitHub Actions siempre usa UTC. Las copias de seguridad nocturnas pueden alargarse, así que usa flock -n, registra la salida con marcas de tiempo y prueba las restauraciones, no solo los códigos de salida. Una franja cercana es 30 3 * * *.