Si mañana desapareciera tu web, ¿cuánto tardarías en recuperarla?
Y hay una segunda pregunta, bastante más incómoda: ¿de qué momento sería la web que recuperarías?
No es lo mismo volver a estar online en dos horas recuperando prácticamente toda la información que levantar la web después de un día y descubrir que faltan pedidos, formularios, reservas o cambios realizados durante las últimas 24 horas.
Muchas empresas no conocen la respuesta.
Saben que «el hosting hace copias», ven alguna opción de backup en el panel y dan por resuelto el asunto.
Hasta que necesitan restaurar.
Una estrategia de copias de seguridad no consiste en tener archivos almacenados en algún sitio. Consiste en saber qué se está copiando, con qué frecuencia, dónde se guarda, cuánto tiempo se conserva y cuánto tardaríamos en recuperar la web si mañana ocurre algo serio.
Y esto último importa más de lo que parece.
Recientemente hemos tenido ocasión de analizar un incidente real sufrido por una infraestructura de alojamiento en la que se encontraban varias webs.
Durante la madrugada, un ataque de ransomware afectó a la plataforma de virtualización y provocó el cifrado de sistemas y la interrupción de los servicios.
El proveedor aisló el entorno afectado y comenzó la recuperación utilizando sus copias de seguridad.
Aquí está lo importante: las copias no habían sido comprometidas.
Los servicios pudieron restaurarse progresivamente durante la misma jornada hasta quedar nuevamente operativos.
Sin esas copias, el incidente habría sido otro completamente distinto.
Pero el caso también muestra otra cuestión que suele olvidarse: la recuperación se realizó desde el último punto válido disponible y eso supuso una pérdida estimada de unas 24 horas de información.
Es un buen ejemplo de por qué hablar simplemente de «tener backups» dice bastante poco.
Había copias.
Funcionaron.
Permitieron recuperar la infraestructura.
Y aun así existió una ventana de pérdida de datos.
Para una web corporativa que apenas cambia puede ser asumible. Para un WooCommerce con decenas de pedidos diarios, un sistema de reservas o una academia online, puede no serlo.
Una instalación de WordPress tiene dos grandes componentes.
Por un lado están los archivos:
Y por otro está la base de datos, donde se guarda buena parte de la información que convierte esa instalación en tu web:
La propia documentación de WordPress diferencia expresamente ambos elementos al explicar cómo realizar una copia completa del sitio.
Una copia únicamente de los archivos no basta.
Una exportación únicamente de la base de datos tampoco.
Para poder reconstruir correctamente una web necesitas disponer de ambas partes.
WordPress explica aquí cómo realizar copias completas del sitio.
Este es probablemente uno de los errores más habituales.
Un proveedor puede decir:
Hacemos una copia automática cada día.
Perfecto.
Pero todavía faltan muchas preguntas.
¿Dónde se almacena?
¿Está físicamente separada de la infraestructura principal?
¿Cuántas versiones conserva?
¿Puedes acceder a una copia de hace 20 días?
¿Qué ocurre si la cuenta completa resulta comprometida?
¿Cuánto tarda una restauración?
¿La restauración está incluida?
¿Alguna vez se ha comprobado que esa copia funciona?
¿Puedes recuperar únicamente la base de datos?
¿Y un archivo concreto?
¿Qué ocurre si el malware llevaba tres semanas dentro del servidor antes de ser detectado?
Un snapshot diario puede formar parte de una buena estrategia.
No es la estrategia.
Una referencia habitual en continuidad de negocio es la regla 3-2-1.
CISA, la agencia estadounidense de ciberseguridad, la resume de esta manera:
Aplicado a una pyme con WordPress podría traducirse así.
Es la información con la que estás trabajando ahora mismo.
No es un backup, naturalmente, pero constituye la primera copia dentro del modelo 3-2-1.
Puede ser el sistema de snapshots o backups proporcionado por el hosting.
Es extremadamente útil para recuperar rápidamente un archivo eliminado, revertir una actualización problemática o restaurar un sitio completo.
Aquí introducimos una separación importante.
Por ejemplo:
De esta forma, una incidencia grave en el proveedor principal no afecta necesariamente a todas las vías de recuperación.
CISA recomienda además mantener copias aisladas u offline y probar regularmente su restauración como medida frente al ransomware.
Consulta las recomendaciones de CISA sobre ransomware y backups.
De este tipo de incidentes puede extraerse una conclusión equivocada:
«Si un hosting puede sufrir un ataque, da igual cuál contrate.»
No.
Precisamente ocurre lo contrario.
Ningún proveedor serio puede prometer que nunca sufrirá una vulnerabilidad, una avería, un ataque o un error humano.
La diferencia aparece cuando algo falla.
En un incidente real deberían importar cuestiones como:
Un buen hosting no es solo CPU, RAM y gigabytes.
También compras capacidad de respuesta.
Por eso, cuando analizamos qué debería tener un hosting WordPress para una empresa, el precio mensual es solamente una de las variables.
También conviene entender las diferencias entre hosting compartido, WordPress gestionado y VPS.
Y hay otro matiz importante: elegir un buen alojamiento tampoco significa convertirlo en responsable de toda la seguridad de tu WordPress. Ya explicamos esta separación de responsabilidades en Tu hosting no es tu equipo de seguridad.
Infraestructura, aplicación WordPress y mantenimiento son capas distintas.
No existe una frecuencia universal.
La pregunta correcta es:
¿cuánta información puedes permitirte perder?
Aquí aparecen dos conceptos utilizados en continuidad de negocio: RPO y RTO.
El Recovery Point Objective representa el punto al que necesitas poder volver.
Imagina que tu última copia es de las 02:00 y el problema aparece a las 14:00.
Potencialmente tienes doce horas de diferencia entre ambos momentos.
En una web corporativa donde nadie ha realizado cambios durante ese periodo puede no importar.
En una tienda online significa otra cosa.
Podrían existir:
Por eso una copia diaria puede ser suficiente para una web y claramente insuficiente para otra.
El Recovery Time Objective responde a otra pregunta:
¿cuánto tiempo puede permanecer caída la web antes de que la interrupción empiece a afectar seriamente al negocio?
No es lo mismo una web informativa de un pequeño despacho que:
Tu política de backups debería diseñarse teniendo en cuenta ambos valores.
No son reglas universales, pero pueden servir como punto de partida.
Una combinación razonable podría ser:
Podría requerir:
Aquí una copia diaria de la base de datos puede dejar una ventana demasiado grande.
Dependiendo del volumen de actividad, puede ser necesario:
No deberías elegir la frecuencia por comodidad técnica.
Deberías elegirla según el coste que tendría perder los datos generados entre una copia y la siguiente.
Otro error es conservar únicamente «la última copia».
Imagina una infección silenciosa.
El malware entra el día 1.
Nadie lo detecta.
El día 2 se genera una copia.
También el día 3.
Y el día 4.
Cuando descubres el problema dos semanas después, todas las copias recientes contienen ya la infección.
Necesitas poder retroceder suficientemente en el tiempo.
Una política sencilla podría conservar, por ejemplo:
La retención exacta dependerá del sitio, de cuánto ocupa y del impacto económico de la pérdida de información.
Pero guardar solamente uno o dos puntos de restauración reduce mucho las opciones cuando el problema se descubre tarde.
Hay una comprobación extremadamente sencilla que muchas empresas nunca hacen.
Restaurarlo.
Porque una cosa es que el panel diga:
Backup completado correctamente.
Y otra bastante distinta es reconstruir una instalación WordPress utilizando ese archivo.
La documentación de WordPress recomienda disponer de copias tanto de archivos como de base de datos y conocer el procedimiento de restauración. CISA también incluye expresamente las pruebas periódicas de recuperación dentro de sus recomendaciones frente al ransomware.
Una prueba de restauración permite descubrir problemas cuando todavía no estás bajo presión.
Por ejemplo:
El día en que tu tienda lleva cuatro horas caída no es un buen momento para descubrirlos.
No hace falta experimentar sobre producción.
Puede utilizarse un entorno de staging, un subdominio temporal o un servidor aislado.
El procedimiento básico sería:
Si existe WooCommerce:
Si la web genera contactos:
Si es una academia:
La pregunta no es simplemente si aparece la portada.
La pregunta es si la actividad que hace útil la web sigue funcionando.
Sí.
Y puede ser extraordinariamente útil.
El caso real que comentábamos al principio lo demuestra: unas copias intactas permitieron reconstruir los servicios después de que un ataque de ransomware cifrara la infraestructura.
La conclusión no debería ser «no confíes en tu hosting».
Debería ser:
no diseñes toda tu continuidad de negocio alrededor de un único mecanismo que no controlas.
WordPress incluso recomienda expresamente realizar tus propias copias aunque el proveedor ya respalde el servidor.
La redundancia existe precisamente porque pueden fallar cosas.
Un sistema de backups no debería vivir aislado del resto del mantenimiento.
Antes de actualizar un plugin delicado hacemos una copia.
Antes de modificar PHP hacemos una copia.
Antes de migrar el servidor hacemos una copia.
Antes de introducir cambios importantes hacemos una copia.
Y si aparece una incidencia, necesitamos saber inmediatamente cuál es el último punto limpio al que podemos volver.
Por eso en Mantenimiento WordPress en 2026: qué debería incluir realmente tratamos las copias, las restauraciones y la monitorización como parte del mismo proceso.
También hay una relación directa con el SEO.
Una web caída, infectada o generando miles de URLs de spam no es únicamente un problema técnico. Puede convertirse en un problema de rastreo, reputación y visibilidad. Lo explicamos en cómo se relacionan el mantenimiento WordPress y el SEO técnico.
Y si el incidente ya ha ocurrido, disponer de una copia limpia puede cambiar completamente el proceso de recuperación. En nuestra guía sobre qué hacer cuando un WordPress ha sido hackeado explicamos por qué identificar un punto de restauración anterior a la infección puede resultar decisivo.
No hace falta convertir una pyme en un centro de datos.
Pero sí conviene cubrir unos mínimos.
Depender de que alguien recuerde pulsar un botón cada viernes no es una política de backup.
Ambos son necesarios para reconstruir la instalación.
Como mínimo, una copia debería estar fuera de la misma infraestructura que aloja la web.
Tiene que permitir regresar a distintos momentos y no únicamente al día anterior.
Cuantos más datos cambian, menor debería ser normalmente el intervalo entre copias.
También hay backups que fallan.
Hay que comprobar que los trabajos programados realmente terminan correctamente.
Una prueba periódica reduce drásticamente la incertidumbre cuando llega una incidencia.
Cuando la web cae, alguien debería saber:
Nuestro trabajo no consiste simplemente en instalar un plugin de backups y dejarlo ejecutándose.
Primero hay que entender qué web estamos protegiendo.
No necesita la misma estrategia una web corporativa que recibe tres formularios a la semana que un WooCommerce que procesa pedidos todos los días.
Por eso podemos revisar:
A partir de ahí podemos integrar las copias dentro del mantenimiento WordPress y encargarnos también de su supervisión.
Y si el alojamiento actual no ofrece las garantías necesarias, también podemos estudiar una migración a una infraestructura más adecuada.
No buscamos montar el sistema técnicamente más complejo.
Buscamos que, cuando algo ocurra, exista una respuesta conocida.
Abre ahora mismo el panel de tu hosting o la herramienta que utilices para hacer copias.
Y comprueba cuatro cosas:
¿De cuándo es tu última copia?
¿Dónde está almacenada?
¿Cuántos días puedes retroceder?
¿Has restaurado alguna vez una de ellas?
Si no puedes responder con seguridad a alguna de estas preguntas, todavía no sabes realmente si tienes un sistema de recuperación.
Solo sabes que, aparentemente, se están generando unos archivos.
Hay una diferencia considerable.
Un ataque, un fallo de servidor o un error humano pueden dejar una web fuera de servicio.
Lo que determina si aquello acaba siendo una incidencia de unas horas o un problema serio para el negocio es lo que hayas preparado antes.
Si quieres comprobar si las copias de tu WordPress serían suficientes ante un incidente real, en arreglotuweb.com podemos revisar tu alojamiento, backups, retención y procedimiento de recuperación y decirte qué tienes, qué falta y qué conviene cambiar.
Porque la mejor copia de seguridad no es la que aparece con una marca verde en el panel.
Es la que puedes restaurar cuando realmente la necesitas.
