Restauración activa: ¿Puede la recuperación ante desastres ocurrir más rápido? ¿Mucho mas rápido?

Hacer una copia de seguridad de los datos importantes es algo bueno. Pero ¿qué pasa si el trabajo debe continuar de inmediato y cada minuto cuenta? En Acronis decidimos comprobar qué tan posible es resolver el problema de iniciar el sistema lo más rápido posible. Y esta es la primera publicación de la serie Active Restore, en la que les contaré cómo iniciamos el proyecto junto con la Universidad de Innopolis, qué solución encontramos y en qué estamos trabajando hoy. Los detalles están debajo del corte.

Restauración activa: ¿Puede la recuperación ante desastres ocurrir más rápido? ¿Mucho mas rápido?

¡Hola! Mi nombre es Daulet Tumbayev y hoy me gustaría compartir con ustedes mi experiencia en el desarrollo de un sistema que acelera la recuperación ante desastres. Para hablar de todo el camino de desarrollo del proyecto, comencemos un poco desde lejos. Actualmente trabajo en Acronis, pero también me gradué de la Universidad de Innopolis, donde completé el programa de Maestría en Gestión del Desarrollo de Software (conocido como MSIT-SE). Innopolis es una universidad joven y el plan de estudios es aún más joven. Pero se basa en el plan de estudios de la Universidad Carnegie Mellon, cuyo trabajo incluye temas como los proyectos industriales.

El objetivo del proyecto industrial es sumergir al estudiante en el desarrollo real y consolidar en la práctica los conocimientos adquiridos. Para ello, la universidad coopera con empresas como Yandex, Acronis, MTC y decenas más (en total, en 2018, la universidad contaba con 144 socios). En el marco de la cooperación, las empresas ofrecen sus áreas de trabajo a la universidad y los estudiantes eligen uno de los proyectos que más se acerca a sus intereses y nivel de formación. Hace literalmente dos años todavía estaba "al otro lado de las barricadas" y trabajaba como estudiante en otro proyecto de Acronis. Pero esta vez me convertí en consultor técnico para estudiantes por parte de la empresa y propuse el proyecto Active Restore a Innopolis. La idea misma de Active Restore fue formulada por el equipo Kernel de Acronis, pero el desarrollo de la solución comenzó junto con la Universidad de Innopolis.

Restauración activa: ¿por qué es necesaria?

Tradicionalmente, la recuperación ante desastres funciona según un esquema estándar. Después de problemas con su computadora, vaya a la interfaz web de algún sistema de respaldo, por ejemplo, Acronis True Image, y haga clic en el botón grande "restaurar". A continuación, debe esperar N minutos y solo después podrá continuar trabajando.

Restauración activa: ¿Puede la recuperación ante desastres ocurrir más rápido? ¿Mucho mas rápido?

El problema es que este número N, también conocido como RTO (objetivo de tiempo de recuperación), el tiempo de recuperación permitido, puede ser bastante impresionante, lo que depende de la velocidad de la conexión (si la recuperación es desde la nube), el tamaño del disco duro de su máquina y una serie de otros factores. ¿Es posible reducirlo? Sí, puedes, porque para reanudar el trabajo no siempre necesitas un disco de computadora lleno. Las mismas fotos y vídeos no afectan la funcionalidad del dispositivo de ninguna manera y pueden visualizarse más tarde en segundo plano.

Se necesita conductor...

El sistema operativo espera comenzar con el disco completamente listo. Por ello, Windows realiza una serie de comprobaciones para comprobar la integridad del disco. El sistema no permitirá un inicio normal si algunos archivos que el sistema operativo espera encontrar faltan o están dañados. Para solucionar este problema, se decidió colocar en el disco los llamados archivos redirector que creamos, que reemplazan los archivos faltantes o dañados, pero que en realidad son ficticios. No lleva mucho tiempo crear dichos redirectores, porque en realidad no tienen ningún contenido.

La restauración adicional se produce de la siguiente manera. Mediante un proceso en segundo plano, en paralelo con el funcionamiento del sistema operativo, se rellenan "maniquíes" con datos. El proceso de recuperación en segundo plano tiene en cuenta la carga del disco y no excede el límite especificado. Sin embargo, el usuario o el propio sistema operativo pueden requerir repentinamente un archivo que aún no existe. Aquí es donde entra en juego el segundo modo de recuperación. La prioridad del archivo solicitado se eleva al máximo y el proceso de recuperación carga urgentemente el archivo en el disco. El sistema operativo recibe el archivo requerido, aunque con un ligero retraso.

Así es como se ve una imagen ideal. Sin embargo, en el mundo real, existe una gran cantidad de obstáculos y posibles puntos muertos. Junto con los estudiantes de maestría de Innopolis, decidimos explorar este escenario de recuperación, evaluar las ganancias en RTO y comprender si tal enfoque es factible. Al fin y al cabo, en aquel momento simplemente no existían soluciones de este tipo en el mercado.

Y si decidía confiar el componente de servicio a los chicos de Innopolis, entonces dentro de Acronis comenzó el trabajo en minifiltro por controlador del sistema de archivos. Esto fue hecho por el equipo del Kernel de Windows. El plan era así:

  • Inicie el controlador en una etapa temprana del inicio del sistema operativo.
  • Durante el trabajo, cuando el espacio de usuario estará completamente listo, descarga el servicio
  • El servicio procesa las solicitudes de los conductores y coordina su trabajo posterior.

Restauración activa: ¿Puede la recuperación ante desastres ocurrir más rápido? ¿Mucho mas rápido?

Sutilezas de la ingeniería de conductores.

Si mis colegas hablarán sobre el servicio en otra publicación, en este texto revelaremos las complejidades del desarrollo de controladores. El controlador de minifiltro ya desarrollado tiene dos modos de funcionamiento: cuando el sistema se inicia en modo normal y cuando el sistema acaba de experimentar una falla y se está restaurando. Antes de cargar las bibliotecas y aplicaciones del usuario, y por tanto nuestro servicio, el controlador se comporta igual. No sabe en qué estado se encuentra actualmente el sistema. Como resultado, se registra cada creación, lectura y escritura, y se registran todos los metadatos. Y cuando el servicio está en línea, el conductor proporciona esta información al servicio.

Restauración activa: ¿Puede la recuperación ante desastres ocurrir más rápido? ¿Mucho mas rápido?
En caso de un arranque normal, el servicio envía una señal de “Relax” al conductor para que se “relaje” y deje de registrar escrupulosamente todos los datos. En este caso, el controlador cambia para registrar solo los cambios en el disco y los informa al servicio que, utilizando otras herramientas de Acronis, mantiene la copia de seguridad del disco en el estado más actualizado en los medios especificados por el usuario. Puede ser una copia de seguridad en la nube, remota, gradual o nocturna.

Restauración activa: ¿Puede la recuperación ante desastres ocurrir más rápido? ¿Mucho mas rápido?
Si el modo de recuperación está habilitado, el servicio le dice al conductor que necesita trabajar en modo "Recuperación". El sistema acaba de recuperarse de una falla y tan pronto como solicita abrir un archivo en el disco, el minifiltro debe interceptar esta operación, realizar esta solicitud él mismo, verificar si dicho archivo existe en el disco y si se puede abrir.

Si falta un archivo, el minifiltro transmite esta información al servicio, lo que aumenta la prioridad de recuperación del archivo (todo este tiempo la recuperación se realiza en segundo plano). Resulta que este archivo simplemente salta al principio de la cola. Después de esto, el propio servicio (u otro medio de Acronis) restaura este archivo y le dice al controlador que todo está bien, ahora el sistema operativo puede acceder a él y el controlador "libera" la solicitud original, del sistema al disco.

Si la recuperación es imposible, el servicio informa al controlador que el archivo no está en la copia de seguridad. Nuestro controlador de minifiltro simplemente pasa la solicitud del sistema y el solicitante original (el propio sistema operativo o la aplicación) recibe un error de "archivo no encontrado". Sin embargo, esto es bastante normal si el archivo realmente no estaba en el disco ni en la copia de seguridad.

Restauración activa: ¿Puede la recuperación ante desastres ocurrir más rápido? ¿Mucho mas rápido?

Por supuesto, el sistema operativo funcionará mucho más lento, porque la lectura de cualquier archivo o biblioteca se realiza en varias etapas, posiblemente con acceso a recursos remotos. Pero el usuario puede volver a trabajar lo antes posible mientras aún se lleva a cabo la recuperación.

Necesito más bajo, aún más bajo...

El prototipo ha demostrado su funcionalidad. Pero también encontramos la necesidad de seguir adelante porque en algunos casos todavía hay puntos muertos. Por ejemplo, el sistema operativo puede solicitar varias bibliotecas en varios subprocesos, lo que hace que nuestro servicio vuelva a funcionar.

El problema en el que estoy trabajando actualmente es aumentar la velocidad de Active Restore y aumentar el nivel de seguridad del sistema. Digamos que el sistema no necesita el archivo completo, sino sólo una parte. Para ello, se desarrolló otro controlador: el controlador de filtro de disco. Ya no funciona a nivel de archivo, sino a nivel de bloque. El principio de funcionamiento es similar: en el modo de funcionamiento normal, el controlador simplemente registra los bloques modificados en el disco y, en el modo de recuperación, intenta leer el bloque por sí solo y, si no tiene éxito, solicita al servicio que aumente la prioridad. Sin embargo, todas las demás partes del sistema siguen siendo las mismas. Por ejemplo, un servicio a nivel de sistema operativo ni siquiera sospecha que se le está pidiendo que se comunique con otro controlador, porque la tarea principal es proporcionar al sistema operativo exactamente los datos necesarios para su funcionamiento. Esta área requiere mejoras significativas, aunque sólo sea porque el servicio aún no sabe pensar a nivel de bloque.

En el siguiente paso, decidí ejecutar el controlador más profundamente y antes, descendiendo al nivel de controladores UEFI y aplicaciones nativas de Windows en lugar del servicio. Para ello se desarrolló Controlador de arranque UEFI (o controlador DXE), que se inicia y muere incluso antes de que se inicie el sistema operativo. Pero veremos la "historia" de los controladores UEFI, los detalles sobre el ensamblaje y la instalación, así como los detalles de las aplicaciones nativas de Windows en la próxima publicación. Suscríbete a nuestro blog y, mientras tanto, prepararé una historia sobre la siguiente etapa del trabajo. Estaré encantado de ver tus comentarios y consejos.

Solo los usuarios registrados pueden participar en la encuesta. Registrarsepor favor

¿Alguna vez ha tenido situaciones en las que la recuperación llevó un tiempo insoportablemente largo?

  • 65.1%Sí28

  • 23.2%No10

  • 11.6%No lo pensé5

43 usuarios votaron. 3 usuarios se abstuvieron.

Fuente: habr.com

Añadir un comentario