Copias de seguridad con rsync: guía práctica

Rsync sirve para copias de seguridad cuando necesita sincronizar servidores sin mover todo el árbol cada vez. Rinde mejor con SSH, simulacros, exclusiones claras y restauraciones ensayadas; no sustituye a snapshots ni a una retención seria, pero ahorra tráfico y reduce errores operativos.

Cuándo tiene sentido usar rsync

Rsync encaja cuando controla ambos extremos: un servidor de producción y otro destino con acceso por SSH. Sirve para directorios de aplicaciones, contenido subido por usuarios, repositorios internos, volcados ya generados y copias frías de configuración.

No es una varita mágica. No protege contra corrupción silenciosa si replica el archivo roto al destino. Tampoco arregla bases de datos activas sin una exportación coherente. Para MySQL, PostgreSQL o sistemas con mucha escritura, primero genere un volcado o una instantánea consistente.

En España y Latinoamérica suele aparecer en escenarios mixtos: un dedicado europeo para producción y un destino más cercano al equipo o a los clientes. En HostScout verá proveedores como IONOS, Kamatera, Donweb y OVHcloud con presencia útil para separar producción y respaldo.

La regla: sincronizar no es archivar

Rsync copia cambios. Si usa borrado en destino, también puede borrar la única copia buena. Por eso conviene separar tres piezas: sincronización, retención y prueba de restauración.

Una sincronización diaria sin historial sirve para levantarse de la caída de un servidor. No sirve igual contra un borrado humano detectado tarde. Para ese caso necesita snapshots, rotación de directorios o un sistema de copias con versiones.

Patrón básico con SSH

Para una primera pasada, use rsync de forma explícita y visible. El modo archivo conserva permisos, marcas de tiempo y enlaces simbólicos. La compresión ayuda en enlaces lentos; en redes rápidas puede sobrar, y conviene preguntar por el tráfico antes de darlo por gratis.

• Active primero una simulación para ver qué archivos cambiarían antes de escribir en el destino.
• Mantenga la barra final en el origen cuando quiera copiar el contenido del directorio.
• Quite la simulación solo cuando la lista de cambios sea la esperada.
• Añada borrado en destino únicamente si busca un espejo exacto y ha revisado exclusiones.

La barra final en el origen importa: copia el contenido del directorio, no el directorio como carpeta superior. Ese detalle parece menor hasta que una restauración deja la ruta duplicada y la aplicación no arranca.

El borrado debe ser una decisión, no una costumbre heredada de cualquier tutorial. Si necesita espejo exacto, revise primero qué desaparecerá del destino.

Exclusiones que evitan copias inútiles

El origen no debería mandar cachés, sesiones temporales ni artefactos que la aplicación pueda regenerar. En WordPress, por ejemplo, los uploads importan más que la caché. En una aplicación propia, separe datos de usuario, configuración y dependencias instalables.

Trate las exclusiones como una lista corta y documentada: caché, temporales, dependencias reconstruibles y salidas de compilación. Evite patrones globales que puedan tragarse adjuntos o datos subidos por usuarios.

Revise las exclusiones con restauración, no solo mirando la transferencia. Un patrón demasiado amplio puede dejar fuera adjuntos, claves o plantillas que solo se echan en falta cuando el reloj ya corre.

Elegir el destino de respaldo

El destino no tiene que ser más potente que producción. Tiene que estar separado, ser accesible en una emergencia y permitir restaurar con permisos correctos. En copias de seguridad, el disco manda más de lo que parece.

Para proyectos con usuarios en España, IONOS o OVHcloud pueden encajar por cercanía europea. Para equipos distribuidos entre España y América, Kamatera, DigitalOcean o Hostinger permiten pensar en regiones distintas.

Hetzner suele entrar en conversaciones de coste y capacidad para servidores Linux. Donweb tiene sentido cuando la operación y el soporte comercial se miran desde Argentina. La decisión no debería ser el precio aislado, sino el tiempo real de recuperación.

Evite poner producción y copia en el mismo panel sin aislamiento claro. Si una credencial comprometida permite borrar ambos lados, el respaldo existe solo en el papel.

Automatización sin confianza ciega

Automatizar rsync con cron o systemd está bien, pero el trabajo debe dejar rastro. Registre salida, errores y duración. Haga que el fallo sea visible antes de que lo descubra un cliente.

Use una clave SSH dedicada al respaldo. Limite su alcance en el destino cuando sea posible. Si el servidor de producción cae, no querrá descubrir que la copia dependía de una sesión interactiva, una contraseña olvidada o una ruta montada a mano.

Cuándo evitar rsync como solución principal

No use rsync como único respaldo si necesita historial fino, bloqueo de escritura, cifrado gestionado o restauración por punto temporal. En esos casos, combínelo con snapshots del proveedor, almacenamiento de objetos o herramientas de copia con versiones.

También conviene evitarlo como espejo entre sistemas vivos con millones de ficheros pequeños si no ha medido el coste de escaneo. Rsync transfiere cambios de forma eficiente, pero antes tiene que comparar el árbol. En algunos proyectos, esa comparación ya es el cuello de botella.

Método de revisión de datos

HostScout contrasta proveedores, ubicaciones y familias de planes con datos estructurados del catálogo y revisión editorial. Para este artículo no usamos precios públicos en el cuerpo porque las copias de seguridad dependen más de ubicación, aislamiento y restauración que de una cifra suelta.

La recomendación práctica es simple: elija proveedor por separación operativa, acceso de emergencia y claridad de soporte. El coste importa, pero una copia barata que no puede restaurar a tiempo sale cara. Migrar también cuesta, sobre todo cuando se improvisa.