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