La web muestra un error crítico tras una actualización, o el hosting bloquea la cuenta por una incidencia de seguridad. Entras al panel con la tranquilidad de tener copias diarias, pero descubres que los backups estaban en el mismo espacio afectado, bajo las mismas credenciales y expuestos al mismo borrado.
Los riesgos de almacenar backups en el mismo servidor son claros: una avería, un borrado, un ataque o una suspensión pueden eliminar la web y su recuperación al mismo tiempo. Un backup útil debe sobrevivir al incidente original: aplica la regla 3-2-1-1-0, con tres copias, dos soportes, una fuera del proveedor, una inmutable y restauraciones verificadas sin errores.
Índice
Anuncio
Riesgos de almacenar backups en el mismo servidor
Los riesgos de almacenar backups en el mismo servidor son claros: una avería, un borrado, un ataque o una suspensión pueden eliminar la web y su recuperación a la vez. La regla 3-2-1-1-0 propone 3 copias, 2 soportes, 1 ubicación externa, 1 copia aislada o inmutable y 0 errores comprobados al restaurar.
El problema real no es que la copia esté cerca. El problema es que comparta el mismo dominio de fallo, es decir, el mismo lugar, cuenta o acceso que puede afectar a la web. Guardar un archivo ZIP en otra carpeta de wp-content es como dejar una copia de las llaves dentro de la casa que se está quemando.
Una copia útil debe sobrevivir al incidente original. Si una web corporativa de Madrid pierde el acceso al panel del hosting, pero su backup está en ese mismo panel, no tiene un plan de recuperación: tiene una segunda versión del mismo problema.
Una carpeta distinta no protege
Un backup en otro directorio del servidor sigue dependiendo del mismo disco, la misma máquina virtual y el mismo proveedor. Un fallo de hardware, una corrupción del sistema de archivos o un borrado masivo pueden afectar a producción y a las copias locales en segundos.
Esto incluye los archivos de WordPress, la carpeta wp-content, las imágenes de la biblioteca multimedia y la base de datos MySQL. Restaurar solo los archivos sin la base de datos puede dejar pedidos, usuarios, formularios o cambios de contenido fuera de la web recuperada.
El backup del hosting es una capa
El backup incluido por el hosting puede ser útil, pero no debe ser la única capa de protección. Antes de confiar en él, conviene confirmar dónde se almacena, cuántos días se conserva, si se puede descargar y quién tiene permiso para borrarlo.
Una retención de 7 días puede resultar insuficiente si el malware permanece oculto entre 2 y 4 semanas. En ese caso, todas las copias recientes pueden contener ya el código malicioso o una base de datos dañada.
| Incidente | Qué afecta | Copia expuesta | Protección mínima |
|---|---|---|---|
| Fallo físico | Servidor y discos | Otro directorio o disco local | Copia off-site |
| Borrado accidental | Archivos y MySQL | Copias con los mismos permisos | Cuenta separada |
| Ransomware | Archivos, volúmenes y copias montadas | Discos accesibles desde producción | Inmutabilidad |
| Suspensión de cuenta | Panel y restauración | Backups del mismo hosting | Proveedor alternativo |
| Caída del proveedor | Web, panel y soporte | Copias del mismo proveedor | Segunda ubicación |
| Credenciales robadas | Hosting, SFTP y API | Cloud con la misma cuenta | MFA y credenciales separadas |
Saber qué puede caer a la vez permite elegir una copia que sobreviva. El siguiente matiz decide si una nube externa protege de verdad o solo parece hacerlo.
Una copia externa puede seguir expuesta
Una copia externa no está aislada si la misma identidad puede borrar la web y el backup. Cambiar de servidor o de bucket no sirve cuando el atacante conserva acceso a la misma consola cloud, contraseña o clave API.
El error más frecuente en estos casos es usar una única cuenta para el hosting, Amazon S3, Google Drive y la facturación. Si un correo de phishing compromete esa cuenta, el atacante puede borrar la producción, vaciar el bucket y dificultar la recuperación de acceso.
Air gap lógico e inmutabilidad
Un air gap lógico es una separación de permisos que impide al servidor de producción modificar una copia histórica. Piénsalo como una caja fuerte a la que el repartidor puede meter documentos, pero no abrir para retirarlos.
La inmutabilidad añade una regla de retención: durante un plazo fijado, los archivos no se pueden borrar ni cambiar. Una retención inmutable de entre 30 y 90 días ayuda a recuperar una versión anterior a un ataque, siempre que esté bien configurada.
La nube necesita otra identidad
Amazon S3, Google Drive, Dropbox y Backblaze B2 son destinos válidos, pero no son una defensa automática. Deben estar en una cuenta distinta, con autenticación multifactor, acceso limitado y una credencial de escritura que no pueda eliminar versiones antiguas.
La práctica demuestra que una separación geográfica sin separación de cuenta falla cuando más se necesita. Una copia en otra región, pero bajo el mismo usuario administrador, sigue dependiendo de una sola llave.
La separación técnica evita la pérdida total, pero no indica cuánta información puede perderse. Eso se decide con dos objetivos muy concretos: RPO y RTO.
Anuncio
RPO y RTO según el tipo de web
El RPO fija cuántos datos aceptas perder y el RTO fija cuánto tiempo puedes estar sin web. Una tienda WooCommerce que recibe pedidos no puede tener los mismos objetivos que una página corporativa que cambia una vez al mes.
El RPO, o punto objetivo de recuperación, responde a esta pregunta: «¿cuánto trabajo puedo perder?». El RTO, o tiempo objetivo de recuperación, responde a otra: «¿cuánto puedo tardar en volver a operar?».
Los pedidos y los datos cambian con mayor frecuencia
Una tienda online suele necesitar un RPO de entre 15 y 60 minutos para su base de datos. Los pedidos, pagos, stock, cuentas de clientes y cupones viven principalmente en MySQL, aunque los archivos del tema cambien con menos frecuencia.
Una web corporativa estática puede aceptar un RPO de 24 horas y un RTO de entre 8 y 24 horas. Una tienda que factura cada día suele necesitar un RTO de entre 1 y 4 horas, con un procedimiento probado para restaurar sin improvisar.
La retención cubre daños ocultos
La retención guarda varias generaciones de copias para poder volver atrás. Si solo conservas una versión, un error humano o una infección detectada tarde pueden convertir el backup en una copia del daño.
| Tipo de sitio | RPO orientativo | RTO orientativo | Retención |
|---|---|---|---|
| Web corporativa | 24 horas | 8 a 24 horas | 30 días |
| Blog activo | 4 a 24 horas | 4 a 12 horas | 30 a 90 días |
| Tienda WooCommerce | 15 a 60 minutos | 1 a 4 horas | 90 días o más |
El coste de una copia externa suele ser menor que perder pedidos de una mañana. La arquitectura 3-2-1-1-0 traduce estos tiempos a capas concretas de protección.
La regla 3-2-1-1-0 evita depender de uno
La regla 3-2-1-1-0 reduce el punto único de fallo al repartir datos, soportes, ubicaciones y permisos. No es un producto ni un plugin: es una forma de diseñar la recuperación para que un solo incidente no destruya todo.
Las tres copias incluyen producción y dos versiones adicionales. Los dos soportes pueden ser el almacenamiento principal y un almacenamiento de objetos externo; la copia off-site debe salir del proveedor o de la cuenta que aloja la web.
Arquitectura útil en WordPress
Una arquitectura razonable combina una copia operativa diaria para recuperaciones rápidas, una copia remota cifrada en una cuenta separada y una copia inmutable. Para una tienda, la base de datos puede respaldarse cada 15 o 60 minutos y los archivos cada noche.
Un VPS o servidor dedicado necesita algo más que wp-content y MySQL. También puede requerir configuraciones del servidor, tareas programadas, reglas de firewall, certificados y datos de DNS para reconstruir el servicio sin depender de la memoria de una persona.
Contenedores no guardan tus datos
Una imagen Docker permite recrear una aplicación, pero no garantiza recuperar volúmenes persistentes, secretos o bases de datos externas. En servicios SaaS, la responsabilidad cambia: hay que revisar exportaciones, retención y mecanismos de recuperación del proveedor.
El consenso de seguridad de ENISA y las recomendaciones de respuesta ante incidentes de INCIBE coinciden en separar copias, controlar accesos y comprobar la recuperación. La copia que nunca se restaura es una promesa, no una garantía.
La estructura ya está clara, pero falta proteger el detalle que suele derribarla: quién puede borrar cada capa.
La automatización debe incluir algo más que programar una tarea diaria. Las copias de seguridad WordPress deben registrar fecha, tamaño, resultado y destino de cada ejecución, además de enviar una alerta si falla la exportación de la base de datos MySQL, no se alcanza el almacenamiento externo de backups o el archivo tiene un tamaño anómalo. También conviene controlar que se aplique la política de retención de copias de seguridad y programar una verificación de restauraciones periódica.
Así se detecta, por ejemplo, que un plugin dejó de incluir la protección de wp-content, que una clave API caducó o que el repositorio remoto ya no acepta nuevas copias.
Credenciales separadas protegen las copias
Las mismas credenciales para producción y backups convierten un acceso robado en un borrado doble. La separación de cuentas, MFA y permisos limita el alcance de un ataque de fuerza bruta, phishing o malware de navegador.
El error más frecuente es guardar la clave API del backup en el mismo servidor y concederle permiso total sobre el repositorio. Si el servidor queda comprometido, esa clave permite eliminar las copias que debían salvarlo.
Permisos que permiten escribir, no borrar
El proceso automático de copia debería enviar nuevos backups sin poder borrar las versiones históricas. La cuenta administrativa que cambia la retención o elimina objetos debe ser diferente y usar autenticación multifactor.
También conviene separar la cuenta de facturación de la cuenta técnica cuando el proveedor lo permite. Una suspensión por pago, una baja de servicio o una disputa no deberían impedir descargar el material necesario para recuperar la web.
Restaurar es parte del backup
Una prueba de restauración debe hacerse en un entorno aislado, como un subdominio privado o un servidor de pruebas sin acceso público. No conviene restaurar directamente sobre producción durante una incidencia, porque se pueden perder los pocos datos sanos que todavía quedan.
- Restaura archivos, base de datos MySQL y configuración necesaria.
- Comprueba que el backup se descomprime sin errores y que las tablas cargan.
- Escanea malware antes de publicar la copia restaurada.
- Valida pedidos, usuarios, formularios, enlaces y medios de WordPress.
- Revisa DNS, certificados, correo transaccional y monitorización.
- Documenta el tiempo real empleado y compáralo con tu RTO.
Un caso habitual es restaurar una copia que carga la portada, pero falla al entrar al área de cliente porque faltan tablas o claves externas. Las pruebas trimestrales en sitios activos detectan estas dependencias antes de que una caída las convierta en una parada de varios días.
Anuncio
Dudas habituales
¿Es seguro guardar backups en el mismo hosting?
No, no como única medida, porque una caída, suspensión o acceso comprometido puede afectar a web y copias simultáneamente. El backup del hosting sirve como capa extra si existe otra copia con cuenta y credenciales separadas.
¿Cuántas copias necesita una web WordPress?
Una web debería mantener al menos 3 copias bajo la regla 3-2-1-1-0. Eso incluye producción, una copia adicional, otra externa y una capa aislada o inmutable.
¿Amazon S3 es una copia aislada?
Amazon S3 solo es una copia aislada si usa cuenta, MFA y permisos distintos de producción. Un bucket dentro de la misma cuenta cloud puede borrarse con las mismas credenciales comprometidas.
¿Cada cuánto debo hacer backup de WooCommerce?
Una tienda WooCommerce suele necesitar copias de base de datos cada 15 a 60 minutos y archivos diarios. La frecuencia exacta depende del RPO aceptable y del volumen de pedidos.
¿Qué debe incluir una restauración de WordPress?
Una restauración completa debe incluir archivos, base de datos MySQL, medios, configuración y servicios conectados. También debe validar malware, DNS, correo, usuarios y funcionamiento de pagos o formularios.
¿El RGPD obliga a tener backups fuera de españa?
El RGPD no obliga a guardar las copias fuera de España, pero exige medidas de seguridad adecuadas al riesgo. Si los datos salen de la Unión Europea, deben revisarse las garantías del proveedor y la LOPDGDD.
La copia que importa es la recuperable
- Lo esencial: un backup en el mismo servidor comparte el fallo que debe resolver.
- Lo esencial: otra nube no basta si la misma cuenta o clave API puede borrar producción y copias.
- Lo esencial: RPO y RTO determinan la frecuencia, retención y velocidad de restauración necesarias.
- Lo esencial: una copia aislada e inmutable pierde valor si nunca se ha restaurado y comprobado.
Fuentes de interés
Otros artículos que pueden complementar lo que acabas de leer:
- Backup Externo vs Backup en el Mismo Hosting - Avantys — avantys.com
- Copias de seguridad WordPress: Guía Definitiva y ... — clementemoraleda.com
- Backup WordPress: ¿qué es y cómo hacerlo en tu web? — piensasolutions.com
- ¿Cómo hacer una copia de seguridad en WordPress? — arsys.es
Josu Barrios
Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.