Llevo años peleándome con las copias de seguridad locales y las sincronizaciones en mis equipos. Seguro que quieres que ciertos directorios se sincronicen nada más encender el equipo.
Muchos recurren por inercia a crontab con la directiva @reboot, pero si tu script depende de la red o de un disco externo, falla el 90% de las veces. Hoy te explico cómo montar una sincronización automática con rsync usando systemd para que sea robusta, ligera y se ejecute solo cuando el sistema esté realmente listo.
Guía para configurar la ejecución automática del script de sincronización rsync_arranque.sh durante el arranque del sistema mediante systemd.
El problema de @reboot en crontab es que es "ciego". El script requiere conectividad de red local y acceso SSH. Si se utiliza @reboot, el script intentará ejecutarse antes de que la interfaz de red haya obtenido una dirección IP (vía DHCP) o antes de que el disco esté montado, provocando un fallo silencioso o un error de conexión, no sincronizando los directorios.
systemd, en cambio, permite definir dependencias explícitas para esperar a que la red esté completamente disponible antes de lanzar la sincronización. Cero dolores de cabeza, cero scripts con sleep 30 al principio para "darle tiempo a la red".
sudo.ssh-agent, para que el proceso no se quede colgado pidiendo interacción)./nube/scripts/rsync_arranque/rsync_arranque.sh.Asegúrate de que el script tenga permisos de ejecución asignados:
chmod +x /nube/scripts/rsync_arranque/rsync_arranque.sh
Vamos a crear el archivo de unidad (unit file) que le dirá a systemd cómo y cuándo ejecutar nuestro script. Abre tu editor favorito (yo siempre tiro de nano o vim) con permisos de superusuario:
sudo nano /etc/systemd/system/rsync-arranque.service
Pega la siguiente configuración. Ojo: recuerda cambiar tu_usuario por el nombre de tu usuario real en el sistema.
[Unit]
Description=Sincronizacion Rsync al arranque
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
ExecStart=/nube/scripts/rsync_arranque/rsync_arranque.sh
User=tu_usuario
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
Una vez guardado el archivo, aplicamos los cambios en el gestor de inicio, lo habilitamos para que arranque siempre y lo lanzamos manualmente una vez para comprobar que no hay errores de sintaxis en nuestro script:
# Recargar los demonios de systemd
sudo systemctl daemon-reload
# Habilitar el servicio para el arranque
sudo systemctl enable rsync-arranque.service
# Ejecutarlo ahora mismo para probar (sin necesidad de reiniciar)
sudo systemctl start rsync-arranque.service
Si quieres verificar que todo ha ido como la seda, revisa los logs con:
journalctl -u rsync-arranque.service -e
No vamos a extendernos en teoría innecesaria, pero es vital que entiendas estas cuatro líneas para que puedas adaptarlas a futuros proyectos:
After=network-online.target y Wants=network-online.target: Aquí está la magia. No solo le decimos que se ejecute después de la red, sino que exigimos (Wants) que el objetivo de "red online" se alcance. Esto espera a que la IP esté asignada y haya conectividad real, no solo a que la interfaz de red "suba".sudo systemctl enable NetworkManager-wait-online.service o systemd-networkd-wait-online.service), de lo contrario network-online.target no esperará correctamente.Type=oneshot: Le indica a systemd que este servicio ejecuta un comando, termina y no se queda residente en memoria como un demonio. Es perfecto para tareas de mantenimiento o scripts de bash.User=tu_usuario: Crucial. Si lo omites, el script correrá como root. Al usar root, rsync buscará las claves SSH en /root/.ssh/ en lugar de en tu /home/usuario/.ssh/, y la conexión al servidor remoto será rechazada.StandardOutput=journal: Redirige la salida estándar y los errores al diario del sistema. Imprescindible para depurar si el servidor remoto cambia su huella SSH o si hay un error de permisos en la carpeta de destino.Llevo usando esta configuración en mi servidor de backups y la fiabilidad es del 100%. El consumo de recursos en reposo es literalmente nulo (al ser un servicio oneshot, no consume RAM una vez termina la sincronización) y te ahorra tener que instalar herramientas de terceros pesadas o agentes de sincronización en la nube como puede ser syncthing, etc... que escanean tus archivos.
Es una solución nativa, ligera, automatizable y que respeta al máximo la filosofía de "hazlo una vez, en texto plano, y olvídame". Si buscas independencia digital y control total sobre tus datos, integrar tus scripts de bash con systemd es un paso obligatorio.
Publicado el sábado, 26 de septiembre de 2026
Powered by wdblog
Este obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial-CompartirIgual 4.0 Internacional.