灾难频发世界的数据恢复策略

灾难频发世界的数据恢复策略

从事软件工程、系统管理和客户支持等工作，能够让你有机会接触各种配置和各种问题。此外，这样的职位还能让你深入了解用户的各种需求、痛点和顾虑，而纯工程岗位的从业者可能无法接触到这些。

在支持团队工作近五年，我注意到与我共事的各个团队都存在一些模式。此外，当我被要求协助处理各种配置时，我有机会比较不同的用例和根本原因。因此，我希望在开始与新团队合作时，能够确保打下基础。打下这个基础意味着确保管理实践能够与 HA/DR 套件完美协作，确保团队了解如何进行高可用性设计，以及如何利用系统上软件以外的实用程序来取得成功。这个基础对于确保团队了解如何达到或超越其运营标准至关重要。总结一下常见问题以及他们的答案，为那些对实施高可用性解决方案或者只是想改用新的高可用性解决方案。无论您是刚开始学习系统管理/系统工程的学生，还是被要求扩展职责范围以涵盖系统架构规划的资深软件工程师，以下几点都可以帮助您充分利用高可用性/灾难恢复套件。

不用多说，下面的问题总结了我在我的工作中看到的常见谈话要点，并将帮助您更轻松地理解关键概念并找到合适的解决方案。

什么是灾难恢复？它包含哪些内容？

灾难恢复，当与高可用性致力于优化恢复时间目标 (RTO)（服务恢复前无法访问的时间）和恢复点目标 (RPO)（从备份恢复时可以承受的数据丢失）。恢复时间目标描述系统在停机状态下仍能保持运行标准的时间长度。通常，此指标以百分比表示——常见的“五个九的正常运行时间”指的是 99.999% 的正常运行时间，或者每年最多停机 5 分钟左右。恢复点目标稍微复杂一些，它描述了在符合运行标准的情况下可以丢失的数据量。例如，如果系统在灾难发生后不会丢失任何数据，则称为“零 RPO”。将系统想象成一条时间轴，并将恢复点目标视为以下问题的答案会很有帮助：“如果系统遭遇灾难，您可以‘回溯’系统时间轴的多久，同时仍然满足运行标准？”

灾难恢复与传统的应对中断的方法有何不同？

传统上，如果没有高可用性的基础设施，灾难发生后的环境可能需要很长的恢复时间。系统需要恢复，问题需要解决，应用程序需要管理员启动。根据问题的严重程度，可能需要数小时甚至更长时间才能恢复正常运行。团队必须高效工作，保持紧密沟通，以确保服务无误地恢复，以免再次延迟恢复运营。此外，此类中断期间的数据丢失可能非常严重。如果最近没有备份，或者无法访问最新数据的副本，那么团队可能会依赖已经“过时”的数据，并因关键数据的丢失而遭受组织范围内的运营挫折。从客户的角度来看，当您需要在线服务时，您愿意等待多长时间才能获得访问权限？作为客户，如果在线商店丢失了您的交易记录，您能接受吗？

引入高可用性基础架构、镜像存储方法以及协调高可用性的方法后，影响 RTO 和 RPO 的因素均会得到优化，从而能够更从容地应对灾难。高可用性基础架构具备冗余性，因此可以使用备用系统接管运行。此外，协调器（用于管理集群环境的软件）能够系统地在备用系统上启动服务，其响应速度、可靠性和效率远高于手动干预。因此，恢复时间目标得以缩短，灾难恢复时间可能只需几分钟甚至更短，而非数小时。

高可用性基础设施的另一个方面是数据冗余。磁盘可以“镜像”，连接到不同系统的磁盘都可以实时接收完全相同的数据。因此，上述备用系统上可用的数据可以是精确的副本，从而有效地维护灾难发生前的数据备份。反过来，当服务恢复时，应用程序将以接近零的恢复点目标运行，从而在编排器将操作移至备用系统时，将恢复点目标保持在尽可能最新的运行状态。

组织在设计高可用性灾难恢复 (HADR) 策略时最常犯的错误是什么？如何避免这些错误？

最常见的失误之一是缺乏 QA/测试环境。SIOS 客户体验团队已经处理过多个此类案例，这些案例中，组织试图在应用程序/操作系统上修补/升级或者仅仅是由于规划不足或某种不幸的不兼容而导致的日常维护和体验问题。然后，停机时间环境发生故障，维护过程变成了恢复过程。这会导致生产环境中出现延迟、复杂性以及螺旋式问题的可能性。

到目前为止，能给组织提供的最大建议是创建一个以质量保证能力运行的生产环境一对一副本。生产中需要执行的每个流程都应首先在 QA 环境中进行“彩排”。这使组织能够自由地执行计划中的操作并进行改进，而不会危及基础设施的生产能力。在安全、低风险的环境中进行操作练习，可确保团队随时准备在生产环境中运行，避免遇到意外问题的风险，也不必在压力下“脱稿”快速正确地做出响应。如果 QA 环境中出现问题，则可以联系支持团队，并在确保问题不会影响业务运营的前提下进行调查。这可以极大地提高以可控、有计划且有效的方式找到解决方案并将其应用于运营的可能性。

上述 QA 环境的优势对任何组织都至关重要；然而，随着组织采用更复杂的维护策略，此测试环境的存在也变得更加重要。使用此测试环境不仅可以促进更顺畅的升级流程，还能帮助公司在采用引入复杂性的维护模型时降低风险，从而在维护活动期间提高系统可用性。​​在任何情况下，在 QA 环境中测试维护计划，根据“预演”的结果改进计划，并利用从实践中获得的经验，使组织能够管理生产系统，同时最大限度地降低遇到问题的风险。

消除单点故障的重要性是什么？

团队可能遇到的另一个常见障碍是架构中存在“最薄弱的环节”，而该环节无法从环境其他方面所获得的规划程度中获益。最好用一个例子来描述这一点。SIOS 客户体验团队曾经与一位客户合作，该客户在设计过程中围绕如何保持SAP 应用程序在其环境中运行的服务器，并很好地避免了影响运行 SAP 应用程序的系统的问题。遗憾的是，该客户投入了大量的规划精力来保护其应用程序，而没有投入同样的精力来规划其环境的其他方面。结果，所有系统都依赖于一个单一的内部 DNS 系统来解析其私有网络内的主机。尽管在保护方面付出了巨大的努力，树液当他们的 DNS 系统出现问题时，整个环境都会面临严重的问题，因为名称解析不再可用。实际上，他们为保护 SAP 应用程序所做的努力并没有帮助他们的环境渡过难关，因为 DNS 是所有其他系统正常运行所依赖的“薄弱环节”。在规划环境时，务必退一步，放眼全局——关注架构中出现的最薄弱环节。改进最薄弱的环节可以提升整个环境抵御灾难的可能性。

对于严重依赖云服务的组织，他们如何防范区域或地区范围的灾难？

只需按地理位置分配资源即可防范区域或地区范围的灾难。例如，有人可能将其主应用服务器托管在美国东部地区。然后，为了防止影响美国东部地区的中断，在远离美国东部地区（可能是美国西部地区）的“灾难恢复站点”中托管备用系统。虽然这确实引入了一些额外的步骤来确保跨区域通信，但这种努力是无价的，因为它可以防范区域和地区范围的灾难。通过在美国西部地区运行应用程序，可以承受云提供商美国东部地区全面中断。针对特定区域发生的中断的防护不需要很复杂，并且确保存在灾难恢复站点来承担运营将提高生产环境中的应用程序可用性和数据冗余。

您建议组织如何平衡实施强大的 HA/DR 策略的复杂性和成本与业务敏捷性的需求？

人们普遍认为高可用性/灾难恢复 (HA/DR) 解决方案要么复杂，要么昂贵，或者两者兼而有之。基于这一假设，我们必须密切关注眼前的风险。系统是为了某些业务目的而运行的，而这又会转化为收入。当系统因中断而宕机时，其成本远不止收入损失。如果没有 HA/DR 策略，中断需要员工积极地排除故障，这会产生员工工时成本，并将其计入停机成本中，甚至可能在员工休息不足、无法全力以赴工作的时间进行。此外，当员工不得不将任务切换到解决生产问题，然后再切换回正常工作时，常规工作中断以及延迟/缓慢，也会产生持续的附带成本。此外，声誉成本可能会导致无法识别创收机会。例如，如果您想到“CrowdStrike”？即使这不会立即带来问题和相关的负面报道CrowdStrike 在 2024 年 7 月经历了类似的困境，但在撰写本文时（2025 年 3 月 25 日），其股价才刚刚恢复到 2024 年 7 月 19 日发行股票之前的水平。考虑到配置 HA/DR 解决方案的机会成本，上述因素可能会极大地改变分析结果。SIOS 客户通常会发现，从长远来看，实施 HA/DR 解决方案可以节省成本。此外，凭借 SIOS Technology 数十年来对 HA/DR 产品不断改进和迭代的支持，配置此类解决方案的复杂性比以往任何时候都更加易于理解和简化。如果您仍然担心将 HA/DR 解决方案引入生产环境的复杂性，SIOS Technology 提供的专业服务可以帮助您培训团队、执行安装和配置活动，或者只是验证现有配置。凭借这些机会，将高可用性引入​​系统架构不仅比以往任何时候都更简单，而且实施速度也比以往任何时候都更快。最后，对于那些担心独特配置带来的复杂性，或希望最大限度地发挥 HA/DR 解决方案效用的组织，我们世界一流的支持团队随时准备提供帮助，充分发挥任何实施方案的潜力。

SIOS 技术的解决方案如何帮助组织实施您所倡导的灾难恢复方法？

SIOS Technology 的解决方案可以满足前面提到的所有方面，以下列举其中的一些：

我们采用现代灾难恢复方法LifeKeeper 和 DataKeeper 产品，我们统称为SIOS 保护套件无论在 Linux 还是 Windows 上，这些产品均可提供集群范围的资源编排，确保快速高效地应对灾难，同时确保数据在备用系统上复制并可用。LifeKeeper 监控应用程序故障并在节点之间通信，以确保系统是应用程序恢复的有效目标。Datakeeper 实时复制数据，确保备用系统能够在出现问题时继承应用程序，并继续使用最新的可用数据运行。这些产品协同工作，最大限度地缩短应用程序停机时间，并在灾难发生时最大限度地减少数据丢失。

这些产品还能与您的环境完全集成。它们提供高效的网络控制机制，使客户端始终能够解析与应用服务器的连接。这些解决方案不仅可以监控应用程序或系统的特定组件，还可以监控整个系统和环境。通过使用“仲裁”功能，可以在“全局”层面监控环境，确保应用程序在正确的系统上恢复，并保护数据。SIOS Protection Suite 针对各种灾难场景提供保护措施，因此能够做出适当的响应。

SIOS Protection Suite 还能够跨区域运行，提供我们之前讨论过的针对区域级或区域级灾难的保护。应用程序可以跨区域迁移，数据可以像在同一区域内复制一样轻松地跨区域复制。此外，环境可以多层级。主区域中可以托管多个节点，并充当活动系统或备用系统，从而快速响应系统级问题，同时还可以维护位于不同区域的灾难恢复站点，以确保以相同的速度和保护效率抵御区域级灾难。

最后，SIOS Protection Suite 产品受益于数十年的实际应用。它已在各种场景和部署配置中历经考验，并受益于多年来不断改进的易用性。因此，它是一款灵活、易于部署且可无缝融入生产环境的解决方案。采用 SIOS Protection Suite，可以避免设计和配置 HA/DR 解决方案的复杂性，并享受其丰富的开发历史和无数的改进，以及世界一流的支持团队，随时准备为您解决任何疑问或担忧。除此之外，您还有机会参与 SIOS Protection Suite 产品的协作安装或验证程序，确保您的环境能够应对各种挑战。最后，对于需要经验丰富的员工并希望最大限度地利用 SIOS Protection Suite 及其组件的团队，SIOS 提供培训活动，团队可以与我们的员工合作，了解正在发挥作用的组件，并进行积极的讨论，以促进深入的理解，确保员工能够立即掌握实施解决方案所需的所有信息，以最大限度地发挥其潜力。

保护您的业务免遭停机和数据丢失——请求演示或者开始免费试用看看 SIOS 的实际运行情况。

作者：Philip Merry，CX – SIOS Technology Corp. 软件工程师

经许可转载SIOS

DataKeeper 和棒球：灾难恢复的战略举措

DataKeeper 和棒球：灾难恢复的战略举措

在我的整个职业生涯中，数据管理员正在成为“智囊团”和“茶歇间”闲聊中的行业标准，当谈到数据保护和灾难恢复。美国著名的棒球运动和 DataKeeper 有什么区别？虽然我是棒球的铁杆粉丝，但这两件事看似毫无关联，还是有一些相似之处的。

制定成功的数据保护计划

首先，棒球和 DataKeeper 都需要一个严密的“比赛计划”。在棒球比赛中，球队会进行训练并制定计划，以期击败对手并最终获胜。同样，DataKeeper 需要一个“发人深省”的策略，以确保数据保护得到充分利用，并在发生灾难性事件时能够恢复。

其次，团队合作至关重要。内野手、外野手、教练和击球手各自扮演着特定的角色，以确保获得最佳的胜率。DataKeeper 可能需要多个团队参与，例如数据库管理员、基础设施人员、客户体验/支持、管理层等等。所有团队成员都应该全力投入，有效地保护和恢复数据。

棒球和 DataKeeper 的不同之处：IT 领域的风险更高

有一些差异不容忽视。输掉一场棒球比赛，尤其是在世界大赛第七场，最后一局，2出局，3坏球，2好球，可能令人沮丧，但使用DataKeeper，风险会高得多。数据丢失会给企业带来严重后果。棒球运动员需要独特的运动技能，而DataKeeper解决方案则需要企业系统和相关流程的知识。

总而言之，虽然棒球和DataKeeper看起来完全不同，但我们可以得出一些相似之处。两者都需要：

• 战略
• 团队合作
• ……和专业知识

无论您是棒球迷还是 IT 专业人士，显然，要想取得成功都需要一定的技能和奉献精神。

您的数据保护计划是什么？

查看提供的游戏计划/解决方案us.sios.com/solutions/

打球…

作者：Gregory A. Tucker，SIOS 高级产品支持工程师

经许可转载SIOS

SQL Server 停机风险预算

SQL Server 停机风险预算

在这TechRadar Pro 文章《SQL Server 停机风险预算》中，SIOS 的 Dave Bermingham 强调了将业务连续性计划与切合实际的预算相结合的重要性，以减少关键任务 SQL Server 部署中的中断。他建议组织评估每个 SQL Server 实例的重要性，了解停机的潜在影响（包括收入损失、生产力下降、数据损坏和法律处罚），并分配适当的资源（无论是本地、云端还是混合云），以确保做好应对灾难的准备。

转载自SIOS

从 Linux 的 SIOS DataKeeper 迁移到 DRBD

从 Linux 的 SIOS DataKeeper 迁移到 DRBD

SIOS 于 2019 年推出了分布式复制块设备 (DRBD) 恢复套件SIOS LifeKeeper Linux 版本 9.9.0. 从SIOS 数据管理员对于想要在 Linux 中尝试 DRBD 功能的人来说，将 Linux 迁移到 DRBD 是一个简单的过程生命守护者以及那些以前熟悉 DRBD 的人。

了解 DRBD 及其在 LifeKeeper 中的优势

DRBD 是一种基于软件的、无共享的、复制的存储解决方案，用于在主机之间镜像块设备（硬盘、分区、逻辑卷等）的内容。LifeKeeper for Linux DRBD 恢复套件提供了配置和控制 DRBD 资源以实现高可用性的功能。

比较 Linux 版 SIOS DataKeeper 和 DRBD

Linux 版 SIOS DataKeeper 为 LifeKeeper 环境提供了集成的数据镜像功能。对于想要构建高可用性集群（使用 SIOS LifeKeeper）没有共享存储或只是想在服务器之间实时复制业务关键数据。

SIOS DataKeeper 提供同步或异步卷级镜像，将数据从主服务器（镜像源）复制到一个或多个备份服务器（镜像目标）。本博客不包含创建 PostgreSQL 资源的步骤，但可以找到有关使用 SIOS LifeKeeper 配置 PostgreSQL 的更多信息这里。

如何将 PostgreSQL 数据库迁移到 DRBD

1. 通过 LifeKeeper UI 停止 PostgreSQL 应用程序

lkcli 资源删除 –tag pgsql-demo

1. 为 PostgreSQL 数据库和日志文件创建数据备份

cp -pra /pgsql-demo* /备份/

1. 使用临时文件系统位置创建新的 DRBD 资源。

lkcli 资源创建 drbd –tag drbd-pgsql-demo –device /dev/mapper/singledrbd-lk1 –fstype ext3 –mount_point /tmp/pgsql-demo

确保选择与之前的 DataKeeper for Linux 资源相同的 fstype。所选设备还应足以容纳 PostgreSQL 数据库数据集的数据和日志量。

1. 将DRBD资源扩展到目标服务器。

lkcli 资源扩展 drbd –tag drbd-pgsql-demo –dest node-a –device /dev/xvdc3 –mode 同步 –laddr 10.15.29.165 –raddr 10.15.27.49

1. 使 PostgreSQL 数据库的文件系统资源停止服务。

lkcli 资源删除 –tag /pgsql-demo

1. 更改 /tmp/pgsql/demo 目录的所有者和组。

chown postgres：postgres /tmp/pgsql/demo

1. 将数据复制到 DRBD 镜像文件系统。

cp -pra /备份/* /tmp/pgsql-demo

1. 使新创建的 DRBD 文件系统资源停止服务。

lkcli 资源删除 –tag /tmp/pgsql-demo

1. 打破先前文件系统和 DataKeeper for Linux 资源之间的依赖关系

lkcli 依赖删除 –parent /pgsql-demo –child datarep-pgsql-demo

打破文件系统和 DRBD 资源之间的依赖关系。

lkcli 依赖项删除 –parent /tmp/pgsql-demo –child drbd-pgsql-demo

1. 重新创建现有 /pgsql-demo 文件系统和 drbd 资源之间的依赖关系

lkcli 依赖创建 –parent /pgsql-demo –child drbd-pgsql-demo

1. 启动 pgsql-demo 资源

lkcli 资源恢复 –tag pgsql-demo

开始在服务器“node-b”上恢复“pgsql-demo”

等待服务器启动…完成

服务器已启动

成功恢复服务器“node-b”上的“pgsql-demo”

1. 连接数据库并验证数据库连接。

例如：

psql -p 3308 -h /pgsql-demo/socket -U psql

psql -p <端口> -h <套接字目录> -U <数据库用户>

1. 删除临时 DRBD 文件系统资源

lkcli 资源删除 /tmp/pgsql-demo

1. 删除 DataKeeper for Linux 的数据代表和临时文件系统资源。

lkcli 资源删除 –tag datarep-pgsql-demo

15. 验证切换和连接

为什么要从 Linux 版 SIOS DataKeeper 迁移到 DRBD？

对于那些想要在 LifeKeeper 中试验 DRBD 功能的人以及那些以前更熟悉 DRBD 或想要利用 DRBD 更快的异步复制速度和更广泛的内核支持的人来说，从 SIOS DataKeeper for Linux 迁移到 DRBD 是一个简单的过程。

准备好开始使用 DRBD 了吗？立即联系 SIOS了解 LifeKeeper 如何帮助您顺利迁移并充分利用 DRBD 的潜力，实现高可用性和灾难恢复

作者：Cassius Rhue，SIOS Technology Corp. 客户体验副总裁

经许可转载SIOS

为什么无存储/无节点仲裁对于集群可用性有害？

为什么无存储/无节点仲裁对于集群可用性有害？

一般来说，法定人数是指出席并作出决定的一群人或团体。

在 LifeKeeper 中，Quorum 强制达成共识，使用集群中节点的状态来执行处理集群内节点故障的下一步。LifeKeeperquorum 可以在三种模式下运行；存储、多数和 TCP 远程（TCP 远程仅适用于 LifeKeeper for Linux）。

• 存储 Quorum 使用共享存储设备来跟踪集群中其他系统提供的更新，如果某个系统不提供更新，Quorum 会将该集群标记为失败。
• 多数仲裁依赖于奇数个集群的结构其中一个节点充当见证节点，以确定集群中是否有一个或所有节点无法通信
• 通过指定端口上的 TCP/IP 服务进行 TCP 远程连接，以验证集群中的节点是否可以相互通信。

了解集群中仲裁的重要性

Quorum 的目的是通过采取补救措施来应对意外情况，从而保持应用程序的可用性。它通过降低裂脑情况的风险并通过保持集群中所有节点之间的通信来减少停机时间来实现这一点。

集群中没有仲裁的情况下运行的风险

使用未配置 Quorum 的集群存在风险。以下场景将解决没有 Quorum 的影响以及实施 Quorum 的重要性。

场景 1：减少停机时间

当一个或多个系统由于不可避免的因素（例如崩溃或网络通信暂时故障）而无法使用时，可能会发生意外停机。

有了存储这样的仲裁或 TCP 远程配置，可以使用对存储设备和/或端口的访问来跟踪集群中的通信状态。此附加措施可以防止不必要的故障转移，从而避免造成长时间停机。在其他情况下，Quorum 将采取措施关闭或重新启动服务器以将其恢复到健康状态并避免更长的停机时间。

场景 2：脑裂

一个裂脑是指集群中的多个系统认为自己是主服务器。当主服务器与其辅助服务器失去通信，并且辅助服务器认为主系统已关闭时，就会发生这种情况。这会导致集群中出现两个活动的主系统。

如果配置了多数法定人数，则会提供另一个系统作为见证人，以投票决定哪个系统应该作为主系统，从而防止发生裂脑。

为什么适当的仲裁配置很重要

操作集群缺乏存储或多数仲裁是危险的，因为这会增加因裂脑和/或网络中断而导致数据丢失或长时间停机的风险。使用 Quroum 可以提供反制措施，确保集群始终健康，并适当处理任何不健康的系统。

立即联系 SIOS了解我们的高可用性解决方案如何帮助您以正确的方式配置仲裁并保护您的集群。

作者：Alexus Gore，SIOS Technology Corp. 客户体验软件工程师

经许可转载西欧斯