Hacer copias de seguridad de datos importantes es una buena práctica. Pero, ¿qué pasa si se necesita continuar trabajando de inmediato y cada minuto cuenta? En Acronis decidimos comprobar qué tan rápido se puede iniciar el sistema. Este es el primer post de la serie Active Restore, en el que hablaremos de cómo comenzamos este proyecto junto con la Universidad Innopolis, qué solución encontramos y en qué estamos trabajando hoy. Los detalles están a continuación.
¡Hola! Soy Daulet Tumbaev y hoy quiero compartir con ustedes mi experiencia en el desarrollo de un sistema que acelera la recuperación ante desastres. Para contarles sobre todo el proceso de desarrollo del proyecto, comencemos un poco más lejos. Actualmente trabajo en Acronis, pero también soy graduado de la Universidad Innopolis, donde terminé el programa de maestría en "Gestión del Desarrollo de Software" (conocido como MSIT-SE). Innopolis es una universidad joven y su programa educativo es aún más nuevo. Sin embargo, se basa en los planes de estudios de la Universidad Carnegie Mellon, que incluye temas como proyectos industriales.
El objetivo de un proyecto industrial es sumergir al estudiante en el desarrollo real y consolidar los conocimientos adquiridos en la práctica. Para ello, la universidad colabora con empresas como Yandex, Acronis, MTC y decenas de otras (en total, en 2018, la universidad tenía 144 socios). Durante la colaboración, las empresas ofrecen a la universidad sus áreas de trabajo, y los estudiantes eligen uno de los proyectos que más les interesa y se ajusta a su nivel de preparación. Hace apenas dos años estaba "al otro lado de la barricada" y trabajaba como estudiante en otro proyecto de Acronis. Pero esta vez me convertí en consultor técnico para los estudiantes por parte de la empresa y propuse el proyecto Active Restore. La idea de Active Restore fue formulada por el equipo Kernel de Acronis, sin embargo, el desarrollo de la solución comenzó junto con la Universidad Innopolis.
Active Restore - ¿para qué sirve?
Tradicionalmente, la recuperación ante desastres se lleva a cabo de acuerdo con un esquema estándar. Después de un contratiempo con la computadora, accede a la interfaz web de algún sistema de respaldo, por ejemplo, Acronis True Image, y presiona un gran botón de "restaurar". Luego debe esperar N minutos, y solo después podrá continuar trabajando.
El problema radica en que este número N, también conocido como RTO (objective de tiempo de recuperación), el tiempo de recuperación aceptable, puede ser bastante significativo, dependiendo de la velocidad de la conexión (si la recuperación se realiza desde la nube), del tamaño del disco duro de su máquina y de varios otros factores. ¿Se puede reducir? Sí, se puede, ya que para reanudar la operación no siempre se necesita el disco completo de la computadora. Las fotos y videos no afectan la funcionalidad del dispositivo y se pueden recuperar más tarde en segundo plano.
Se necesita un controlador…
El sistema operativo calcula que debe iniciarse con un disco completamente preparado. Por lo tanto, Windows realiza una serie de comprobaciones de la integridad del disco. El sistema no permitirá un inicio normal si falta o está dañado alguno de los archivos que el OS espera encontrar. Para solucionar este problema, se decidió colocar en el disco los llamados archivos redirigidos, que reemplazan los archivos faltantes o dañados, pero que en realidad son vacíos. Crear tales redirigidos no toma mucho tiempo, ya que en realidad no tienen ningún contenido.
A continuación, la recuperación ocurre de la siguiente manera. Un proceso en segundo plano, en paralelo con el funcionamiento del sistema operativo, llena las "vacías" con datos. El proceso de recuperación en segundo plano tiene en cuenta la carga del disco y no supera el límite establecido. Sin embargo, el usuario o el propio sistema operativo pueden de repente solicitar un archivo que aún no existe. Aquí entra en juego un 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 necesario, aunque con un pequeño retraso.
Así es como se ve la imagen ideal. Sin embargo, en el mundo real, existe una gran cantidad de trampas y posibles bloqueos. Junto con los estudiantes de Innopolis, decidimos investigar este escenario de recuperación, evaluar la ganancia en RTO y comprender si tal enfoque es viable. Es que soluciones como estas no existían en el mercado en ese momento.
Y si decidí dejar el componente de servicio en manos de los chicos de Innopolis, en Acronis comenzó el trabajo en Esto fue abordado por el equipo de Windows Kernel. El plan era el siguiente:
- Iniciar el controlador en una etapa temprana del arranque del sistema operativo,
- Durante el funcionamiento, cuando esté completamente listo, cargar el servicio.
- El servicio procesa las solicitudes del controlador y coordina su funcionamiento posterior.
Particularidades del desarrollo de controladores
Si mis colegas hablarán sobre el servicio en otra publicación, en este texto revelaremos los detalles del desarrollo del controlador. El controlador de mini-filtro ya desarrollado tiene dos modos de operación: cuando el sistema se ha iniciado en modo normal y cuando el sistema acaba de experimentar un fallo y se está recuperando. Antes de que se carguen las bibliotecas y aplicaciones de usuario, y, por lo tanto, nuestro servicio, el controlador se comporta de la misma manera. No sabe en qué estado se encuentra actualmente el sistema. Como resultado, cada creación, lectura y escritura se registra, y se almacenan todos los metadatos. Y cuando el servicio esté en línea, el controlador proporciona esta información al servicio.
En caso de un inicio normal, el servicio envía una señal al controlador de 'Relajar', para que 'se relaje' y deje de registrar minuciosamente todos los datos. En este caso, el controlador pasa a registrar solo los cambios en el disco y los informa al servicio, que, con la ayuda de otras herramientas de Acronis, mantiene la copia de seguridad del disco en el estado más actual posible en el medio que el usuario ha determinado. Esto puede ser copia de seguridad en la nube, remota, incremental o nocturna.
Si se activa el modo de recuperación, el servicio informa al controlador que debe operar en modo 'Recuperación'. El sistema acaba de recuperarse de un fallo y, tan pronto como hace una solicitud para abrir un archivo en el disco, el mini-filtro debe interceptar esta operación, hacer esa solicitud, verificar si existe dicho archivo en el disco y si se puede abrir.
En caso de que falte el archivo, el mini-filtro transmite esta información al servicio, que aumenta la prioridad de recuperación del archivo (mientras tanto, la recuperación se realiza en segundo plano). Así que el archivo simplemente salta al principio de la cola. Después de esto, el servicio restaura el archivo por sí mismo (o mediante otros medios de Acronis) y le informa 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 no es posible, el servicio informa al controlador que el archivo no está en la copia de seguridad. Nuestro mini-filtro controlador simplemente deja pasar la solicitud del sistema y la aplicación original recibe el error "archivo no encontrado". Sin embargo, esto es completamente normal si el archivo realmente no existía en el disco ni en la copia de seguridad.
Por supuesto, el sistema operativo funcionará mucho más lentamente, porque la lectura de cualquier archivo o biblioteca se realiza en varias etapas, y es posible que se acceda a recursos remotos. Pero el usuario puede comenzar a trabajar en el menor tiempo posible, mientras la recuperación aún está en curso.
Necesito más abajo, aún más abajo…
El prototipo ha demostrado su funcionalidad. Pero también identificamos la necesidad de avanzar, porque en algunos casos aún ocurren bloqueos. Por ejemplo, el sistema operativo puede solicitar diferentes bibliotecas en varios hilos, lo que lleva a que nuestro servicio se bloquee a sí mismo.
El problema en el que estoy trabajando ahora es mejorar la velocidad de Active Restore y aumentar el nivel de seguridad del sistema. Supongamos que el sistema no necesita un archivo completo, solo una parte de él. Para esto se desarrolló otro controlador: un controlador de filtro de disco. Funciona no a nivel de archivos, sino a nivel de bloques. El principio de funcionamiento es similar: en modo normal, el controlador simplemente registra los bloques cambiados en el disco, y en modo de recuperación, intenta leer el bloque por sí mismo; en caso de fallo, solicita al servicio que aumente la prioridad. Al mismo tiempo, todas las demás partes del sistema permanecen iguales. Por ejemplo, el servicio a nivel de sistema operativo ni siquiera sospecha que se le está pidiendo que interactúe con otro controlador, porque la tarea principal es proporcionar al sistema operativo exactamente los datos necesarios para su funcionamiento. Esta línea de trabajo requiere mejoras sustanciales, al menos porque el servicio aún no puede pensar a nivel de bloques.
El siguiente paso decidí fue lanzar el controlador más profundo y más temprano, bajando al nivel de controladores UEFI y aplicaciones nativas de Windows en lugar del servicio. Para esto se desarrolló el (o controlador DXE), que se activa y se apaga incluso antes de que el sistema operativo arranque. Pero la "historia" de los controladores UEFI, los detalles sobre la compilación y la instalación, así como la especificidad de las aplicaciones nativas de Windows, lo discutiremos en la próxima publicación. Así que suscríbanse a nuestro blog, y yo mientras tanto me prepararé para hablar sobre la siguiente etapa del trabajo. Agradeceré sus comentarios y consejos.
Solo los usuarios registrados pueden participar en la encuesta. , por favor.
¿Alguna vez has tenido situaciones en las que la recuperación tomó increíblemente mucho tiempo?
65.1%Sí28
23.2%No10
11.6%No he pensado en ello5
Votaron 43 usuarios. 3 usuarios se abstuvieron.
Fuente: habr.com
