Backups WordPress que no son backups (y cómo hacer uno real)

La regla 3-2-1, que casi nadie sigue

El estándar de oro es la regla 3-2-1:

• 3 copias de tus datos (la original + 2 backups)
• En al menos 2 medios distintos (disco local + cloud, por ejemplo)
• Con al menos 1 fuera del sitio (geográficamente separada)

La mayoría de webs WordPress típicas tienen UN backup, dentro del mismo servidor, hecho por un plugin que ni saben si funciona. Si ese servidor se cae, se cifra o se borra, no hay nada que rescatar.

Los 5 "backups" que no son backups

1. El backup que está en el mismo servidor

Plugins como UpdraftPlus o BackupBuddy por defecto guardan el ZIP en /wp-content/updraft/. Está en el mismo servidor que tu web. Si te entran ransomware, te cifran también el backup. Si el disco falla, lo pierdes todo. Si te hackean y borran archivos, también borran los backups.

Solución: el backup tiene que salir del servidor. S3, Backblaze B2, Google Drive, Dropbox, FTP de otro proveedor. Lo que sea, pero fuera.

2. El backup que no incluye la base de datos

Hay backups que sólo copian archivos (wp-content/ y el resto del filesystem). Pero el 90% del contenido de WordPress está en la base de datos: posts, páginas, comentarios, opciones, usuarios. Sin la DB, tienes un theme bonito sin nada que mostrar.

Solución: verifica que tu backup incluye SQL dump de todas las tablas, no solo el filesystem.

3. El backup que nunca has probado restaurar

Este es el más peligroso. Un backup que no has restaurado nunca no es un backup, es una esperanza. Causas comunes de backups "rotos" que parecían buenos:

• El ZIP está corrupto pero el plugin nunca verificó
• Falta una tabla MyISAM porque el dump dio timeout
• El backup incluye paths absolutos del servidor antiguo y no se puede mover a otro
• El plugin que hace los backups requiere la misma versión del plugin en el destino, y el plugin ya no existe / cambió de licencia
• El backup está cifrado con una clave que perdiste

Solución: al menos una vez al trimestre, baja un backup, móntalo en un staging (subdominio dev o local), comprueba que arranca. Si algo falla, te enteras antes del desastre, no durante.

4. El backup sin retención

Si tu backup se sobrescribe cada noche, y un atacante entra en tu WP el lunes pero tú no te das cuenta hasta el viernes, tus backups del martes, miércoles, jueves y viernes están todos comprometidos. Has perdido la versión limpia.

Algunos malware (especialmente backdoors persistentes) están diseñados para esperar 2-3 semanas dormidos antes de actuar. Para entonces, ningún backup reciente está limpio.

Solución: retención escalonada. Por ejemplo: 7 dailies + 4 weeklies + 12 monthlies. Si descubres la infección tarde, puedes ir hacia atrás hasta encontrar una copia antes del compromiso.

5. El backup que no incluye la config del servidor

WordPress no es sólo lo que hay en /var/www/. También están: las configuraciones de Apache/Nginx, el .htaccess, los crons del sistema, los certificados SSL, las cuentas de email, las cuentas FTP. Si el servidor entero se cae, restaurar sólo WP no te devuelve el correo de la empresa, ni los rewrites custom, ni las cuentas de los empleados.

Solución: usa backups a nivel Plesk subscription o servidor completo, no sólo WordPress. Plesk lo hace por defecto si lo activas (ver guía Plesk).

Cómo configurar un backup que SÍ funciona

Sin entrar en herramientas pago, esto es lo que recomendamos para una PYME con un único WP sobre Plesk:

Paso 1: Backup de Plesk subscription a almacenamiento externo

Configura un backup remoto diario en Plesk (a S3 / Wasabi / Backblaze / Google Drive). Esto te da:

• Copia completa de la subscription (filesystem + DB + config + mail + SSL)
• Fuera del servidor (cumple la "1" de la regla 3-2-1)
• Restauración con UN click desde el Backup Manager si pasa algo

Wasabi y Backblaze B2 cuestan ~5€/mes por 100 GB. Para una web típica con 5-10 GB es despreciable.

Paso 2: Backup adicional dentro de WordPress (DB-only + filesystem-only)

Como segundo paraguas, instala UpdraftPlus o BackWPup en WP y configúralo para:

• Backup de DB cada 12h, hacia un destino externo distinto del Plesk (por ejemplo: si Plesk usa Wasabi, WP que use Google Drive)
• Backup de wp-content/uploads/ cada 7 días (los uploads cambian poco)

El objetivo: si pierdes acceso a uno de los proveedores (cuenta suspendida, password olvidada, factura impagada), tienes otro.

Paso 3: Versionado del código con Git

Tu theme custom, tu plugin custom, tu functions.php con cambios — todo eso debería estar en Git (GitHub privado, GitLab, Bitbucket). No como sustituto del backup, pero sí como complemento: si pierdes los archivos, los reconstruyes desde el repo en 5 minutos.

Paso 4: Test de restauración trimestral (lo más importante)

Marca en el calendario: cada 3 meses, dedica 30 minutos a:

1. Baja un backup completo de Plesk de la semana pasada
2. Restáuralo en un subdominio de staging (backuptest.tudominio.com)
3. Comprueba que arranca, que muestra contenido, que puedes hacer login en wp-admin
4. Borra el staging

Si en cualquier punto algo falla, descubres el problema con tiempo de sobra y no a las 3 de la madrugada con la web caída.

Una nota sobre los backups "automáticos" del hosting

Casi todos los hostings españoles (Webempresa, Raiola, SiteGround, OVH) anuncian "backups diarios incluidos". Lo que NO dicen casi nunca:

• La retención por defecto suele ser 7 días
• Algunos hostings borran tus backups si te das de baja, incluso si pagas el siguiente mes
• La restauración a veces requiere abrir ticket y esperar horas
• Si el problema es el propio hosting (downtime extendido, quiebra como Nominalia), el backup está dentro de su infraestructura y no lo recuperas

El backup del hosting es complementario, no es tu backup principal. Tu backup principal lo controlas tú, en un proveedor distinto al del hosting.

El test definitivo

Hazte estas 5 preguntas. Si fallas a una sola, tu backup tiene un agujero:

1. ¿Sé dónde está mi último backup ahora mismo?
2. ¿Está fuera del servidor donde corre la web?
3. ¿Incluye base de datos + filesystem + config?
4. ¿He restaurado uno en los últimos 6 meses, comprobando que funciona?
5. ¿Tengo retención al menos para volver atrás 30 días?

Si fallas en cualquiera, tu siguiente fin de semana puedes dedicar 2 horas a arreglarlo. El día que sí tengas un desastre, te ahorrarás 100 veces ese tiempo.