Copias de seguridad web: cómo comprobar que podrás restaurar

13.08.2026 · Lectura: 7–9 min

Una copia de seguridad solo es útil si permite restaurar la web dentro del tiempo que el negocio puede asumir y sin perder más datos de los aceptables. Guardar un archivo comprimido de vez en cuando no basta. Hay que decidir qué se protege, con qué frecuencia, quién puede acceder, dónde se conserva y cómo se comprueba la recuperación.

Para una empresa en España, una web puede concentrar formularios, pedidos, contenidos, reservas, cuentas de usuario e integraciones con terceros. Si una actualización falla, una credencial queda comprometida o un ataque cifra el servidor, el problema no termina al recuperar unos ficheros: también hay que reconstruir el estado correcto del sistema y verificar que no se reintroduce la causa del incidente.

Empieza por dos límites de negocio: RPO y RTO

Antes de elegir una herramienta conviene responder dos preguntas. El RPO marca cuántos datos recientes puede permitirse perder la empresa. El RTO indica cuánto tiempo puede estar indisponible la web antes de que el impacto resulte inaceptable.

Una web corporativa que recibe pocos cambios quizá tolere una copia diaria. Una tienda online con pedidos durante todo el día puede necesitar copias de la base de datos mucho más frecuentes. Del mismo modo, no es igual recuperar un blog en una jornada que mantener parado un checkout durante ese periodo. Estas decisiones deben salir del impacto real, no de la frecuencia que venga activada por defecto en el alojamiento.

Qué debe incluir una copia recuperable

En WordPress, la documentación oficial distingue la base de datos de los archivos del sitio. La base contiene entradas, comentarios, enlaces, ajustes y otros datos dinámicos; los ficheros incluyen temas, plugins, medios subidos y configuración. Restaurar solo una de las dos partes puede dejar una web incompleta o incompatible.

En otros gestores y desarrollos a medida, el inventario debe seguir la misma lógica. Como mínimo, revisa:

• base de datos y registros necesarios para recuperar el estado correcto;
• código, plantillas, plugins, dependencias y archivos de configuración;
• imágenes, documentos y otros contenidos subidos por usuarios o editores;
• reglas del servidor, tareas programadas y versiones de PHP u otros runtimes;
• DNS, certificados y configuración del proveedor de correo;
• documentación de integraciones: pagos, facturación, CRM, formularios y API;
• claves y secretos mediante un procedimiento seguro, nunca pegados en el archivo de la web.

No todo tiene que copiarse con la misma frecuencia. El código versionado puede reconstruirse desde un repositorio; los pedidos o formularios recientes, no. Separar componentes ayuda a ajustar costes sin dejar fuera lo que realmente cambia.

Evita que el incidente alcance también a las copias

Una copia conectada permanentemente con las mismas credenciales que el servidor puede desaparecer junto con el original. La guía de CISA frente al ransomware recomienda mantener copias críticas offline y cifradas, comprobar regularmente su disponibilidad e integridad y ensayar los procedimientos de recuperación. El objetivo es que un atacante o un error operativo no pueda borrar de una vez producción y respaldo.

Una adaptación práctica del principio 3-2-1 consiste en conservar varias copias, utilizar más de un tipo de almacenamiento y mantener al menos una fuera del entorno principal. No hace falta aplicar la misma arquitectura a todos los negocios, pero sí evitar un único punto de fallo. También conviene separar cuentas, activar autenticación multifactor cuando el proveedor la ofrezca y limitar quién puede eliminar versiones antiguas.

Una prueba de restauración debe parecerse a un incidente real

Ver un mensaje de «copia completada» solo confirma que terminó una tarea. No demuestra que el archivo esté íntegro, que incluya todos los componentes ni que el equipo sepa usarlo. NIST sitúa la recuperación dentro de la planificación de contingencia: primero se analizan las operaciones y prioridades, después se prepara el procedimiento.

La prueba puede hacerse en un entorno aislado para no tocar producción. Un guion básico sería:

1. elegir una versión anterior conocida y registrar su fecha;
2. levantar un entorno limpio y compatible;
3. restaurar archivos, base de datos y configuración siguiendo la documentación;
4. cambiar contraseñas y claves si el escenario simula una intrusión;
5. comprobar navegación, formularios, búsquedas, acceso, pedidos e integraciones;
6. medir el tiempo real y la pérdida de datos respecto al RPO;
7. documentar fallos, responsables y mejoras antes de cerrar la prueba.

Si la recuperación procede de un incidente de seguridad, no basta con volver a publicar el estado anterior. CISA advierte de la necesidad de evitar que sistemas limpios se reinfecten durante la recuperación. Antes de reconectar la web hay que revisar la causa, actualizar componentes vulnerables y confirmar que la copia elegida no contiene el mismo problema.

Cuándo hacer una copia extraordinaria

Además del calendario habitual, crea un punto de retorno antes de cambios con impacto: actualizaciones de CMS y plugins, migraciones, modificaciones masivas de contenido, cambios de DNS, despliegues de código, importaciones de catálogo o ajustes del checkout. La copia debe reflejar exactamente el estado previo y conservar la estructura necesaria para un rollback rápido.

Eso no significa acumular archivos indefinidamente. Define una retención razonable, protege los respaldos que contengan datos personales y elimina versiones conforme al calendario aprobado. Una copia de producción puede contener los mismos datos sensibles que la web activa y requiere controles equivalentes.

Cómo evaluar el sistema de copias de un proveedor

No te quedes con la frase «hacemos backup». Pide respuestas concretas:

• qué componentes están incluidos y cuáles no;
• frecuencia, retención y ubicación de las copias;
• si existe separación de cuentas o una copia offline/inmutable;
• quién puede iniciar y quién puede borrar una restauración;
• cuándo se realizó la última prueba completa y qué resultado obtuvo;
• qué RPO y RTO se han comprobado en la práctica;
• cómo se recuperan servicios externos que no controla el hosting.

El resultado debería ser un procedimiento corto, ejecutable y actualizado. Si solo funciona porque una persona recuerda pasos no escritos, todavía existe un riesgo operativo.

Protección de datos y respuesta ante incidentes

Las copias no sustituyen la gestión de una brecha de datos personales. Si un incidente afecta a confidencialidad, integridad o disponibilidad, hay que evaluarlo conforme al RGPD y al procedimiento interno. La AEPD mantiene información específica sobre gestión y notificación de brechas. La decisión depende del caso y este artículo no sustituye asesoramiento jurídico o de protección de datos.

En la práctica, el plan técnico debe permitir identificar qué versión se restauró, qué datos pudieron quedar afectados, cuándo se detectó el incidente y qué medidas se aplicaron. Esa trazabilidad ayuda tanto a recuperar el servicio como a tomar decisiones documentadas.

Preguntas frecuentes sobre copias de seguridad web y VOWE

¿Puede VOWE revisar las copias y el proceso de restauración de una web?

Sí. Dentro del mantenimiento evolutivo y el soporte técnico, VOWE puede inventariar los componentes del sitio, revisar el sistema de copias, documentar dependencias y preparar una prueba de restauración controlada. El alcance depende del hosting, el gestor de contenidos, las integraciones y los accesos disponibles.

¿Qué información hace falta para empezar?

Conviene aportar la URL, la plataforma y el hosting, la frecuencia y retención actuales, la ubicación de las copias, las integraciones críticas y el tiempo de parada y pérdida de datos que el negocio puede asumir. No es necesario enviar contraseñas dentro del formulario de contacto.

¿Una prueba de restauración garantiza que nunca habrá una caída?

No. La prueba reduce incertidumbre y permite detectar copias incompletas, dependencias olvidadas y tiempos irreales, pero no elimina todos los fallos ni sustituye la seguridad, el mantenimiento y un plan de respuesta. Cada cambio importante puede exigir una nueva comprobación.

Fuentes y siguiente paso

Esta guía sintetiza las recomendaciones de WordPress Developer Resources sobre copias de archivos y base de datos, la guía de planificación de contingencia de NIST, la guía #StopRansomware de CISA y la información de la AEPD sobre brechas de datos personales.

Si no conoces el RPO, el RTO o la última fecha de restauración probada de tu web, el siguiente paso no es comprar más almacenamiento: es hacer un inventario y ejecutar una recuperación controlada.