Cómo hacer backups automáticos con cron en Linux

Cómo hacer backups automáticos con cron en Linux
Cómo hacer backups automáticos con cron en Linux

En esta guía aprenderás a configurar backups automáticos con cron en Linux, el programador de tareas nativo del sistema. Verás la sintaxis explicada con ejemplos, un script profesional comentado línea a línea, y los errores más comunes a evitar.

🎯Nivel: Principiante

Tiempo de lectura: 10 min

Tabla de contenido

  1. ¿Por qué automatizar backups en Linux?
  2. ¿Qué es cron y cómo funciona?
  3. Sintaxis de cron en Linux: guia completa con ejemplos
  4. Cómo editar el crontab
  5. Tu primer backup automático con cron
  6. Script de backup automatico en Linux comentado linea a linea
  7. Errores comunes al usar cron para backups
  8. Como verificar que cron esta activo en Linux
  9. Herramientas para mejorar tus backups con cron en Linux
  10. Preguntas frecuentes sobre cron y backups en Linux

1. ¿Por qué automatizar backups en Linux?

La respuesta honesta: porque los humanos olvidamos.

Un backup que depende de que alguien se acuerde de ejecutarlo no es un backup real, es una esperanza. Y cuando ocurre un fallo de disco, un borrado accidental o un ataque de ransomware, "se me olvidó hacer backup" es la frase más cara que puedes pronunciar.

Automatizar backups en Linux con cron resuelve este problema de forma elegante:

  • No depende de intervención humana
  • Es gratuito y ya está instalado en tu sistema
  • Funciona con una fiabilidad probada desde hace décadas
  • Puedes combinarlo con scripts para añadir logs, rotación y alertas

2. ¿Qué es cron y cómo funciona?

cron es el demonio de planificación de tareas de Linux.

Un demonio (daemon) es un proceso que corre en segundo plano de forma continua, esperando que llegue el momento de ejecutar una tarea programada.

Cada usuario del sistema tiene su propio archivo de configuración llamado crontab (cron table), donde define qué comandos ejecutar y cuándo.

cron revisa estos archivos cada minuto y ejecuta los comandos cuya hora coincida. Sin ruido, sin ventanas emergentes, sin necesidad de que estés delante del terminal.

3. Sintaxis de cron en Linux: guia completa con ejemplos

La sintaxis de cron es lo que más intimidación genera al principio, pero una vez interiorizada es increíblemente poderosa. Cada línea de crontab sigue este formato:

┌─────────── minuto        (0 - 59)
│  ┌──────── hora          (0 - 23)
│  │  ┌───── día del mes   (1 - 31)
│  │  │  ┌── mes           (1 - 12)
│  │  │  │  ┌─ día semana  (0 - 7, donde 0 y 7 = domingo)
│  │  │  │  │
*  *  *  *  *   comando_a_ejecutar

Cada campo acepta los siguientes tipos de valores:

Tabla explicativa de la sintaxis de cron con los 5 campos: minuto, hora, dia del mes, mes y dia de la semana
Tabla explicativa de la sintaxis de cron con los 5 campos: minuto, hora, dia del mes, mes y dia de la semana

Ejemplos reales de expresiones cron

Veamos casos concretos para que la lógica quede completamente clara:
Ejecutar todos los días a las 2:00 AM:

0 2 * * *   /usr/local/bin/backup.sh

→ Minuto 0, hora 2, cualquier día del mes, cualquier mes, cualquier día de semana.

Ejecutar cada 30 minutos:

*/30 * * * *   /scripts/sync.sh

→ Cada vez que el minuto sea divisible entre 30 (minuto 0 y minuto 30 de cada hora).

Ejecutar cada lunes a las 8:00 AM:

0 8 * * 1   /scripts/informe_semanal.sh

→ Minuto 0, hora 8, cualquier día del mes, cualquier mes, pero solo si es lunes (1).

Ejecutar el día 1 de cada mes a medianoche:

0 0 1 * *   /scripts/backup_mensual.sh

→ Minuto 0, hora 0 (medianoche), día 1 del mes, cualquier mes.

Ejecutar de lunes a viernes a las 9:00 AM y a las 18:00 PM:

0 9,18 * * 1-5   /scripts/notificacion.sh

→ En los minutos 0, a las horas 9 y 18, cualquier día del mes, cualquier mes, solo de lunes a viernes.

Ejecutar cada 5 minutos solo en horario de oficina:

*/5 9-18 * * 1-5   /scripts/monitor.sh

→ Cada 5 minutos, entre las 9 y las 18 horas, de lunes a viernes.

💡
Truco: Usa crontab.guru para validar cualquier expresión cron visualmente antes de usarla en producción. Es gratis y te ahorrará errores.

4. Cómo editar el crontab

Para abrir el editor del crontab de tu usuario actual:

crontab -e

La primera vez te preguntará qué editor usar. Elige nano si eres nuevo en Linux, o vim si ya te manejas con él.

Otros comandos útiles de crontab:

crontab -l          # Lista todas las tareas programadas del usuario actual

crontab -r          # Elimina TODO el crontab del usuario (¡sin confirmación!)

crontab -u usuario  # Edita el crontab de otro usuario (requiere permisos de root)

Para editar el crontab del sistema (que corre como root):

sudo crontab -e

5. Tu primer backup automático con cron

Caso 1:Backup simple de un directorio

0 2 * * * tar -czf /backups/home_$(date +\%F).tar.gz /home/tu_usuario

Este comando hace lo siguiente:

  • Se ejecuta a las 2:00 AM todos los días
  • Crea un archivo comprimido .tar.gz en /backups/
  • Le pone la fecha en el nombre (home_2025-06-10.tar.gz)

Importante sobre el %: Dentro de crontab, el carácter** %** tiene un significado especial (equivale a nueva línea en el comando). Debes escaparlo siempre como** %** cuando lo uses en expresiones como date +%F. Si no lo haces, cron romperá silenciosamente tu comando y no entenderás por qué no funciona.

Caso 2: Backup con registro de errores

0 2 * * * tar -czf /backups/home_$(date +\%F).tar.gz /home/tu_usuario >> /var/log/backup.log 2>&1

El añadido >> /var/log/backup.log 2>&1 redirige tanto la salida estándar como los mensajes de error al archivo de log. Si algo falla en el futuro, tendrás registro de qué ocurrió y cuándo.

6. Script de backup automatico en Linux comentado linea a linea

Para casos reales, lo mejor es extraer la lógica a un script separado y llamarlo desde cron. Esto facilita el mantenimiento, la depuración y la reutilización.

Crea el archivo /usr/local/bin/backup.sh:

#!/bin/bash
# ↑ Shebang: indica al sistema que interprete este archivo con bash

# =============================================================
# CONFIGURACIÓN — Cambia estas variables según tu entorno
# =============================================================

ORIGEN="/home/tu_usuario"       # Directorio que quieres respaldar
DESTINO="/backups"              # Dónde se guardarán los archivos de backup
FECHA=$(date +%F)               # Obtiene la fecha actual en formato YYYY-MM-DD
ARCHIVO="home_${FECHA}.tar.gz"  # Nombre del archivo de backup con la fecha incluida
LOG="/var/log/backup.log"       # Archivo donde se registran los eventos del backup
DIAS_RETENCION=7                # Número de días que se conservarán los backups antiguos

# =============================================================
# PREPARACIÓN
# =============================================================

# Crea el directorio de destino si no existe (-p evita error si ya existe)
mkdir -p "$DESTINO"

# =============================================================
# EJECUCIÓN DEL BACKUP
# =============================================================

# Escribe en el log la hora de inicio del proceso
echo "[$(date '+%Y-%m-%d %H:%M:%S')] Iniciando backup de ${ORIGEN}..." >> "$LOG"

# tar: empaqueta y comprime el directorio
#   -c → crear un nuevo archivo
#   -z → comprimir con gzip
#   -f → especificar el nombre del archivo de salida
# Los posibles errores se redirigen también al log (2>> "$LOG")
tar -czf "${DESTINO}/${ARCHIVO}" "$ORIGEN" 2>> "$LOG"

# =============================================================
# VERIFICACIÓN DEL RESULTADO
# =============================================================

# $? contiene el código de salida del último comando (0 = éxito, otro = error)
if [ $? -eq 0 ]; then
    # El backup terminó sin errores
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] ✔ Backup completado correctamente: ${ARCHIVO}" >> "$LOG"
else
    # Algo salió mal; el detalle del error ya está en el log gracias al 2>> anterior
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] ✘ ERROR: El backup de ${ORIGEN} falló. Revisa el log." >> "$LOG"
fi

# =============================================================
# LIMPIEZA DE BACKUPS ANTIGUOS
# =============================================================

# find: busca archivos en $DESTINO
#   -name "*.tar.gz"     → solo archivos con esa extensión
#   -mtime +${DIAS_RETENCION} → modificados hace más de N días
#   -delete              → los elimina directamente
find "$DESTINO" -name "*.tar.gz" -mtime +${DIAS_RETENCION} -delete

# Registra en el log que se hizo la limpieza
echo "[$(date '+%Y-%m-%d %H:%M:%S')] Backups de más de ${DIAS_RETENCION} días eliminados." >> "$LOG"

Dale permisos de ejecución:

chmod +x /usr/local/bin/backup.sh

Pruébalo manualmente antes de programarlo:

/usr/local/bin/backup.sh

cat /var/log/backup.log

Añádelo al crontab:

0 2 * * * /usr/local/bin/backup.sh
Instalar y configurar Docker Engine en Ubuntu | Guía paso a paso
Aprende a instalar y configurar Docker Engine en Ubuntu. Guía completa paso a paso para poner en marcha contenedores y gestiona tu entorno Linux.

7. Errores comunes al usar cron para backups

Error 1: Usar rutas relativas

Cron no hereda tu entorno de usuario. No conoce tu $PATH, no sabe cuál es tu directorio de trabajo actual y no carga tu .bashrc. Esto significa que un comando que funciona perfectamente en tu terminal puede fallar silenciosamente en cron.

❌ Mal:

0 2 * * *   backup.sh

✅ Bien:

0 2 * * *   /usr/local/bin/backup.sh

Error 2: Olvidar escapar el %

Dentro de crontab,** %** es un carácter especial que cron interpreta como salto de línea. Si escribes date +%F directamente en el crontab sin escapar, el comando fallará.

❌ Mal (en crontab directo):

0 2 * * *   tar -czf /backups/home_$(date +%F).tar.gz /home/user

✅ Bien:

0 2 * * *   tar -czf /backups/home_$(date +\%F).tar.gz /home/user
💡
Mejor usa un script separado donde no necesites escapar nada

Error 3: No tener logs

Si no tienes logs,si falla cron no sabras ni cuando ni por qué falló.

Error 4: No probar el comando antes de programarlo

Ejecuta siempre el comando o script manualmente y comprueba que devuelve el resultado esperado.Una vez hecho esto, prográmalo en cron.

Error 5: El disco de destino se llena

Si no tienes rotación de backups, el disco de destino se llenará eventualmente. Implementa siempre la limpieza de archivos antiguos con find ... -delete.

8. Como verificar que cron esta activo en Linux

Antes de confiar en tus tareas programadas, asegúrate de que el servicio cron está activo:

# En Debian, Ubuntu y derivados

systemctl status cron

# En RHEL, CentOS, Fedora y derivados

systemctl status crond

Si aparece como inactivo,actívalo:

systemctl enable --now cron    # Debian/Ubuntu

systemctl enable --now crond   # RHEL/CentOS

Para ver logs del demonio de cron y verificar que tus tareas están ejecutandose:

grep CRON /var/log/syslog        # Debian/Ubuntu

journalctl -u cron --since today # Con systemd
10 comandos de Linux esenciales para DevOps (con ejemplos reales)
Los 10 comandos de Linux más usados en DevOps: grep, tail, curl, jq, rsync y más. Con ejemplos reales y capturas de producción.

9. Herramientas para mejorar tus backups con cron en Linux

// Para backups automáticos en Linux con cron

Herramienta ¿Qué hace? Tipo Dificultad Más info
⚡ crontab.guru Validador visual de expresiones cron. Escribe tu expresión y ves en tiempo real qué días y horas se ejecutará.
→ Úsalo antes de añadir cualquier tarea a producción
Gratuito
Visitar
🔄 anacron Programador de tareas para máquinas que no están encendidas 24/7. Si el sistema estaba apagado cuando tocaba la tarea, la ejecuta al arrancar.
→ Ideal para laptops, VMs o servidores sin uptime garantizado
Nativo Linux
man page
📋 logrotate Gestiona la rotación automática de archivos de log. Evita que /var/log/backup.log crezca indefinidamente comprimiendo y purgando entradas antiguas.
→ Configúralo para rotar el log de backups semanalmente
Demonio
man page
📦 rsync Alternativa a tar para backups incrementales. Solo transfiere los archivos que han cambiado, ahorrando espacio y tiempo. Funciona en local y sobre SSH.
→ Perfecto para backups remotos o datasets grandes
Nativo Linux
man page

Todas las herramientas nativas están disponibles en los repositorios oficiales de tu distribución

10. FAQ — Preguntas frecuentes sobre cron y backups en Linux

No. Si el sistema está apagado cuando llega el momento programado, cron simplemente no ejecuta la tarea y no la recupera después.

Para esos casos existe anacron. A diferencia de cron, anacron detecta las tareas que se perdieron por estar el sistema apagado y las ejecuta la próxima vez que arranque. Se configura en /etc/anacrontab.

Si tu máquina es un servidor con uptime garantizado, cron es suficiente. Si es un portátil o VM que se apaga con frecuencia, usa anacron.

Sí, sin límite práctico. Cada línea del crontab es una tarea independiente. Puedes tener:

  • Backups diarios del home
  • Backups semanales de bases de datos
  • Scripts de limpieza mensuales
  • Monitores que corren cada 5 minutos

Si lanzas varias tareas pesadas al mismo tiempo pueden solaparse. Escálalas en tiempo: 2:00, 2:15, 2:30...

crontab -e edita el crontab personal del usuario actual. Las tareas se ejecutan con los permisos de ese usuario. Es la opción recomendada para tareas normales.

/etc/crontab es el crontab del sistema. Tiene un campo adicional: el nombre de usuario con el que se ejecuta la tarea:

0 2 * * *   root   /usr/local/bin/backup.sh

Requiere permisos de root y se usa para tareas de administración global del sistema.

Las causas más frecuentes, ordenadas de más a menos común:

  1. El demonio cron no está activosystemctl status cron
  2. Rutas relativas en el comando → usa siempre rutas absolutas
  3. El script no tiene permisos de ejecuciónchmod +x /ruta/script.sh
  4. Hay un % sin escapar → escríbelo como \% en crontab
  5. Variables de entorno → cron no carga tu .bashrc ni tu $PATH

Para depurar añade >> /tmp/cron-debug.log 2>&1 al final de la línea y revisa ese archivo.

1. Revisa el log del script:

tail -f /var/log/backup.log

2. Verifica que el archivo existe y tiene tamaño razonable:

ls -lh /backups/

3. Consulta el log del demonio cron:

grep CRON /var/log/syslog | tail -20
journalctl -u cron --since today

No es recomendable. Si el disco falla, pierdes los datos originales y los backups al mismo tiempo.

La regla del sector es la estrategia 3-2-1:

  • 3 copias de tus datos
  • 2 en soportes distintos (disco interno + externo)
  • 1 fuera de la ubicación física (nube o servidor remoto)

Sí. Cada motor tiene su herramienta de volcado:

MySQL / MariaDB:

0 3 * * * mysqldump -u root -pPASS mi_db \
  | gzip > /backups/db_$(date +\%F).sql.gz

PostgreSQL:

0 3 * * * pg_dump mi_db \
  | gzip > /backups/db_$(date +\%F).sql.gz

Añade siempre >> /var/log/backup-db.log 2>&1 para registrar errores.

Con compresión gzip, la reducción típica es:

  • Texto / código / logs → 70–90% de reducción
  • Imágenes, vídeos, binarios → 0–10% (ya comprimidos)
  • Bases de datos SQL → 60–80% de reducción

Fórmula conservadora:

espacio = tamaño_original × 0.4 × días_retención

Ejemplo: 10 GB de datos, 7 días → unos 28 GB. Multiplica por 1.5 para tener margen.

No se encontraron preguntas para esa búsqueda.

Read more