Un respaldo solo sirve si la restauración funciona

Una prueba de restauración debe recuperar el sitio en un entorno aislado y demostrar que se puede utilizar. Descargar un archivo o recibir una notificación de respaldo exitoso no basta. También hay que medir cuánto trabajo reciente se perdería y cuánto tarda la recuperación completa.

Acuerde los objetivos antes de preparar el servidor

Plantee al negocio dos preguntas distintas: cuánto tiempo puede estar fuera de servicio y cuántos datos recientes podría reconstruir. Las respuestas definen el objetivo de tiempo de recuperación, RTO, y el objetivo de punto de recuperación, RPO. La guía de pruebas de recuperación de AWS recomienda verificar la restauración frente a ambos objetivos.

Un sitio corporativo que cambia poco y una publicación con actualizaciones durante todo el día necesitan frecuencias diferentes. Elija los objetivos según el trabajo expuesto, no según el paquete de alojamiento más barato. Incluya el tiempo para conseguir credenciales, restaurar datos, revisar la aplicación y autorizar la reapertura. Encender el servidor no equivale a recuperar el servicio.

Prepare un destino seguro para restaurar

Cree un entorno aislado con controles de acceso antes de importar el respaldo. Impida que envíe correos reales, cobre pagos, active notificaciones a clientes o ejecute integraciones de producción. Restrinja conexiones salientes cuando sea posible: las credenciales copiadas podrían reconectar la prueba con sistemas reales.

Compruebe que el respaldo contiene los componentes necesarios. La documentación de WordPress diferencia los respaldos de archivos y de base de datos; una recuperación completa habitual necesita ambos. Un sitio a medida también puede depender de archivos de despliegue, almacenamiento multimedia, configuración y acceso a secretos administrados por separado.

Pida a otra persona autorizada que siga las instrucciones escritas. Si solo una persona conoce el proceso y no está disponible, el respaldo puede resultar inútil durante una emergencia. Registre los problemas de acceso sin incluir contraseñas en el informe.

Verifique datos y tareas, no solo la portada

Prepare evidencia del punto de recuperación esperado. Utilice identificadores de contenido y fechas conocidas, en vez de confiar en la memoria. La revisión debería comprobar que:

• Existe un artículo reciente junto con su imagen.
• Las páginas privadas conservan sus restricciones.
• Una persona autorizada puede ingresar y guardar cambios.
• Los formularios llegan a un buzón de prueba, sin contactar destinatarios reales.
• Los registros coinciden con el punto de recuperación elegido.
• Las tareas programadas podrían reactivarse de forma controlada.

Anote lo que quedó fuera. Una restauración aislada no demuestra que funcionará el cambio de DNS o que estará disponible el proveedor de pagos, salvo que también se prueben esas dependencias. Elimine el entorno temporal y sus datos copiados al terminar.

Ejemplo hipotético de una prueba que revela el problema

Imagine una publicación con un RTO de dos horas y un RPO de una hora. Son objetivos hipotéticos. Restaurar archivos y base de datos toma cuarenta minutos, pero recuperar acceso al almacenamiento de imágenes requiere otras dos horas. La aplicación abre, aunque la recuperación incumple el tiempo acordado.

La solución no consiste necesariamente en comprar servidores más rápidos. Documente el acceso delegado al almacenamiento, compruebe que las credenciales se pueden recuperar y repita la prueba. Revise también el artículo más reciente: una restauración rápida con datos de ayer incumpliría el objetivo de pérdida de datos.

Programe una restauración aislada y asigne un responsable a cada fallo encontrado. Lleve esa evidencia a una conversación de soporte y mantenimiento web con 5e Labs.