我们继续沉浸在迷人的猜测世界中……通过日志进行故障排除。 在 我们就基本术语的含义达成一致，并将 Veeam 的整体结构视为一个单一的应用程序。 这个任务的任务是弄清楚日志文件是如何形成的，其中显示了什么样的信息以及它们为什么看起来像这样。
你认为这些“日志”是什么？ 根据大多数人的说法，任何应用程序的日志都应该被赋予一种无所不能的实体的角色，这种实体大部分时间都长在后院的某个地方，但在适当的时候会穿着闪亮的盔甲突然出现并拯救所有人。 也就是说，它们应该包含所有内容，从每个组件中最轻微的错误到单个数据库事务。 因此，在错误发生后，它立即被写入如何修复它。 所有这些都应该适合几兆字节，仅此而已。 这只是文字！ 文本文件不能占用几十GB，我在哪里听说过！
所以日志
在现实世界中，日志只是诊断信息的存档。 而在那里存储什么，从哪里获取存储信息以及应该存储多详细，则由开发人员自己决定。 有人通过记录开/关水平来遵循极简主义的道路，有人勤奋地搜集他们能触及的一切。 虽然还有一个中间选项可以选择所谓的日志记录级别，但当您自己指明要存储多少详细信息以及您有多少额外磁盘空间时 =) 顺便说一句，VBR 有六个这样的级别。 而且，相信我，您不想看到磁盘上有可用空间的最详细日志记录会发生什么。
美好的。 我们大致了解了要保存的内容，但出现了一个合理的问题：从哪里获取这些信息？ 当然，我们通过内部流程形成了记录自己的事件的一部分。 但是当与外部环境发生交互时怎么办？ 为了不陷入拐杖和自行车的地狱，Veeam 倾向于不发明已经发明的发明。 每当有现成的 API、内置函数、库等时，我们都会优先考虑现成的选项，然后再开始围栏我们的装置。 虽然后者也足够了。 因此，在分析日志时，重要的是要了解大部分错误来自第三方 API、系统调用和其他库的消息。 在这种情况下，VBR 的作用归结为将这些错误转发到原样日志文件。 用户的主要任务是学习了解哪条线来自谁，以及这个“谁”负责什么。 因此，如果 VBR 日志中的错误代码将您带到 MSDN 页面，那是正确的。
正如我们之前达成的共识：Veeam 是所谓的基于 SQL 的应用程序。 这意味着所有设置、所有信息以及通常仅正常运行所需的一切 - 一切都存储在其数据库中。 因此，一个简单的事实是：日志中没有的很可能在数据库中。 但这也不是灵丹妙药：有些东西不在 Veeam 组件的本地日志中，也不在其数据库中。 因此，你需要学习如何研究主机日志、本机日志以及备份和恢复过程中涉及的所有日志。 而且还发生了根本无法在任何地方获得必要信息的情况。 就是这样。
此类 API 的一些示例
此列表并不旨在特别完整，因此无需在其中寻找最终的真相。 它的目的只是展示我们产品中最常用的第三方 API 和技术。
让我们开始吧 VMware的.
名单上的第一个将是 vSphere API. 用于身份验证、读取层次结构、创建和删除快照、请求有关机器的信息等等（非常多）。 该解决方案的功能非常广泛，因此我可以推荐该版本的 VMware vSphere API Reference и . 对于更多当前版本，一切都只是用谷歌搜索。
波动率指数. 管理程序的黑魔法，有一个单独的 . VMware API 用于处理主机上的文件而无需通过网络连接到它们。 当您需要将文件放在没有更好的通信通道的机器中时，这是最后的选择。 如果文件很大，主机加载，那是痛苦和煎熬。 但这里的规则有效，即使 56,6 Kb/s 也比 0 Kb/s 好。 在 Hyper-V 中，这个东西叫做 PowerShell Direct。 但那只是之前
vSpehere Web 服务 API 从 vSphere 6.0 开始（大约，因为这个 API 是在版本 5.5 上首次引入的）它用于与来宾机器一起工作并且几乎在所有地方都取代了 VIX。 事实上，这是另一个用于管理 vSphere 的 API。 对于那些有兴趣的人，我建议学习 手动的。
电源电压K （虚拟磁盘开发工具包）。 图书馆，这在这部分讨论 . 用于读取虚拟磁盘。 曾几何时，它是 VIX 的一部分，但随着时间的推移，它被转移到一个单独的产品中。 但作为继承人，它使用与 VIX 相同的错误代码。 但是由于某些原因，SDK本身并没有对这些错误的描述。 因此，根据经验发现，其他代码的 VDDK 错误只是从二进制代码到十进制代码的转换。 它由两部分组成——上半部分是关于上下文的未记录信息，第二部分是传统的 VIX/VDDK 错误。 例如，如果我们看到：
VDDK error: 21036749815809.Unknown error
然后我们大胆地将其转换为十六进制并得到 132200000001。我们简单地丢弃 132200 的无信息开头，其余部分将是我们的错误代码（VDDK 1：未知错误）。 关于最常见的 VDDK 错误，最近有一个单独的 .
现在让我们看看 视窗.
在这里，对我们来说最必要和最重要的一切都可以在标准中找到 事件查看器“. 但有一个问题：根据悠久的传统，Windows 不会记录错误的全文，而只会记录错误的编号。 例如错误5是“拒绝访问”，1722是“RPC服务器不可用”，10060是“连接超时”。 当然，如果您能记住最著名的那些当然很好，但是那些至今未曾见过的呢？
为了让生活看起来一点也不像蜂蜜，错误也以十六进制形式存储，前缀为 0x8007。 例如，0x8007000e 实际上是 14，Out of Memory。 为什么以及为谁这样做是一个笼罩在黑暗中的谜。 但是，可以免费下载完整的错误列表，无需通过 SMS 从 .
顺便说一句，有时还有其他前缀，而不仅仅是 0x8007。 在这种情况下，为了理解 HRESULT（“结果句柄”），您需要更深入地研究 对于开发人员。 在平常的生活中，我不建议你这样做，但如果你突然按在墙上或者只是好奇，现在你知道该怎么做了。
但是微软的战友有点可怜我们，给世界展示了一个实用工具 . 这是一小块控制台幸福，可以在不使用 Google 的情况下将错误代码翻译成人类。 它是这样工作的。
C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"一个合理的问题出现了：为什么我们不立即将解密写入日志，而是留下这些神秘的代码？ 答案在第三方应用程序中。 当您自己拉一些 WinAPI 调用时，不难破译其响应，因为甚至有一个特殊的 WinAPI 调用。 但正如已经提到的，所有仅在响应中出现的内容都会进入我们的日志。 在这里，为了解密它，人们必须不断地监视这种意识流，从中提取带有 Windows 错误的片段，解密它们并将它们粘贴回去。 老实说，这不是最令人兴奋的活动。
Windows 文件管理 API 在处理文件时以各种可能的方式使用。 创建文件、删除、打开写入、使用属性等等。
上面提到过 PowerShell 直接 作为 Hyper-V 世界中 VIX API 的类似物。 不幸的是，没有那么灵活：功能上有很多限制，它不适用于所有版本的主机，也不适用于所有来宾。
RPC的 （远程过程调用）我认为使用过 WIndows 的人没有一个没有见过与 RPC 相关的错误。 尽管存在普遍的误解，但这并不是一个单一的协议，而是满足多个参数的任何客户端-服务器协议。 但是，如果我们的日志中出现 RPC 错误，90% 的情况下它是来自 Microsoft RPC 的错误，它是 DCOM（分布式组件对象模型）的一部分。 您可以在网上找到大量关于此主题的文档，但其中大部分已经过时了。 但是，如果强烈希望研究该主题，那么我可以推荐文章 , 和长长的名单 .
我们日志中出现 RPC 错误的主要原因是尝试在 VBR 组件（例如服务器 > 代理）之间进行通信失败，而且最常见的原因是通信问题。
所有 top 中排在首位的是错误 The RPC server is unavailable (1722)。 简单来说，客户端无法与服务器建立连接。 如何以及为什么 - 没有单一的答案，但通常是身份验证或对端口 135 的网络访问的问题。后者是具有动态端口分配的基础设施的典型问题。 关于这个话题，甚至有 . 而微软有 查找故障原因。
第二个最常见的错误：端点映射器 (1753) 没有更多可用的端点。 RPC 客户端或服务器无法为自己分配端口。 通常发生在服务器（在我们的例子中，客户机）被配置为动态分配已结束的狭窄范围内的端口时。 如果您从客户端（在我们的例子中是 VBR 服务器）登录，这意味着我们的 VeeamVssAgent 没有启动或没有注册为 RPC 接口。 这个话题也有 .
好吧，为了完成前 3 个 RPC 错误，让我们记住 RPC 函数调用失败 (1726)。 如果连接已建立，但未处理 RPC 请求，则会出现。 例如，我们请求有关 VSS 状态的信息（现在突然在那里制造了一个影子地雷，我们正试图攀登），作为对我们的回应，沉默和忽略。
Windows 磁带备份 API 需要使用磁带库或驱动器。 正如我在开头提到的：我们没有乐趣编写我们自己的驱动程序，然后在每个设备的支持下受苦。 因此，vim 没有自己的驱动程序。 全部通过标准 API，其支持由硬件供应商自己实现。 更合乎逻辑，对吧？
SMB / CIFS 出于习惯，每个人都把它们并排写，虽然不是每个人都记得 CIFS（通用互联网文件系统）只是 SMB（服务器消息块）的私有版本。 所以概括这些概念并没有错。 Samba 已经是 LinuxUnix 的实现，它有自己的特点，但我离题了。 这里重要的是：当 Veeam 要求向 UNC 路径（服务器目录）写入内容时，服务器使用文件系统驱动程序的层次结构（包括 mup 和 mrxsmb）来写入 ball。 因此，这些驱动程序也会产生错误。
离不开 温索克API. 如果需要通过网络完成某些操作，VBR 会通过 Windows Socket API（通常称为 Winsock）工作。 因此，如果我们在日志中看到一堆 IP:Port，就是这样。 官方文档有一个很好的可能列表 .
上面提到过 WMI的 (Windows Management Instrumentation) 是一种全能的 API，用于管理 Windows 世界中的一切和所有人。 例如，在使用 Hyper-V 时，几乎所有对主机的请求都经过它。 总之，这东西绝对无可替代，而且能力非常强大。 为了帮助找出损坏的位置和损坏的内容，内置的 WBEMtest.exe 工具大有帮助。
最后在名单上，但绝不是最不重要的—— VSS （卷影存储）。 这个主题是取之不尽、用之不竭、神秘莫测的，因为关于它的文档很多。 Shadow Copy 最简单理解为一种特殊类型的快照，本质上就是这样。 多亏了他，您可以在 VMware 中以及在 Hyper-V 中进行几乎所有内容的应用程序一致备份。 我计划写一篇单独的文章，对 VSS 进行一些挤压，但现在你可以尝试阅读 . 只是要小心，因为。 试图在一瞬间理解 VSS 会导致脑损伤。
在这一点上，也许我们可以停下来。 我认为解释最基本的事情的任务已经完成，所以在下一章中我们已经查看了日志。 但如果您有任何问题，请随时在评论中提问。
来源： habr.com