¿Qué debería recuperar una copia de seguridad de un sitio web?

Una copia de seguridad puede terminar correctamente sin que nadie haya probado la recuperación. El informe de éxito no demuestra que esa copia permita recuperar las partes del sitio web que necesita el negocio. Incluso si se restaura la página de inicio, eso no indica si el equipo podrá iniciar sesión, encontrar los datos de los clientes o abrir los documentos subidos.

Empiece por el trabajo diario. ¿Qué necesitaría hacer en el sitio web después de perderlo? Después, pida a su proveedor que le explique qué tendría que recuperarse para poder hacerlo.

La reserva y su documento adjunto van juntos

Imagine un sitio web de reservas que guarda las citas en una base de datos y los documentos de los clientes como archivos subidos. Es un ejemplo hipotético, pero el problema se entiende enseguida: recupera la reserva, hace clic en el documento adjunto y descubre que falta.

Tiene los datos de la reserva. Aun así, no puede hacer el trabajo para el que necesita el documento.

En un sitio web típico de WordPress, la guía de copias de seguridad de WordPress explica que hacen falta tanto la base de datos como los archivos, y que deben conservarse como un conjunto coherente. Otros sitios pueden estar construidos de otra manera. Pregunte dónde se guardan realmente sus registros y archivos subidos, en vez de dar por hecho que una copia de una sola carpeta los incluye.

También importan el software del sitio web, su configuración y los accesos necesarios para restaurarlo y utilizarlo. Lo mismo ocurre con los servicios conectados. La guía de gestión de sistemas de la Dirección de Señales de Australia recomienda recuperar los datos, las aplicaciones y la configuración hasta un mismo punto, y detectar antes las dependencias. Para el propietario de un negocio, eso significa preguntar si todas las piezas funcionarán juntas y quién tiene acceso para recuperarlas.

¿Cuánto trabajo reciente podría faltar?

Una copia restaurada corresponde a un momento anterior del sitio web. Una reserva creada después de ese momento podría faltar, aunque la restauración funcione tal como se esperaba.

Pida a su proveedor que indique hasta qué momento podría recuperar el sitio y qué antigüedad tendría esa información cuando la necesitara. Después, piense en lo que supondría el trabajo perdido. ¿Podría el equipo reconstruirlo a partir de otro registro? ¿Habría que avisar a los clientes? La respuesta adecuada depende de lo que haga su sitio web.

También cuenta el tiempo que se tarda en volver al trabajo. Copiar los datos de vuelta es solo una parte. Alguien tiene que restaurar las demás piezas y comprobar que las tareas importantes funcionan. La guía de AWS sobre pruebas de recuperación recomienda probar la recuperación por separado, comprobar que se puede acceder a los datos restaurados y utilizarlos, y medir su antigüedad y el tiempo necesario para restaurarlos y validarlos según las necesidades del negocio.

Pregunte cuánto tardaron esos pasos en la prueba. Así tendrá un dato concreto para conversar. No es una promesa sobre cuánto durará un incidente futuro de principio a fin, porque también hay que detectar el problema y decidir qué hacer.

Puede que el pago ya se haya realizado

Volvamos al ejemplo de la reserva. Suponga que el cliente pagó una señal mediante un servicio de pago externo. Restaurar una copia antigua del sitio web no deshace ese pago ni demuestra que los registros del sitio coincidan con los del servicio de pago.

Si la reserva se guarda en un servicio externo, quizá ni siquiera figure en la copia del sitio web. Pregunte qué sistema contiene el registro en el que debe confiar el equipo, qué puede recuperar ese servicio y cómo comprobará alguien que los registros coinciden. Restaurar su sitio web no puede hacer retroceder todo lo que está conectado a él.

Pida una restauración segura

El siguiente paso útil es que personas autorizadas hagan una restauración planificada en un entorno aislado. Acuerden quién la hará y qué comprobará. La copia restaurada debe proteger los datos personales y del negocio, no quedar expuesta al público y dejar intactos los registros activos.

También hay que impedir que envíe correos reales, cobre pagos, active solicitudes automáticas a otros servicios o cree reservas reales. Las cuentas y conexiones de prueba controladas pueden ayudar cuando estén disponibles. Si no se puede utilizar un servicio de forma segura durante la prueba, anote esa limitación y compruebe su función por separado.

En nuestro ejemplo hipotético, el proveedor restauraría una copia coherente, iniciaría sesión con un acceso controlado, abriría la reserva elegida y su documento adjunto, y los compararía con lo que debería existir en ese momento de recuperación. Esto resulta mucho más útil que una captura de la página de inicio.

El relato de GitLab sobre su interrupción de la base de datos de enero de 2017 ofrece un recordatorio histórico de por qué importa: el informe de GitLab sobre la interrupción de enero de 2017. Las copias de seguridad de la base de datos que se esperaban no estaban disponibles y los correos de error habían sido rechazados; la recuperación dependió de otra instantánea. La pérdida afectó a información de la base de datos de GitLab.com, no a los datos de los repositorios ni a los clientes que gestionaban su propia instalación. El caso muestra la diferencia entre tener copias de seguridad previstas y contar con una forma útil de volver a trabajar.

Use el resultado para decidir qué hay que cambiar

Pida un breve registro de qué se restauró y desde qué momento, qué tareas se comprobaron y qué ocurrió. También debería indicar la antigüedad de la información restaurada, cuánto tardaron la restauración y las comprobaciones, qué accesos y servicios conectados hicieron falta, y qué falló o quedó sin probar.

Comprobar una reserva demuestra que esa tarea funcionó en esas condiciones de prueba. No demuestra que todos los registros estén intactos, que todas las funciones vayan bien ni que cualquier recuperación futura tarde lo mismo. Una copia aislada tampoco demuestra por sí sola que el sitio recuperado sea seguro o esté libre de un ataque.

Compare el resultado con lo que necesita su negocio. Puede tener pruebas suficientes de que la cobertura acordada le sirve. Puede descubrir una carencia concreta, como archivos subidos que faltan o una cuenta inaccesible. O la prueba puede dejar sin respuesta una tarea importante y hacer falta ir más allá.

Si está hablando con LINK-V sobre el mantenimiento de sitios web, lleve una lista de las tareas que su equipo y sus clientes necesitarían realizar después de una recuperación. Entonces podrán acordar qué cubrir y qué pruebas de restauración necesita su sitio web.