Si mañana tu WordPress dejara de funcionar, ¿podrías recuperarlo?
La pregunta parece sencilla hasta que intentas responderla con precisión.
Quizá el hosting hace copias automáticas. Tal vez tienes instalado un plugin de backups. Puede que incluso veas varios archivos almacenados en Google Drive, Dropbox o algún otro servicio.
Pero ninguna de esas cosas demuestra por sí sola que puedas reconstruir la web.
Un backup puede existir y estar incompleto.
Puede contener los archivos pero no la base de datos.
Puede haberse generado correctamente y estar corrupto.
Puede necesitar credenciales que ya nadie conserva.
Puede restaurarse, pero devolver la web a un punto tan antiguo que falten pedidos, formularios, reservas o cambios importantes.
O puede ocurrir algo todavía más incómodo: que nunca hayas probado el proceso y descubras el problema precisamente cuando la web está caída.
Por eso una estrategia de copias de seguridad en WordPress no debería responder únicamente a «¿tenemos backups?».
Debería poder responder a estas tres preguntas:
Esa diferencia separa una copia almacenada de un sistema real de recuperación.
Es fácil confundir ambos conceptos.
Un backup es una copia de determinados datos en un momento concreto.
La recuperación es el proceso completo que permite utilizar esa copia para devolver la web a un estado funcional.
Entre una cosa y otra pueden aparecer muchos problemas.
Puedes tener diez copias y no disponer de ninguna suficientemente antigua para recuperar una web infectada hace tres semanas.
Puedes tener una copia de los archivos y descubrir que no contiene la base de datos.
Puedes recuperar WordPress y comprobar después que el formulario de contacto no funciona, faltan imágenes o se han perdido pedidos posteriores a la fecha de la copia.
Por eso el resultado que interesa a una empresa no es:
«El backup terminó correctamente».
El resultado que interesa es:
«Sabemos qué recuperar, desde qué punto y mediante qué procedimiento, y hemos comprobado que la web resultante funciona».
Ese es un estándar bastante más exigente.
La documentación oficial de WordPress separa una instalación típica en dos grandes partes: archivos y base de datos.
Para poder reconstruir completamente una web normalmente necesitas ambas.
Aquí encontramos, entre otros elementos:
wp-config.php;.htaccess;Una parte especialmente importante es wp-content, donde normalmente se encuentran plugins, temas y archivos multimedia.
La base de datos contiene buena parte de la información que hace que WordPress sea realmente tu web y no simplemente una colección de archivos.
Por ejemplo:
En WooCommerce también existen datos empresariales especialmente sensibles, como los relacionados con pedidos y clientes.
Descargar únicamente el directorio de WordPress normalmente no equivale a guardar la base de datos. WordPress utiliza habitualmente MySQL o MariaDB y esos datos se almacenan separadamente.
Por eso conviene pensar en archivos y base de datos como un mismo conjunto de recuperación, creado de forma suficientemente próxima en el tiempo.
Que exista un archivo no significa automáticamente que puedas confiar en él.
Estos son algunos de los problemas que conviene detectar antes de necesitarlo.
Es uno de los fallos más básicos.
Puedes descubrir que el backup solo contiene archivos, solo contiene la base de datos o excluye determinadas carpetas.
En ese caso quizá puedas recuperar una parte de la instalación, pero no necesariamente reconstruir la web completa.
La documentación oficial de WordPress insiste precisamente en la necesidad de considerar archivos y base de datos conjuntamente para una recuperación completa.
Un proceso automático puede haber generado un archivo aparentemente normal que después falle durante la restauración.
Por ejemplo, pueden aparecer:
La forma más fiable de descubrirlo no es mirar si existe una marca verde junto al backup.
Es intentar restaurarlo.
Este problema es especialmente importante para webs que cambian constantemente.
Supón que el lunes a las 02:00 se genera una copia correcta.
El martes a las 14:00 necesitas restaurarla.
Técnicamente el backup puede ser perfecto.
Pero entre ambos momentos se han podido producir:
Restaurar correctamente no significa necesariamente recuperar todo lo que existía inmediatamente antes del incidente.
Puedes solucionar la avería y, al mismo tiempo, perder información posterior al punto de restauración.
Imagina una infección que permanece oculta durante varias semanas.
Día tras día se generan backups.
Cuando finalmente detectas el malware, descubres que las últimas quince copias ya contienen archivos comprometidos.
Aquí el problema no es que falten backups.
El problema es que falta retención histórica suficiente para poder localizar un punto anterior al incidente.
Esto también puede ocurrir con errores de configuración, datos eliminados accidentalmente o problemas que pasan desapercibidos durante días.
Este caso es más frecuente de lo que debería.
Las copias existen, pero:
Un sistema de recuperación depende también de las personas, accesos y procedimientos necesarios para ejecutarlo.
No existe una frecuencia universal válida para todos los WordPress.
Una pregunta más útil es:
¿cuánta información puede permitirse perder el negocio?
Aquí resulta útil entender dos conceptos empleados en continuidad de negocio: RPO y RTO.
El Recovery Point Objective ayuda a definir cuánta información podrías asumir perder en una recuperación.
Imagina que la última copia es de las 02:00 y el incidente ocurre a las 14:00.
Existe una diferencia de doce horas.
En una web corporativa que no ha cambiado durante ese periodo, quizá tenga poca importancia.
En una tienda online esas doce horas podrían contener pedidos, altas de clientes o modificaciones de stock.
En una academia pueden incluir inscripciones.
En una web de servicios, formularios comerciales.
Por eso la frecuencia debe guardar relación con la velocidad a la que cambian los datos y con su importancia para el negocio.
El Recovery Time Objective plantea otra cuestión:
¿cuánto tiempo puede permanecer fuera de servicio la web antes de que la interrupción resulte seria para la empresa?
Las necesidades son diferentes para:
Dos empresas pueden utilizar WordPress y necesitar estrategias de recuperación completamente distintas.
Restaurar una tienda online requiere más precaución que recuperar una web prácticamente estática.
Supongamos que detectas un problema a las 18:00 y decides restaurar la copia de las 02:00.
La restauración puede eliminar el fallo técnico.
Pero durante esas dieciséis horas quizá hayan entrado nuevos pedidos o cambiado otros datos de la tienda.
Por tanto, restaurar una copia completa de producción sin analizar qué ha ocurrido desde el punto de backup puede introducir una segunda incidencia: pérdida o inconsistencia de datos comerciales recientes.
Además, WooCommerce dispone actualmente de mecanismos específicos para almacenar y consultar pedidos, entre ellos High-Performance Order Storage (HPOS).
Esto refuerza una idea importante:
en una tienda activa no conviene tratar la restauración de la base de datos como si fuera simplemente volver atrás en una web estática.
Antes de sobrescribir producción conviene saber:
Una restauración completa puede ser la solución adecuada, pero debe realizarse conociendo sus consecuencias.
Restaurar una base de datos puede sustituir los datos actuales por los existentes en el momento del backup.
Por eso no conviene probar una restauración directamente sobre una web empresarial activa únicamente para comprobar «si funciona».
Antes de sobrescribir producción deberías conocer exactamente:
Cuando sea posible, una prueba de restauración debería hacerse primero en un entorno separado.
Si no tienes experiencia administrando WordPress, bases de datos o restauraciones, una incidencia real tampoco es un buen momento para experimentar sobre la única copia que tienes.
Hay una comprobación mucho más útil que verificar si la tarea automática termina sin errores:
restaurar una copia y comprobar el resultado.
La documentación oficial de WordPress incluye procedimientos tanto para realizar copias como para restaurar bases de datos.
CISA, en sus recomendaciones frente al ransomware, también aconseja mantener backups protegidos y probar periódicamente su disponibilidad e integridad en escenarios de recuperación.
Una prueba puede descubrir problemas mientras todavía tienes tiempo para corregirlos.
Por ejemplo:
Lo importante es descubrirlo un martes tranquilo, no durante una incidencia con clientes intentando entrar en una tienda caída.
Que aparezca la portada no demuestra que la recuperación haya terminado correctamente.
Una validación razonable debería recorrer las funciones que realmente importan para ese negocio.
Por ejemplo:
wp-admin?Según la web:
También conviene comprobar servicios externos que WordPress pueda necesitar:
Una copia puede reconstruir WordPress sin reconstruir automáticamente todos los elementos externos de los que depende la web.
Depender exclusivamente de un único lugar introduce un riesgo innecesario.
Las copias ofrecidas por el hosting son muy útiles.
Permiten en muchos casos recuperar rápidamente archivos, bases de datos o instalaciones completas.
Pero conviene saber qué ocurriría si el propio proveedor o la cuenta sufriese una incidencia grave.
De ahí que sea habitual aplicar principios como la estrategia 3-2-1:
En contextos de ransomware, CISA recomienda además mantener copias protegidas fuera del alcance del sistema comprometido y comprobar periódicamente su integridad y disponibilidad.
Para una pyme con WordPress esto puede traducirse, por ejemplo, en combinar:
La implementación concreta dependerá del nivel de riesgo y de las necesidades de cada empresa.
El problema no es confiar en el proveedor.
El problema es no conocer las condiciones de esa copia.
Si tu hosting incluye backups, merece la pena preguntar:
La propia documentación de WordPress recomienda mantener tus propias copias aunque el alojamiento disponga de sistemas de backup.
No porque los proveedores sean necesariamente poco fiables, sino porque la redundancia forma parte de una estrategia de recuperación razonable.
Guardar únicamente la copia más reciente simplifica el sistema, pero reduce enormemente tus opciones.
Imagina esta secuencia:
Si solo conservas unos pocos días, quizá ya no exista ninguna copia anterior al problema.
Por eso una política puede combinar distintos niveles de retención:
No existe una cantidad universal de días que sirva para todas las webs.
Hay que decidirlo teniendo en cuenta:
Las copias de seguridad no deberían configurarse una vez y olvidarse.
Tienen relación directa con el mantenimiento de WordPress.
Antes de una actualización importante necesitas un punto al que regresar si algo falla.
Antes de cambiar la versión de PHP, migrar el servidor o modificar componentes críticos, también.
Y después de realizar cambios conviene comprobar que el sistema de backups continúa funcionando.
En Cómo actualizar un WordPress antiguo sin romperlo explicamos precisamente por qué no recomendamos intervenir en una instalación desactualizada hasta disponer de una copia que pueda recuperarse.
Las copias también forman parte de una estrategia de seguridad.
Si una web ha sido comprometida, localizar un punto limpio anterior al incidente puede ser útil durante la recuperación. Pero restaurar una copia antigua sin corregir la causa de la intrusión puede hacer que el problema reaparezca.
Por eso backups, mantenimiento, seguridad y recuperación no deberían gestionarse como tareas independientes.
No hace falta redactar un manual de cincuenta páginas.
Pero alguien debería poder responder rápidamente a estas preguntas:
No «creo que en el hosting».
Ubicación concreta y acceso disponible.
Archivos, base de datos y cualquier otro elemento necesario para la web.
Necesitas conocer hasta qué fecha podrías retroceder.
No solo el último generado.
El último del que existe evidencia razonable de que puede utilizarse.
Persona interna, proveedor de mantenimiento, hosting o responsable técnico.
Preferentemente en un entorno separado cuando la situación lo permita.
Especialmente importante en WooCommerce, reservas, formularios, suscripciones y cualquier web con actividad frecuente.
Portada, administración, formularios, pagos, pedidos, correos e integraciones relevantes para el negocio.
Puedes empezar revisando estas preguntas:
Si varias respuestas son «no sé», el problema no es necesariamente que no tengas backups.
El problema es que todavía no conoces tu capacidad real de recuperación.
Nuestro enfoque no consiste simplemente en instalar un plugin y comprobar que una tarea automática aparece en verde.
Primero hay que entender qué web estamos protegiendo.
No necesita la misma política una página corporativa que apenas cambia que un WooCommerce con pedidos diarios o una plataforma donde se registran usuarios constantemente.
Por eso una revisión puede incluir:
A partir de ahí las copias pueden integrarse dentro del mantenimiento WordPress y supervisarse como cualquier otro elemento crítico.
Y si ya existe una incidencia, lo primero no debería ser restaurar arbitrariamente la copia más reciente.
Hay que determinar qué ocurrió, qué punto conviene recuperar y qué información podría perderse durante el proceso.
Abre el panel de tu hosting o la herramienta que utilices para hacer copias.
Busca la última copia y responde a estas cinco preguntas:
¿De cuándo es?
¿Qué contiene?
¿Dónde está almacenada?
¿Cuánto tiempo puedes retroceder?
¿Cuándo fue la última vez que comprobaste una restauración?
Si puedes responder a las cinco, tienes bastante más información que alguien que simplemente sabe que «el hosting hace backups».
Si no puedes hacerlo, merece la pena revisarlo antes de que exista una incidencia.
Porque una copia de seguridad no demuestra que puedas recuperar WordPress.
La prueba real llega cuando puedes reconstruir la web, comprobar que funciona y saber de antemano qué información vas a conservar y cuál podrías perder.
Ese es el objetivo de una estrategia de backups: no acumular archivos.
Poder recuperar el negocio cuando realmente haga falta.
Para completar esta estrategia, consulta también qué incluye el mantenimiento WordPress, cómo actualizar WordPress de forma segura y qué comprobar tras un hackeo.
