Un backup con rsync suele fallar por un detalle tonto: se copian los archivos visibles, pero se olvidan carpetas críticas, exclusiones mal planteadas o permisos que luego impiden restaurar WordPress con normalidad. Cuando llega una actualización problemática, una infección o un borrado accidental, el problema no es solo tener copia, sino poder recuperar el sitio sin sorpresas ni huecos.
Un backup a nivel de archivo con rsync copia solo los cambios entre ejecuciones, ahorrando tiempo y espacio. Bien configurado, permite automatizar copias incrementales de WordPress o carpetas críticas, restaurarlas con precisión y verificar que no falte nada. La clave está en elegir bien el origen, el destino, las exclusiones y la política de rotación.
Resumen del proceso
- Define qué carpetas quieres guardar y cuáles conviene excluir.
- Prepara un destino local o remoto con permisos correctos.
- Lanza la primera copia completa con rsync y revisa el resultado.
- Automatiza la copia con cron y guarda logs.
- Crea una rotación para no sobrescribir siempre la misma copia.
- Prueba una restauración en una carpeta vacía antes de confiar en ella.
| Herramienta |
Copia incremental |
Uso remoto |
Cuándo encaja |
| rsync |
Sí |
Sí, con SSH |
Copias repetidas, control de cambios y restauración fina |
| cp |
No |
No |
Copias rápidas locales sin historial |
| scp |
No |
Sí |
Envíos simples por SSH, sin control fino de diferencias |
Qué protege en WordPress y qué no
Un backup con rsync protege bien los archivos que cambian de verdad. En WordPress, eso suele ser wp-content, temas hijos, plugins personalizados, subidas y archivos de configuración, si sabes exactamente cuáles guardas.
Lo que no protege por sí solo es la historia de cambios. Si sincronizas una carpeta espejo con --delete, lo que borres en origen desaparece también en destino. Eso funciona como un espejo, no como una caja fuerte.
Archivos que sí conviene incluir
Guarda la parte del sitio que no quieres rehacer a mano. En un WordPress típico, eso incluye wp-content/uploads, wp-content/themes si hay personalización, wp-content/plugins si hay plugins propios y cualquier carpeta con ficheros subidos por clientes.
Un caso habitual: una tienda online actualiza un plugin y rompe la plantilla. Si la copia incluye el tema hijo y los cambios propios, la vuelta atrás tarda minutos. Si solo se guardó una carpeta mal elegida, la restauración se complica mucho.
La mayoría de guías hablan de “hacer una copia”. Lo que no mencionan es que una copia útil depende de qué archivos puedan reconstruirse y cuáles no. En WordPress, eso marca la diferencia entre volver a publicar o pasar horas apagando fuegos.
Los archivos personalizados de un tema hijo suelen pesar poco y salvar muchas horas de trabajo. Si se pierden, tocará rehacer cambios uno a uno.
Lo que conviene excluir
Excluye cachés, logs, temporales y archivos que WordPress regenera solo. Es como no guardar los envoltorios si lo que importa es el contenido.
Suelen sobrar carpetas como cache, tmp, logs y archivos de sesión. También conviene revisar directorios creados por plugins de optimización o por sistemas de caché de servidor.
Según WordPress y Automattic, gran parte del contenido del sitio vive en wp-content y no en el núcleo del sistema. La documentación oficial de WordPress sobre copias de seguridad insiste en no confiar solo en una sincronización ciega.
Flujo real de una copia con rsync
Origen: WordPress
→
Exclusiones: cachés y logs
→
Destino: copia recuperable
→
Prueba de restauración
Cuándo usar rsync y cuándo cp o scp
rsync gana cuando el backup se repite y solo cambian algunos archivos. cp sirve para una copia simple local. scp encaja si quieres enviar algo por SSH sin más control.
La diferencia práctica se nota en sitios con muchas imágenes. Copiar otra vez miles de archivos idénticos con cp o scp es como volver a mover toda una mudanza por una chaqueta nueva.
Diferencias que sí se notan
rsync compara origen y destino, y manda solo lo que cambió. Eso reduce tiempo, ancho de banda y desgaste del servidor, sobre todo si la copia se repite cada noche.
Cp copia todo cada vez. Scp también manda el archivo entero, aunque solo haya cambiado una parte pequeña. En un alojamiento con sitio grande, esa diferencia se nota rápido.
Linus Torvalds creó Git pensando en cambios pequeños, no en copiarlo todo siempre. Rsync sigue una lógica parecida: solo mover lo que cambió. Esa idea encaja muy bien con WordPress, donde unas pocas imágenes nuevas no justifican rehacer toda la copia.
Matriz para elegir bien
| Escenario |
Mejor opción |
Motivo |
| Copia diaria de WordPress |
rsync |
Solo transfiere cambios y permite automatizar |
| Mover una carpeta una vez |
cp |
Es más simple y no exige sincronización |
| Enviar un archivo urgente por SSH |
scp |
Es rápido para un envío puntual |
Para copias repetidas de un mismo sitio, rsync suele ahorrar entre minutos y horas cada semana, según el tamaño del directorio y la cantidad de cambios.
Cómo construir un backup recuperable
Un backup recuperable no es solo una carpeta copiada. También guarda permisos, dueños de archivos y la ruta exacta, para que la restauración no deje el sitio roto por dentro.
La parte que más se olvida es esta: si el backup copia bien pero cambia permisos, WordPress puede fallar igual. La copia parece buena. El sitio, no.
Lanza la primera copia completa
Empieza con una copia local para comprobar que todo sale bien. Un comando útil, para una carpeta de WordPress completa, sería este:
rsync -a --info=progress2 /var/www/html/ /backups/wordpress/2026-06-23/
La opción -a conserva permisos, fechas y enlaces simbólicos. Eso ayuda mucho en restauración. El error típico aquí es olvidar la barra final de la ruta, porque cambia qué carpeta se copia y dónde acaba.
Si quieres ver más detalle, añade -v o registra la salida en un archivo. En servidores con muchos ficheros, este paso tarda entre 5 y 30 minutos, según tamaño y disco.
Añade exclusiones útiles
Las exclusiones se escriben en un archivo para no repetirlas a mano. Eso evita errores tontos, que aquí salen caros.
Ejemplo de archivo /etc/wordpress.exclude:
wp-content/cache/
wp-content/uploads/cache/
wp-content/debug.log
*.log
.tmp/
Luego lo usas así:
rsync -a --exclude-from=/etc/wordpress.exclude /var/www/html/ /backups/wordpress/2026-06-23/
La clave está en revisar cada ruta. Un patrón demasiado amplio puede dejar fuera imágenes o archivos de clientes sin que nadie lo note hasta la restauración.
Crea una copia remota por SSH
Para enviar la copia a otro servidor, rsync por SSH va muy bien. Es como meter una caja cerrada en un furgón con llave.
Ejemplo:
rsync -a -e ssh /var/www/html/ usuario@servidor:/backups/wordpress/2026-06-23/
Si el servidor remoto usa una clave SSH, la tarea nocturna no pedirá contraseña. Eso hace posible automatizarla con cron sin trucos raros.
Un ejemplo paso a paso ayuda a entender de verdad el backup a nivel de archivo con rsync. Imagina una instalación con /var/www/html/, donde solo quieres salvar wp-content/ y wp-config.php en un disco externo montado en /mnt/backups/. El proceso sería: primero crear la carpeta destino, después lanzar una copia con rsync -a --delete --exclude='wp-content/cache/' /var/www/html/ /mnt/backups/site/, y por último revisar que la estructura coincide. Si el sitio tiene muchas imágenes o cambios pequeños, este método funciona como una sincronización de archivos muy eficiente, porque solo manda lo que se modificó desde la última ejecución.
En la práctica, eso reduce tiempo, evita duplicados y deja una base clara para futuras copias incrementales.
Automatiza con cron, logs y rotación
Automatizar un backup con rsync evita el olvido humano, que sigue siendo la causa más común de copias perdidas. Una tarea bien montada corre sola, deja rastro y no machaca siempre la misma versión.
La mayoría de guías dicen “ponlo en cron”. Lo que no mencionan es que sin logs y sin rotación no sabes si lleva tres noches fallando o si está sobrescribiendo el único backup útil.
Usa cron para lanzar la copia
Una entrada mínima en crontab puede ser esta:
0 2 * * * /usr/local/bin/backup-wordpress.sh >> /var/log/backup-wordpress.log 2>&1
Esa línea ejecuta el script cada día a las 02:00. El error habitual es escribir mal la ruta del script o asumir que cron hereda el mismo entorno que la terminal. No lo hace.
Si el script usa rutas relativas, fallará. Por eso conviene trabajar siempre con rutas absolutas. En servidores con muchos procesos, ese detalle ahorra sustos.
Rota las copias con fecha
Una rotación simple usa una carpeta por día. Así no pisas la copia anterior y puedes volver atrás si la última salió mal.
Ejemplo de estructura:
/backups/wordpress/2026-06-21/
/backups/wordpress/2026-06-22/
/backups/wordpress/2026-06-23/
Otra opción es guardar siete copias diarias y una semanal. Esa política suele bastar para la mayoría de sitios pequeños y medianos, aunque depende del ritmo de cambios.
Una rotación corta, de 7 a 14 días, suele cubrir errores de actualización sin llenar el disco de copias viejas.
Guarda errores en un log claro
Un log útil debe dejar ver fecha, salida de rsync y código de error. Sin eso, revisar fallos se vuelve un paseo a ciegas.
Ejemplo de script:
set -e
FECHA=$(date +%F)
ORIGEN="/var/www/html/"
DESTINO="/backups/wordpress/$FECHA/"
LOG="/var/log/backup-wordpress.log"
mkdir -p "$DESTINO"
rsync -a --delete --exclude-from=/etc/wordpress.exclude "$ORIGEN" "$DESTINO" >> "$LOG" 2>&1
El error más frecuente en este punto es usar --delete sin entender que borra en destino lo que ya no existe en origen. Sirve para espejar, no para conservar versiones anteriores.
Para que la automatización con cron sea fiable, no basta con lanzar la copia: también hay que registrar logs de copia y definir una retención de backups. Un enfoque habitual es guardar una copia diaria con fecha, mantener siete versiones diarias y una semanal durante un mes, y borrar automáticamente las más antiguas con un script sencillo. Por ejemplo, un cron nocturno puede ejecutar backup-wordpress.sh, escribir la salida en /var/log/backup-wordpress.log y, al final, eliminar backups con más de 30 días.
Así la rotación de copias no depende de una limpieza manual y el historial sigue siendo útil si un fallo se detecta varios días después.
Restaurar sin perder versiones anteriores
Restaurar un backup con rsync consiste en devolver los archivos a una ruta limpia, revisar permisos y comprobar que el contenido coincide con lo esperado. Si se hace directo sobre producción, el margen de error se vuelve pequeño.
Un caso habitual: un plugin rompe la web tras actualizarse. Si se restaura primero en una carpeta temporal, el problema se ve antes de tocar la web en vivo. Esa prueba tarda poco y evita un susto grande.
Restaura en una carpeta temporal
La forma segura es restaurar en otra ruta, no encima del sitio activo. Así puedes revisar sin prisas.
Ejemplo:
rsync -a /backups/wordpress/2026-06-23/ /var/www/html-restauracion/
Primero comprueba que la estructura coincide. Luego revisa archivos clave, como wp-config.php, subidas recientes y el tema hijo. Si falta algo, todavía estás a tiempo de corregirlo.
Comprueba permisos y dueño
La restauración no termina al copiar archivos. También hay que ajustar permisos y dueño, porque un archivo con dueño equivocado puede bloquear la web.
Ejemplo típico en muchos servidores Linux:
chown -R www-data:www-data /var/www/html-restauracion/
find /var/www/html-restauracion/ -type d -exec chmod 755 {} /;
find /var/www/html-restauracion/ -type f -exec chmod 644 {} /;
Esto funciona bien en teoría, pero en la práctica depende del usuario real del servidor web. En Plesk o cPanel, ese usuario puede cambiar según la configuración del hosting.
Si el dueño de archivos no coincide con el del servidor web, el sitio puede mostrar errores aunque la copia sea perfecta.
Verifica integridad con pruebas reales
La verificación útil no consiste en leer “ok” en pantalla. Consiste en comparar tamaños, fechas, permisos y, si se puede, restaurar una muestra completa.
El Consejo de la UE y la Agencia Española de Protección de Datos insisten en medidas técnicas y organizativas para proteger datos personales. La AEPD publica criterios claros sobre seguridad y conservación de datos, y eso encaja con un backup que puedas demostrar y restaurar.
Compara contenido y tamaños
Compara el origen y el destino con rsync en modo simulación. Eso no copia nada, solo enseña diferencias.
rsync -a --dry-run --itemize-changes /var/www/html/ /backups/wordpress/2026-06-23/
Si aparecen muchos cambios inesperados, algo va mal. Puede ser una exclusión demasiado amplia, una ruta mal escrita o un problema de permisos.
Usa hashes cuando el archivo importa
Para archivos muy sensibles, como configuraciones o exportaciones, calcula hash. Un hash es una huella digital del archivo.
Ejemplo:
sha256sum /var/www/html/wp-config.php
sha256sum /backups/wordpress/2026-06-23/wp-config.php
Si ambos valores coinciden, el archivo es igual. Si no coinciden, hay diferencia real. Esa prueba vale más que una suposición.
Casos límite en servidores WordPress
rsync no resuelve todo. Si los archivos cambian mientras se copian, si el disco está lleno o si el destino remoto corta conexión, la copia puede quedar a medias.
Un caso claro: una web con muchas subidas durante el día genera cambios mientras corre el backup nocturno. Si se copia sin cuidado, el resultado puede mezclar archivos viejos y nuevos. No siempre falla, pero conviene saberlo.
Archivos en uso o abiertos
Los archivos de WordPress suelen cambiar poco durante la noche, pero las subidas, logs o cachés pueden seguir escribiéndose. Si copias una carpeta muy activa, el archivo puede salir incompleto.
La solución práctica es reducir el conjunto copiado o hacer la copia en una franja con menos actividad. También ayuda excluir carpetas temporales y logs que se regeneran solas.
Destinos remotos y cortes
Si la copia va a otro servidor por SSH, un corte de red puede dejar una ejecución a medias. Rsync suele reanudar bien, pero solo si la siguiente ejecución encuentra el mismo destino y la misma ruta.
Por eso conviene guardar logs y no mezclar varios destinos con nombres distintos cada día. Si cambias la ruta sin criterio, pierdes continuidad y complicas la recuperación.
Este método no es la mejor opción si no tienes acceso a línea de comandos o si tu hosting bloquea SSH. En ese caso, herramientas como cPanel, Plesk o Acronis pueden encajar mejor.
Un backup con rsync funciona mejor cuando se combina con una copia de base de datos aparte. En WordPress, los archivos guardan la estructura; la base de datos guarda entradas, ajustes y pedidos.
Preguntas frecuentes
¿Rsync sirve para hacer backup de WordPress?
Sí, sirve muy bien para los archivos de WordPress. Copia solo los cambios y ahorra tiempo en sitios con muchas imágenes o temas personalizados.
¿Qué diferencia hay entre rsync y scp para
Rsync copia diferencias; scp copia el archivo entero. Para una copia diaria repetida, rsync suele gastar menos tiempo y ancho de banda.
¿Puedo usar rsync con cron sin contraseña?
Sí, si usas claves SSH y el usuario remoto tiene permisos correctos. Eso permite ejecutar la copia automática sin intervención manual.
¿Qué pasa si uso --delete?
Borra en destino los archivos que ya no existen en origen. Eso es útil para espejar, pero peligroso si quieres conservar versiones anteriores.
¿Cómo sé si el backup de rsync es recuperable?
Prueba una restauración en una carpeta vacía. Si el sitio arranca, los permisos son correctos y los archivos clave están, la copia va bien.
¿Hace falta copiar toda la carpeta wp-content?
No siempre. Conviene copiar subidas, temas hijos y plugins propios, y excluir cachés o logs que WordPress regenera.
¿Rsync sustituye a la copia de base de datos?
No. Rsync protege archivos; la base de datos guarda contenido, ajustes y pedidos. En WordPress, ambos backups se necesitan.
Qué dejar listo antes de confiar en la copia
El backup con rsync solo es fiable cuando existe una política clara de retención, una restauración probada y un log que muestre errores. Sin esas tres piezas, la copia puede parecer correcta y fallar justo el día malo.
WordPress, Matt Mullenweg y Automattic han empujado durante años la idea de un sistema flexible y basado en archivos. Esa flexibilidad ayuda, pero también exige disciplina. Si el sitio es serio, la copia debe serlo igual.
La combinación que mejor funciona en producción suele ser sencilla: rsync para archivos, backup aparte de base de datos, cron para automatizar y una prueba mensual de restauración. Es un plan sobrio. Y, por eso mismo, suele aguantar cuando llega el problema de verdad.
