Diferencias entre Cron y Anacron en Linux explicadas a fondo

Si trabajas con GNU/Linux tarde o temprano te toparás con la necesidad de automatizar tareas periódicas: copias de seguridad, actualizaciones, limpieza de logs, sincronización de ficheros, etc. En ese punto aparecen casi siempre los mismos nombres: Cron y Anacron. Todo el mundo los menciona, pero no siempre se explica bien qué hace cada uno, en qué se diferencian y, sobre todo, cuándo conviene usar uno, el otro o los dos a la vez.

En este artículo vamos a desgranar con calma cómo funcionan, qué archivos tocan, cómo se configuran y cuáles son las diferencias prácticas entre Cron y Anacron en Linux. Verás ejemplos concretos, trucos habituales (como lanzar scripts gráficos, gestionar permisos de usuarios o combinar ambos sistemas) y también algunas buenas prácticas para no liarla al programar tareas críticas.

Qué son Cron y Anacron y en qué se diferencian de forma general

De forma muy resumida, Cron es un demonio que ejecuta tareas en momentos exactos (minuto y hora concretos), mientras que Anacron es un programador pensado para equipos que no están siempre encendidos y que garantiza que las tareas periódicas no se pierdan aunque el sistema haya estado apagado.

Cron da por hecho que el sistema está disponible 24/7, algo muy típico en servidores, VPS o máquinas de producción. Si la tarea debía lanzarse a las 03:00 y el servidor está encendido, se ejecuta. Si a esa hora el equipo estaba apagado o suspendido, la tarea se pierde y Cron esperará al siguiente momento programado sin intentar compensar nada.

Anacron, en cambio, asume justo lo contrario: que el equipo puede apagarse o suspenderse a menudo (portátiles, PCs de sobremesa, mini‑servidores caseros…). Por eso no trabaja con horas exactas, sino con periodos expresados en días. Si había una tarea «diaria» y el equipo ha pasado tres días apagado, al volver a encenderse Anacron comprobará qué cosas quedaron pendientes y las irá ejecutando cuando toque.

Una diferencia importante de filosofía es que Cron es síncrono en el sentido de tiempo exacto (hora/minuto específicos), mientras que Anacron trabaja de forma asíncrona respecto al reloj del sistema: sólo le importa cuánto tiempo ha pasado desde la última ejecución, no la hora concreta.

Cómo funciona Cron: demonio, archivos y estructura de las tareas

Cron es un demonio del sistema (un servicio en segundo plano) que está activo de forma permanente mientras la máquina está encendida. En Debian, Ubuntu y muchas otras distribuciones se ejecuta como el servicio cron y cada minuto inspecciona una serie de archivos y directorios donde se definen las tareas programadas.

En sistemas tipo Debian/Ubuntu, Cron revisa habitualmente estas ubicaciones:

• /etc/crontab: archivo maestro de sistema.
• /etc/cron.d/: ficheros de tareas adicionales, normalmente creados por paquetes o por el administrador.
• /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, /etc/cron.monthly: directorios con scripts que se lanzan de forma periódica.
• /var/spool/cron/crontabs/: ficheros de tareas de cada usuario individual.

En Debian y derivadas, el fichero /etc/crontab incluye entradas especiales que llaman a scripts genéricos para ejecutar el contenido de esos directorios cron.*. Por ejemplo, una línea típica ejecuta todo lo que haya en /etc/cron.daily una vez al día a una hora concreta, siempre y cuando Anacron no esté ocupándose de ello (luego veremos qué pasa cuando Anacron entra en juego).

Estructura de una línea de Cron en ficheros de sistema

En los ficheros de sistema como /etc/crontab y los archivos bajo /etc/cron.d/, cada línea con una tarea sigue esta estructura:

Min  Hora  Día_mes  Mes  Día_semana  Usuario  Comando

Línea de ejemplo:

14  1  *  *  *  pepe  /home/pepe/bin/tarea.sh > /dev/null 2>&1

En este caso, la tarea se lanza todos los días a la 01:14, se ejecuta como el usuario pepe y el comando indicado es el script /home/pepe/bin/tarea.sh, redirigiendo la salida estándar y de error a /dev/null para que no moleste.

Crontab de usuario: programación propia para cada cuenta

Cada usuario del sistema puede definir sus propias tareas usando el comando crontab. Esto genera y gestiona archivos individuales bajo /var/spool/cron/crontabs/ (en Debian), uno por usuario. En estos ficheros no aparece la columna de usuario, ya que Cron sabe que todo lo que hay allí debe ejecutarse como ese propietario.

• crontab -e: edita o crea las tareas del usuario actual.
• crontab -l: lista las tareas de ese usuario.
• crontab -e -u nombre: como root, edita las tareas de otro usuario.
• crontab -l -u nombre: lista las tareas de otro usuario.

Formato de cada línea en crontabs de usuario:

Min  Hora  Día_mes  Mes  Día_semana  Comando

Algunos ejemplos típicos usando crontab -e serían:

# Ejecutar copia de Nextcloud todos los días a las 22:14
14 22 * * * /home/pi/scripts/nextcloudbkp.sh

# Ejecutar cada 3 horas
0 0,3,6,9,12,15,18,21 * * * /home/pi/scripts/nextcloudbkp.sh

# Cada 6 horas simplificado
0 */6 * * * /home/pi/scripts/nextcloudbkp.sh

# Lunes a viernes a las 13:30
30 13 * * 1-5 /home/pi/scripts/nextcloudbkp.sh

# Usando atajos @reboot, @daily, @weekly, @monthly, @yearly
@reboot  /home/pi/scripts/al_arrancar.sh
@monthly /home/pi/scripts/backup_mensual.sh

Significado de los campos de Cron

En todos los crontab, ya sean de sistema o de usuario, los cinco primeros campos tienen el mismo significado. Es fundamental entenderlos bien para que las tareas se disparen cuando tú quieres.

Campo	Descripción
Minuto (m)	Valor entre 0 y 59. El símbolo * significa «todos los minutos».
Hora (h)	Rango de 0 a 23 en formato 24h. * indica «todas las horas».
Día del mes (dom)	Número entre 1 y 31, admite rangos como 10-20 y listas como 1,15,30 además de *.
Mes (mon)	Valores de 1 a 12, también con rangos/listas y el comodín *.
Día de la semana (dow)	De 0 a 7, donde 0 y 7 suelen ser domingo; también se admiten abreviaturas en inglés: mon, tue, wed, thu, fri, sat, sun.

Además de números y asteriscos, puedes usar expresiones como */15 para indicar «cada 15 unidades» en el campo correspondiente (por ejemplo, cada 15 minutos en el primero) o rangos tipo 1-5 para «de lunes a viernes» en el campo de día de la semana.

Directorio /etc/cron.d: tareas empaquetadas y de sistema

El directorio /etc/cron.d/ está pensado para que los paquetes del sistema o el administrador definan tareas periódicas sin tocar el fichero principal /etc/crontab. Cada archivo que metas ahí representa una o varias tareas que Cron revisa cada minuto.

La sintaxis de cada línea es la misma que en /etc/crontab, es decir, incluye el campo de usuario. Por ejemplo, si quieres que un script de actualización de Firefox se ejecute todos los días a las 22:00 como root, podrías crear /etc/cron.d/firefox con este contenido:

0 22 * * * root bash /home/joan/scripts/firefox_update.sh

Estos ficheros sólo los puede crear y editar alguien con permisos de administrador, así que son una buena forma de separar tareas del sistema de la configuración personal de cada usuario.

Directorio cron.daily, cron.weekly, cron.monthly, cron.hourly

Los directorios /etc/cron.daily, /etc/cron.weekly, /etc/cron.monthly y /etc/cron.hourly se utilizan para colocar scripts ejecutables que se lanzarán con la frecuencia indicada por su nombre.

• cron.hourly: se ejecuta cada hora, siempre gestionado por Cron.
• cron.daily: se ejecuta una vez al día, por Cron o por Anacron según la configuración.
• cron.weekly: se ejecuta una vez a la semana.
• cron.monthly: se ejecuta una vez al mes.

Si Anacron no está presente, la hora exacta en que se disparan estos directorios la marca /etc/crontab. Si Anacron sí está instalado, normalmente se encarga de cron.daily, cron.weekly y cron.monthly, mientras que cron.hourly suele seguir dependiendo de Cron (esto se puede cambiar, pero es la configuración típica).

Gestión de permisos de usuarios: cron.allow y cron.deny

Por defecto, en la mayoría de distros todos los usuarios pueden programar tareas con Cron. No obstante, si gestionas un servidor compartido quizá quieras restringir quién puede usar crontab. Para eso existen los ficheros:

• /etc/cron.allow: lista blanca de usuarios autorizados.
• /etc/cron.deny: lista negra de usuarios a los que se les prohíbe usar Cron.

La lógica es sencilla: si existe /etc/cron.allow y no hay /etc/cron.deny, sólo los usuarios listados podrán usar Cron. Si sólo existe /etc/cron.deny, todos menos los indicados tendrán acceso. Y si no existe ninguno de los dos, cualquier usuario del sistema puede definir sus crontab.

Consideraciones prácticas al usar Cron

Hay una serie de detalles que conviene tener en cuenta para que las tareas de Cron funcionen sin sustos:

• Usa siempre rutas absolutas en los comandos (por ejemplo, /usr/bin/rsync en lugar de rsync a secas).
• Si necesitas lanzar comandos complejos con tuberías, redirecciones o varios pasos, es mejor crear un script en bash y llamar a ese script desde Cron.
• El carácter % tiene un significado especial (marca fin de línea y comienzo de entrada estándar), así que si lo necesitas literalmente hay que escaparlo.
• Para lanzar aplicaciones gráficas desde Cron tienes que exportar un DISPLAY válido, por ejemplo:
  env DISPLAY=:0 /usr/bin/xdg-open /ruta/archivo

Y muy importante: si el equipo está apagado en el momento exacto programado, la tarea no se recuperará después. Se pierde y se esperará al siguiente intervalo. Justo para cubrir ese hueco aparece Anacron.

Cómo funciona Anacron: filosofía, archivos y control de tareas pendientes

Anacron es un programa pensado para resolver la gran limitación de Cron en equipos que no están encendidos todo el tiempo: la pérdida de tareas programadas cuando el sistema está apagado o suspendido en el momento clave.

No es un demonio que esté residente en memoria todo el rato. Anacron se ejecuta de forma puntual: normalmente al arrancar el sistema, al reanudar desde suspensión o a través de una tarea de Cron que lo llama periódicamente (por ejemplo, cada hora entre ciertas franjas horarias).

Cuando se lanza, Anacron lee su configuración, revisa qué trabajos debería haber ejecutado en los últimos días y comprueba si ha pasado el periodo definido desde la última vez. Si detecta que hay tareas atrasadas, las planifica con un posible retardo y las va ejecutando hasta ponerse al día.

Archivos clave de Anacron

En un sistema Debian/Ubuntu, los elementos principales de Anacron suelen ser:

• /etc/anacrontab: fichero central donde se declaran las tareas de Anacron.
• /var/spool/anacron/: directorio donde se guardan los archivos de marcas de tiempo para cada tarea.
• /etc/cron.d/anacron: en muchos sistemas, fichero que hace que Cron llame a Anacron de forma periódica (por ejemplo, una vez por hora entre las 7:30 y las 23:30).
• /etc/apm/event.d/anacron u otros scripts de inicio: usados en algunas distros para ejecutar Anacron al detectar alimentación de red o al arrancar el sistema.

Además, cuando Anacron toma el control de los directorios de sistema, las tareas diarias, semanales y mensuales de /etc/cron.daily, /etc/cron.weekly y /etc/cron.monthly se ejecutan bajo su paraguas. Los scripts de esos directorios siguen siendo los mismos, pero ya no los lanza Cron directamente, sino Anacron a través de lo definido en /etc/anacrontab.

Estructura del fichero /etc/anacrontab

Si abres /etc/anacrontab con un editor de texto verás que, al principio, se declaran algunas variables de entorno:

• SHELL: intérprete de comandos utilizado para las tareas (normalmente /bin/sh o /bin/bash).
• PATH: rutas en las que se buscarán los ejecutables.
• HOME: directorio de trabajo por defecto.
• LOGNAME: usuario bajo el que se ejecutan las tareas (suele ser root).

Después de estas variables vienen las líneas que definen cada tarea. La estructura general es:

periodo  retraso  identificador  comando

Donde:

• periodo: número de días entre ejecuciones o atajos como @daily, @weekly, @monthly.
• retraso: minutos que se esperan desde que Anacron decide que debe ejecutarse el trabajo hasta que realmente lo lanza.
• identificador: nombre único de la tarea, sirve para identificarla en logs y para nombrar el archivo de marca de tiempo.
• comando: orden o script a ejecutar, con su ruta completa.

Ejemplo sencillo de tarea semanal:

7   10   backup.semanal   /bin/bash /home/joan/scripts/backup.sh

En este caso, Anacron se asegurará de que cada 7 días se ejecute ese script. Si el equipo ha estado apagado y han pasado más de siete días desde la última ejecución, en cuanto se arranque o Anacron se ejecute de nuevo, se esperarán 10 minutos (retraso) y luego se lanzará la copia.

Marcas de tiempo en /var/spool/anacron

Para saber cuándo se ejecutó por última vez cada tarea, Anacron crea un archivo por trabajo en /var/spool/anacron/. El nombre de cada fichero coincide con el identificador definido en /etc/anacrontab (por ejemplo, backup.semanal, cron.daily, cron.weekly…).

El contenido de esos archivos suele ser simplemente una fecha en formato AAAAMMDD. Cuando Anacron arranca, compara esa marca de tiempo con la fecha actual y con el periodo definido en anacrontab. Si ha pasado el número de días indicado o más, programa la ejecución del comando correspondiente.

Esto quiere decir que sólo se tiene en cuenta la fecha, no la hora exacta. De ahí que Anacron no sirva para ejecutar cosas a una hora concreta, sino para garantizar que «esta tarea se ejecuta al menos una vez cada N días».

Parámetros y opciones útiles de Anacron

El comando anacron acepta una serie de opciones que son muy prácticas para pruebas o para controlar cómo se ejecutan las tareas:

• -f: fuerza la ejecución de todos los trabajos, aunque todavía no haya vencido el periodo.
• -u: actualiza las marcas de tiempo de todos los trabajos como si se hubieran ejecutado, pero sin correr realmente los comandos.
• -s: ejecuta las tareas de forma secuencial, esperando a que termine una antes de empezar la siguiente.
• -n: ejecuta inmediatamente los trabajos que toquen, activando implícitamente -s.
• -d: no se va al background; muestra mensajes por salida estándar (útil para depurar).
• -q: suprime mensajes de error por salida estándar, pensado para usar junto a -d.
• -t fichero: usa un fichero de tareas alternativo en lugar de /etc/anacrontab.
• -T: comprueba la sintaxis de un fichero de tareas y muestra errores sin ejecutar nada.
• -S dir: usa un directorio alternativo para almacenar las marcas de tiempo.

Si en algún momento quieres forzar la ejecución inmediata de las tareas definidas en anacrontab para comprobar que todo va bien, puedes usar:

sudo anacron -f

Opciones avanzadas en /etc/anacrontab: horarios y retrasos aleatorios

Además de las líneas de tareas, en /etc/anacrontab se pueden definir algunos parámetros extra que afectan al comportamiento global:

• START_HOURS_RANGE=3-22: limita el rango horario en el que Anacron puede ejecutar trabajos (en este ejemplo, sólo entre las 03:00 y las 22:00).
• RANDOM_DELAY=10: añade un retraso aleatorio entre 0 y 10 minutos a cada tarea, lo que ayuda a evitar picos de carga lanzando todo a la vez justo al arrancar.

Combinando estos parámetros con los periodos y los retardos de cada tarea puedes afinar el comportamiento y evitar sorpresas de CPU o disco trabajando a tope en mitad del horario de trabajo.

Diferencias clave entre Cron y Anacron

Una vez vistos los dos por separado, conviene comparar las características principales de Cron y Anacron para tener claro qué aporta cada uno.

Cron	Anacron
Es un demonio siempre activo en segundo plano.	Es un programa que se ejecuta puntualmente cuando lo llaman (inicio del sistema, Cron, scripts).
Permite programar tareas a minuto y hora exactos.	Trabaja con periodos en días (diario, semanal, mensual, cada N días), sin horas concretas.
Si el equipo está apagado cuando toca una tarea, esa ejecución se pierde.	Si el equipo estaba apagado, al volver a encenderse ejecuta las tareas atrasadas cuando corresponda.
Cualquier usuario puede programar tareas (salvo restricciones con cron.allow/cron.deny).	Normalmente sólo las puede configurar el administrador (root).
Es ideal para servidores o sistemas 24/7 donde el reloj es fiable.	Es ideal para portátiles, sobremesas y equipos que se apagan a menudo.

En muchas distribuciones modernas, especialmente en Debian y derivadas, vienen ambos instalados o se recomienda instalarlos juntos. Cron se ocupa de las tareas con hora exacta, trabajos de usuario y directores como cron.hourly, mientras que Anacron se hace responsable de cron.daily, cron.weekly y cron.monthly para que las tareas de mantenimiento del sistema no se pierdan aunque el equipo no esté encendido siempre.

Cuándo usar Cron, cuándo usar Anacron y cuándo combinarlos

Una forma muy práctica de decidir es pensar en el tipo de máquina y en el tipo de tarea que quieres automatizar.

• En un servidor que funciona 24/7 (web, base de datos, correo, etc.), lo normal es apoyarse casi exclusivamente en Cron. Puedes instalar Anacron si quieres, pero en un servidor que nunca se apaga no aporta tanto.
• En un ordenador de escritorio o portátil que se apaga y enciende cada día, lo sensato es usar Cron + Anacron: Cron para tareas muy concretas (ejecutar algo cada 15 minutos mientras el equipo esté encendido) y Anacron para las tareas de mantenimiento «diarias», «semanales» o «mensuales» que no quieres perder si el PC estaba apagado cuando tocaba.

Reglas prácticas que suelen funcionar bien:

• Si necesitas ejecuciones exactas a la hora (por ejemplo, un script que lanza facturación diaria a las 23:58), usa Cron.
• Si te basta con que algo ocurra al menos una vez cada X días (por ejemplo, rotar logs, borrar temporales, regenerar índices), usa Anacron o haz que tus scripts en cron.daily, cron.weekly y cron.monthly los gestione él.
• En servidores Debian, es habitual que las tareas instaladas por paquetes se sitúen en /etc/cron.daily y similares. Si Anacron está presente, se encargará de que estas tareas se ejecuten aunque tu servidor sufra apagones inesperados.

Ejemplo práctico con Anacron: copias diarias aunque el equipo no esté siempre encendido

Imagina que quieres tener una copia diaria de un fichero importante, pero tu equipo se apaga cada noche y no sabes exactamente a qué hora lo encenderás. Anacron es perfecto para esto.

Supongamos que tienes un archivo /home/usuario/prueba.txt y que quieres guardar copias diarias con la fecha y hora en el nombre. Puedes crear un pequeño script bash, otorgarle permisos de ejecución y luego añadir una línea en /etc/anacrontab que lo ejecute una vez al día con un pequeño retardo tras arrancar el sistema.

Flujo de trabajo típico:

• Creas el script /home/usuario/prueba.sh que copia el archivo con un sufijo de fecha y hora.
• Le das permisos de ejecución con chmod 700 prueba.sh.
• Pruebas el script manualmente para confirmar que hace lo que toca.
• Editas /etc/anacrontab y añades una línea tipo:
  @daily 1 somebooks /bin/bash /home/usuario/prueba.sh
• Reinicias o fuerzas Anacron para comprobar que todo se ejecuta bien.

A partir de ese momento, una vez al día, o tan pronto como el equipo se encienda si no ha podido ejecutar el trabajo el día anterior, Anacron se encargará de lanzar tu script, esperar un minuto (retraso=1) y generar una nueva copia versionada.

Otras herramientas relacionadas: at y systemd timers

Aunque la estrella de la automatización recurrente en Linux son Cron y Anacron, hay otras herramientas que conviene tener en el radar.

Por un lado tienes at, pensado para programar tareas que se ejecutan una sola vez en un momento concreto. Es ideal cuando quieres decir algo como «ejecuta este comando mañana a las 10:15 y olvídate».

• Un ejemplo básico para reiniciar a una hora determinada:
  at 10:15
> reboot
> ^D
• O algo más elaborado, con parada de un servicio, espera y arranque de nuevo un día concreto:
  at 12.12.2106 21:23
> /etc/init.d/apache stop
> sleep 600
> /etc/init.d/apache start
> ^D

Los trabajos de at se almacenan en /var/spool/cron/atjobs y puedes listarlos con atq o at -l, además de borrarlos con atrm.

Por otro lado, en sistemas modernos con systemd también existen los systemd timers, que permiten sustituir (parcial o totalmente) a Cron y Anacron definiendo unidades .timer y .service. Son una opción muy potente, pero algo más compleja de configurar; si ya dominas Cron/Anacron y quieres un control aún más fino sobre dependencias y estados de servicios, merece la pena echarles un vistazo.

En la práctica, para la mayoría de administradores y usuarios avanzados, combinar Cron, Anacron y at ofrece un abanico suficiente para cubrir casi cualquier necesidad de automatización sin tener que complicarse la vida desde el primer día con systemd timers.

Con todo esto sobre la mesa, ya tienes una visión bastante completa de cómo Cron y Anacron se reparten el trabajo de la automatización en Linux: Cron se encarga de disparar procesos con una precisión de reloj suizo siempre que el sistema esté en pie, mientras que Anacron va por detrás comprobando qué se ha quedado en el tintero cuando la máquina ha estado apagada, garantizando que las tareas diarias, semanales o mensuales de mantenimiento no se pierdan aunque el equipo tenga una vida más humana que la de un servidor clásico.