Estrategia de backups para WordPress: la regla 3-2-1 aplicada

Por PathSentinel · Jesús Macías Rubiales — Investigación de seguridad web

Un plan de recuperación empieza mucho antes del incidente. Si gestionas una web crítica, las copias de seguridad WordPress son la última línea entre un susto de una hora y una pérdida de datos irreversible. En esta guía, parte de nuestro pilar sobre seguridad y hardening de WordPress, aplicamos la regla 3-2-1 de forma concreta: qué respaldar, con qué frecuencia, dónde guardarlo y —lo que casi nadie hace— cómo verificar que la restauración funciona.

En PathSentinel vemos a diario la diferencia entre quien tiene backups y quien tiene backups probados. Trabajamos con pymes y e-commerce, pero también con entornos exigentes como banca o tiendas que manejan datos de tarjeta, donde una restauración incompleta no es una molestia: es un incidente reportable.

Qué es la regla 3-2-1 y por qué protege tus copias de seguridad WordPress

La regla 3-2-1 es un estándar de la industria del backup, sencillo de recordar y difícil de discutir. Se resume en tres números:

• 3 copias de tus datos: la de producción más dos respaldos independientes.
• 2 soportes distintos: por ejemplo, el disco del servidor y un almacenamiento de objetos externo. No sirve tener las tres copias en la misma máquina.
• 1 copia fuera del sitio (offsite): en otra región o proveedor, idealmente inmutable, para que un ransomware o un borrado accidental no se lleve todo por delante.

El fallo más común no es no tener copias, sino tenerlas todas en el mismo hosting. Cuando un atacante consigue acceso, borra la web y también el snapshot que vivía en el mismo panel. La copia offsite es lo que convierte un desastre en una tarde incómoda.

Qué respaldar exactamente en WordPress

Un WordPress no es un único bloque. Una copia útil incluye dos piezas que caducan a ritmos distintos:

• Base de datos MySQL/MariaDB: entradas, páginas, comentarios, pedidos de WooCommerce, usuarios y opciones. Cambia constantemente, sobre todo en tiendas.
• Ficheros: el directorio wp-content (uploads, temas, plugins), wp-config.php y cualquier fichero fuera de raíz. Los uploads pesan; el core de WordPress se puede reinstalar limpio.

Separar ambas cosas te permite ajustar la frecuencia: la base de datos merece respaldo horario en un e-commerce activo, mientras que los ficheros pueden ir a diario o tras cada despliegue.

Frecuencia según el valor de los datos

No todas las webs necesitan lo mismo. La pregunta clave es tu RPO (Recovery Point Objective): ¿cuántos datos puedes permitirte perder? Una web corporativa que cambia una vez al mes tolera un backup diario. Una tienda que factura cada hora no puede perder ocho horas de pedidos.

• Blog o web informativa: base de datos y ficheros a diario, retención de 30 días.
• E-commerce con tráfico: base de datos horaria o continua (binlogs), ficheros diarios, retención de 30-90 días.
• Antes de cada actualización: siempre un punto de restauración justo antes de tocar el core, temas o plugins. Es tu red bajo la cuerda floja: lo desarrollamos en actualizaciones seguras: staging, rollback y por qué no desactivarlas.

Cifrado, inmutabilidad y control de acceso

Una copia de seguridad es una réplica completa de tus datos, incluidos los personales de tus clientes. Trátala con el mismo cuidado que la producción:

• Cifra en reposo y en tránsito. Un backup sin cifrar en un bucket mal configurado es una filtración esperando a ocurrir.
• Usa almacenamiento inmutable o versionado (object lock). Si el atacante no puede sobrescribir ni borrar los respaldos, el ransomware pierde su mejor jugada.
• Aísla las credenciales. La cuenta que escribe backups no debería poder borrarlos, y el WordPress comprometido no debería tener las llaves del almacén offsite.

La prueba que casi nadie hace: restaurar

Aquí está el corazón del asunto. Un backup que nunca has restaurado no es un backup: es una suposición. Los fallos silenciosos son habituales —dumps de base de datos truncados, uploads incompletos, versiones de PHP incompatibles— y solo se descubren en el peor momento.

Programa una restauración de prueba periódica en un entorno de staging aislado: levanta la copia, comprueba que la web arranca, que los pedidos están, que las imágenes cargan y que el login funciona. Mide también tu RTO (cuánto tardas en volver a estar en pie). Si no sabes tu RTO, no tienes un plan de recuperación; tienes un deseo.

La documentación oficial de Hardening WordPress de WordPress.org insiste en los backups como base del endurecimiento, y el Learning Center de Wordfence documenta cómo muchas infecciones se resuelven precisamente restaurando desde una copia limpia previa al compromiso. Cuando una vulnerabilidad concreta entra en juego, contrastarla en el NVD del NIST te ayuda a saber a qué versión conviene volver.

Automatiza, pero no dispares y olvides

Automatizar el backup es imprescindible; automatizar la vigilancia del backup lo es más. Configura alertas cuando un respaldo falle o pese menos de lo esperado, y revisa el registro de restauraciones de prueba. En agencias con muchas webs esto se vuelve un problema de escala que abordamos en gestión de parches para agencias: la misma disciplina de flota aplica a las copias.

La regla 3-2-1 no es burocracia: es la diferencia entre explicar a tu cliente que ya está resuelto o que has perdido su negocio. Empieza hoy por lo básico —tres copias, dos soportes, una fuera— y prueba una restauración esta misma semana.