La sauvegarde des données importantes est essentielle. Mais que faire si vous devez continuer à travailler immédiatement, et chaque minute compte ? Chez Acronis, nous avons décidé d'explorer la possibilité de lancer un système aussi rapidement que possible. C'est le premier article d'une série sur Active Restore, où je vous expliquerai comment nous avons débuté le projet en collaboration avec l'Université d'Innopolis, quelle solution nous avons trouvée et sur quoi nous travaillons aujourd'hui. Les détails se trouvent ci-dessous.
Salut ! Je m'appelle Daulet Tumbaev, et aujourd'hui, j'aimerais partager avec vous mon expérience de développement d'un système qui accélère la récupération après sinistre. Pour vous raconter tout le parcours du projet, commençons par le début. Je travaille actuellement chez Acronis, mais je suis également diplômé de l'Université d'Innopolis, où j'ai terminé le programme de maîtrise en "Gestion du développement de logiciels" (appelé MSIT-SE). Innopolis est une université récente, et le programme d'études l'est encore plus. Néanmoins, il est basé sur les programmes de l'Université Carnegie Mellon, qui a une expertise en industrie.
L'objectif du projet industriel est d'immerger l'étudiant dans un développement réel et de consolider ses connaissances par la pratique. Pour cela, l'université collabore avec des entreprises telles que Yandex, Acronis, MTC et des dizaines d'autres (en 2018, l'université comptait 144 partenaires). Au cours de cette collaboration, les entreprises proposent à l'université leurs directions de travail, et les étudiants choisissent l'un des projets qui leur correspondent le mieux en termes d'intérêts et de niveau de préparation. Il y a à peine deux ans, j'étais encore "de l'autre côté de la barricade" et je travaillais comme étudiant sur un autre projet d'Acronis. Mais cette fois-ci, je suis devenu consultant technique pour les étudiants du côté de l'entreprise et j'ai proposé au projet Active Restore à Innopolis. L'idée même d'Active Restore a été formulée par l'équipe Kernel chez Acronis, mais le développement de la solution a commencé avec l'Université d'Innopolis.
Active Restore – pourquoi est-ce nécessaire ?
Traditionnellement, la récupération après sinistre fonctionne selon un schéma standard. Après un problème avec l'ordinateur, vous accédez à l'interface web d'un système de sauvegarde, par exemple Acronis True Image, et vous appuyez sur le gros bouton "restaurer". Ensuite, vous devez attendre N minutes, et seulement après cela vous pourrez continuer à travailler.
Le problème réside dans le fait que ce nombre N, également connu sous le nom de RTO (objectif de temps de récupération), le temps de récupération acceptable, peut être considérable, dépendant de la vitesse de connexion (si la récupération se fait à partir du cloud), de la taille du disque dur de votre machine et de plusieurs autres facteurs. Peut-on le réduire ? Oui, c'est possible, car pour reprendre le travail, il n'est pas toujours nécessaire d'avoir un disque plein. Les photos et vidéos, par exemple, n'affectent en rien la fonctionnalité de l'appareil et peuvent être récupérées plus tard en arrière-plan.
Pilote requis...
Le système d'exploitation prévoit de démarrer avec un disque complètement préparé. Par conséquent, Windows effectue une série de vérifications de l'intégrité du disque. Le système ne permettra pas un démarrage normal en l'absence ou en cas de corruption de certains fichiers que l'OS s'attend à trouver. Pour résoudre ce problème, il a été décidé d'ajouter sur le disque des fichiers appelés redirections, qui remplacent les fichiers manquants ou corrompus, mais qui, en réalité, sont des coquilles vides. Créer de tels redirigeurs ne prend pas longtemps, car ils ne contiennent réellement aucune information.
La récupération se déroule ensuite comme suit. En arrière-plan, parallèlement au fonctionnement du système d'exploitation, les "coquilles vides" sont remplis de données. Le processus de récupération en arrière-plan prend en compte la charge sur le disque et ne dépasse pas la limite fixée. Cependant, l'utilisateur ou le système d'exploitation lui-même peut soudainement exiger un fichier qui n'est pas encore disponible. C'est là qu'intervient le deuxième mode de récupération. La priorité du fichier demandé est élevée au maximum, et le processus de récupération charge en urgence le fichier sur le disque. Le système d'exploitation obtient le fichier nécessaire, même avec un léger retard.
Voici le tableau idéal. Cependant, dans le monde réel, il existe une multitude de pièges et de blocages potentiels. Avec des étudiants de l'Université Innopolis, nous avons décidé d'explorer ce scénario de récupération, d'évaluer le gain en RTO et de comprendre si une telle approche est réalisable. Car de telles solutions n'existaient tout simplement pas sur le marché à ce moment-là.
Et si j'ai décidé de confier l'aspect service aux gars d'Innopolis, alors au sein d'Acronis, le travail sur C'est ce dont s'est occupée l'équipe Windows Kernel. Le plan était le suivant :
- Lancer le pilote à un stade précoce du démarrage du système d'exploitation,
- Lors de son fonctionnement, lorsque sera entièrement prêt, charger le service
- Le service traite les requêtes du pilote et coordonne son fonctionnement ultérieur.
Les subtilités du développement de pilotes
Si mes collègues parleront du service dans un autre post, cet article va explorer les détails du développement du pilote. Un pilote de mini-filtre déjà développé a deux modes de fonctionnement - lorsque le système démarre en mode normal, et lorsque le système vient de subir un crash et est en cours de récupération. Avant le chargement des bibliothèques et des applications utilisateur, et donc de notre service, le pilote se comporte de la même manière. Il ne sait pas dans quel état le système se trouve actuellement. En conséquence, chaque création, lecture et écriture est enregistrée, toutes les métadonnées sont fixées. Et lorsque le service sera en ligne, le pilote fournit ces informations au service.
En cas de démarrage normal, le service envoie un signal "Relax" au pilote, pour qu'il "se détende" et cesse de protocoler toutes les données de manière scrupuleuse. Dans ce cas, le pilote passe à la protocolisation uniquement des modifications sur le disque et les communique au service, qui, à l'aide d'autres outils Acronis, maintient la sauvegarde du disque dans un état aussi actuel que possible sur le support déterminé par l'utilisateur. Cela peut être une sauvegarde cloud, distante, incrémentielle ou nocturne.
Si le mode de récupération est activé, le service informe le pilote qu'il doit fonctionner en mode "Recovery". Le système vient de se remettre d'un crash, et dès qu'il fait une demande pour ouvrir un fichier sur le disque, le mini-filtre doit intercepter cette opération, faire cette demande lui-même, vérifier si ce fichier existe sur le disque et s'il peut être ouvert.
En l'absence de fichier, le mini-filtre transfère cette information au service, qui augmente la priorité de la restauration du fichier (pendant ce temps, la restauration se poursuit en arrière-plan). Ainsi, ce fichier se retrouve simplement en tête de la queue. Par la suite, le service restaure ce fichier (soit de manière autonome, soit par d'autres moyens Acronis) et informe le pilote que tout est en ordre, permettant ainsi au système d'exploitation d'y accéder, et le pilote "libère" la requête originale, de la part du système vers le disque.
Si la restauration est impossible, le service informe le pilote qu'il n'y a pas de fichier, même dans la sauvegarde. Notre mini-filtre pilote se contente de laisser passer la requête système, et la requête originale (le système d'exploitation lui-même ou l'application) reçoit une erreur "fichier non trouvé". Cela dit, c'est tout à fait normal si le fichier n'était effectivement pas présent sur le disque et dans la sauvegarde.
Bien sûr, le système d'exploitation fonctionnera beaucoup plus lentement, car la lecture de tout fichier ou bibliothèque se fait en plusieurs étapes, et peut nécessiter un accès à des ressources distantes. Mais de cette façon, l'utilisateur peut commencer à travailler dans les plus brefs délais, pendant que la restauration est toujours en cours.
Il faut aller plus bas, encore plus bas…
Le prototype a prouvé son efficacité. Cependant, nous avons également découvert la nécessité d'aller plus loin, car dans certains cas, des blocages se produisent encore. Par exemple, le système d'exploitation peut demander différentes bibliothèques à travers plusieurs threads, ce qui conduit notre service à se bloquer sur lui-même.
Le problème sur lequel je travaille actuellement est l'augmentation de la vitesse de la restauration active et l'amélioration de la sécurité du système. Supposons que le système n'ait pas besoin d'un fichier entier, mais seulement d'une partie. Pour cela, un autre pilote a été développé : un filtre de pilote de disque. Il fonctionne non pas au niveau des fichiers, mais au niveau des blocs. Le principe de fonctionnement est similaire : en mode normal, le pilote enregistre simplement les blocs modifiés sur le disque, et en mode de récupération, il tente de lire le bloc lui-même; en cas d'échec, il demande au service d'augmenter la priorité. Pendant ce temps, toutes les autres parties du système restent inchangées. Par exemple, le service au niveau du système d'exploitation n'a même pas de soupçons qu'il lui est proposé de communiquer avec un autre pilote, car l'objectif principal est de fournir au système d'exploitation exactement les données nécessaires à son fonctionnement. Ce domaine nécessite des améliorations substantielles, ne serait-ce que parce que le service ne sait pas encore penser au niveau des blocs.
L'étape suivante consistera à lancer le pilote plus en profondeur et plus tôt, en descendant au niveau des pilotes UEFI et des applications Windows natives au lieu du service. Pour cela, un ou pilote DXE, qui démarre et s'arrête avant même le démarrage du système d'exploitation. Mais nous examinerons l'histoire des pilotes UEFI, les détails de la construction et de l'installation, ainsi que les spécificités des applications Windows natives dans le prochain article. Alors, abonnez-vous à notre blog, pendant que je prépare le récit de la prochaine étape des travaux. Je serais ravi de vos commentaires et conseils.
Seuls les utilisateurs enregistrés peuvent participer au sondage. , s'il vous plaît.
Avez-vous déjà rencontré des situations où la restauration prenait une éternité :
65.1%Oui28
23.2%Non10
11.6%Je n'y pensais pas
43 utilisateurs ont voté. 3 utilisateurs se sont abstenus.
Source : habr.com
