Las copias de seguridad para sitio web fallan más por el plugin que por el hosting. He visto restaurar un backup de hace tres semanas porque el plugin guardaba el archivo en la misma carpeta pública del WordPress y un borrado accidental se llevó por delante también las copias. Ese es el problema puntual del que quiero hablar aquí, y la solución exacta.
El patrón se repite: instalas un plugin de respaldo, lo configuras con la opción por defecto, ves el mensaje «backup completado» y te olvidas. Meses después, un update rompe el tema, entras a restaurar y descubres que la copia está corrupta, incompleta o alojada en el mismo servidor que acaba de caer. Las copias de seguridad para sitio web no son un botón; son una cadena con varios eslabones y basta que uno se rompa para que todo el sistema sea inútil.
Dónde se rompe de verdad una copia de seguridad de un sitio web
El fallo más común no es la frecuencia ni el almacenamiento: es no haber probado nunca la restauración. Un backup que no se ha restaurado en un entorno de pruebas es solo una promesa. En un proyecto de una tienda con WooCommerce, el plugin generaba el archivo correctamente, pero excluía la carpeta de uploads por defecto para ahorrar espacio. La copia pesaba poco, parecía sana, y al restaurar en staging el catálogo aparecía sin imágenes. Nadie lo detectó hasta el día del desastre.
La segunda grieta típica es la base de datos. Muchos plugins hacen un volcado SQL sin comprobar la integridad, y si el proceso se interrumpe por un timeout del hosting, el archivo queda truncado con el mismo nombre que uno válido. Ese archivo corrupto pasa desapercibido durante meses. Por eso insisto en algo que casi ningún tutorial menciona: la verificación de integridad de la copia de seguridad del sitio web debería ser parte del proceso, no una ocurrencia de último minuto.
La solución exacta: 3-2-1 aplicado con criterio, no por dogma
La regla 3-2-1 (tres copias, dos medios distintos, una fuera del servidor) sigue siendo el estándar sensato. Pero aplicarla a rajatabla en un blog pequeño es absurdo. Lo que sí funciona en la práctica:
- Una copia local en el servidor solo como caché rápida, nunca como única copia.
- Una copia externa automática en almacenamiento de objetos (S3, Backblaze, Google Cloud Storage) configurada desde el propio plugin o desde un cron del servidor.
- Una copia descargada manualmente cada cierto tiempo y guardada en un disco físico o en otro proveedor, para cubrir el escenario de que el proveedor cloud suspenda la cuenta.
El detalle que marca la diferencia es la frecuencia: no la que te recomienda el plugin por defecto, sino la ligada a tu ritmo real de cambios. Un sitio con publicaciones diarias necesita copias diarias de base de datos y semanales de archivos. Un sitio estático que cambia dos veces al mes no necesita más. Aquí no hay talla única.
Restaurar es la prueba real, no el mensaje de éxito
Un plan de copias de seguridad para sitio web sin simulacro de restauración es teatro. Lo que hago con clientes: una vez al trimestre, restaurar el backup más reciente en un entorno aislado y comprobar tres cosas concretas: que la home carga, que el login del admin funciona y que la última entrada publicada aparece. Si algo falla, la copia no vale. Este test de cinco minutos detecta más problemas que cualquier panel de métricas del plugin.
Esto no funciona para sitios con bases de datos muy grandes (varios GB) si el entorno de staging no tiene los mismos recursos que producción; la restauración puede tardar horas y no es viable repetirla trimestralmente. En ese caso conviene segmentar: restaurar solo la base de datos y validar las tablas críticas con un checksum contra el original.
Elegir el plugin y el destino sin caer en la trampa del «todo en uno»
Los plugins de copias de seguridad para sitio web con más funciones no son necesariamente mejores. UpdraftPlus, Duplicator y BackupBuddy resuelven bien el respaldo, pero el punto crítico sigue siendo el destino. Si el plugin envía la copia a un servicio que está en el mismo proveedor que el hosting, pierdes la protección frente a caídas del proveedor. Es un error que veo constantemente en instalaciones con todo contratado en el mismo panel.
Mi recomendación honesta: separa proveedores. Si el hosting es A, el almacenamiento de copias que sea B. Si no puedes o no quieres, al menos descarga manualmente una copia mensual a un disco externo. No es elegante, pero cubre el escenario que ningún plugin controla.
Lo que ninguna copia te salva
Una copia de seguridad del sitio web no protege frente a un hackeo silencioso que lleva meses dentro. Si el atacante añadió código malicioso hace tres meses y tus copias son de hace cuatro, restaurar te devuelve al sitio limpio pero pierdes todo el contenido de ese periodo. Para eso están los escaneos de malware y la monitorización de integridad de archivos, no el backup. Tampoco cubre un borrado del proveedor cloud por impago: si la copia externa vive en una cuenta que no pagas, no existe.
La lección práctica: las copias de seguridad para sitio web son una parte del sistema de recuperación, no el sistema completo. Documenta quién restaura, cómo y en cuánto tiempo. Un backup que nadie sabe restaurar es un archivo muerto.
Perfiles verificables: Sitio web
Publicado el 31 de October de 2026. Última revisión: 31 de October de 2026.