Sistemas OperativosIntermedio⏱ 25 min

Cómo sustituir cron por timers de systemd, paso a paso

systemdcronadministración Linux

26 de septiembre de 2026Actualizado el 26 de septiembre de 2026por Sergio Ruiz Navarro

systemd incluye desde hace años su propio mecanismo de tareas programadas — los timers — como alternativa nativa a cron. No es obligatorio migrar lo que ya funciona, pero para servicios nuevos en una máquina que ya usa systemd, un timer da algo que cron no tiene de serie: recuperación automática de la ejecución perdida si la máquina estaba apagada.

1
Paso 1: Crear el servicio
Un timer siempre acompaña a un .service que define QUÉ se ejecuta. Crea /etc/systemd/system/backup-homelab.service:
ini
```
[Unit]
Description=Backup diario del homelab

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-homelab.sh
```

Paso 2: Crear el timer

Crea /etc/systemd/system/backup-homelab.timer en el mismo directorio, con el mismo nombre base:

ini

[Unit]
Description=Ejecuta backup-homelab.service cada dia a las 03:00

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

3
Paso 3: Qué hace Persistent=true
Con Persistent=true, si la máquina estaba apagada a las 03:00, systemd ejecuta el job pendiente en cuanto arranca — algo que cron no hace por sí solo (necesitaría anacron aparte). Para tareas que no pueden saltarse un día, esta única línea ya justifica el cambio.
4
Paso 4: Habilitar y arrancar el timer
El timer se habilita como cualquier unidad de systemd — se activa el .timer, no el .service directamente:
bash
```
sudo systemctl daemon-reload
sudo systemctl enable --now backup-homelab.timer
```
5
Paso 5: Comprobar cuándo se ejecutará
Lista todos los timers activos y su próxima ejecución:
bash
```
systemctl list-timers
```
6
Paso 6: Revisar los logs de una ejecución
Cada ejecución del .service queda registrada en el journal, identificada por su nombre:
bash
```
journalctl -u backup-homelab.service --since today
```

Conclusión

OnCalendar admite expresiones más flexibles que el cron clásico (por ejemplo Mon..Fri 09:00, o eventos relativos con OnUnitActiveSec). Para una única tarea puntual no merece la pena migrar un cron que ya funciona, pero para servicios nuevos en una máquina con systemd, el timer es hoy la opción por defecto razonable.

Sergio Ruiz Navarro

Soy especialista en hardware y validación tecnológica. Mi día a día consiste en montar, analizar y poner a prueba equipos de alto rendimiento, realizando benchmarks, pruebas de estabilidad y evaluaciones de componentes como procesadores, tarjetas gráficas, almacenamiento y redes. Me gusta entender cómo responde cada sistema en diferentes escenarios para encontrar el equilibrio perfecto entre rendimiento, eficiencia y fiabilidad. Tengo especial interés por la optimización del hardware, el análisis térmico y el overclocking, siempre con un enfoque metódico y documentando cada resultado. Antes de recomendar un componente, prefiero haberlo llevado al límite para conocer realmente de lo que es capaz. Fuera del trabajo me gusta seguir trasteando con un pequeño homelab, donde experimento con servidores, virtualización y nuevas tecnologías. También soy un apasionado del mundo del cómic y de las películas de terror, dos aficiones con las que desconecto y que despiertan mi curiosidad tanto como cualquier nuevo componente que llega a mis manos.

Paso 1: Crear el servicio

Paso 2: Crear el timer

Paso 3: Qué hace Persistent=true

Paso 4: Habilitar y arrancar el timer

Paso 5: Comprobar cuándo se ejecutará

Paso 6: Revisar los logs de una ejecución

Conclusión

Otros tutoriales