Cómo crear tareas programadas con cron y crontab en Debian 13: guía completa con ejemplos prácticos

En Linux, muchas tareas de administración deben ejecutarse periódicamente: realizar copias de seguridad, eliminar archivos temporales, comprobar el espacio disponible, generar informes, revisar servicios o ejecutar scripts automáticamente.

Aunque podemos realizar estas operaciones manualmente desde la terminal, no siempre es conveniente depender de que un administrador esté conectado al equipo.

Para solucionar este problema existe cron, un servicio que permite ejecutar comandos y programas automáticamente en fechas y horarios establecidos.

En este tutorial aprenderemos a utilizar cron y crontab en Debian 13, desde sus conceptos fundamentales hasta la creación de tareas de mantenimiento y monitoreo.

También veremos cómo trabajar con scripts Bash, guardar registros, recibir notificaciones por correo y solucionar errores frecuentes.

1. ¿Qué es cron en Linux?

Cron es un programador de tareas utilizado en sistemas Unix y Linux.

Su función consiste en ejecutar comandos o scripts de manera automática según una programación definida.

Por ejemplo, podemos indicarle al sistema que:

• Realice una copia de seguridad todos los días a las 2:00 a. m.
• Compruebe el espacio del disco cada 15 minutos.
• Genere un informe todos los lunes.
• Limpie determinados archivos temporales una vez por semana.
• Ejecute un script de mantenimiento cada madrugada.
• Compruebe periódicamente si un servicio está funcionando.

La principal ventaja es que estas tareas se ejecutan sin intervención manual, siempre que el equipo esté encendido, el servicio cron funcione y se cumplan las condiciones necesarias.

Diferencia entre cron y crontab

Aunque suelen mencionarse juntos, no son exactamente lo mismo.

Cron: es el servicio encargado de revisar las programaciones y ejecutar las tareas.

Crontab: es el archivo o herramienta utilizada para definir las tareas programadas.

Podemos entenderlo así:

Administrador
     |
     v
  crontab
     |
     v
Servicio cron
     |
     v
Ejecuta comandos y scripts
     |
     v
Guarda resultados o envía notificaciones

2. Instalar cron en Debian 13

En muchas instalaciones de Debian, cron ya se encuentra disponible. Sin embargo, conviene comprobarlo.

Primero actualizamos la información de los paquetes:

sudo apt update

Después instalamos cron:

sudo apt install cron

Para comprobar su estado:

systemctl status cron

Si está funcionando correctamente, normalmente veremos:

Active: active (running)

Si no está iniciado, podemos ejecutarlo:

sudo systemctl start cron

Para configurarlo de manera que se inicie automáticamente con el sistema:

sudo systemctl enable cron

También podemos realizar ambas operaciones con:

sudo systemctl enable --now cron

¿Qué sucede si cron está detenido?

Las tareas programadas no se ejecutarán mientras el servicio permanezca detenido.

Además, cron tradicional no garantiza recuperar automáticamente todas las ejecuciones que se perdieron mientras el equipo estaba apagado.

Para trabajos que deben recuperarse después de un apagado existen alternativas como anacron y los temporizadores de systemd, que veremos más adelante.

3. ¿Qué es crontab y cómo se utiliza?

Cada usuario puede tener su propia lista de tareas programadas.

Para editar las tareas del usuario actual:

crontab -e

La primera vez, Debian puede solicitar que seleccionemos un editor de texto.

Por ejemplo:

Select an editor:

1. /bin/nano
2. /usr/bin/vim
3. /usr/bin/editor

Si estamos comenzando, Nano suele ser una opción sencilla.

Consultar las tareas existentes

crontab -l

Este comando muestra las tareas programadas del usuario actual.

Eliminar todas las tareas del usuario

crontab -r

Precaución: este comando elimina el crontab del usuario. No debemos utilizarlo sin estar seguros.

En algunas implementaciones, incluida la utilizada habitualmente en Debian, podemos solicitar confirmación:

crontab -i -r

Editar las tareas de root

sudo crontab -e

Las tareas del usuario root se ejecutan con sus privilegios.

Por ello, solamente debemos programar tareas como root cuando realmente necesiten permisos administrativos.

4. Cómo interpretar los cinco campos de cron

Esta es la parte más importante del tutorial.

Una tarea cron convencional tiene la siguiente estructura:

* * * * * comando
| | | | |
| | | | +---- Día de la semana
| | | +------ Mes
| | +-------- Día del mes
| +---------- Hora
+------------ Minuto

Los cinco campos indican cuándo debe ejecutarse el comando.

Campo	Valores permitidos	Significado
Minuto	0–59	Minuto de ejecución
Hora	0–23	Hora del día
Día del mes	1–31	Día del mes
Mes	1–12	Mes del año
Día de la semana	0–7	Día semanal; 0 y 7 representan domingo

Los nombres abreviados de meses y días también pueden utilizarse en muchas implementaciones, como la de Debian.

Ejemplo: ejecutar una tarea a las 3:30 a. m.

30 3 * * * /ruta/script.sh

Interpretación:

30 = Minuto 30
 3 = Hora 3
 * = Todos los días del mes
 * = Todos los meses
 * = Todos los días de la semana

Resultado: el script se ejecutará todos los días a las 3:30 a. m.

Ejemplo: ejecutar todos los lunes a las 8:00 a. m.

0 8 * * 1 /ruta/script.sh

El último campo es 1, que representa lunes.

Ejemplo: ejecutar el primer día de cada mes

0 0 1 * * /ruta/script.sh

Se ejecutará a medianoche el día primero de cada mes.

5. Los símbolos especiales de cron

Además de los números, cron permite utilizar símbolos para construir programaciones más flexibles.

Asterisco (*): todos los valores

El asterisco representa todos los valores posibles de un campo.

* * * * * comando

Significa ejecutar el comando cada minuto.

Coma (,): seleccionar varios valores

0 8,12,18 * * * comando

Ejecuta el comando todos los días a las 8:00, 12:00 y 18:00.

Guion (-): definir un intervalo

0 9-17 * * * comando

Ejecuta el comando a cada hora en punto desde las 9:00 hasta las 17:00, inclusive.

Barra (/): establecer saltos

*/15 * * * * comando

Ejecuta el comando cada 15 minutos.

En este caso, durante cada hora se ejecutará en los minutos:

00
15
30
45

Otro ejemplo:

0 */2 * * * comando

Ejecuta el comando cada dos horas, a las horas pares del día.

Combinación de símbolos

*/10 8-18 * * 1-5 comando

Significa:

• Cada 10 minutos.
• Entre las 8:00 y las 18:59, con ejecuciones en los minutos 00, 10, 20, 30, 40 y 50.
• De lunes a viernes.

Importante: cuando restringimos simultáneamente el día del mes y el día de la semana, cron tradicional de Debian puede ejecutar la tarea si coincide cualquiera de esos dos campos. No debemos asumir que siempre funcionan como una condición lógica AND.

6. Tabla de ejemplos frecuentes

Expresión cron	Frecuencia
* * * * *	Cada minuto
*/5 * * * *	Cada cinco minutos
*/15 * * * *	Cada quince minutos
0 * * * *	Cada hora en punto
0 */6 * * *	Cada seis horas
0 0 * * *	Todos los días a medianoche
30 2 * * *	Todos los días a las 2:30 a. m.
0 8 * * 1-5	Lunes a viernes a las 8:00 a. m.
0 3 * * 0	Domingos a las 3:00 a. m.
0 0 1 * *	Primer día de cada mes
0 0 1 1 *	Primero de enero a medianoche

7. Primera práctica: crear una tarea que escriba en un archivo

Vamos a realizar una prueba sencilla y segura.

Primero creamos un directorio de laboratorio:

mkdir -p ~/laboratorio-cron

Después editamos nuestro crontab:

crontab -e

Agregamos:

* * * * * /usr/bin/date >> /home/USUARIO/laboratorio-cron/registro.txt

Debemos reemplazar USUARIO por el nombre real de nuestra cuenta.

Podemos consultarlo con:

whoami

¿Qué hace este comando?

/usr/bin/date ejecuta el programa que muestra la fecha y hora.

El operador:

>>

Agrega la salida al final del archivo sin borrar su contenido anterior.

Por lo tanto, cada minuto se añadirá una nueva línea.

Después de esperar uno o dos minutos, consultamos:

cat ~/laboratorio-cron/registro.txt

Podríamos encontrar:

dom 8 nov 2026 23:30:01 CST
dom 8 nov 2026 23:31:01 CST
dom 8 nov 2026 23:32:01 CST

Las fechas son ilustrativas; dependerán de cuándo ejecutemos la práctica.

¿Por qué utilizamos una ruta absoluta?

Cron no necesariamente utiliza el mismo entorno que nuestra terminal interactiva.

Por eso conviene indicar rutas completas para los programas, scripts y archivos importantes.

Cuando terminemos esta prueba, debemos eliminar su línea del crontab para evitar que siga escribiendo indefinidamente.

8. Segunda práctica: ejecutar automáticamente un script Bash

Ahora crearemos un script independiente.

Primero:

nano ~/laboratorio-cron/saludo.sh

Escribimos:

#!/bin/bash

FECHA=$(/usr/bin/date '+%Y-%m-%d %H:%M:%S')

echo "[$FECHA] Cron ejecutó correctamente el script." \
    >> "$HOME/laboratorio-cron/saludos.log"

Guardamos y concedemos ejecución:

chmod u+x ~/laboratorio-cron/saludo.sh

Podemos probarlo manualmente:

~/laboratorio-cron/saludo.sh

Ahora agregamos la tarea a crontab -e:

*/5 * * * * /home/USUARIO/laboratorio-cron/saludo.sh

El script se ejecutará cada cinco minutos.

¿Qué aprendimos?

Que cron no necesita contener toda la lógica del trabajo.

Lo recomendable es colocar las operaciones complejas dentro de scripts y utilizar cron únicamente para establecer cuándo deben ejecutarse.

Esto facilita el mantenimiento, la depuración y la reutilización del código.

9. Tercera práctica: monitorear el espacio disponible en disco

Este ejemplo es especialmente útil para servidores Debian.

Imaginemos que administramos un VPS y queremos recibir una advertencia cuando el sistema de archivos raíz alcance un nivel elevado de ocupación.

Crearemos:

nano ~/laboratorio-cron/disco.sh

Contenido:

#!/bin/bash

UMBRAL=90

USO=$(/usr/bin/df -P / | /usr/bin/awk 'NR==2 {gsub(/%/, "", $5); print $5}')

FECHA=$(/usr/bin/date '+%Y-%m-%d %H:%M:%S')

if [ "$USO" -ge "$UMBRAL" ]; then

    echo "[$FECHA] ALERTA: El disco raíz está al ${USO}%." \
        >> "$HOME/laboratorio-cron/disco.log"

fi

Explicación

UMBRAL=90 establece el porcentaje a partir del cual queremos generar una advertencia.

df -P / consulta la ocupación del sistema de archivos que contiene / utilizando un formato de salida adecuado para scripts.

awk extrae el porcentaje de uso y elimina el símbolo %.

La condición:

if [ "$USO" -ge "$UMBRAL" ]; then

Comprueba si el porcentaje es mayor o igual que el límite establecido.

Programar la revisión

*/15 * * * * /bin/bash /home/USUARIO/laboratorio-cron/disco.sh

Cada quince minutos comprobará la ocupación del disco.

Este ejemplo registra una alerta cada vez que detecta el umbral superado. En producción conviene añadir mecanismos para evitar notificaciones repetidas.

10. Cuarta práctica: enviar alertas por correo local con Postfix

Si tenemos Postfix o un sistema de correo local compatible correctamente configurado, podemos enviar notificaciones al administrador.

Por ejemplo, modificamos el script anterior para utilizar:

echo "Advertencia: el disco raíz alcanzó el ${USO}%." \
    | /usr/bin/mail -s "ALERTA DE DISCO EN DEBIAN" root

Esto enviará un mensaje al buzón local de root, siempre que la entrega local esté funcionando.

Podemos consultar ese buzón con:

sudo mail -u root

También podemos configurar un alias de root hacia una dirección administrativa externa si Postfix tiene habilitada y correctamente configurada la entrega al exterior.

Una recomendación: en producción, las alertas críticas deberían integrarse también con un sistema de monitoreo externo, ya que el propio servidor podría fallar antes de enviar el mensaje.

11. Quinta práctica: crear respaldos automáticos con tar

Una aplicación habitual de cron es la creación de copias de seguridad.

Para esta práctica utilizaremos un directorio de ejemplo:

mkdir -p ~/laboratorio-cron/datos

Creamos un archivo:

echo "Información importante" > ~/laboratorio-cron/datos/documento.txt

Después creamos el script:

nano ~/laboratorio-cron/respaldo.sh

Contenido:

#!/bin/bash

set -euo pipefail

ORIGEN="$HOME/laboratorio-cron/datos"
DESTINO="$HOME/laboratorio-cron/respaldos"

FECHA=$(/usr/bin/date '+%Y-%m-%d_%H-%M-%S')

/usr/bin/mkdir -p "$DESTINO"

/usr/bin/tar -czf \
    "$DESTINO/respaldo_$FECHA.tar.gz" \
    -C "$ORIGEN" .

echo "Respaldo creado: $DESTINO/respaldo_$FECHA.tar.gz"

¿Qué hace cada instrucción?

set -euo pipefail activa controles útiles para detectar determinados errores durante la ejecución del script.

ORIGEN indica qué directorio queremos respaldar.

DESTINO indica dónde se almacenarán las copias.

date genera una marca de tiempo para evitar que cada respaldo sobrescriba al anterior.

mkdir -p crea el directorio de destino si no existe.

tar -czf genera un archivo comprimido .tar.gz.

La opción -C permite cambiar al directorio de origen antes de agregar su contenido al archivo.

Probar el script

chmod u+x ~/laboratorio-cron/respaldo.sh

Después:

~/laboratorio-cron/respaldo.sh

Consultamos los respaldos:

ls -lh ~/laboratorio-cron/respaldos

Programar el respaldo diario

0 2 * * * /bin/bash /home/USUARIO/laboratorio-cron/respaldo.sh >> /home/USUARIO/laboratorio-cron/respaldos.log 2>&1

Este trabajo se ejecutará diariamente a las 2:00 a. m.

¿Qué significa 2>&1?

Es una redirección utilizada en Bash.

1 representa la salida estándar.

2 representa la salida de errores.

Con:

>> archivo.log 2>&1

Guardamos tanto los mensajes normales como los errores en el mismo archivo.

Importante: un respaldo almacenado en el mismo disco no protege frente a la pérdida completa de ese disco. Para producción conviene utilizar destinos independientes, comprobar la integridad de las copias y realizar pruebas de restauración.

12. Sexta práctica: eliminar respaldos antiguos

Cuando realizamos respaldos diariamente, el espacio utilizado puede aumentar rápidamente.

Podemos establecer una política de retención.

Por ejemplo, eliminar los archivos de respaldo del laboratorio con más de treinta días.

Primero podemos visualizar qué archivos coinciden:

find "$HOME/laboratorio-cron/respaldos" \
    -maxdepth 1 \
    -type f \
    -name 'respaldo_*.tar.gz' \
    -mtime +29 \
    -print

Si confirmamos que la selección es correcta, podemos crear una tarea de limpieza:

#!/bin/bash

/usr/bin/find "$HOME/laboratorio-cron/respaldos" \
    -maxdepth 1 \
    -type f \
    -name 'respaldo_*.tar.gz' \
    -mtime +29 \
    -delete

La opción -mtime +29 selecciona archivos cuya antigüedad, medida en periodos completos de 24 horas, es de al menos treinta días.

La opción -delete elimina los archivos seleccionados.

Precaución: antes de automatizar una eliminación, debemos probar el comando con -print y verificar cuidadosamente la ruta y el patrón.

Podemos programar esta limpieza para los domingos:

0 4 * * 0 /bin/bash /home/USUARIO/laboratorio-cron/limpieza.sh

En un entorno de producción, la política de retención debe considerar también la cantidad de copias disponibles y las necesidades de recuperación.

13. Séptima práctica: comprobar si un servicio está activo

Otra aplicación interesante consiste en revisar periódicamente el estado de un servicio.

Por ejemplo, podemos supervisar SSH.

Creamos:

nano ~/laboratorio-cron/servicio.sh

Contenido:

#!/bin/bash

SERVICIO="ssh"

if ! /usr/bin/systemctl is-active --quiet "$SERVICIO"; then

    FECHA=$(/usr/bin/date '+%Y-%m-%d %H:%M:%S')

    echo "[$FECHA] ALERTA: El servicio $SERVICIO no está activo." \
        >> "$HOME/laboratorio-cron/servicios.log"

fi

Programamos la revisión:

*/5 * * * * /bin/bash /home/USUARIO/laboratorio-cron/servicio.sh

Cada cinco minutos comprobará el estado de SSH.

Este ejemplo genera un registro cuando detecta una falla. No intenta reiniciar el servicio.

En producción, para supervisar y recuperar servicios administrados por systemd, normalmente conviene utilizar primero las capacidades nativas de systemd, como Restart=on-failure, y complementar con monitoreo externo.

14. Octava práctica: ejecutar tareas al reiniciar el sistema

Cron también admite expresiones especiales.

Una de ellas es:

@reboot /ruta/script.sh

Permite ejecutar una tarea cuando se inicia el servicio cron, normalmente durante el arranque del sistema.

Por ejemplo:

@reboot /bin/bash /home/USUARIO/laboratorio-cron/inicio.sh

Esto puede servir para inicializar determinadas tareas de usuario.

Sin embargo, debemos tener en cuenta que @reboot no garantiza que la red, una base de datos u otros servicios estén completamente disponibles.

Si una aplicación necesita dependencias específicas, los servicios de systemd suelen ofrecer mecanismos más adecuados para establecer el orden y las condiciones de inicio.

15. Otras expresiones especiales de cron

En el crontab de Debian podemos utilizar abreviaturas como:

Expresión	Significado
@reboot	Al iniciar cron
@yearly	Una vez al año
@annually	Equivalente a @yearly
@monthly	Una vez al mes
@weekly	Una vez por semana
@daily	Una vez al día
@midnight	Equivalente a @daily
@hourly	Una vez por hora

Por ejemplo:

@daily /bin/bash /home/USUARIO/laboratorio-cron/respaldo.sh

Equivale a ejecutar la tarea diariamente a medianoche.

16. ¿Dónde se almacenan las tareas cron en Debian?

Además de los crontabs personales, Debian dispone de directorios y archivos para programaciones del sistema.

Entre ellos:

/etc/crontab
/etc/cron.d/
/etc/cron.hourly/
/etc/cron.daily/
/etc/cron.weekly/
/etc/cron.monthly/

/etc/crontab

Este archivo permite definir tareas del sistema.

A diferencia del crontab personal, incluye un campo adicional para indicar el usuario que ejecutará el comando.

Por ejemplo:

0 3 * * * root /usr/local/bin/mantenimiento.sh

La estructura es:

Minuto Hora Día Mes Semana Usuario Comando

/etc/cron.d/

Permite colocar archivos independientes con tareas programadas del sistema.

También utilizan el campo de usuario.

Directorios cron.daily y similares

Permiten organizar scripts que deben ejecutarse con determinada periodicidad.

En Debian, la ejecución de estas tareas puede depender de la configuración de cron, run-parts y, cuando está instalado y configurado, anacron.

Por eso no debemos asumir que todos los scripts de esos directorios se ejecutarán exactamente a medianoche.

17. Variables de entorno en cron

Una diferencia importante entre ejecutar comandos manualmente y ejecutarlos mediante cron es el entorno disponible.

Cuando utilizamos nuestra terminal, podemos tener variables como:

PATH
HOME
SHELL
LANG

Pero cron utiliza un entorno más limitado.

Esto puede provocar que un script funcione manualmente y falle al ejecutarse automáticamente.

Definir PATH

Podemos agregar al inicio de nuestro crontab:

PATH=/usr/local/bin:/usr/bin:/bin

Definir el intérprete

SHELL=/bin/bash

Definir el destinatario de los mensajes

MAILTO=root

Cuando cron produce una salida que no ha sido redirigida, puede enviarla por correo al destinatario indicado, siempre que exista un sistema de entrega de correo funcional.

Si establecemos:

MAILTO=""

Desactivamos el envío de esos mensajes por correo.

¿Por qué un script funciona manualmente, pero no en cron?

Las causas habituales incluyen:

• Rutas relativas.
• Variables de entorno ausentes.
• Permisos insuficientes.
• Dependencia de una sesión gráfica.
• Uso de comandos que requieren interacción.
• Falta de acceso a determinados recursos.
• Diferencias de directorio de trabajo.

Una buena práctica es probar los scripts utilizando rutas absolutas y registrar tanto la salida normal como los errores.

18. Cómo evitar que una tarea se ejecute dos veces simultáneamente

Imaginemos que programamos un respaldo cada cinco minutos, pero el respaldo tarda ocho minutos.

Cron podría iniciar una segunda ejecución antes de que termine la primera.

Esto puede generar conflictos.

En Debian podemos utilizar flock, disponible habitualmente mediante el paquete util-linux.

Ejemplo:

*/5 * * * * /usr/bin/flock -n /tmp/oplinux-respaldo.lock /bin/bash /home/USUARIO/laboratorio-cron/respaldo.sh

¿Qué hace flock?

Intenta adquirir un bloqueo asociado a un archivo.

La opción -n evita esperar si el bloqueo ya está ocupado.

De esta manera, si una ejecución anterior sigue activa y mantiene el bloqueo, la nueva ejecución no iniciará el script.

Importante: debemos utilizar una ruta de bloqueo apropiada y asegurarnos de que todas las ejecuciones del mismo trabajo utilicen el mismo bloqueo.

19. Cómo consultar los registros de cron

Cuando una tarea no se ejecuta correctamente, debemos revisar los registros.

En Debian podemos consultar:

sudo journalctl -u cron

Para visualizar los registros recientes:

sudo journalctl -u cron --since "1 hour ago"

También podemos consultar los mensajes de cron registrados en syslog, si el sistema tiene configurado ese servicio:

sudo grep CRON /var/log/syslog

El archivo /var/log/syslog puede no existir en todas las instalaciones.

Guardar registros propios

Una práctica recomendable es redirigir la salida de los scripts:

0 2 * * * /bin/bash /home/USUARIO/laboratorio-cron/respaldo.sh >> /home/USUARIO/laboratorio-cron/respaldo.log 2>&1

Así tendremos un registro específico del trabajo.

Debemos considerar que los registros pueden crecer con el tiempo, por lo que conviene establecer mecanismos de rotación o retención cuando sea necesario.

20. Cron, anacron y temporizadores de systemd

Aunque cron es muy utilizado, no es la única herramienta para programar tareas.

Herramienta	Uso principal
cron	Ejecutar comandos según horarios establecidos
anacron	Ejecutar tareas periódicas que pudieron omitirse mientras el equipo estaba apagado
systemd timers	Programar unidades systemd con opciones de dependencias, registros y persistencia

¿Cuándo utilizar cron?

Es una buena opción para tareas sencillas, periódicas y compatibles con su modelo de programación.

¿Cuándo utilizar anacron?

Es útil en equipos que no permanecen encendidos todo el tiempo, como determinadas computadoras personales.

¿Cuándo utilizar systemd timers?

Resultan especialmente útiles cuando necesitamos integrar las tareas con servicios systemd, administrar dependencias, consultar registros mediante journalctl o recuperar ciertas ejecuciones omitidas mediante opciones como Persistent=true.

21. Recomendaciones de seguridad para tareas programadas

Cron es una herramienta poderosa, pero una configuración incorrecta puede provocar problemas.

Estas son algunas recomendaciones:

1. Ejecutar las tareas con el usuario menos privilegiado posible.
2. Evitar utilizar root cuando no sea necesario.
3. Utilizar rutas absolutas para archivos y comandos importantes.
4. No almacenar contraseñas directamente en líneas de crontab.
5. Proteger los scripts contra modificaciones no autorizadas.
6. Registrar errores y resultados relevantes.
7. Probar manualmente los scripts antes de programarlos.
8. Evitar eliminaciones automáticas sin verificar los archivos afectados.
9. Utilizar bloqueos cuando puedan producirse ejecuciones simultáneas.
10. Revisar periódicamente las tareas programadas que ya no se necesitan.

22. Errores frecuentes al utilizar cron

Error: la tarea no se ejecuta

Comprobar el servicio:

systemctl status cron

Consultar el crontab:

crontab -l

Revisar los registros:

sudo journalctl -u cron --since "30 minutes ago"

Error: el script funciona manualmente, pero no con cron

Comprobar las rutas, el entorno, los permisos y el intérprete.

Podemos ejecutarlo explícitamente con Bash:

*/5 * * * * /bin/bash /ruta/script.sh

Error: el archivo de registro no aparece

Verificar que exista el directorio de destino y que el usuario de la tarea tenga permisos de escritura.

Error: la tarea se ejecuta a una hora diferente

Comprobar la zona horaria del sistema:

timedatectl

Las tareas tradicionales de cron se interpretan normalmente según la zona horaria utilizada por el servicio.

Los cambios de horario de verano también pueden afectar determinadas programaciones.

Error: se ejecutan varias instancias al mismo tiempo

Considerar el uso de flock u otro mecanismo de exclusión mutua.

23. Laboratorio final: automatizar el mantenimiento básico

Como práctica final, podemos combinar varias tareas dentro de un mismo crontab.

Supongamos que tenemos estos scripts:

/home/USUARIO/laboratorio-cron/
    saludo.sh
    disco.sh
    respaldo.sh
    limpieza.sh
    servicio.sh

Nuestro crontab podría contener:

# Entorno de ejecución
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin

# Prueba del laboratorio: cada cinco minutos
*/5 * * * * /bin/bash /home/USUARIO/laboratorio-cron/saludo.sh

# Revisar espacio en disco cada quince minutos
*/15 * * * * /bin/bash /home/USUARIO/laboratorio-cron/disco.sh

# Comprobar SSH cada cinco minutos
*/5 * * * * /bin/bash /home/USUARIO/laboratorio-cron/servicio.sh

# Crear un respaldo diario a las 2:00 a. m.
0 2 * * * /usr/bin/flock -n /tmp/oplinux-respaldo.lock /bin/bash /home/USUARIO/laboratorio-cron/respaldo.sh >> /home/USUARIO/laboratorio-cron/respaldos.log 2>&1

# Eliminar respaldos antiguos los domingos a las 4:00 a. m.
0 4 * * 0 /bin/bash /home/USUARIO/laboratorio-cron/limpieza.sh

Antes de utilizarlo, debemos reemplazar USUARIO por nuestra cuenta real, crear todos los scripts correspondientes y probar cada uno manualmente.

Este laboratorio demuestra cómo cron puede coordinar distintas actividades de mantenimiento sin necesidad de ejecutarlas una por una.

24. Conclusión

Cron es una herramienta fundamental para administrar Linux y automatizar tareas repetitivas.

Su funcionamiento se basa en una idea sencilla: definir cuándo debe ejecutarse un comando y permitir que el sistema lo ejecute automáticamente.

La estructura que debemos recordar es:

* * * * * comando
| | | | |
| | | | +-- Día de la semana
| | | +---- Mes
| | +------ Día del mes
| +-------- Hora
+---------- Minuto

Y los comandos principales son:

crontab -e
crontab -l
crontab -r

Con estas herramientas podemos automatizar respaldos, monitorear servicios, revisar el almacenamiento, ejecutar scripts y generar informes periódicos.

Sin embargo, automatizar no significa olvidarnos de las tareas. Debemos comprobar que funcionan, registrar sus resultados y revisar periódicamente su configuración.

En administración de sistemas, una tarea programada correctamente puede ahorrar tiempo; una tarea programada sin supervisión puede repetir el mismo error durante meses.

---

OPERSLINUX — Aprende Linux comprendiendo cómo funciona.

Practicar cron en Debian 13 es una excelente forma de comenzar a desarrollar habilidades de automatización que posteriormente podremos aplicar a servidores web, bases de datos, aplicaciones PHP y sistemas de producción.