Todas las publicaciones
Artículo

Qué debe demostrar una prueba de restauración de un respaldo del sitio web

Pide un informe de restauración que detalle el respaldo, los datos recuperables, las pruebas aisladas, el tiempo transcurrido y los pendientes.

Por Noe Guerrero III

Pide un informe breve después de una prueba de restauración de un respaldo del sitio web. Debe identificar qué se restauró, hasta qué momento llegan los datos recuperables, qué se revisó, el tiempo transcurrido y los pendientes. Una captura de la página de inicio sirve como evidencia de una página; no demuestra que los registros, los archivos cargados y los procesos conectados del sitio se puedan recuperar.

El informe no tiene que ser complicado. Necesita suficientes detalles para que tú y tu desarrollador puedan decidir qué corregir y qué probar después. Esta es una forma práctica de definir el alcance del ensayo sin experimentar con el negocio en funcionamiento.

Identifica las partes que intentas recuperar

Empieza con una lista de componentes. Según el sitio, puede incluir los archivos de la aplicación, la base de datos, los archivos multimedia cargados, los requisitos de configuración y las instrucciones para reconstruir el entorno donde funciona. Pregunta dónde se respalda cada componente y quién puede obtenerlo.

Especifica qué incluye el “respaldo del sitio web”. La guía oficial de respaldos de WordPress explica que un sitio típico de WordPress necesita tanto los archivos como la base de datos para una restauración completa. Descargar el directorio del sitio normalmente no incluye la base de datos que se almacena por separado. Otras plataformas necesitan su propia revisión de cobertura.

También enumera las dependencias que quedan fuera del respaldo. Tu proveedor de correo, la cuenta del dominio, el procesador de pagos o el servicio externo de reservaciones pueden tener sus propios datos y procesos de recuperación. Registra quién administra cada uno. Recuperar los archivos del sitio no demuestra que esos servicios separados también se hayan recuperado.

La lista de componentes debe indicar qué está incluido, qué está excluido, qué se debe proporcionar por separado y quién es responsable del siguiente paso. Registra dónde se puede obtener la configuración autorizada; no incluyas contraseñas ni claves privadas en el informe.

Separa el punto de recuperación de los datos del tiempo de recuperación

Aquí hay dos preguntas para el negocio: cuánto trabajo reciente podría faltar y cuánto tiempo toma restablecer el servicio necesario.

La guía de NIST sobre planeación de respaldos para proveedores de servicios distingue entre la antigüedad aceptable de los datos respaldados y el plazo deseado para restaurarlos. Acuerda ambos con el negocio antes de considerar exitoso un ensayo.

Imagina un taller de muebles a la medida en McAllen que recibe solicitudes de cotización con bocetos adjuntos a través de su sitio web. Es un ejemplo hipotético. El respaldo elegido contiene datos hasta las 9:00 a.m., hora Central, y el ensayo empieza a las 10:00 a.m. La hora entre esos momentos representa un posible periodo de datos faltantes que deben discutir; no es el tiempo que tardó la restauración.

Pídele al desarrollador que identifique el punto real hasta el que se pueden recuperar los datos. La hora de inicio del respaldo, su hora de finalización y el registro más reciente incluido no son intercambiables. Si la base de datos y los archivos multimedia provienen de copias tomadas en momentos distintos, pregunta cómo se comprobó su consistencia. Un registro de cotización que apunta a un boceto faltante es un resultado incompleto, aunque la página abra.

Anota cuánta pérdida de trabajo ha acordado tolerar el negocio y el proceso para conciliar cualquier dato que quede fuera de la copia restaurada. No des por hecho, sin discutirlo, que cada consulta se puede reconstruir a partir de una notificación por correo.

Aprueba un ensayo aislado

Pídele al desarrollador que prepare un entorno de prueba con acceso restringido antes de restaurar la copia. Confirma que no pueda enviar correos a clientes, cobrar a una tarjeta, crear una reservación real ni activar integraciones en producción. Darle una dirección distinta a un sitio clonado no basta para establecer esos límites.

Acuerden qué datos se permiten en el ensayo. Cuando sea posible, usa registros ficticios designados y cuentas de prueba para las revisiones, y protege los datos del negocio que se copien bajo los mismos criterios de acceso que los originales. La configuración de visibilidad en buscadores, por sí sola, no es un control de acceso.

Pide una definición clara del alcance: ubicación de la prueba, persona responsable, referencia del respaldo, acciones permitidas y conexiones excluidas. Verifica la separación antes de que alguien recorra el proceso. Este artículo describe qué pedirle al desarrollador; no es una instrucción para sobrescribir el sitio en producción.

Para el ejemplo del taller, el envío controlado de una solicitud de cotización podría guardar datos únicamente en la base de datos del ensayo y en un buzón de prueba designado. Un servicio de correo de producción desconectado debe registrarse como excluido, con un plan de verificación separado si la entrega de correos es importante para la recuperación.

Revisa una parte útil de la operación del negocio

Elige las revisiones antes de restaurar. Incluye páginas públicas representativas, un registro de prueba existente que hayas designado y los archivos multimedia adjuntos a él. Después, prueba un proceso acordado en el entorno aislado. Si el sitio admite inglés y español, incluye ambos cuando el contenido restaurado o la navegación puedan ser distintos.

Para el taller hipotético, eso podría significar abrir una página de servicios, encontrar una solicitud de cotización ficticia creada antes del punto del respaldo, abrir su boceto y enviar una nueva solicitud ficticia a la copia aislada. Pídele al desarrollador que inspeccione el resultado guardado, en lugar de depender únicamente de la pantalla de confirmación del cliente.

Lo siguiente es un ejemplo ficticio de entradas del informe, no evidencia de una prueba de un cliente real:

Componente o revisiónEvidencia esperadaEjemplo de entrada del informe
Página de serviciosContenido aprobado de la página del respaldo elegidoPasó: página y navegación revisadas en ambos idiomas admitidos
Solicitud de cotización ficticia existenteRegistro identificado incluido antes del punto de restauraciónPasó: los campos esperados coincidieron con el registro de prueba designado
Boceto adjuntoArchivo enlazado desde esa solicitud ficticiaFalló: registro restaurado, archivo adjunto no disponible
Nueva solicitud ficticiaRegistro guardado en la base de datos aisladaPasó: resultado guardado inspeccionado con una cuenta de prueba
Entrega de correo de producciónRevisión de entrega acordada por separadoExcluido: remitente de producción desconectado; revisión separada asignada

Distingue entre pasó, falló, excluido y sin verificar. “No lo revisamos” debe quedar visible. Un archivo adjunto faltante necesita una persona responsable y una corrección, aunque el resto de la página se vea bien.

Mide todo el ejercicio acordado

Define de antemano cuándo empieza y termina la medición. ¿El tiempo empezó a contarse cuando alguien pidió acceso, cuando comenzó la descarga del respaldo o cuando se ejecutó el comando de restauración? ¿Terminó cuando cargó la página de inicio o cuando se completaron las revisiones acordadas?

Registra esos momentos por separado. Incluye el tiempo dedicado a obtener el respaldo, conseguir acceso autorizado, reconstruir la configuración faltante y revisar el resultado. Si alguien preparó el entorno de antemano, indícalo también. De lo contrario, un ensayo rápido puede ocultar trabajo de preparación que todavía sería necesario durante una interrupción del servicio.

Informa la duración observada y las condiciones. No conviertas un ensayo exitoso en una promesa de que todos los incidentes futuros tomarán el mismo tiempo. Esta prueba tampoco demuestra que sea seguro usar un respaldo después de un incidente de seguridad; eso requiere su propia evaluación.

Termina con responsables y una nueva prueba

Cierra el informe con los pendientes, la persona responsable de cada corrección y lo que contará como una nueva prueba exitosa. Para el boceto faltante, la siguiente tarea es identificar el problema en la cobertura de archivos multimedia, corregirlo y demostrar el archivo adjunto restaurado a partir de un conjunto de respaldos adecuado.

Conserva el informe junto con las instrucciones de recuperación y repite las revisiones pertinentes después de cambios importantes en el hosting, el almacenamiento o la aplicación del sitio. Nuestra lista de revisión para lanzar una app de negocio incluye la recuperación junto con los permisos y otras revisiones previas al lanzamiento; este informe de ensayo le da a la conversación sobre recuperación su propia evidencia.

Lleva la lista de componentes y el último informe a tu próxima conversación de mantenimiento. Te dan una pregunta mucho mejor que “¿Están activados los respaldos?”: ¿qué puede recuperar este negocio y qué falta por demostrar?