备份重要数据是好的。 但是，如果需要立即继续工作并且每一分钟都很重要，该怎么办？ Acronis的我们决定检查尽可能快地解决启动系统任务的可能性。 这是“活动还原”系列的第一篇文章，我将告诉您我们如何与Innopolis University合作启动该项目，找到了什么解决方案以及我们现在正在做什么。 详细信息-下切。
你好 我叫Daulet Tumbaev，今天，我想与大家分享我在开发可加速灾难恢复的系统方面的经验。 要谈论项目的整个开发路径，让我们从头开始。 我目前在Acronis工作，但我也是Innopolis大学的毕业生，我毕业于软件开发管理硕士学位（称为MSIT-SE）。 Innopolis是一所年轻的大学，课程甚至更年轻。 但是，它是建立在卡内基·梅隆大学（Carnegie Mellon University）的课程基础上的，其成就涉及诸如工业项目之类的话题。
工业项目的目的是使学生沉浸在实际发展中，并巩固在实践中获得的知识。 为此，该大学与Yandex，Acronis，MTC等公司合作，并与其他数十家公司合作（该大学在2018年共有144个合作伙伴）。 在合作过程中，公司会向大学提供工作指导，学生可以从他们的兴趣和培训水平中选择与他们更接近的项目之一。 就在两年前，我还处于“路障的另一边”，并在另一个Acronis项目中当学生。 但是这次，我成为了该公司学生的技术顾问，并向Innopolis提出了Active Restore项目。 Active Restore的想法是由Acronis的内核团队提出的，但是该解决方案的开发始于Innopolis大学。
活动还原-为什么需要这样做？
传统上，灾难恢复按照标准方案进行。 在计算机出现故障之后，您可以转到某些备份系统的Web界面，例如Acronis True Image，然后单击大的“还原”按钮。 接下来，您需要等待N分钟，然后您才能继续工作。
问题在于，该数字N（也称为RTO（恢复时间目标），即允许的恢复时间）会非常令人印象深刻，这取决于连接速度（如果从云中进行恢复），计算机硬盘的容量以及其他许多因素。 可以减少吗？ 是的，您可以，因为为了继续工作，您并不总是需要完整的计算机磁盘。 相同的照片和视频不会影响设备的功能，以后可以在后台将其拉起。
需要驱动程序...
操作系统希望从完全完成的磁盘开始。 因此，Windows会进行一系列磁盘完整性检查。 如果操作系统预期找不到某些文件，则系统将不允许正常启动。 为了解决此问题，决定将我们创建的所谓的重定向器文件放在磁盘上，该文件将替换丢失或损坏的文件，但实际上是虚拟文件。 创建这样的重定向器并不长，因为实际上它们没有内容。
进一步恢复发生如下。 后台进程与操作系统的运行并行，“虚拟”充满了数据。 后台恢复过程会考虑磁盘上的负载，并且不会超过设置的限制。 但是，用户或操作系统本身可能突然请求一个尚不存在的文件。 这是第二恢复模式起作用的地方。 所请求文件的优先级增加到最大，并且恢复过程紧急将文件上传到磁盘。 操作系统会接收所需的文件，尽管会稍有延迟。
看起来很完美。 但是，在现实世界中，存在大量陷阱和潜在的僵局。 我们决定与Innopolis本科生一起调查这种恢复方案，评估RTO的收益，并了解这种方法是否可行？ 确实，当时市场上根本没有这种决策。
如果我决定将服务组件交给Innopolis的那些家伙，那么在Acronis内部，便开始使用
微型过滤器文件系统驱动程序 。 这是由Windows内核团队完成的。 计划是这样的：
- 在启动操作系统的早期阶段运行驱动程序，
- 在操作过程中，当用户空间已准备就绪时，请下载服务
- 该服务处理驱动程序的请求并协调其进一步的工作。
驱动程序工程的精妙之处
如果我的同事将在另一篇文章中谈论该服务，那么在本文中，我们将揭示驱动程序开发的精妙之处。 已经开发的驱动程序微型过滤器具有两种操作模式-系统以正常模式启动时以及系统刚经历故障并恢复时。 在加载用户库和应用程序以及我们的服务之前，驱动程序的行为相同。 他不知道系统现在处于哪个状态。 结果，记录了每个创建，读取和写入操作，并记录了所有元数据。 并且当服务在线时，驱动程序会将此信息提供给服务。
在正常启动的情况下，服务会向驾驶员发送“放松”信号，以便其“放松”并停止仔细记录所有数据。 在这种情况下，驱动程序将切换为仅记录磁盘上的更改并将其报告给服务，这将在其他Acronis工具的帮助下将磁盘备份保持在用户定义的介质上的最新状态。 这可以是云备份，远程备份，渐进备份或夜间备份。
如果启用了恢复模式，该服务会通知驱动程序它需要在“恢复”模式下工作。 系统在出现故障后才刚刚恢复，并且在发出打开磁盘上文件的请求后，微型过滤器应拦截此操作，自行发出此请求，检查磁盘上是否存在此类文件以及是否可以打开该文件。
如果没有文件，则微型过滤器会将此信息传输到服务，这将增加文件恢复的优先级（一直以来，恢复正在进行中）。 原来，该文件只是跳到队列的开头。 之后，服务本身（或通过其他Acronis工具）将还原该文件并告诉驱动程序一切正常，现在操作系统可以访问该文件，并且驱动程序“释放”原始请求，从系统到磁盘。
如果无法恢复，则该服务会通知驱动程序备份中也没有文件。 我们的微型筛选器驱动程序只是进一步跳过了系统请求，原始请求者（操作系统本身或应用程序）收到“找不到文件”错误。 但是，如果文件确实不在磁盘和备份中，则这是很正常的。
当然，操作系统的运行速度会慢得多，因为读取文件或库的过程分为多个阶段，并且可能会访问远程资源。 但是，当恢复仍在进行时，用户可以尽快开始工作。
需要更低，甚至更低...
该原型已证明其价值。 但是我们也发现有必要继续前进，因为在某些情况下仍然会发生死锁。 例如，操作系统可能在多个线程中请求各种库，这导致我们自身的服务关闭。
我现在正在处理的问题是提高Active Restore的速度并提高系统安全性。 假设系统不需要整个文件，而只需要一部分。 为此，开发了另一个驱动程序-磁盘过滤器驱动程序。 它不再适用于文件，而是适用于块级。 操作原理类似：在正常操作中，驱动程序仅将更改后的块记录在磁盘上，而在恢复模式下，驱动程序尝试自行读取该块，如果发生故障，它会请求服务提高优先级。 但是，系统的所有其他部分保持不变。 例如，一个OS级服务甚至不怀疑它是提供与另一个驱动程序进行通信的，因为主要任务是为OS提供恰好可以正常运行的数据。 如果仅因为服务仍然不知道如何在块级别思考，则此方向需要重大改进。
下一步，我决定更深入，更早地运行驱动程序，降至UEFI驱动程序和本机Windows应用程序（而不是服务）级别。 为此，开发了
UEFI引导驱动程序 （或DXE驱动程序），该驱动程序会在操作系统启动之前启动并消失。 但是UEFI驱动程序的“历史”，有关组装和安装的详细信息以及Windows Native应用程序的详细信息，我们将在下一篇文章中进行讨论。 因此，订阅我们的博客，现在，我将准备一个有关下一阶段工作的故事。 我很高兴为您提供意见和建议。