floure.ARCHIVO / Tecnologías de la información
← Volver a la colección2 MIN DE LECTURA

Tecnologías de la información

Respaldo automático con Cron

Sistemas Operativos / Linux

Automatizar un guardado exige comprobar también los fallos. El éxito del cron o de la unidad debe significar que el contenido se escribió donde corresponde, no solo que el proceso terminó haciendo ruido.

Esto salió de probar iptables. La idea es guardar las reglas de forma periódica. Ojo: guardar una configuración no crea por sí solo un historial de respaldos ni la restaura al arrancar. (¬_¬)

Script automatización para guardar iptables y cronjob

El script guarda primero en un archivo temporal y lo mueve al destino solo si la exportación terminó bien. Así evita sobrescribir las reglas guardadas con una exportación fallida.

#!/bin/bash
set -euo pipefail
PATH=/usr/sbin:/usr/bin:/sbin:/bin
umask 077

DIR="/etc/iptables"
ARCHIVO="$DIR/rules.v4"
install -d -m 700 "$DIR"
TEMPORAL=$(mktemp "$DIR/.rules.v4.XXXXXX")
trap 'rm -f -- "$TEMPORAL"' EXIT
iptables-save > "$TEMPORAL"
mv -f -- "$TEMPORAL" "$ARCHIVO"
printf 'Reglas guardadas en %s\n' "$ARCHIVO"

Está pensado para ejecutarse como root. El script y sus directorios deben ser propiedad de root y no permitir escritura a usuarios sin privilegios. Una ubicación apropiada para este ejemplo es /usr/local/sbin/guardar_reglas.sh, con modo 700; no dejar un script editable por un usuario dentro de un cron de root.

En sudo crontab -e:

0 0 * * * /usr/local/sbin/guardar_reglas.sh

Se programa cada día a las 00:00 según la zona horaria del daemon. Si queremos retener versiones anteriores, hace falta una política de nombres, rotación y restauración aparte.

Servicio que ejecuta un comando

Esta alternativa ejecuta el guardado al iniciar una unidad; no implementa guardado al apagar, reiniciar o suspender.

Archivo /etc/systemd/system/guardar_reglas.service:

[Unit]
Description=Guardar configuración actual de iptables

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/guardar_reglas.sh

[Install]
WantedBy=multi-user.target

Al habilitarla, se incorpora al arranque de multi-user.target. No hace falta habilitar cron y esta unidad a la vez si solo queremos un mecanismo. Antes de instalarla hay que decidir si guardar el estado que exista al arrancar tiene sentido en nuestra política de firewall.

Dudas

¿Iniciar el servicio ejecuta el script? Sí: ExecStart se ejecuta cuando se inicia la unidad. Type=oneshot hace que systemd espere a que termine; no significa «solo una vez en toda la vida del equipo».

¿Qué hacía Before=? Definía orden cuando las unidades estaban en la misma transacción; por sí solo no las activaba. WantedBy= sirve para crear dependencias al habilitar la unidad, no para separar mágicamente el servicio de su script.

¿Cómo comprobar el guardado? Verificar el archivo exportado, sus permisos y el comportamiento ante un fallo del comando. Probar también la programación y la restauración en un entorno aislado.

Referencias: systemd.unit, systemd.service y Bash: manual distribuido por Debian.

+----------------------------------------+
| Floure &                               |
| Tachibana's guild                      |
| [Hikari · Nozomi · Vesper]             |
| SEAL: sha256/12: 152907bd13a9          |
| STATUS: LITURGY_IN_PROGRESS            |
+----------------------------------------+

Conexiones

Abrir red completa ↗
✳

Fin del apunte

Seguir explorando ↗