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
- ¿Por qué automatizar backups en Linux?
- ¿Qué es cron y cómo funciona?
- Sintaxis de cron en Linux: guia completa con ejemplos
- Cómo editar el crontab
- Tu primer backup automático con cron
- Script de backup automatico en Linux comentado linea a linea
- Errores comunes al usar cron para backups
- Como verificar que cron esta activo en Linux
- Herramientas para mejorar tus backups con cron en Linux
- 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_ejecutarCada campo acepta los siguientes tipos de valores:

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.
4. Cómo editar el crontab
Para abrir el editor del crontab de tu usuario actual:
crontab -eLa 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_usuarioEste 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>&1El 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.shPruébalo manualmente antes de programarlo:
/usr/local/bin/backup.sh
cat /var/log/backup.logAñádelo al crontab:
0 2 * * * /usr/local/bin/backup.sh
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.shError 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/userError 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 crondSi aparece como inactivo,actívalo:
systemctl enable --now cron # Debian/Ubuntu
systemctl enable --now crond # RHEL/CentOSPara 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
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:
- El demonio cron no está activo →
systemctl status cron - Rutas relativas en el comando → usa siempre rutas absolutas
- El script no tiene permisos de ejecución →
chmod +x /ruta/script.sh - Hay un
%sin escapar → escríbelo como\%en crontab - Variables de entorno → cron no carga tu
.bashrcni 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.

