Visión General del Proyecto

En este ejercicio construimos un sistema completo de respaldo automático usando herramientas nativas de systemd, sin depender de cron ni software externo. El resultado es un servicio robusto con reinicios automáticos, logging centralizado y ejecución programada.

Objetivos

Crear un script de respaldo automático que comprime /home con nombre basado en fecha.
Convertirlo en un servicio systemd controlado y monitoreable.
Configurar logs centralizados y reinicios automáticos ante fallos.
Programar ejecución diaria automática con un timer systemd.

Flujo completo

paso 1

respaldo.sh

Script bash con logs

paso 2

.service

Unidad systemd

paso 3

daemon-reload

Activar y probar

paso 4

.timer

Programar diario

paso 5

journalctl

Verificar logs

1. Preparar el Script de Respaldo

Creamos el script en /usr/local/bin/ — una ubicación estándar para ejecutables del administrador, que está en el PATH del sistema.

CREAR el archivo

bash

sudo nano /usr/local/bin/respaldo.sh

CONTENIDO del script

bash — /usr/local/bin/respaldo.sh

#!/bin/bash
# Script simple de respaldo

FECHA=$(date +%Y-%m-%d_%H-%M-%S)
ORIGEN="/home"
DESTINO="/var/backups/home_$FECHA.tar.gz"

echo "[$(date)] Iniciando respaldo de $ORIGEN a $DESTINO" >> /var/log/respaldo.log

tar -czf $DESTINO $ORIGEN 2>> /var/log/respaldo.log

if [ $? -eq 0 ]; then
    echo "[$(date)] Respaldo completado con éxito." >> /var/log/respaldo.log
else
    echo "[$(date)] Error durante el respaldo."   >> /var/log/respaldo.log
fi

DAR permisos de ejecución

bash

sudo chmod +x /usr/local/bin/respaldo.sh

💡 ¿Qué hace el script? Genera un nombre de archivo con la fecha y hora exacta, comprime /home con tar, y registra cada paso (inicio, éxito o error) en /var/log/respaldo.log. El código de salida $? permite detectar si tar falló.

2. Crear la Unidad Systemd

Un archivo .service le indica a systemd cómo ejecutar, supervisar y reiniciar nuestro script. Se ubica en /etc/systemd/system/ para que tenga prioridad sobre archivos de paquetes.

CREAR el archivo de unidad

bash

sudo nano /etc/systemd/system/respaldo.service

CONTENIDO del archivo .service

ini — /etc/systemd/system/respaldo.service

[Unit]
Description=Servicio de respaldo automático
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/respaldo.sh
Restart=on-failure
RestartSec=30
StandardOutput=append:/var/log/respaldo.log
StandardError=append:/var/log/respaldo.log

[Install]
WantedBy=multi-user.target

Explicación de las directivas

Directiva	Valor	Descripción
Description	texto	Nombre descriptivo que aparece en `systemctl status`.
After	network.target	Garantiza que la red esté disponible antes de iniciar el servicio. Útil para respaldos remotos en el futuro.
Type	simple	El proceso principal es el indicado en `ExecStart`. Systemd lo considera activo mientras esté corriendo.
ExecStart	ruta	Comando que systemd ejecuta al iniciar el servicio. Debe ser una ruta absoluta.
Restart	on-failure	Reinicia el servicio automáticamente si termina con código de error. No reinicia si termina con éxito.
RestartSec	30	Espera 30 segundos antes de intentar reiniciar tras un fallo.
StandardOutput/Error	append:ruta	Redirige la salida estándar y errores al archivo de log especificado, sin sobreescribirlo (`append`).
WantedBy	multi-user.target	El servicio se activa cuando el sistema alcanza el modo multiusuario (arranque normal sin interfaz gráfica).

3. Recargar Systemd y Probar

Tras crear cualquier archivo .service nuevo, systemd necesita recargar su configuración para reconocerlo.

RECARGAR la configuración de systemd

bash

sudo systemctl daemon-reload

INICIAR el servicio

bash

sudo systemctl start respaldo.service

VERIFICAR el estado

bash

sudo systemctl status respaldo.service

Captura — systemctl status respaldo.service

Salida de systemctl status respaldo.service

HABILITAR en el arranque

bash

sudo systemctl enable respaldo.service

Captura — systemctl enable respaldo.service

Salida de systemctl enable respaldo.service

⚠️ daemon-reload es obligatorio: Si creas o modificas un archivo .service y no ejecutas daemon-reload, systemd seguirá usando la versión anterior en memoria. Siempre recarga antes de start o restart.

4. Automatizar con un Timer

En lugar de arrancar el servicio manualmente, podemos usar un timer systemd — el equivalente moderno a cron, pero integrado y controlable con systemctl.

CREAR el archivo de timer

bash

sudo nano /etc/systemd/system/respaldo.timer

CONTENIDO del archivo .timer

ini — /etc/systemd/system/respaldo.timer

[Unit]
Description=Ejecutar respaldo automáticamente cada día

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Directivas del timer

Directiva	Valor	Descripción
OnCalendar	daily	Activa el servicio una vez al día (a medianoche). Acepta otros valores: `hourly`, `weekly`, `Mon --* 02:00:00`, etc.
Persistent	true	Si el sistema estaba apagado cuando debía ejecutarse, al arrancar el timer ejecutará el servicio inmediatamente para compensar la ejecución perdida.
WantedBy	timers.target	El timer se activa cuando el sistema llega al objetivo de timers (durante el arranque normal).

ACTIVAR el timer (enable + start a la vez)

bash

sudo systemctl daemon-reload
sudo systemctl enable --now respaldo.timer

COMPROBAR los timers activos del sistema

bash

systemctl list-timers

Salida típica

NEXT                         LEFT     LAST                         PASSED   UNIT               ACTIVATES
Wed 2025-01-15 00:00:00 CET  8h left  Tue 2025-01-14 00:00:01 CET  15h ago  respaldo.timer     respaldo.service
...

🔍 Timer vs Cron: Los timers systemd tienen varias ventajas sobre cron: se pueden monitorear con systemctl y journalctl, respetan Persistent=true para ejecuciones perdidas, heredan toda la gestión de logs de systemd, y pueden depender de otros targets o servicios del sistema.

5. Verificación de Logs

Toda la actividad del servicio queda registrada en dos lugares: el journal de systemd y el archivo de log propio.

Via journalctl

bash — Ver todos los logs del servicio

journalctl -u respaldo.service

bash — Seguir los logs en tiempo real

journalctl -u respaldo.service -f

bash — Logs de las últimas 2 horas

journalctl -u respaldo.service --since "2 hours ago"

Via archivo de log propio

bash — Seguir el archivo en tiempo real

tail -f /var/log/respaldo.log

Ejemplo de contenido del log

[Wed Jan 15 00:00:01 2025] Iniciando respaldo de /home a /var/backups/home_2025-01-15_00-00-01.tar.gz
[Wed Jan 15 00:00:04 2025] Respaldo completado con éxito.
[Thu Jan 16 00:00:01 2025] Iniciando respaldo de /home a /var/backups/home_2025-01-16_00-00-01.tar.gz
[Thu Jan 16 00:00:05 2025] Respaldo completado con éxito.

💡 Verificar los archivos generados:
ls -lh /var/backups/home_*.tar.gz — para listar todos los respaldos creados y sus tamaños.

En Resumen — Qué Hemos Logrado

Con todo lo implementado, hemos construido un sistema completo de respaldo automático bajo systemd con varias ventajas clave:

1️⃣

Script de respaldo funcional

Comprime /home con nombre basado en fecha y registra cada paso en /var/log/respaldo.log (inicio, éxito y errores).

2️⃣

Servicio systemd controlado

respaldo.service con reinicios automáticos (on-failure), logging centralizado y arranque después de la red.

3️⃣

Habilitación en arranque

Con systemctl enable, el servicio se ejecuta automáticamente cada vez que se inicia el sistema, sin intervención manual.

4️⃣

Timer diario automático

respaldo.timer con Persistent=true: si el sistema estaba apagado, ejecuta el respaldo pendiente al arrancar.

5️⃣

Logs y verificación completa

Toda la actividad accesible desde journalctl -u respaldo.service y desde /var/log/respaldo.log. Permite revisar errores, confirmar ejecuciones y auditar el historial completo de respaldos.

Conclusión

Con todo esto, hemos conseguido una solución completa y moderna de respaldo automático, integrada nativamente en Linux sin depender de herramientas externas.

Un respaldo automático y confiable de /home, con nombre basado en fecha y hora.
Servicio controlado por systemd, con reinicios automáticos si falla y tiempo de espera configurable.
Automatización diaria con respaldo.timer y Persistent=true para no perder ejecuciones.
Registro centralizado de logs, fácil de auditar tanto desde journalctl como desde el archivo de log propio.
Integración completa en Linux moderno, usando únicamente herramientas de systemd, sin depender de cron.