cron vs systemd timers: automatizar su VPS Linux

Un VPS es un servidor que funciona de forma continua, a menudo sin supervisión humana directa. Precisamente por eso la automatización de las tareas recurrentes es fundamental: nadie estará ahí a las 3 de la madrugada para lanzar la copia de seguridad o renovar el certificado Let's Encrypt. Una tarea olvidada puede traducirse en una pérdida de datos, en un certificado caducado que deja el sitio fuera de línea o en un disco saturado por falta de rotación de logs.

En la práctica, cinco categorías de tareas aparecen en todo VPS Linux serio: rotación de logs de Nginx para evitar que /var/log/nginx/ llegue a varios gigabytes en pocas semanas; limpieza de imágenes Docker huérfanas (docker image prune -af) para recuperar espacio en disco sin intervención manual; copias de seguridad de PostgreSQL hacia almacenamiento remoto; verificación del certificado SSL antes de su expiración para lanzar una renovación de certbot; y finalmente scripts de scraping ligero o indexación planificados que deben ejecutarse a hora fija. Las dos grandes herramientas disponibles en Linux — cron y los systemd timers — permiten planificar estas operaciones de forma fiable.

Cron está presente en casi todos los sistemas Linux. Para planificar una tarea se edita la crontab del usuario actual con crontab -e. La sintaxis se basa en cinco campos separados por espacios, seguidos del comando:

# minuto (0-59), hora (0-23), día del mes (1-31), mes (1-12), día de la semana (0-7)
  0  3  *  *  *  /usr/local/bin/backup.sh

Los atajos @daily, @weekly, @monthly y @reboot simplifican los casos habituales. Los ficheros en /etc/cron.d/ pertenecen al sistema e indican el usuario de ejecución directamente. Para revisar las ejecuciones pasadas: /var/log/syslog con grep CRON /var/log/syslog, o journalctl -t CRON. Un detalle importante: el PATH por defecto de cron es mínimo — /usr/bin:/bin — lo que obliga a usar rutas absolutas en los scripts, o a redefinir PATH= al inicio de la crontab. La variable MAILTO controla el envío de salidas por correo; ponerla vacía (MAILTO="") lo desactiva silenciosamente. Cron no conserva ningún historial nativo de las ejecuciones pasadas y no gestiona las tareas perdidas si la máquina estaba apagada.

Un timer de systemd es una pareja de dos ficheros de unidad: un fichero .service que describe qué ejecutar y un fichero .timer que describe cuándo lanzarlo. El timer se activa con systemctl enable --now monservice.timer y lo gobierna el gestor de servicios.

La directiva OnCalendar= acepta una sintaxis rica y legible:
- daily — todos los días a medianoche
- Mon *-*-* 03:00:00 — cada lunes a las 3 AM
- *-*-* 02:30:00 — todos los días a las 2:30
- *:0/15 — cada 15 minutos

La directiva AccuracySec= (por defecto: 1 minuto) permite a systemd agrupar los timers próximos para ahorrar despertares del procesador. La directiva Persistent=true en el bloque [Timer] es la funcionalidad diferencial respecto a cron: si la máquina estaba apagada a la hora prevista, el timer recupera la ejecución perdida en el siguiente arranque. Todas las salidas pasan por journald y se consultan con journalctl -u monservice.service. El comando systemctl list-timers muestra todos los timers activos, su próximo vencimiento y la fecha de su última activación.

Cron sigue siendo la buena elección en varias situaciones concretas. En sistemas antiguos o minimalistas sin systemd — algunos contenedores Docker ligeros, imágenes Alpine, sistemas BSD — cron suele ser la única herramienta disponible. En un entorno multiusuario donde cada desarrollador gestiona sus propias tareas con crontab -e sin permisos de root, cron es más sencillo de delegar.

Para scripts de una sola línea muy simples — un certbot renew semanal, un rsync nocturno sin dependencias — la crontab sigue siendo legible y mantenible sin multiplicar los ficheros. Cron es también la buena elección para incorporar a un equipo no especializado en Linux: la sintaxis de los cinco campos, documentada en todas partes, es más accesible que una unidad systemd. Por último, si sus tareas cron llevan años funcionando sin problemas, la migración no aporta valor inmediato. El criterio decisivo es la necesidad de logs estructurados, dependencias entre servicios o restricciones de recursos.

Los timers de systemd se imponen en cuanto la tarea supera el marco de un simple comando aislado. ¿Necesita journald para trazar cada ejecución, sus salidas y su código de retorno sin fontanería manual? Systemd timers. ¿Su script de copia de seguridad debe ejecutarse solo después de que PostgreSQL esté listo, declarando After=postgresql.service? Systemd timers. ¿Quiere limitar la memoria de un trabajo de sincronización para que no ahogue a los demás procesos (MemoryMax=512M)? Systemd timers.

Las dependencias entre servicios son el argumento más fuerte: un backup lanzado cuando la base de datos no está disponible tras un reinicio produce un fichero vacío sin error visible bajo cron. Systemd garantiza el orden. El logging integrado via journald elimina todo el ruido de las redirecciones manuales. La gestión de errores con OnFailure= permite disparar una notificación (correo, webhook) sin contaminar el script. Y si el servidor se reinicia a las 2:58 cuando la copia de las 3 tendría que haberse ejecutado, Persistent=true garantiza que se ejecutará en el siguiente arranque.

Cinco problemas se repiten al poner en marcha los timers.

1. "Unit not found" al hacer systemctl enable — el fichero .timer o .service no está en /etc/systemd/system/ o tiene un nombre incorrecto. Compruebe la ortografía exacta con ls /etc/systemd/system/*.timer. Un daemon-reload es obligatorio antes de cualquier enable o start sobre un fichero nuevo.

2. Timer activo pero que nunca se dispara — ¿muestra systemctl list-timers una fecha coherente en la columna NEXT? Si NEXT está vacío o en el pasado, un Persistent=true olvidado combinado con una máquina que no ha reiniciado desde la creación del timer es una causa habitual. Compruebe systemctl status backup.timer: active (waiting) es el estado normal.

3. ExecStart no encontrado o permiso denegado — use siempre la ruta absoluta en ExecStart= (/usr/bin/certbot y no certbot). Verifique que el script es ejecutable (chmod +x /usr/local/bin/backup.sh) y que el usuario declarado en User= tiene acceso a él.

4. Permisos en el script — si User=postgres pero el script pertenece a root sin permiso de ejecución para postgres, el servicio fallará con el código 203/EXEC. Consulte journalctl -u backup.service -n 20 para ver el mensaje exacto.

5. Conflicto entre cron y systemd en la misma tarea — si está migrando de forma progresiva, asegúrese de no tener ambos activos a la vez para una tarea destructiva (purga de logs, rotación de ficheros). Los dos se ejecutarán independientemente y duplicarán las operaciones. La comprobación es sencilla: crontab -l | grep backup y systemctl is-active backup.timer.

Cron y los systemd timers conviven sin problema en el mismo servidor: no tiene que migrarlo todo de golpe. Conserve cron para sus tareas sencillas y sus scripts de usuario existentes, y adopte los timers de systemd para las nuevas automatizaciones que se benefician de los logs de journald, de las dependencias entre servicios o del aislamiento por cgroups. Los comandos systemd-analyze calendar y systemctl list-timers son sus mejores aliados para validar y supervisar sus planificaciones.