Cómo comprobar que una copia de WordPress permite recuperar tu web

Recibir el aviso «copia completada» es tranquilizador, pero no responde a la pregunta que importa cuando surge una incidencia: ¿podremos recuperar la web y volver a trabajar con ella? Para saberlo, hace falta algo más que comprobar que existe un archivo de respaldo.

Si delegas el mantenimiento de WordPress, puedes pedir una prueba de recuperación con un alcance concreto. No necesitas ejecutar tú la restauración: necesitas saber qué se ha probado, con qué copia y qué ha quedado pendiente. Esta guía propone una forma de acordarlo y revisar el resultado, sin tocar la web activa para hacer experimentos.

Identifica qué copia se va a comprobar

La documentación de WordPress sobre copias de seguridad distingue los archivos de la web y su base de datos: normalmente necesitas ambos para una recuperación completa. Descargar la carpeta del alojamiento no significa que hayas guardado también la base de datos.

Pide la fecha y hora del respaldo, qué componentes contiene y quién puede recuperarlo. Los archivos y los datos deben corresponder a un conjunto coherente. Una copia anterior a un cambio importante puede no reproducir el estado que esperas encontrar.

Frecuencia, conservación y prueba de restauración son cosas diferentes. Tener copias diarias no dice durante cuánto tiempo se guardan, y conservarlas no demuestra que se haya probado una recuperación. Conviene preguntar por las tres cuestiones por separado.

Acuerda qué significa «la web funciona» para tu empresa

Antes de empezar, elige los recorridos que tu negocio necesita. Esta selección es una propuesta de trabajo, no la afirmación de que todos los planes incluyan todas las pruebas:

Que la portada cargue es un primer control, no el cierre de la revisión. También pueden quedar fuera de la copia elementos externos, como el servicio de correo o la configuración de una integración. Hay que identificarlos para no confundir «WordPress recuperado» con «toda la operativa comprobada».

La prueba debe estar aislada de la actividad real

Lo razonable es preparar un entorno de pruebas separado, con acceso protegido, y concretar cómo se impedirán efectos sobre clientes, pedidos o sistemas externos. Una web clonada puede conservar conexiones activas: no basta con ponerle otro dominio.

En tiendas, WooCommerce recomienda probar los pedidos en un entorno de staging, separado de la tienda activa. También advierte de que los pedidos de prueba pueden generar correos y aparecer en sus estadísticas. El técnico debe revisar las pasarelas, las notificaciones y las conexiones implicadas antes de iniciar el recorrido.

Nuestra recomendación práctica es dejar por escrito qué acciones se permiten en esa prueba y cuáles se bloquean. Si una conexión con el proveedor, transportista o sistema de reservas no puede probarse de forma segura, debe constar como pendiente; no marcar todo como correcto por haber visto la página en pantalla.

Pide un resultado verificable, no solo «todo bien»

Un registro breve puede ser suficiente si permite entender qué ocurrió. Puedes utilizar estos campos como plantilla orientativa para acordar la entrega:

• Copia utilizada: fecha, hora y componentes recuperados.
• Entorno de prueba: dónde se realizó y cómo se aisló de producción.
• Funciones revisadas: recorrido, resultado y evidencia sin datos privados innecesarios.
• Exclusiones: servicios o integraciones no probados y motivo.
• Incidencias: qué falta resolver, responsable y siguiente paso.
• Tiempo observado: duración de esa prueba y dependencias que podrían cambiarla.

La duración observada sirve para planificar, pero no garantiza que una futura recuperación tarde lo mismo. Influyen el tamaño de la web, el acceso al alojamiento y la incidencia concreta. Tampoco un ensayo satisfactorio asegura que todas las copias futuras estén bien: hay que acordar cuándo repetir la comprobación según los cambios y la importancia de la web.

Revisa lo que ha ocurrido después de la copia

Antes de restaurar la web activa, hay una decisión adicional: qué hacer con los datos recientes. Por ejemplo, en una tienda hipotética cuya copia sea de las 02:00 y que haya recibido pedidos a las 10:00, devolver la base de datos al estado de las 02:00 no conservaría esos pedidos por sí solo.

No es una razón para renunciar a las copias, sino para preparar la intervención. El responsable técnico debe identificar la información posterior al respaldo y valorar cómo preservarla o reconciliarla. Guardar una exportación no significa que después pueda importarse sin conflictos; depende de la instalación y de los sistemas conectados.

En una web de servicios pueden ser consultas o reservas; en una tienda, pedidos, clientes o movimientos de stock. Pide que esta revisión forme parte de la decisión antes de autorizar una restauración en producción.

Cómo encaja esta comprobación en el mantenimiento

Si no tienes claro qué se copia o quién comprobaría la recuperación, reúne esa información antes de que haya una urgencia. En el mantenimiento WordPress de Necotec puedes plantear las funciones críticas de tu web y concretar el alcance de las tareas, las horas necesarias y las dependencias antes de intervenir.

La pregunta final para tu proveedor no debería ser únicamente «¿tenemos copias?», sino «¿qué podríamos recuperar con ellas, qué se ha probado y qué queda por comprobar?». Esa respuesta te ayuda a tomar decisiones con un alcance conocido, sin confundir una copia disponible con una recuperación ya validada.