Copias de seguridad de WordPress que sí se restauran

La configuración habitual de copias en WordPress falla justo cuando hace falta. Un plugin guarda un zip dentro de wp-content, en la misma cuenta de hosting que el sitio. Si un atacante, un ransomware o la suspensión de la cuenta se llevan el sitio, esa copia se va con él.

Una copia de seguridad solo vale algo si se puede restaurar. Esta guía explica qué incluir, dónde guardar las copias, con qué frecuencia hacerlas, cómo probar una restauración y cómo elegir un punto de restauración limpio después de un hackeo.

Qué debe incluir una copia de WordPress: archivos y base de datos

Un sitio WordPress tiene dos mitades y hacen falta ambas. La base de datos contiene entradas, páginas, usuarios y hashes de contraseñas, ajustes, pedidos de WooCommerce y envíos de formularios. Piense en un plugin de formularios de contacto que guarda los mensajes en la base de datos: con una copia solo de archivos se pierde cada consulta, y con una copia solo de la base de datos recupera los mensajes sin el plugin que los lea.

De los archivos necesita wp-content (subidas, plugins, temas), wp-config.php y .htaccess o la configuración de su servidor. El núcleo de WordPress se puede volver a descargar, pero solo si sabe qué versión usaba.

Desde la raíz de WordPress, con WP-CLI:

# Exportación de la base de datos, fuera de la raíz web
mkdir -p ~/backups
wp db export ~/backups/db-$(date +%F).sql

# Archivos: wp-content, wp-config.php y .htaccess (sin cachés ni carpetas de copias antiguas)
tar --exclude='wp-content/cache' \
    --exclude='wp-content/backups' \
    -czf ~/backups/files-$(date +%F).tar.gz \
    wp-content wp-config.php .htaccess

# Registrar versiones para reinstalar núcleo, plugins y temas desde fuentes oficiales
wp core version > ~/backups/versions-$(date +%F).txt
wp plugin list --fields=name,version,status >> ~/backups/versions-$(date +%F).txt
wp theme list --fields=name,version,status >> ~/backups/versions-$(date +%F).txt

Sustituya wp-content/backups por la carpeta que use su plugin de copias. En nginx no existe .htaccess: quítelo del comando y respalde en su lugar la configuración del servidor. Las copias dentro de copias hacen crecer cada archivo. Los comandos db de WP-CLI están documentados en WordPress.org.

La regla 3-2-1 y por qué una copia en su cuenta de hosting no cuenta

La regla es: tres copias de los datos, en dos tipos de almacenamiento distintos, con una copia fuera de las instalaciones. El sitio en producción cuenta como una copia. Una copia en la misma cuenta de hosting es la segunda, pero comparte el acceso, el servidor y el proveedor del sitio.

Quien pueda escribir en su sitio suele poder borrar esa copia. Un ransomware que cifra la raíz web cifra también el zip que está a su lado. Una cuenta suspendida o un fallo del host se llevan ambos a la vez. Las instantáneas del proveedor son útiles y rápidas de restaurar, pero siguen siendo una única copia que usted no controla.

La tercera copia es la que cuenta. Debe ir a un almacenamiento de otro proveedor, con credenciales independientes que no estén guardadas en el servidor web de forma que permitan borrar. Dos ajustes marcan una gran diferencia:

• Versionado o inmutabilidad. Muchos servicios de almacenamiento de objetos ofrecen versionado, bloqueo de objetos o bloqueo de retención en el propio proveedor. El versionado conserva copias anteriores, pero quien tenga permiso de borrado aún puede eliminarlas. Un bloqueo en su modo más estricto (compliance) impide a todos, incluido usted, borrar o sobrescribir una copia hasta que acabe el plazo.
• Credenciales de solo escritura para la tarea de copia. Si la clave del servidor solo puede subir archivos, y el versionado o un bloqueo conserva las copias anteriores, un atacante que la robe no podrá borrar ni sobrescribir su historial.

Con qué frecuencia copiar y cuánto tiempo conservar las copias

Fije la frecuencia según la rapidez con que cambian sus datos. A un sitio de presentación que se edita una vez al mes le basta una copia semanal. Una tienda que recibe pedidos a diario necesita copias de la base de datos como mínimo diarias, y a menudo más frecuentes. Los archivos suelen cambiar menos que la base de datos, así que pueden seguir un calendario aparte.

El plazo de conservación es un equilibrio. Las intrusiones se descubren con frecuencia semanas después de empezar. Si solo guarda siete días de copias, es posible que todas contengan ya la puerta trasera. Por otro lado, las copias antiguas mantienen vivos datos personales, incluidas cuentas cuya supresión pidieron los usuarios.

Defina un plazo de conservación y una rotación fijos, por ejemplo copias diarias durante unas semanas y copias mensuales durante un periodo limitado. Déjelo por escrito. Ese calendario documentado también ayuda con las solicitudes de supresión: los datos desaparecen de las copias cuando estas caducan, y hasta entonces usted se asegura de que no se restauren ni se utilicen. Reescribir los archivos por cada solicitud rara vez es viable; consulte la guía de su autoridad de control (en España, la AEPD) sobre copias de seguridad.

Las copias contienen datos personales: cifrado, acceso y contratos

Una copia de WordPress incluye cuentas de usuario, hashes de contraseñas, datos de clientes y de pedidos y envíos de formularios. Perderla es tan grave como perder la base de datos en producción.

• Cifre en tránsito y en reposo. El cifrado es una de las medidas que cita el art. 32(1)(a) del RGPD. Guarde la clave en un lugar distinto del almacenamiento que protege.
• Limite el acceso. Solo quienes restauran sitios deberían poder descargar copias. Elimine los enlaces de descarga compartidos antiguos y las cuentas de usuario caducadas en el almacenamiento.
• Firme contratos. Un proveedor de almacenamiento de copias, o una agencia que conserve copias, es un encargado del tratamiento según el art. 28 y necesita un contrato de encargo del tratamiento.

Una copia sin cifrar que se pierde o queda accesible públicamente puede constituir por sí misma una violación de la seguridad de los datos personales. Si ocurre, consulte la guía de notificación en 72 horas.

Pruebe una restauración antes de necesitarla

Restaure en un entorno de pruebas (staging) o en una copia local, nunca sobre el sitio en producción. Use la copia externa, no la local que le queda a mano, porque la externa es la que tendrá después de un incidente real.

# En una raíz web vacía de staging; WP_VERSION sale de su archivo de versiones
wp core download --version="$WP_VERSION" --skip-content
tar -xzf files-2026-10-23.tar.gz
# Edite wp-config.php: credenciales de la base de datos de staging, y después:
wp db import db-2026-10-23.sql
wp search-replace 'https://www.example.com' 'https://staging.example.com' --skip-columns=guid
wp option update blog_public 0

blog_public 0 solo pide a los buscadores que no lo indexen. Proteja además el staging con autenticación HTTP. Evite que envíe correos a clientes reales o llame a webhooks de pago, y valore define( 'DISABLE_WP_CRON', true ); mientras prueba.

Después, compruebe:

• El acceso de administrador funciona
• El envío de un formulario llega a su destino
• El pedido o la entrada más reciente está presente
• Las imágenes y las descargas cargan
• La lista de plugins y las versiones coinciden con su registro
• Ha anotado el tiempo total desde el inicio hasta tener el sitio funcionando

Ese tiempo es su tiempo real de recuperación, que suele ser mayor de lo que se supone. Anote la fecha, la copia utilizada, el resultado y los problemas encontrados. Una copia que nunca se ha restaurado no le demuestra nada a usted ni a quien le pregunte cómo cumple el art. 32(1)(c) y (d) o el deber de responsabilidad proactiva del art. 5(2).

Restaurar tras un hackeo: encuentre el último punto limpio

No restaure a ciegas la copia más reciente: probablemente contiene la puerta trasera. La más antigua puede estar limpia, pero le faltarán semanas de pedidos. Antes de cambiar nada, conserve una copia del estado infectado para poder investigar después.

A continuación, estime cuándo empezó el compromiso. Revise los registros del servidor y de acceso, las fechas de modificación de archivos, los usuarios administradores que no reconozca y los archivos que difieran de una copia anterior. Elija entonces una copia anterior a esa fecha. Una línea base de integridad de archivos ayuda aquí. El plugin Security Audit & Compliance registra una y señala los archivos modificados y los indicadores de compromiso, lo que acota cuándo cambiaron las cosas. No crea ni restaura copias de seguridad.

Un método más limpio que una restauración completa:

1. Reinstale el núcleo, los plugins y los temas desde fuentes oficiales, en versiones conocidas.
2. Tome del punto limpio solo las subidas y la base de datos. Compruebe que las subidas no contengan archivos PHP (cómo encontrar web shells en uploads).
3. Revise en la base de datos si hay administradores inyectados (wp user list --role=administrator) y contenido spam.
4. Vuelva a introducir o migre los pedidos y datos creados desde ese punto.

Una restauración no cierra la brecha. Antes de volver a publicar el sitio, actualice o elimine el componente vulnerable y cambie todas las contraseñas, claves y salts. Si no, volverán a atacarle por el mismo camino. El procedimiento completo está en nuestro plan de eliminación de malware, y verificar las sumas de comprobación del núcleo confirma que el núcleo está limpio.

Qué esperan el RGPD y NIS2 de sus copias de seguridad

El RGPD, en su art. 5(1)(f), exige una seguridad adecuada, que incluye la integridad y la confidencialidad. El art. 32(1)(c) pide la capacidad de restaurar la disponibilidad y el acceso a los datos personales de forma rápida tras un incidente, y la letra d) pide una verificación periódica de sus medidas. Perder datos de clientes sin posibilidad de recuperarlos puede considerarse una violación de la disponibilidad.

Para las entidades incluidas en el ámbito de la normativa nacional, la Directiva NIS2 cita en su art. 21(2)(c) la continuidad de las actividades, con la gestión de copias de seguridad y la recuperación en caso de catástrofe. Aunque NIS2 no le afecte, sus clientes sujetos a NIS2 pueden pedirle pruebas como proveedor o agencia. Nuestro resumen del artículo 32 del RGPD cubre el panorama completo.

Mantenga un registro de copias de una página: qué se copia, dónde, con qué frecuencia, el plazo de conservación, el cifrado, quién tiene acceso, y la fecha y el resultado de la última prueba de restauración. Su siguiente paso: programe esta semana esa primera prueba de restauración con la copia externa.

Preguntas frecuentes

¿Basta con la copia diaria de mi proveedor de hosting?

Normalmente no por sí sola. Es una única copia, guardada con el mismo proveedor y a menudo durante poco tiempo. Compruebe cuánto se conserva y añada una copia externa que usted controle.

¿Debo copiar el núcleo de WordPress?

No es necesario si registra las versiones del núcleo, los plugins y los temas. Reinstalar desde WordPress.org le da además archivos de núcleo de confianza.

¿Cómo gestiono una solicitud de supresión cuando los datos de la persona están en las copias?

Elimine los datos del sitio en producción y apóyese en el plazo de conservación documentado para las copias. Si alguna vez restaura, asegúrese de que los datos de esa persona no vuelvan al sitio en producción.

¿Con qué frecuencia debo probar una restauración?

Con regularidad, y siempre tras cambios importantes en el hosting, el sitio o la herramienta de copias. Elija un intervalo que realmente vaya a cumplir y registre cada prueba.

Este artículo es información general y no constituye asesoramiento jurídico.