向我们的博客读者问好！ 我们已经部分熟悉了 - 我的英文帖子出现在这里，由我亲爱的同事翻译 。 这次我决定直接向俄语观众讲话。
对于我的首次亮相，我想找到一个尽可能广泛的受众感兴趣并且需要详细考虑的主题。 丹尼尔·笛福认为，死亡和税收等待着每个人。 就我而言，我可以说任何支持工程师都会对恢复点存储策略（或更简单地说，保留）有疑问。 四年前，作为一名初级初级工程师，我开始解释如何保留人才，现在我已经作为西班牙语和意大利语团队的领导者继续解释。 我确信来自第二级甚至第三级支持的同事也会定期回答同样的问题。
有鉴于此，我想写一篇尽可能详细的最终文章，供俄语用户可以一次又一次地返回作为参考书。 现在正是时候——最近发布的十周年纪念版在多年来未曾改变的基本功能上添加了新功能。 我的帖子主要关注这个版本 - 尽管大部分内容都适用于以前的版本，但您根本找不到其中描述的一些功能。 最后，展望未来，我会说下一个版本中预计会有一些变化，但我们会在时机成熟时告诉您。 那么让我们开始吧。
备份作业
首先我们看一下版本10中没有改变的部分。保留策略是由几个参数决定的。 让我们打开用于创建新任务的窗口并转到“存储”选项卡。 在这里我们将看到一个参数，该参数确定所需的还原点数量：
然而，这只是等式的一部分。 实际点数还取决于为作业设置的备份模式。 要选择此选项，请单击同一选项卡上的“高级”按钮。 这将打开一个包含许多选项的新窗口。 让我们对它们进行编号并一一考虑：
如果仅启用选项 1，作业将以“永远向前增量”模式运行。 这里没有困难 - 该任务将存储从完整备份（具有 VBK 扩展名的文件）到最后一个增量（具有 VIB 扩展名的文件）的指定数量的恢复点。 当点数超过设定值时，最旧的增量将与完整备份合并。 换句话说，如果任务设置为存储 3 个点，那么在下一个会话之后，存储库上将立即有 4 个点，之后完整备份将与最旧的增量合并，并且点总数将返回到3.
“反向增量”模式（选项2）的保留也非常简单。 由于在这种情况下，最新的点将是完整备份，然后是一系列所谓的回滚（具有 VRB 扩展名的文件），因此要应用保留，只需删除最旧的回滚就足够了。 情况也是一样的：会话结束后，点数会超过设定值1，之后又会恢复到所需值。
请注意，使用反向增量模式，您还可以启用定期完整备份（选项4），但这不会改变本质。 是的，完整的恢复点会出现在链中，但我们仍然会简单地一一删除最旧的点。
最后，我们来到了有趣的部分。 如果您激活增量备份，但另外启用选项 3 或 4（或同时启用两者），任务将开始使用“主动”或合成方法创建定期完整备份。 创建完整备份的方法并不重要——它将包含相同的数据，并且增量链将被划分为“子链”。 这种方法称为前向增量，正是这种方法向我们的客户提出了很大一部分问题。
此处通过删除链中最旧的部分（从完整备份到增量备份）来应用保留。 同时，我们不会只删除完整的备份或只删除部分增量。 整个“子链”立即被彻底删除。 设置点数的含义也会发生变化 - 如果在其他方法中这是最大允许数量，之后必须应用保留，那么这里此设置确定最小数量。 换句话说，删除最旧的“子链”后，剩余部分的点数不应低于这个最小值。
我将尝试以图形方式描述这个概念。 假设保留设置为 3 个点，任务每天运行，并在周一进行完整备份。 当总点数达到 10 时，将在这种情况下应用保留：
为什么他们放了 10 个却已经有 3 个了？ 周一创建了完整备份。 从周二到周日，工作量不断增加。 最后，下周一再次创建全备份，只有创建了2个增量后，才能最终删除整个链的旧部分，因为剩余的点数不会低于设定的3。
如果想法很明确，那么我建议你尝试自己计算留存率。 我们假设以下条件：周四首次启动任务（自然会进行完整备份）。 任务设置为每周三、周日创建全量备份，并存储8个恢复点。 何时首次应用保留？
为了回答这个问题，我建议您拿一张纸，将其按一周中的每一天排列起来，并写下每天创建的点。 答案将变得显而易见
回答
说明：要回答，只需问自己“何时应用保留”？ 答案是当我们可以删除前 3 个点（VBK、VIB、VIB）并且链的其余部分不低于所需的 8 个点时。 很明显，当我们总共得到11分时，即第二周的周日，我们就能做到这一点。
有些读者可能会反对：“如果有的话为什么要做这一切？ ？。 毫无疑问，这是一个非常有用的工具，在某些情况下我会使用它，但它也有局限性。 首先，它不允许你指定初始条件，很多时候问题恰恰是“我们有这样一条链，如果我们改变这样那样的设置会发生什么？” 其次，该工具仍然有些不够明确。 向客户展示 RPS 页面，我没有发现任何理解，但是按照示例中的方式绘制它（即使使用相同的 Paint），日复一日，一切都变得清晰了。
最后，我们没有考虑“将以前的备份链转换为回滚”选项（标记为数字5）。 此选项有时会让“自动”激活它、只想启用合成备份的客户感到困惑。 同时，此选项激活一种非常特殊的备份模式。 不说细节，我就直接说，在产品开发的现阶段，“将之前的备份链改回回滚”已经是一个过时的选择，我也想不出什么场景应该使用它。 它的价值是如此可疑，以至于有一段时间安东·戈斯特夫（Anton Gostev）本人通过论坛呼吁，要求向他发送其有用用途的示例（如果你有，请写在评论中，我非常感兴趣）。 如果没有（我认为会是这种情况），那么该选项将在未来的版本中删除。
该任务将创建增量 (VIB)，直到计划合成完整备份的那一天为止。 这一天，实际上创建了一个VBK，但是这个VBK之前的所有点都转化为回滚（VRB）。 此后，任务将继续创建完整备份的增量，直到下一次合成备份。 结果，在链中创建了 VBK、VBR 和 VIB 文件的爆炸性混合物。 保留的应用非常简单 - 通过删除最后一个 VBR：
问题
除了实际了解其工作原理之外，使用增量模式时出现的大多数问题通常都与完整备份相关。 此模式需要定期进行完整备份，否则存储库将累积积分直至满。
例如，可能很少创建完整备份。 假设任务设置为存储 10 个点，每月创建一次完整备份。 很明显，这里的实际点数将明显大于显示的点数。 或者任务一般设置为无限增量模式工作，存储50个点。 然后有人不小心创建了完整备份。 就是这样，从现在开始，任务将等待满点累积 49 个增量，之后它将应用保留并返回到无限满模式。
在其他情况下，设置为定期创建完整备份，但由于某种原因却没有。 我将在这里列出最受欢迎的原因。 一些客户端更喜欢使用“run after”调度选项并将作业配置为在链中运行。 让我们举个例子：有 3 个作业每天运行并在周日创建完整备份。 第一个任务于22.30开始，其余任务链式启动。 增量备份需要 10 分钟，因此到 23.00:22.30 所有作业都完成工作。 但完整备份需要一个小时，因此周日会发生以下情况：第一个任务从 23.30 运行到 23.30。 接下来从 00.30 到 XNUMX。 但第三项任务从周一开始。 完整备份设置为周日，因此在这种情况下根本不会发生。 该任务将等待完整备份来应用保留。 因此，在使用“run after”选项时要小心，或者根本不使用它 - 只需将作业设置为同时启动，然后让资源调度程序完成其工作即可。
困难的选项“删除已删除的项目”
完成任务“存储”-“高级”-“维护”的设置后，您可以看到“删除此后删除的项目数据”选项，该选项可以按天计算。
一些客户希望这能够保留。 事实上，这是一个完全独立的选择，误解可能会导致意想不到的后果。 然而，首先，我们需要解释贝加莱如何应对会话期间只有少数计算机成功备份的情况。
让我们想象一下这个场景：一个无限增量作业配置为存储 6 个点。 任务中有两台机器，一台总是备份成功，另一台有时会出错。 结果到了第七点就出现了下面的情况：
是时候申请保留了，但是一辆车有7分，另一辆车只有4分。这里会申请保留吗？ 答案是肯定的，会的。 如果至少有一个对象已备份，贝加莱就会认为该点已创建。
如果在某个会话期间某些机器根本没有包含在任务中，则可能会出现类似的情况。 例如，当机器不是单独添加到任务中，而是作为容器（文件夹、存储）的一部分添加到任务中，并且某些机器临时迁移到另一个容器时，就会发生这种情况。 在这种情况下，任务就会被认为是成功的，但是在统计中你会发现一条消息，要求你注意某某台机器不再被任务处理。
如果不注意这一点会发生什么？ 在无限增量或反向增量模式的情况下，“问题”机器的恢复点数量会随着每次会话而减少，直到达到1，存储在VBK中。 也就是说，即使机器很长时间没有备份，仍然会保留一个恢复点。 如果启用定期完整备份，情况会有所不同。 如果您忽略来自贝加莱的信号，最后一点可能最终会与链的旧部分一起被删除。
了解这些细节后，您终于可以考虑“删除之后删除的项目数据”选项。 如果特定机器 X 天没有备份，它将删除该机器的所有点。 请注意，此设置不会响应错误（尝试过，但没有成功）。 甚至不应该尝试备份机器。 该选项似乎很有用，应该始终保持启用状态。 如果管理员将机器从任务中删除，那么一段时间后，清除不必要的数据链是合乎逻辑的。 然而，定制需要纪律和谨慎。
我给大家举一个实践中的例子：任务中添加了几个容器，其组成是相当动态的。 由于缺乏 RAM，贝加莱服务器遇到了未被发现的问题。 该任务开始并尝试对机器进行备份，但其中一台机器除外，该机器当时不存在于容器中。 由于许多机器产生错误，默认情况下贝加莱应该再尝试 3 次来备份“问题”机器。 由于 RAM 不断出现问题，这些尝试持续了几天。 没有重复尝试对丢失的虚拟机进行备份（缺少虚拟机并不是错误）。 结果，在其中一次重复尝试中，满足了“删除已删除的项目”条件，并且机器上的所有点都被删除了。
对此，我可以这么说：如果您设置了有关任务结果的通知，甚至更好的是，使用与 Veeam ONE 的集成，那么很可能这种情况不会发生在您身上。 如果您每周查看一次贝加莱服务器以检查一切是否正常，那么最好拒绝可能导致备份删除的选项。
v.10 中添加的内容
我们之前讲的内容在贝加莱已经存在了很多版本。 了解了这些操作原理之后，我们现在来看看周年庆“十”新增了哪些内容。
每日保留率
上面我们研究了基于点数的“经典”存储策略。 另一种方法是在同一菜单中设置“天”而不是“恢复点”。
从名称中就可以清楚地看出这个想法 - 保留将存储一定的天数，但每天的积分数量并不重要。 在这种情况下，您需要记住以下几点：
- 计算留存率时不考虑当天
- 任务根本不起作用的天数也被计算在内。 应牢记这一点，以免意外丢失那些不规则任务的分数。
- 恢复点从创建开始之日开始计算（即，如果任务在周一开始工作并在周二完成，则这是从周一开始的点）
否则，按任务使用保留的原则也由所选的备份方法决定。 让我们使用相同的增量方法尝试另一个计算任务。 假设保留设置为 8 天，该任务每 6 小时运行一次，并在周三进行一次完整备份。 然而，该任务在周日不起作用。 该作业首次在周一运行。 什么时候会应用保留？
回答
一如既往，最好画一个标志。 我将允许自己简化任务，并且不会绘制每天创建的所有积分，因为每天的积分数量在这里并不重要。 对我们来说唯一重要的是，在第一个星期一和星期三，第一个点将是完整备份，但在剩余的日子里，任务将仅创建 4 个增量点。
我们明确表示，保留将通过删除周一的完整备份及其增量来应用。 什么时候会发生这种情况？ 当链的其余部分包含 8 天时。 同时，我们不计算当天，相反，我们计算星期日。 因此，答案是第二周的星期四。
常规作业的 GFS 归档
在 v.10 之前，祖父-父-子 (GFS) 存储方法仅适用于备份复制作业和磁带复制作业。 现在可用于定期备份。
虽然这与当前主题无关，但我不得不说，新功能并不意味着背离3-2-1策略。 主存储库中存档点的存在不会以任何方式影响其可靠性。 据了解，GFS 将与 Scale-out 存储库结合使用，将这些点上传到 S3 和类似存储。 如果您不使用它，那么最好继续将主点和归档点存储在不同的存储库中。
现在我们来看看创建GFS点的原理。 在任务设置的“存储”步骤中，会出现一个特殊按钮，可调用以下菜单：
GFS 的本质可以归结为几点（请注意，GFS 在其他类型的任务中的工作方式有所不同，稍后会详细介绍）：
- 该任务不会为 GFS 点创建单独的完整备份。 相反，将使用最合适的完整备份。 因此，任务必须以增量模式工作并定期进行全量备份，或者必须由用户手动创建全量备份。
- 如果仅启用一个周期（例如一周），则在 GFS 周期开始时，任务将简单地开始等待完整备份并将第一个合适的备份标记为 GFS。
示例：作业配置为使用周三的备份来存储每周的 GFS。 该任务每天运行，但计划在周五进行完整备份。 在这种情况下，GFS 周期将从周三开始，任务将开始等待合适的点。 它将在周五出现，并标有 GFS 标志。
- 如果同时包含多个周期（例如，每周和每月），则贝加莱将使用允许将同一点用作多个间隔的 GFS 的方法（以节省空间）。 旗帜将从最小的开始按顺序分配。
示例：每周 GFS 设置为星期三，每月 GFS 设置为该月的最后一周。 该任务每天运行并在周一和周五创建完整备份。
为简单起见，我们从该月的倒数第二周开始计数。 本周将在周一创建完整备份，但该备份将被忽略，因为每周 GFS 间隔从周三开始。 但周五的全备份完全适合GFS点。 这个系统我们已经很熟悉了。
现在让我们看看本月最后一周发生了什么。 每月的 GFS 间隔将从星期一开始，但星期一的 VBK 将不会标记为 GFS，因为该作业旨在将一个 VBK 标记为每月和每周的 GFS 点。 在这种情况下，搜索从每周一次开始，因为根据定义，它也可以成为每月一次。
但是，如果仅包括每周和每年间隔，它们将彼此独立运行，并且可以将 2 个单独的 VBK 标记为相应的 GFS 间隔。
备份复制任务
另一种类型的任务通常需要对工作进行澄清。 首先，让我们看看没有创新的“经典”工作方法 v.10
简单的保留方法
默认情况下，此类作业以无限增量模式运行。 点的创建由两个参数决定 - 复制间隔和所需的恢复点数量（此处没有按天保留）。 创建作业时，在第一个作业选项卡上设置复印间隔：
点数在“目标”选项卡上进一步确定
该任务为每个时间间隔创建 1 个新点（原始任务为 VM 创建了多少个点并不重要）。 在间隔结束时，新点被最终确定，并且如有必要，通过组合 VBK 和最旧的增量来应用保留。 这个机制我们已经很熟悉了。
使用 GFS 的保留方法
BCJ 还可以存储存档点。 这是在同一“目标”选项卡上配置的，位于恢复点数量设置的下方：
GFS 点可以通过两种方式创建 - 综合地使用辅助存储库上的数据，或者通过模拟完整备份并从主存储库读取所有数据（由标记为 3 的选项激活）。 两种情况下的保留率会有很大不同，因此我们将分别考虑。
合成GFS
在这种情况下，GFS 点不会恰好在指定日期创建。 相反，当计划创建 GFS 点当天的 VIB 与完整备份合并时，将创建 GFS 点。 这有时会引起误解，因为时间过去了，仍然没有 GFS 点。 并且只有来自技术支持的强大萨满才能预测该点将在哪一天出现。 事实上，不需要魔法——只需查看设定的点数和同步间隔（每天创建多少个点）。 尝试用这个例子自己计算一下：任务设置为存储7个点，同步间隔为12小时（即每天2个点）。 目前，链上已有7个点，今天是周一，计划在这一天创建GFS点。 将于哪一天创建？
回答
这里最好描述一下链条如何随着时间的推移、日复一日地变化：
因此，在周一，链中的最后一个增量被标记为 GFS，但没有其他可见的变化发生。 每天该任务都会创造 2 个新点，而保留会无情地推动链条前进。 最后，周四是时候将保留应用于该增量了。 此会话将比平时花费更长的时间 - 因为任务将从链中“提取”必要的块并创建一个新的完整点。 从这一刻起，链上已经有8个点——主链7个+GFS。
使用“读取整个点”选项创建 GFS 点
上面我说了BCJ是以无限增量模式运行的。 现在我们来看看这条规则的唯一例外。 启用“读取整个点”选项后，GFS 点将在计划的日期准确创建。 任务本身将以增量模式运行，并定期进行完整备份，我们上面已经讨论过。 还将通过删除链中最旧的部分来应用保留。 但是，在这种情况下，只会删除增量，而完整备份将保留为 GFS 点。 因此，在计算保留时，不会考虑标有 GFS 标志的点。
假设任务设置为存储 7 个点并在周一创建每周 GFS 点。 在这种情况下，每周一该任务实际上会创建一个完整备份并将其标记为 GFS。 当从最旧的部分删除增量后，剩余增量的数量不低于 7 时，将应用保留。如下图所示：
因此，到第二周结束时，链条上总共有 14 个点。 第二周，任务创造了7分。 如果这是一项简单的任务，那么就已经应用了保留。 但这是一个有GFS保留的BCJ，所以我们不计算GFS点，也就是说只有6个，也就是说，我们还不能应用保留。 在第三周，我们使用 GFS 标志创建另一个完整备份。 15 分，但我们再次不计算这一点。 最后，在第三周的星期二，我们创建了一个增量。 现在，如果我们删除第一周的环链增量，则增量总数将满足既定的留存率。
如上所述，在这种方法中，定期创建完整备份非常重要。 比方说，如果你设置主要保留期为7天，但只有1个年积分，很容易想象增量会积累很多很多，远远超过7。在这种情况下，最好使用创建的合成方法政府飞行服务队。
再次“删除已删除的项目”
BCJ 也存在此选项：
这里此选项的逻辑与常规备份任务中的逻辑相同 - 如果机器在指定的天数内未得到处理，则其数据将从链中删除。 然而，对于 BCJ 来说，该选项的实用性客观上更高，原因如下。
在正常模式下，BCJ 以无限增量模式运行，因此如果在某个时刻从作业中删除一台机器，则保留将逐渐删除所有恢复点，直到只剩下一个恢复点 - 在 VBK 中。 现在，我们假设该任务仍配置为创建合成 GFS 点。 到时候，作业将必须为链中的所有机器创建一个 GFS。 如果某台机器根本没有新点，那么，您就必须使用现有的机器。 每次都是这样。 结果，可能会出现以下情况：
请注意“文件”部分：我们有主要的 VBK 和 2 周 GFS 点。 现在到恢复点部分 - 事实上，这些文件包含相同的机器映像。 当然，这样的 GFS 点没有任何意义，它们只是占用空间。
这种情况只有在使用合成 GFS 时才有可能出现。 为了防止这种情况，请使用“删除已删除的项目”选项。 只需记住将其设置为足够的天数即可。 技术支持发现该选项设置的天数少于同步间隔的情况 - BCJ 开始发狂并在创建点之前删除点。
另请注意，此选项不会影响已创建的 GFS 点。 如果您想清理存档，则需要手动执行此操作 - 右键单击计算机并选择“从磁盘删除”（在出现的窗口中，不要忘记选中“删除 GFS 完整备份”框） :
创新 v.10 – 立即复制
处理完“经典”功能后，让我们继续讨论新功能。 有一项创新，但非常重要。 这是一种新的运作模式。
不存在所谓的“同步间隔”；任务将不断监视是否出现新点并将其全部复制，无论有多少个。 但同时，作业仍然是增量的，也就是说，即使主作业创建了VBK或VRB，这些点也会被复制为VIB。 否则，在此模式下不会有任何意外 - 标准保留和 GFS 保留都根据上述规则进行工作（但是，此处仅提供合成 GFS）。
磁盘正在旋转。 具有旋转驱动器的存储库的功能
勒索软件病毒的持续威胁已使其成为事实上的安全标准，在病毒无法到达的介质上保存数据副本。 一种选择是使用磁盘轮换存储库，一次使用一个磁盘：当一个磁盘连接且可写时，其余磁盘存储在安全位置。
要教贝加莱使用此类存储库，您需要在存储库步骤中单击存储库设置中的高级按钮，然后选择适当的选项：
此后，VBR 预计现有链会定期从存储库中消失，这意味着磁盘轮转。 根据存储库类型和作业类型，贝加莱的行为会有所不同。 这可以用下表来表示：
让我们考虑一下每个选项。
普通任务和 Windows 存储库
因此，我们有一个任务将链保存到第一个磁盘。 在轮换期间，创建的链实际上消失了，任务需要以某种方式在这种损失中幸存下来。 创建完整备份让她感到安慰。 因此，每次旋转都意味着一次完整的备份。 但是断开连接的磁盘上的点会发生什么情况呢？ 在计算保留率时，它们会被记住并考虑在内。 因此，任务中设定的点数就是需要在所有磁盘上保留多少个点。 这是一个例子：
该作业以无限增量模式运行，并配置为存储 3 个还原点。 但我们还有第二个磁盘，我们每周轮换一次（可能会有更多磁盘，这不改变本质）。
在第一周，任务将在第一个磁盘上创建点并合并多余的点。 因此，总点数将等于三：
然后我们连接第二个驱动器。 启动时，贝加莱会注意到磁盘已被更换。 第一个磁盘上的链将从界面中消失，但有关它的信息将保留在数据库中。 现在任务将在第二个圆盘上保留 3 个点。 一般情况会是这样的：
最后，我们重新连接第一个驱动器。 在创建新点之前，任务将检查保留发生的情况。 我提醒你，保留度设置为存储 3 点。 同时，我们在磁盘 3 上有 2 个点（但它已断开连接并存储在 B&R 无法到达的安全位置），并且在磁盘 3 上有 1 个点（但此点已连接）。 这意味着我们可以安全地从磁盘 3 中删除 1 个点，因为它们超出了保留范围。 之后任务再次创建完整备份，我们的链开始如下所示：
如果保留配置为存储天数而不是点数，则逻辑不会改变。 此外，当使用带有磁盘轮转的存储库时，根本不支持 GFS 保留。
常规作业和Linux存储库网络存储
此选项也是可行的，但由于施加的限制，通常不推荐这样做。 该任务将以相同的方式对磁盘旋转和链消失做出反应 - 通过创建完整备份。 该限制是由于切断保留机制造成的。
这里，在轮转期间，断开连接的磁盘上的整个链都会从贝加莱数据库中删除。 请注意，从数据库中，文件本身保留在磁盘上。 它们可以被导入并用于恢复，但很容易猜测这些被遗忘的链迟早会填满整个存储库。
解决方案是添加 DWORD ForceDeleteBackupFiles，如此页所示： 。 然后，作业将开始在每次轮换时简单地删除作业文件夹或存储库文件夹（取决于值）的全部内容。
然而，这并不是优雅的保留，而是对所有内容的清理。 不幸的是，技术支持遇到过这样的情况：存储库只是磁盘的根目录，除了备份之外，还存放其他数据。 这一切都在旋转过程中被破坏了。
此外，启用 ForceDeleteBackupFiles 后，它适用于所有类型的存储库，也就是说，即使 Windows 上的存储库也会停止应用保留并开始删除内容。 也就是说，Windows上的本地磁盘是这种备份存储系统的最佳选择。
备份副本和 Windows 存储库
有了 BCJ，事情就会变得更加有趣。 不仅拥有完整的保留，而且无需每次换盘时都进行全量备份！ 它的工作原理如下：
首先，贝加莱开始在第一张光盘上创建点。 假设我们将保留率设置为 3 分。 该任务将以无限增量模式工作，并合并所有不必要的内容（我提醒您，在这种情况下不支持 GFS 保留）。
然后我们连接第二个驱动器。 由于上面还没有链，我们创建一个完整备份，之后我们有第二个包含三个点的链：
最后，是时候重新连接第一个驱动器了。 这就是神奇的开始，因为该任务不会创建完整备份，而是简单地继续增量链：
此后，实际上每个磁盘都会有自己独立的链。 因此，这里的保留并不是指所有磁盘上的点数，而是每个磁盘上单独的点数。
备份副本和Linux存储库网络存储
再一次，如果存储库不在本地 Windows 驱动器上，那么所有的优雅都会消失。 该脚本的工作原理与上面讨论的脚本类似，只执行一项简单的任务。 每次轮换时，BCJ 将创建完整备份，并且现有点将被忘记。 为了避免耗尽可用空间，您需要使用 DWORD ForceDeleteBackupFiles。
结论
因此，由于文本如此长，我们研究了两种类型的任务。 当然，还有更多任务，但不可能以一篇文章的形式考虑所有这些任务。 如果阅读后您还有任何疑问，请在评论中写下来，我将很乐意亲自解答。
来源： habr.com