SDB:灾难恢复

跳转到：导航，搜索
openSUSE 支持数据库
门户 - SDB 分类 - 如何编写文章


目标：重建被破坏的系统

您希望做好准备，以便在系统被破坏时，无论具体是什么被破坏了，都能尽可能地将其恢复到以前的状态，从损坏的软件（如删除的重要文件、损坏的文件系统、破坏的磁盘分区）到损坏的硬件（如有缺陷的硬盘或完全破坏的计算机）。

从“重建系统”这一目标出发，可以得出：

灾难恢复意味着安装（从头开始重新安装）

灾难恢复的核心是一个可以从头开始重新安装系统的安装程序。

系统安装的基本步骤是：

  • 在“裸机”上启动安装系统，其中“裸机”也可以是裸虚拟机。
  • 在安装系统中运行一个安装程序，执行以下基本步骤：
  1. 准备持久化存储（磁盘分区，文件系统和挂载点）。
  2. 将有效负载存储在持久化存储中（安装文件）。
  3. 安装引导加载程序。
  • 最后重启，以便关闭安装系统并启动已安装的系统。

在初始系统安装的情况下，“存储有效负载”通常意味着安装RPM软件包。

在灾难恢复的情况下，“存储有效负载”意味着从备份恢复文件。

通常系统安装和灾难恢复的唯一真正区别在于存储有效负载的方式。

系统配置（例如网络、用户、服务、语言、键盘等）是另一个分离的任务，不与此处所说的“安装”混淆。（例如，即使在YaST中，实际安装也与配置分开，至少在一定程度上是这样。）

系统配置是另一个区别。

初始的常规系统安装需要额外的后续系统配置步骤，因为安装的RPM软件包会产生一个原始的“原始”系统，其中包含软件包的默认配置文件，这些配置文件必须根据需要进行配置。

相反，灾难恢复会产生一个配置好的系统，因为配置文件是从备份中恢复的。

镜像安装

另一种系统安装方法（有或没有配置）是所谓的“镜像安装”。在镜像安装的情况下，“存储有效负载”通常意味着将文件的镜像（无论“镜像”具体是什么）存储在持久化存储中，这可以产生一个带有默认配置文件的“原始”系统或一个带有调整后配置文件的配置系统，具体取决于需要。

例如，KIWI是一个镜像构建系统，可用于镜像安装（参见 https://en.wikipedia.org/wiki/KIWI_%28computing%29）。

基础

本文仅介绍如何通过重建被破坏的系统来从灾难中恢复。其他如何应对灾难的方法（例如通过冗余复制系统实现高可用性解决方案）在此处未描述。

在这种特定情况下，“灾难恢复”意味着重建基本操作系统（即您最初从openSUSE或SUSE Linux Enterprise安装介质安装的内容）。

特别是，通常需要以额外的单独步骤重建特定的第三方应用程序（例如，一个第三方数据库系统，通常需要采取特殊操作才能安装和设置）。

基本操作系统可以在相同的硬件或完全兼容的替换硬件上重建，以便实现“裸机恢复”。

需要完全兼容的替换硬件

“完全兼容的替换硬件”基本上意味着替换硬件使用与原始硬件相同的内核模块，并且以相同的方式启动。例如，您不能拥有一个需要不同内核模块（可能需要不同的附加固件）的替换网络接口卡，也不能从BIOS切换到UEFI或切换到不同的架构（例如从32位到64位），等等。

通常，“硬件”也可以是虚拟硬件，例如带有虚拟硬盘的虚拟机（参见下面的“虚拟机”部分）。但是，“完全兼容的替换硬件”意味着您不能从真实硬件切换到虚拟硬件，也不能从一种虚拟化环境切换到另一种虚拟化环境（例如从KVM/QEMU到XEN）。

此外，“完全兼容的替换硬件”意味着您不能从一种存储结构切换到另一种存储结构（例如从单个磁盘切换到两个磁盘，反之亦然）。您也不能从一种存储硬件切换到另一种存储硬件（例如从SATA磁盘切换到NVMe磁盘或从本地磁盘切换到远程存储，如SAN）。理想情况下，替换硬件上的磁盘大小应与原始系统上的磁盘大小完全相同（通常，磁盘大小稍大不会引起大问题，但较小的磁盘大小通常比较麻烦）。

系统运行时准备工作

  1. 创建所有文件的备份
  2. 创建一个可启动的恢复介质，其中包含用于您系统的恢复安装系统和恢复安装程序
  3. 准备好替换硬件
  4. 验证在您的替换硬件上重建您的系统是否可行

系统被破坏后

  1. 如果需要：将损坏的硬件替换为您的替换硬件
  2. 使用您的恢复介质和备份重建您的系统

不切实际的期望

“只是”、“简单”、“容易”等词语不适用于灾难恢复。

  • 灾难恢复并非“容易”。
  • 灾难恢复根本不是“简单”。
  • 没有一个灾难恢复解决方案可以“即刻生效”。

有一个例外，在那种情况下这些词语是合适的

系统越简单，恢复就越简单。

灾难恢复并非“即刻生效”

即使您在没有错误或警告的情况下创建了恢复介质，也不能保证在您的特定情况下使用您的恢复介质重建您的系统能够正常工作。

没有灾难恢复解决方案可以“即刻生效”的基本原因是，以可靠的工作方式自动检测重建特定系统所需的所有信息实际上是不可能的

  • 有关硬件的信息，例如所需的内核模块、内核参数等。
  • 有关存储的信息，例如分区、文件系统、挂载点等。
  • 有关引导加载程序的信息
  • 有关网络的信息

例如，存在一个普遍的问题，即无法以可靠的方式确定正在运行的系统是如何启动的。假设在初始系统安装期间，GRUB安装在活动分区的引导扇区中，例如/dev/sda1，然后手动将LILO安装到/dev/sda硬盘的主引导记录中。然后实际上LILO用于启动系统，但GRUB安装仍然存在。此外，在UEFI的情况下，像“BootCurrent”（例如在'efibootmgr -v'输出中）这样的内容并不可靠，无法确定系统是如何启动的（参见 https://github.com/rear/rear/issues/2276#issuecomment-559865674）。或者硬盘上的引导加载程序安装可能根本不起作用，系统是从可移动介质（如CD或USB棒/磁盘）启动的，或者当前运行的系统甚至没有正常启动，而是直接从另一个正在运行的系统通过'kexec'启动（参见下面的“通过kexec启动ReaR恢复系统”部分）。

在“足够简单”的情况下，灾难恢复甚至可能“即刻生效”。

如果不起作用，您可能会更改系统配置以使其更简单，或者您必须手动调整和增强灾难恢复框架使其适用于您的特定情况。

没有经过测试和持续验证的灾难恢复

您必须提前测试，使用您的特定恢复介质重建您的特定系统是否可行，重建的系统是否可以自行启动，以及重建的系统是否具有所有系统服务，并且在您的特定情况下仍然可以正常工作。

您必须准备好可用于重建系统的替换硬件，并且必须尝试使用您的恢复介质在替换硬件上重建系统，以验证其是否有效。

您必须持续验证恢复在替换硬件上仍然有效，尤其是在基本系统每次更改后。

建议

从一开始就为灾难恢复做好准备

在准备初始系统安装的同时，准备适合您特定需求的灾难恢复程序。

请参阅下面的“帮助和支持 - 提前可行 - 事后无望”。

最终，当情况危急时，您精心设计的复杂系统将变得无用，因为您无法使用灾难恢复程序重建它。

您的系统越简单，恢复就越简单容易（参考上面）。

最终重要的是什么

Regardless how a system was installed and
regardless what is used for disaster recovery
eventually a disaster recovery installation
will be the final system installation.

请参阅下面的“关于使用 Relax-and-Recover 演示文稿的灾难恢复要点”链接。

通过恢复安装进行部署

从 openSUSE 或 SUSE Linux Enterprise 安装介质进行初始安装（以及配置）后，设置您的系统恢复，然后通过您的系统恢复程序重新安装它，以进行实际的生产部署。

这样您就可以知道您的系统恢复至少适用于您用于生产系统的确切硬件。

此外，通过恢复安装进行部署可确保，在发生灾难时，您的特定灾难恢复重新安装不会使用（可能微妙但严重）的差异重建您的系统（参考下面的“限制在于特殊的 ReaR 恢复系统可以做什么”），因为这样您将使用相同的安装程序（恢复安装程序）进行部署和灾难恢复（参考上面的“灾难恢复就是安装”）。

为灾难恢复准备替换硬件

您必须准备好完全兼容的替换硬件，可以随时用于灾难恢复。

请参阅上面关于“完全兼容的替换硬件”的含义。

“可随时用于灾难恢复的替换硬件”尤其意味着其存储设备（硬盘或虚拟磁盘）必须完全干净（即，您的替换存储必须像全新的存储一样工作）。

如果您的替换存储不是全新的存储（即，如果它曾经被使用过），则必须完全清零您的替换存储。否则，当您尝试在以前使用过的磁盘上重新安装系统（参考上面的“灾难恢复意味着……重新安装”）时，由于磁盘上残留的各种意外问题（例如 RAID 的残留、分区表签名和其他类型的“魔术字符串”，如 LVM 元数据等），可能会遇到各种意想不到的问题。

在非 PC 兼容架构上，可能存在启动 Relax-and-Recover (ReaR) 恢复系统的问题，请参阅下面的“恢复介质兼容性”部分。您可能需要使用支持 kexec 的系统（可能很小且简单）来准备您的替换硬件，以便您可以通过 kexec 启动 ReaR 恢复系统，请参阅下面的“通过 kexec 启动 ReaR 恢复系统”部分。

由于清零存储空间可能需要很长时间，并且准备支持 kexec 的系统也需要时间和测试，因此您应该在有时间以“放松”的方式进行操作时提前准备好您的替换硬件（参考下面的“关于‘Relax-and-Recover’中‘Relax’的含义”）。

为最坏的情况做好准备

做好系统恢复无法重建系统的准备。准备好从头开始手动重建。始终准备好重建您的特定系统所需的所有信息。将您的系统手动重建到您的替换硬件上作为练习。

直面现实：通过恢复安装程序进行部署是必须的

上述“建议”实际上不是很好的建议，而是强制要求。

只要您使用与您以后在紧急情况下和时间紧迫的灾难恢复时打算使用的工具集（安装系统加安装程序）不同的工具集安装系统，您就没有真正的灾难恢复程序。

如果您使用与用于重新安装不同的工具集安装系统，它就无法真正工作。

对于真正的灾难恢复程序，您应该使用相同的安装系统和相同的安装程序进行所有类型的安装。

至少，您必须使用相同的安装系统和相同的安装程序进行您的生产部署安装和您的灾难恢复重新安装。

即使这样，仍然要充分了解您的系统，以便您始终准备好从头开始手动重建。

为您的关键系统维护真正的灾难恢复程序

如果您有关键系统，但没有如上所述的真正的灾难恢复程序（即通过恢复安装进行部署，并持续验证您的灾难恢复程序实际上适用于您的替换硬件），那么您所谓的“关键系统”实际上对您来说并不是真正的关键，因为您实际上并不充分关心您的系统。如果您的灾难恢复程序在原始系统被破坏后无法在您的替换硬件上重建系统，通常会陷入僵局，请参阅下面的“帮助和支持”部分。

用于灾难恢复的 Relax-and-Recover (ReaR) RPM 包

Relax-and-Recover (ReaR) 是 Linux 上的事实上的灾难恢复框架。

这些软件包中的软件面向有经验的用户和系统管理员。没有易于使用的用户前端（特别是没有 GUI），并且通常灾难恢复软件的行为并不完全可靠（它以‘root’身份运行，您需要知道它在做什么）。

rear / rear116 / rear1172a / rear118a / rear23a / rear27a

通过 SUSE Linux Enterprise 高可用性扩展 (SLE-HA) 使用 Relax-and-Recover (ReaR) 的 SUSE Linux Enterprise “rear...” RPM 包，用于灾难恢复。

  • “rear116”包含 ReaR 上游版本 1.16 加上 SUSE Linux Enterprise 12 GA 中 btrfs 的特殊调整。
  • “rear1172a”包含 ReaR 上游版本 1.17.2 加上 SUSE Linux Enterprise 12 SP1 中 btrfs 的特殊调整（rear116 不适用于 SUSE Linux Enterprise 12 SP1 中的默认 btrfs 设置，因为与 SUSE Linux Enterprise 12 GA 中的默认 btrfs 设置相比，存在重大变化）。
  • “rear118a”包含 ReaR 上游版本 1.18 加上大量 ReaR 上游提交到版本 1.19（基本上 rear118a 几乎是 ReaR 上游版本 1.19），特别是它包含一个 SLE12-SP2-btrfs-example.conf 文件，以支持自 SUSE Linux Enterprise 12 SP2 以来使用的 snapper 的 btrfs 配额设置，另一个主要功能是 UEFI 支持，以及自 ReaR 版本 1.18 以来用于制作 SUSE Linux Enterprise 系统上的 UEFI 可引导 ReaR 恢复系统 ISO 镜像的新软件包 ebiso（我们提供的所有 ReaR 版本直到 SUSE Linux Enterprise 12 SP1 仅支持传统的 BIOS，请参阅下面的“恢复介质兼容性”部分）。
  • “rear23a”包含 ReaR 上游版本 2.4 加上一些后续的 ReaR 上游提交。rear23a RPM 包源自 ReaR 版本 2.3（因此其 RPM 包名称），最初仅在 SUSE Linux Enterprise 15 GA 中提供。与此同时，对 rear23a RPM 包进行了重大更新，现在包含 ReaR 上游版本 2.4 加上一些后续的 ReaR 上游提交（直到 ReaR 上游 git 提交 cc9e76872fb7de5ddd6be72d4008a3753046a528，请参阅 rear23a RPM changelog）。RPM 包名称 rear23a 和版本 2.3.a 被保留，以便可以更新已安装的 rear23a RPM 包。实际上，在 POWER 架构上（即 64 位 PPC64 和 PPC64LE，但不适用于旧的 32 位 PPC，该架构不受支持）基本上需要 ReaR 版本 2.4。ReaR 版本 1.18/1.19 可以在 POWER 上工作，但与自那时以来（2016 年 3 月）在 ReaR 上游中增强和修复的内容相比，rear118a RPM 包在 POWER 上的表现不如当前的（2018 年 9 月）rear23a RPM 包。
  • “rear27a”包含 ReaR 上游版本 2.7 发布。

请参阅 ReaR 上游发布说明 http://relax-and-recover.org/documentation/，了解各个 ReaR 版本中的新功能、重大增强功能以及可能的不兼容更改。ReaR 上游发布说明中 ReaR 版本 2.7 https://relax-and-recover.org/documentation/release-notes-2-7 也包含以前的 ReaR 版本中的更改。

对于一个 SUSE Linux Enterprise 产品，我们并行提供多个 ReaR 版本，以便用户可以在版本 N 不支持他们的特定需求时升级到版本 M，但另一方面，如果用户使用版本 N 具有可用的灾难恢复程序，则无需升级。因此，软件包名称包含版本，并且所有软件包相互冲突，以避免意外替换已安装的版本。请参阅下面的“Relax-and-Recover 版本升级”部分。

为哪些 SUSE Linux Enterprise 版本提供“rear...” RPM 包

SUSE Linux Enterprise 12:
rear116
rear1172a (since SLE12-SP1)
rear118a (since SLE12-SP2)
rear23a (as additional package via maintenance update for SLE12-SP2)
rear27a (since SLE12-SP5)

SUSE Linux Enterprise 15:
rear23a (plus maintenance update to its latest content)
rear27a (since SLE15-SP2)

当前的 openSUSE “rear” RPM 包在 openSUSE Build Service 项目“Archiving”中提供，请参阅 https://build.opensuse.org/package/show/Archiving/rear，请参阅下面的“Relax-and-Recover 版本升级”部分。

使用 Relax-and-Recover (ReaR) 进行灾难恢复

Relax-and-Recover 是一个灾难恢复框架。

Relax-and-Recover 是 Linux 上事实上的灾难恢复框架，特别是对于 Red Hat Enterprise Linux (RHEL) 和 SUSE Linux Enterprise Server (SLES) 等企业 Linux 发行版，通过 SUSE Linux Enterprise 高可用性扩展 (SLE-HA)。

Relax-and-Recover 缩写为 ReaR（经常拼写错误为‘Rear’或‘rear’）。关于 Relax-and-Recover，通常在程序 /usr/sbin/rear 涉及时使用单词‘rear’（例如程序调用“rear mkbackup”和“rear recover”）以及 ReaR 文件和目录名称（例如 /etc/rear/local.conf）。RPM 包名称通常是小写的，因此 ReaR RPM 包命名为‘rear’。

Relax-and-Recover 完全用系统管理的本机语言编写：作为 shell (bash) 脚本。

有经验的用户和系统管理员可以根据需要调整或扩展 ReaR 脚本，以使其适用于他们的特定情况，并且 - 如果最坏的情况发生 - 即使是临时的快速而肮脏的解决方法也相对容易实现 - 只要您了解 ReaR 和您的系统，以便您为适当的手动临时干预做好准备。

来自 Relax-and-Recover 上游 的专业服务和支持可用（请参阅 http://relax-and-recover.org/support/）。

使用 ReaR 进行灾难恢复的基本工作原理

在 /etc/rear/local.conf 中指定 ReaR 配置（参考“man rear”和 /usr/share/rear/conf/examples/ 和 /usr/share/rear/conf/default.conf），然后运行“rear mkbackup”以在 NFS 服务器上创建 backup.tar.gz 和您的系统的可引导 ReaR 恢复 ISO 镜像。

ReaR 恢复 ISO 镜像包含 ReaR 恢复安装系统，其中包含特定于系统所在系统的 ReaR 安装程序。

使用从 ISO 镜像制作的恢复介质在您的替换硬件上启动 ReaR 恢复系统（ReaR 恢复系统通过 ramdisk 在主内存中运行）。

在 ReaR 恢复系统中以 root 用户身份登录并运行 ReaR 安装程序，通过“rear recover”，它执行以下操作

  1. 重建基本的系统存储，特别是磁盘分区和文件系统以及挂载点。
  2. 从 NFS 服务器恢复备份。
  3. 安装引导加载程序。

最后，移除 ReaR 恢复介质并重新启动重建的系统。

在“足够简单”的情况下，它“可以正常工作”（前提是您为特定情况在 /etc/rear/local.conf 中指定了正确的配置）。但是请记住：没有“可以正常工作”的灾难恢复解决方案。因此：如果它不起作用，您可能会更改系统配置以使其更简单，或者您必须手动调整和增强 ReaR 的各种 bash 脚本使其适用于您的特定情况。

关于“Relax-and-Recover”中“Relax”的含义说明

由于没有“可以正常工作”的灾难恢复解决方案，并且没有在实际可用的替换硬件上进行测试的灾难恢复，因此“Relax”的含义不是您可以轻松配置 /etc/rear/local.conf，只需运行“rear mkbackup”，然后放松。

“Relax”的含义是：在有经验的管理员设置它（可能需要进行一些调整）之后，并且在彻底测试后，并且只要持续验证恢复是否确实适用于替换硬件（尤其是在基本系统每次更改后），那么就可以放松。

此外，“Relax”的含义是，您可以在灾难发生之前，有时间以“放松”的方式逐步进行操作时，花时间仔细设置、测试和持续验证您的特定灾难恢复程序。

当后来发生真正的灾难时，即使是相对没有经验的人也可以在替换硬件上执行恢复（启动 ReaR 恢复系统，以 root 用户身份登录，运行“rear recover”，然后最终重新启动）。

此外，“Relax”的含义是，您需要“放松”并花时间仔细设置（进行一些试验和错误），并正确验证您的特定灾难恢复程序，因为最终您的特定灾难恢复安装将成为您的最终系统安装，请参阅下面的“关于使用 Relax-and-Recover 演示文稿的灾难恢复要点”链接。

限制在于特殊的 ReaR 恢复系统可以做什么

ReaR 恢复系统与 openSUSE 或 SUSE Linux Enterprise 安装介质上的安装系统和 YaST 安装程序和 AutoYaST 完全不同。这意味着当使用 ReaR 恢复您的系统时，完全不同的安装程序会重建您的系统。因此，如果从 openSUSE 或 SUSE Linux Enterprise 安装介质进行基本操作系统安装成功，那么特殊的 ReaR 恢复系统可能不适用于您的特定情况，或者它可能有效，但会以一些（可能微妙但严重）的差异重建您的系统。

Relax-and-Recover 与备份和恢复

Relax-and-Recover (ReaR) 补充了文件的备份和恢复，但 ReaR 既不是备份软件也不是备份管理软件，并且不打算成为这些软件。

通常，备份和恢复文件是 ReaR 的外部功能。

即，ReaR 中实际上没有实现备份或恢复功能。

ReaR 仅在“rear mkbackup”期间调用外部工具备份文件，并在“rear recover”期间调用相应的工具恢复文件（默认情况下，该工具是 'tar'）。

验证您的备份是否足以恢复系统，以满足您的需求是您的任务。

验证您的备份是否可以完全读取以恢复所有文件是您的任务。

确保您的备份一致性是您的任务。首先，备份中的文件必须与 ReaR 恢复系统中存储的数据一致（特别是存储在诸如 var/lib/rear/layout/disklayout.conf 之类文件中以重新创建存储的文件系统和挂载点的数据），因为 ReaR 将使用 ReaR 恢复系统中存储的数据重新创建存储（文件系统和挂载点），然后从备份中将文件恢复到重新创建的存储中。这意味着，特别是，恢复的配置文件必须与实际重新创建的系统匹配（例如，恢复的 etc/fstab 的内容必须与实际重新创建的磁盘布局匹配）。因此，每次更改基本系统（特别是更改磁盘布局后），都需要运行“rear mkbackup”以创建新的 ReaR 恢复系统以及与该系统匹配的新文件备份（或者，当使用第三方备份软件时，需要运行“rear mkrescue”以创建新的 ReaR 恢复系统，并另外创建与该系统匹配的新文件备份）。请参阅下文“‘一致的备份’意味着什么”。例如，您可能需要在备份工具运行之前停止某些正在运行的程序（例如，任何可能更改包含在备份中的文件的服务或类似事物）。

确保您的备份保存在足够安全的地方是您的任务。特别是，ReaR 写入新备份的地方（例如，NFS 共享或 USB 磁盘）并不是一个真正安全的地方来保存旧备份（写入时可能会出现各种问题）。

关于“用于恢复的对应工具”：为了能够在“rear recover”期间调用恢复工具，恢复工具及其运行所需的一切（库、配置文件、其他任何内容）必须包含在运行“rear recover”的 ReaR 恢复系统中。对于几种备份和恢复工具/解决方案，ReaR 已经内置了功能，可以将恢复工具及其运行所需的一切获取到 ReaR 恢复系统中。

通常，ReaR 中仅实现对各种备份工具的基本支持（例如，在“rear mkbackup”期间进行普通备份，在“rear recover”期间进行普通恢复）。由于对每个单独备份工具的支持是相互独立实现的，因此 ReaR 中对每个单独备份工具的支持程度差异很大。因此，对于某些特定的备份工具，ReaR 中的当前支持可能甚至只是“非常基本”（请参阅下文“如何调整和增强 Relax-and-Recover”和“如何为 Relax-and-Recover 贡献代码”部分）。特别是，对于大多数第三方备份工具，仅支持在“rear recover”期间进行普通备份恢复，但根本不支持在“rear mkbackup”期间进行备份，因此“rear mkbackup”对大多数第三方备份工具而言毫无用处，只有“rear mkrescue”才有用（“rear mkbackup”创建 ReaR 恢复系统并进行备份，而“rear mkrescue”仅创建 ReaR 恢复系统）。有关更多信息，请参阅“man rear”。为了确保您的备份与 ReaR 恢复系统中存储的数据一致，每次创建新的 ReaR 恢复系统时都应创建新的备份，反之亦然：每次创建新的备份时，也应创建新的 ReaR 恢复系统。当基本系统发生更改（特别是更改磁盘布局后）时，您必须创建新的 ReaR 恢复系统。

ReaR 中基本上没有处理备份的任何进一步操作，除了 NETFS_KEEP_OLD_BACKUP_COPY 等小功能，请参阅下文。

总结

在运行“rear mkbackup”后，用户必须自行决定在特定环境中如何进一步处理备份、ReaR 恢复系统 ISO 镜像和 ReaR 日志文件等。

ReaR 与“大数据”备份

建议将基本系统的灾难恢复与“大数据”的备份和恢复分开，请参阅上述“基础知识”部分，其中写道（摘录）

在这种特定情况下，“灾难恢复”意味着重新创建基本的操作系统……通常需要额外单独的步骤来重新创建第三方数据库系统……

因此，不建议将“大数据”放在用于 ReaR 灾难恢复的备份中，因为当备份中包含“大数据”用于灾难恢复时，恢复基本系统需要很长时间（在“rear recover”期间，备份恢复部分花费了大部分时间）。

此外，一个巨大的“一体化”备份可能比几个分离的备份更容易失败（在备份期间，尤其是在恢复期间），例如，一个用于 ReaR 灾难恢复的基本系统备份，以及根据需要为不同类型的“大数据”创建的独立备份，这些备份在 ReaR 灾难恢复完成后根据需要进行恢复，并在重新启动的基本系统中进行恢复。

最后，几个分离的备份更易于实际操作，因为您可以根据需要单独备份和恢复不同的内容，例如，在 ReaR 重新创建的基本系统中灾难恢复后，首先恢复最重要的“大数据”，然后恢复不太重要的其他“大数据”，或者您可以在紧急情况下并行运行几个“大数据”恢复，以利用强大的硬件尽快完成整个系统灾难恢复过程。

关于 NETFS_KEEP_OLD_BACKUP_COPY

使用 NETFS 备份方法，ReaR 会将其文件（特别是 backup.tar.gz 和 ReaR 恢复系统 ISO 镜像）写入属于网络文件系统（通常是 NFS）的已挂载目录。

使用空 NETFS_KEEP_OLD_BACKUP_COPY=""，第二次“rear mkbackup”运行会覆盖 NFS 目录中来自先前“rear mkbackup”运行的文件。这意味着，在成功运行“rear mkbackup”后，如果未将 NFS 目录中的文件保存到永久安全的地方，则第二次“rear mkbackup”运行失败时将没有备份。特别是，在第二次“rear mkbackup”运行覆盖旧备份时，您将没有备份。

使用非空 NETFS_KEEP_OLD_BACKUP_COPY="yes"，第二次“rear mkbackup”运行将不会覆盖 NFS 目录中来自先前“rear mkbackup”运行的文件。相反，第二次“rear mkbackup”运行会将现有的 NFS 目录重命名为 *.old，然后再写入其文件。

请注意，“KEEP_OLD_BACKUP_COPY”功能并非适用于 ReaR 具有内置支持来调用其备份和恢复功能的各种备份和恢复工具/解决方案。

使用 Relax-and-Recover 进行版本升级

如果您有一个可用的灾难恢复过程，请不要升级 ReaR，也不要更改 ReaR 使用的基本软件（例如，分区工具、文件系统工具、引导加载程序工具、ISO 镜像创建工具等）。

对于 ReaR 的每次版本升级以及 ReaR 使用的软件的每次更改，您都必须仔细完整地重新验证您的特定灾难恢复过程是否仍然适用于您。

相反，如果特定的 ReaR 版本对您不起作用，请尝试更新的版本。

请参阅下文“First steps with Relax-and-Recover”部分，您可以在其中获取最新的 ReaR 版本，或参阅 Relax-and-Recover 上游的下载。

由于 ReaR 仅是 bash 脚本（加上文档），这意味着，最终，您使用的 bash 脚本的版本并不重要。重要的是，实际运行于您的特定灾难恢复过程中的 ReaR bash 脚本的特定子集对您有效，或者可以进行调整或扩展，以便以尽可能少的精力使其工作。

如果它无法与最新的 ReaR 版本一起工作，请尝试更改您的基本系统配置以使其更传统（如果可能，请尝试避免使用基本系统的最新功能），或者您必须手动调整和增强 ReaR 以使其适用于您的特定情况。

对于属于基本系统的任何类型的创新（例如，内核、存储、引导加载程序、init），新的类型（例如，udev、btrfs、Grub2 / UEFI / 安全启动、systemd）将首先出现，然后 ReaR 可以逐步适应以支持它。

另一方面，这意味着：如果您有一个可用的灾难恢复过程，并且升级与基本系统相关的软件或对基本系统进行其他更改，您还必须仔细完整地重新验证您的特定灾难恢复过程是否仍然适用于您。

测试当前的 ReaR 上游 GitHub master 代码

可以在并行中拥有多个 ReaR 版本，每个版本都在其自己的独立目录中，而不会相互冲突，也不会与通过 RPM 包正常安装的 ReaR 版本冲突。

因此，您可以尝试当前的 ReaR 上游 GitHub master 代码，从一个独立的目录中进行测试，以了解与您安装的 ReaR 版本相比，当前 ReaR 上游 master 代码是否效果更好。

基本上，“git clone”当前的 ReaR 上游 GitHub master 代码到一个独立的目录中，然后像这样从该目录中配置和运行 ReaR

git clone https://github.com/rear/rear.git

mv rear rear.github.master

cd rear.github.master

vi etc/rear/local.conf

usr/sbin/rear -D mkbackup

请注意相对路径“etc/rear/”和“usr/sbin/”。

如果出现 ReaR 问题，建议尝试当前的 ReaR 上游 GitHub master 代码，因为那是 ReaR 上游修复错误的地方，即，已发布 ReaR 版本中的错误不会由 ReaR 上游修复，请参阅下文“调试 Relax-and-Recover 的问题”和“如何调整和增强 Relax-and-Recover”部分。

使用 Relax-and-Recover 的第一步

为了充分理解 ReaR 的工作原理，您需要自己使用它，自己尝试，自己进行一些试验，以熟悉 ReaR，这是即使在紧急情况下和时间紧迫的情况下也能以“放松”的方式进行实际灾难恢复的强制先决条件，请参阅上述“‘Relax’在‘Relax-and-Recover’中的含义”部分。

有关 ReaR 文档，请参阅“man rear”和 /usr/share/rear/conf/default.conf 以及 /usr/share/doc/packages/rear*/ 中的文件，如果您安装了 rear* RPM 包，或者 doc/user-guide/ 和 “man -l doc/rear.8” 中的文件，如果您使用当前的 ReaR 上游 GitHub master 代码（如上所述），或在线，例如

建议您按照以下步骤使用 ReaR

1.
您需要一台 NFS 服务器机器，ReaR 可以将备份和 ISO 镜像存储到该机器上。例如，创建一个 /nfs/ 目录并通过 NFS 导出该目录。要设置 NFS 服务器，您可以使用 YaST“NFS Server”模块（由“yast2-nfs-server”RPM 包提供）。您需要调整 /etc/exports 中的默认设置，以便以 root 身份运行的 ReaR 可以将备份和 ISO 镜像写入那里，例如以下示例。特别是，将其导出为“rw”，例如

/nfs    *(rw,root_squash,sync,no_subtree_check)

通常，它应该可以使用“root_squash”（以便在 NFS 服务器上使用非 root 用户和组，例如“nobody:nogroup”），但也许在某些情况下，您甚至可能需要“no_root_squash”（以便在 NFS 服务器上 root 用户可以拥有任何权限）。如果使用“root_squash”，则 NFS 服务器上的导出的“/nfs”目录必须具有足够的权限，以便“nobody:nogroup”可以创建/写入文件和子目录，并访问这些子目录中的文件，例如，您可以允许任何用户和组使用这些权限执行此操作

drwxrwxrwx ... /nfs

2.
在功能强大的主机上（最低要求是双核 CPU 和 4GB 内存），创建两个相同的虚拟 KVM/QEMU 机器，具有完全的硬件虚拟化（CPU 虚拟化除外，因为那样会慢得多），如下所示

  • 单个 CPU
  • 1-2 GB 内存 (RAM)
  • 单个 10-20 GB 虚拟硬盘
  • 单个虚拟网络接口卡
  • 标准的 PC 兼容架构和传统的 BIOS

使用标准的 PC 兼容架构（请参阅有关“非 PC 兼容架构”的部分），特别是不要使用 UEFI（除非您想看看您的 ReaR 第一步将如何失败）。“相同的虚拟 KVM/QEMU 机器”的含义如上文“需要完全兼容的替换硬件”部分所述。特别是，两台机器上的虚拟硬盘大小相同，虚拟网络接口卡类型也相同。如果您使用“virt-manager”创建虚拟 KVM/QEMU 机器，请将默认“OS 类型”显式设置为“Generic”，以获得完全的硬件虚拟化，以便虚拟硬盘显示为真实的硬盘，如 /dev/sda（如果您使用某种形式的半虚拟化，则硬盘显示为 /dev/vda 或类似）。KVM/QEMU 的虚拟网络设置决定了虚拟机器可以访问远程机器的程度。至少，ReaR 将存储其备份和 ISO 镜像以及从中恢复备份的 NFS 服务器必须可以从虚拟机器访问。如果虚拟网络处于所谓的“隔离模式”（使用私有 IP 地址，格式为 192.168.nnn.mmm），则 NFS 服务器必须在主机上运行，在这种模式下，虚拟机器只能相互通信以及与主机通信，但虚拟机器与外部/物理网络断开连接。实际上，对于处于“隔离模式”的虚拟网络，不需要物理网络，这意味着您可以在一台隔离的计算机上进行 ReaR 的第一步，该计算机充当虚拟机器和 NFS 服务器的主机。在这种隔离的私有网络中，主机的 IP 地址通常是 192.168.100.1 或 192.168.122.1，虚拟机器通常通过一个特殊的 DNS+DHCP 服务器“dnsmasq”自动分配 IP 地址，该服务器根据需要自动配置和启动，仅用于此类虚拟网络。

3.
在一台虚拟机器上，安装至少 SLES12-SP5 或 SLES15-SP2 到一个单独的 ext3 或 ext4 文件系统中。对于 ReaR 的第一步，请保持简单，不要使用几个分区（例如，一个用于系统和一个额外的“/home”分区）。特别是，不要使用 SLES12 和 SLES15 中复杂 btrfs 默认结构，除非您希望在 ReaR 的第一步中处理复杂的问题。

4.
对于 ReaR 的首次使用，请使用一个小型测试系统（以便进行小型且快速的备份和还原），但仍然可以正常使用 X Window 系统。例如，仅安装以下软件模式

  • 基本系统
  • 最小系统（Appliances）
  • X Window System

此外，安装 "MozillaFirefox" 包作为一个示例应用程序，以检查系统在恢复前后是否可以正常使用。特别是，安装一个提供 'dhclient' 程序的包，该程序是 ReaR 恢复系统中 DHCP 所必需的。在最新的 openSUSE 和 SLES 版本中，'dhclient' 由 "dhcp-client" RPM 包提供。此外，安装 "bc" 和 "lsb-release" 包，这些包是 ReaR 所必需的。您还可以安装一个提供传统的（现在已弃用）网络工具的包，例如 'ifconfig / netstat / route' 等。在最新的 openSUSE 和 SLES 版本中，这些工具仍然由 "net-tools-deprecated" RPM 包提供。最后，ReaR 需要纯文本编辑器 'vi'，该编辑器由 "vim" RPM 包提供。

5.
对于 ReaR 的首次使用，保持简单，仅使用单个网络接口 "eth0" 并使用 DHCP。

6.
安装最新的 ReaR 版本（至少 ReaR 版本 2.7，最好通过 SLES12-SP5 或 SLES15-SP2 中的 "rear27a" RPM 包）。当前的 ReaR 版本可通过 openSUSE 构建服务项目 "Archiving" 和 "Archiving:Backup:Rear" 直接下载 RPM 包，地址如下：

或者，您可以使用当前 ReaR 上游 GitHub master 代码，如上述“测试当前 ReaR 上游 GitHub master 代码”部分所述。当然，当前的 ReaR 上游 GitHub master 代码正在持续开发中，因此有时可能无法正常工作。

7.
通过使用 /usr/share/rear/conf/examples/SLE11-ext3-example.conf 作为模板（将其复制到 /etc/rear/local.conf）来设置 /etc/rear/local.conf，并根据需要进行调整（阅读该文件中的注释，并参阅 "man rear" 和 /usr/share/rear/conf/default.conf）。如果您没有 /usr/share/rear/conf/examples/SLE11-ext3-example.conf 文件，请安装更现代化的 ReaR 版本（至少 ReaR 版本 2.7）。

8.
检查 MozillaFirefox（或您使用的任何示例应用程序）在系统上是否可以正常使用，并进行一些用户特定的设置（例如，在 MozillaFirefox 中保存一些书签）。是否可以从虚拟机内部访问外部网络（例如 https://www.suse.com 在互联网上）取决于主机上 KVM/QEMU 的网络设置，或者您是否只能访问虚拟机上本地的文件（例如 /usr/share/pixmaps）。

9.
现在运行

rear -d -D mkbackup

在您的 NFS 服务器机器上，您应该在它导出的 '/nfs' 目录的 'hostname' 子目录中获得一个 'backup.tar.gz' 和一个 'rear-hostname.iso'（参考上述关于 NFS 服务器设置）。

10.
关闭运行 "rear -d -D mkbackup" 的系统，以模拟该系统已损坏。

11.
使用该 rear-hostname.iso 启动另一个虚拟机，并在 ReaR 的启动屏幕上选择“recover hostname”（即使用手动恢复 - 不要使用自动恢复），并以 root 用户身份登录（无需密码）。

12.
现在，ReaR 恢复系统在另一个虚拟机上运行。其中运行 ReaR 恢复安装程序，命令如下：

rear -d -D recover

您应该在另一个虚拟机上重新创建系统。

13.
关闭 ReaR 恢复系统并重新启动重新创建的系统。

14.
检查 MozillaFirefox（或您使用的任何示例应用程序）在重新创建的系统中是否仍然可以正常使用，并检查您的用户特定设置（例如，MozillaFirefox 中的书签）是否仍然存在。

您可以通过 ssh 远程运行 "rear recover"，如下所示：

在 /etc/rear/local.conf 中设置

USE_DHCLIENT="yes"

以及类似如下内容：

SSH_ROOT_PASSWORD="rear"

切勿在此处使用您原始的 root 密码。

在您的第一个虚拟机上运行

rear -d -D mkbackup

使用 rear-hostname.iso 启动另一个虚拟机，并在 ReaR 的启动屏幕上选择“recover hostname”（即使用手动恢复 - 不要使用自动恢复），并以 root 用户身份登录（无需密码）。

输入 "ifconfig" 或 "ip addr" 以查看 ReaR 恢复系统中的 IP 地址，并通过 ssh 使用 SSH_ROOT_PASSWORD 值从远程登录，然后运行

rear -d -D recover

调试 Relax-and-Recover 的问题

由于 ReaR 完全用 bash 脚本编写，因此调试 ReaR 通常是 bash 调试。

要仅显示将要运行的脚本（即 ReaR 主脚本 /usr/sbin/rear 将“source”的脚本）对于特定的 rear 命令（而不实际执行它们），请使用 '-s' 选项（模拟模式），例如：“rear -s mkbackup”和“rear -s recover”。

要调试 ReaR，请同时使用 '-d' 选项（记录调试消息）和 '-D' 选项（debugscript 模式）来记录命令及其参数，因为它们正在执行（通过 'set -x'），例如：“rear -d -D mkbackup”和“rear -d -D recover”。

之后，检查 ReaR 日志文件以进行进一步分析。

ReaR 日志文件存储在 /var/log/rear/ 目录中。

当 "rear -d -D recover" 完成时，日志文件将被复制到恢复的系统中，要么进入 /root/ 目录，要么对于较新的 ReaR 版本进入分离的 /var/log/rear/recover/ 目录，以确保从上次恢复的日志文件安全且与其它 ReaR 日志文件分离，以便在需要时可以随时分析上次恢复的日志文件。

当 "rear -d -D recover" 失败时，您需要在关闭 ReaR 恢复系统之前将日志文件从 ReaR 恢复系统（运行 "rear -d -D recover" 并失败的位置）保存出来 - 否则日志文件将丢失（因为 ReaR 恢复系统在 ramdisk 中运行）。此外，ReaR 恢复系统中的 /var/lib/rear/ 目录及其子目录中的文件（特别是 /var/lib/rear/layout/disklayout.conf 和 /var/lib/rear/layout/diskrestore.sh）需要用于分析 "rear -d -D recover" 失败。请参阅上面的“使用 Relax-and-Recover 的第一步”部分，了解如何通过 ssh 从远程访问 ReaR 恢复系统，以便可以使用 'scp' 将文件从 ReaR 恢复系统中取出。

要分析和调试 "rear mkrescue/mkbackup" 失败，以下信息是强制性的

  • ReaR 版本 ("/usr/sbin/rear -V")
  • 操作系统版本 ("cat /etc/os-release" 或 "lsb_release -a" 或 "cat /etc/rear/os.conf")
  • ReaR 配置文件 ("cat /etc/rear/local.conf" 和/或 "cat /etc/rear/site.conf")
  • 原始系统的硬件（PC 或 PowerNV BareMetal 或 ARM）或虚拟机（KVM 客户机或 PoverVM LPAR）
  • 原始系统的系统架构（x86 兼容或 PPC64/PPC64LE 或什么确切的 ARM 设备）
  • 原始系统的固件（BIOS 或 UEFI 或 Open Firmware）和引导加载程序（GRUB 或 ELILO 或 Petitboot）
  • 原始系统的存储（本地磁盘或 SSD）和/或 SAN（FC 或 iSCSI 或 FCoE）和/或多路径（DM 或 NVMe）
  • 原始系统上 "lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT" 的输出
  • 原始系统上 "findmnt -a -o SOURCE,TARGET,FSTYPE -t btrfs,ext2,ext3,ext4,xfs,reiserfs,vfat" 的输出
  • 原始系统上 "rear -d -D mkbackup" 或 "rear -d -D mkrescue" 的调试日志文件（在 /var/log/rear/ 中）

要分析和调试 "rear recover" 失败，以下附加信息也至关重要

  • 替换硬件（PC 或 PowerNV BareMetal 或 ARM）或替换虚拟机（KVM 客户机或 PoverVM LPAR），请参阅上述“需要完全兼容的替换硬件”部分
  • 替换系统的系统架构（x86 兼容或 PPC64/PPC64LE 或什么确切的 ARM 设备）（必须与原始系统使用的相同）
  • 替换系统的固件（BIOS 或 UEFI 或 Open Firmware）和引导加载程序（GRUB 或 ELILO 或 Petitboot）（必须与原始系统使用的相同）
  • 替换硬件上的存储（本地磁盘或 SSD）和/或 SAN（FC 或 iSCSI 或 FCoE）和/或多路径（DM 或 NVMe）（应尽可能与原始系统使用的相同）。替换存储必须表现得像全新的存储（请参阅上述“为灾难恢复准备替换硬件”部分）
  • 从 ReaR 恢复系统内部在替换系统上两次输出 "lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"，在调用 "rear -d -D recover" 之前和调用失败之后（请参阅上述如何通过 ssh 从远程访问 ReaR 恢复系统，以便可以更轻松地复制和粘贴命令输出）
  • 从 ReaR 恢复系统内部在替换系统上两次输出 "findmnt -a -o SOURCE,TARGET,FSTYPE -t btrfs,ext2,ext3,ext4,xfs,reiserfs,vfat"，在调用 "rear -d -D recover" 之前和调用失败之后（请参阅上述如何通过 ssh 从远程访问 ReaR 恢复系统，以便可以更轻松地复制和粘贴命令输出）
  • 与 "rear recover" 失败匹配的 "rear -d -D mkbackup" 或 "rear -d -D mkrescue" 的调试日志文件（在 /var/log/rear/ 中）（即从原始系统创建 ReaR 恢复系统的 "rear -d -D mkbackup" 或 "rear -d -D mkrescue" 命令的调试日志）
  • 替换系统上 ReaR 恢复系统内部 "rear -d -D recover" 的调试日志文件（在 /var/log/rear/ 中），在失败的位置（请参阅上述如何从 ReaR 恢复系统中保存日志文件）
  • 替换系统上 ReaR 恢复系统内部 /var/lib/rear/ 目录及其子目录的内容，在 "rear -d -D recover" 失败的位置（请参阅上述如何从 ReaR 恢复系统中保存文件）

如何调整和增强 Relax-and-Recover

由于 ReaR 完全用 bash 脚本编写，因此调整和增强 ReaR 基本上是“常规 bash 脚本”。

通常 bash 脚本主要用作一种变通方法，以快速而粗糙地完成某事。

除非您确定您的特定调整和增强永远不会对任何人有用，因为您确定其他人也可能遇到您进行特定调整和增强的特定问题，否则不要以这种方式调整和增强 ReaR。

您将 ReaR 作为 自由软件 获得，并且您从中受益。

如果您在使用 ReaR 时遇到问题，请调整和增强它，以便其他人也能从您的调整和增强中受益。

这意味着您应该为 ReaR 上游做出贡献（请参阅 如何为 Relax-and-Recover 贡献），如下所示：

如何为 Relax-and-Recover 贡献

  • 在 ReaR 上游报告您的问题，以便其他人也了解它：https://github.com/rear/rear/issues
  • 以向后兼容的方式实现您的调整和增强，以便您的更改不会对其他人造成回归
  • 在您的调整和增强的源代码中提供注释，解释您做了什么以及为什么这样做，以便其他人可以轻松理解您更改的原因（即使所有内容对您来说都非常明显，但那些不了解您的特定用例或没有您的特定环境的人可能无法理解您的更改）
  • 遵循 ReaR 编码风格指南：https://github.com/rear/rear/wiki/Coding-Style
  • 将您的调整和增强提交给 ReaR 上游，以便其他人受益于您的工作：http://relax-and-recover.org/development/

当您提交您的调整和增强，以便 ReaR 上游可以接受它们时，您将从 ReaR 中受益更多，因为这是您的调整和增强也将在未来的 ReaR 版本中可用，并且其他受益于您的调整和增强的人可以将其保持为最新状态的唯一方法。

相反，如果您只在自己身上进行调整和增强，您将被抛在后面。

如果您在使用 ReaR 时遇到问题，但无法自行调整和增强它，您可以让其他人为您完成：http://relax-and-recover.org/support/sponsors

虚拟机

通常，虚拟化主机软件提供快照功能，以便可以保存和还原整个虚拟机（客户机）。使用快照功能会导致虚拟机保存到特定于所用虚拟化主机软件的文件中，这些文件通常存储在虚拟化主机上。因此，必须在额外的步骤中保存这些文件（通常应保存整个虚拟化主机），才能使虚拟机免受虚拟化主机故障的影响。

与此相反，使用 ReaR 时，虚拟机将保存为备份和 ISO 镜像，这些镜像独立于虚拟化主机。

全/硬件虚拟化

使用 ReaR，可以保存在特定虚拟化环境中在一台物理机器上运行的虚拟机，并在另一台物理机器上的相同虚拟化环境中还原它。这样，应该能够在不同的替换硬件上还原虚拟机，从而减轻对相同或兼容的替换硬件的需求。但是，您必须测试这是否适用于您的特定情况和您的特定替换硬件。

通常，无法保存在一种虚拟化环境中运行的虚拟机并在不同的虚拟化环境中还原它，因为不同的虚拟化环境模拟不同的机器，这些机器通常不兼容。

半虚拟化

半虚拟化虚拟机是一种特殊情况，特别是半虚拟化的 XEN 客户机。

半虚拟化的 XEN 客户机需要一个特殊的 XEN 内核 (vmlinux-xen) 和一个特殊的 XEN initrd (initrd-xen)。启动半虚拟化 XEN 客户机的 XEN 主机软件期望在特定的文件名 "/boot/ARCH/vmlinuz-xen" 和 "/boot/ARCH/initrd-xen" 中找到 XEN 内核和 XEN initrd，其中 ARCH 通常是 i386 或 i586 或 x86_64。

此外，半虚拟化的 XEN 客户机特别需要加载 xennet 和 xenblk 内核模块。这可以在 /etc/rear/local.conf 中使用一行 "MODULES_LOAD=( xennet xenblk )" 来指定，这让 ReaR 恢复系统以给定的顺序自动加载这些模块（请参阅 /usr/share/rear/conf/default.conf）。

ReaR 不提供创建可直接用于启动半虚拟化 XEN 客户机的特殊“媒介”的功能。ReaR 创建一个可引导的 ISO 镜像，该镜像在通常的 PC 硬件上启动。ReaR 创建一个可引导的 ISO 镜像，其中内核和 initrd 位于 ISO 镜像的根目录中。

要使用 ReaR 重新创建半虚拟化的 XEN 客户机，必须调整 XEN 主机的配置，以便它可以从通常的可引导 ISO 镜像启动 ReaR 恢复系统。基本上，这意味着从通常的可引导 ISO 镜像启动半虚拟化的 XEN 客户机。

请记住：没有“即插即用”的灾难恢复解决方案。因此：如果它不起作用，你或许可以更改你的系统使其更简单（例如，使用完全/硬件虚拟化代替半虚拟化），或者你必须手动调整和增强灾难恢复框架使其适用于你的特定情况。

非 PC 兼容架构

非 PC 兼容架构是指既不是 x86/i386/i486/i586（32 位）也不是 x86_64（64 位）的架构，例如 ppc、ppc64、ia64、s390、s390x。

恢复介质兼容性

ReaR（至版本 1.17.2）创建一个传统的 El Torito 可引导 ISO 镜像，它以传统方式在 PC 硬件上引导（即，它以 BIOS 模式引导 - 而不是 UEFI 模式）。对于可引导 UEFI 的 ISO 镜像，至少需要 ReaR 版本 1.18 加上 ebiso 包（参阅上方“rear / rear116 / rear1172a / rear118a / rear23a / rear27a”部分中的“rear118a”）或足够新的 ReaR 版本（至少 ReaR 版本 2.7）加上足够新的 xorriso 版本（参阅 https://github.com/rear/rear/issues/3084 其中特别是 https://github.com/rear/rear/issues/3084#issuecomment-1891492816）。

ReaR 不提供特殊功能来创建可用于在非 PC 兼容架构上引导的任何类型的特殊可引导“介质”。

因此，在无法引导 El Torito 可引导介质的硬件架构上，不能在没有适当的增强和/或修改的情况下使用 ReaR。

通过 kexec 启动 ReaR 恢复系统

应该始终能够通过 kexec 从你的替换硬件上的任意已运行系统启动 ReaR 恢复系统（前提是该已运行系统支持 kexec）。

在你的替换硬件上，有一个已运行的系统，它可以是任何支持 kexec 的系统（任何小型且简单的支持 kexec 的系统就足够了），并且可以根据你的喜好安装（例如，从 openSUSE 或 SUSE Linux Enterprise 安装介质），参阅上面的“为灾难恢复准备替换硬件”部分。

该已运行的系统不需要与你打算重现的系统兼容。例如，当你打算重现一个具有各种文件系统复杂结构的 SUSE Linux Enterprise 15 系统时，该已运行的系统可以是只有一个 ext4 根文件系统的最小 openSUSE Tumbleweed 系统。

建议该已运行的系统保持最新，因为更新的内核应该能更好地应对 kexec 失败的潜在问题，尤其是在新内核已经运行的同时，旧内核仍然存在内存中的持续硬件操作（例如，仍然写入内存中的旧 DMA 操作）。

在你要重现的原始系统上，让 ReaR 将其包含 ReaR 恢复系统和你要重现的系统的原始内核的纯 initrd 复制到 ReaR 的输出位置，方法是使用 'OUTPUT=RAMDISK'。

在 ReaR 版本 2.6 之前，'OUTPUT=RAMDISK' 可能无法正常工作，参阅 https://github.com/rear/rear/pull/2149 和 https://github.com/rear/rear/issues/2148，因此你应该使用 ReaR 版本 2.6，或者你可以尝试当前的 ReaR 上游 GitHub master 代码，参阅上面的“测试当前的 ReaR 上游 GitHub master 代码”部分。

在替换硬件上已运行的系统中，kexec 加载你要重现的系统的原始内核加上匹配的 ReaR 恢复系统 initrd，以启动 ReaR 恢复系统。

一个示例 etc/rear/local.conf 可能是这样的（摘录）

OUTPUT=RAMDISK
BACKUP=NETFS
BACKUP_URL=nfs://your.NFS.server.IP/path/to/your/rear/backup

通过 OUTPUT=RAMDISK，“rear mkrescue/mkbackup” 将内核（默认命名为 kernel-HOSTNAME）加上 ReaR 恢复系统 initrd（默认命名为 initramfs-HOSTNAME.img）复制到输出位置，与备份存储的位置相同（即 BACKUP_URL 指定的内容）。

要在你的替换硬件上重现该系统，启动你替换硬件上已安装的系统，并在其中执行以下步骤

1.)
将内核和 ReaR 恢复系统 initrd 从 ReaR 的输出位置复制到你的替换硬件上已运行的系统中。

2.)
加载内核和 ReaR 的 initrd，并提供适当的内核命令行，以在 ramdisk 中运行 ReaR 恢复系统，并使用标准 VGA 80x25 文本模式（你可能需要从你要重现的原始系统的 /proc/cmdline 中添加特殊的硬件相关参数）例如：

kexec -l kernel-HOSTNAME --initrd=initramfs-HOSTNAME.img --command-line='root=/dev/ram0 vga=normal rw'

3.)
kexec 加载的内核（加上 ReaR 的 initrd），这将立即重启到加载的内核，而无需干净地关闭当前运行的系统

kexec -e

4.)
在启动的 ReaR 恢复系统中，以 'root' 用户身份登录（这可能仅在系统控制台上有效），并恢复你的系统，这将完全替换之前的系统，因此即使它没有干净地关闭也无关紧要

rear -D recover

另请参阅 ReaR 上游的 issue “Alternatively do kexec instead of regular boot to speed up booting” https://github.com/rear/rear/issues/2186。

引导加载程序兼容性

基本上，GRUB 就像在通常的 PC 硬件上使用的那样，是唯一支持的引导加载程序。

可能存在对特殊引导加载程序配置的一些有限支持，但你不能依赖它。

因此，建议使用具有标准配置的 GRUB。

如果非 PC 兼容架构上无法使用具有标准配置的 GRUB，则需要适当的增强才能添加对特殊引导加载程序配置的支持。

至关重要的是，提前检查是否可以使用 ReaR 或你使用的任何其他灾难恢复程序重现你特定的非 PC 兼容系统。

所有文件系统都是平等的，但有些比其他文件系统更平等

ext2 ext3 ext4

当使用标准设置的标准 Linux 文件系统 ext2、ext3、ext4 时，不应存在问题，但特殊的 文件系统调整设置可能需要手动调整才能使其适用于你的特定情况。

btrfs

首先最重要的是：如果你使用 btrfs，不要期望任何类型的灾难恢复框架“即插即用”。

自 ReaR 版本 1.17 以来，存在对具有普通子卷的 btrfs 的通用基本支持（但不包括快照子卷）。请注意“基本支持”。特别是，不支持“交织的 btrfs 子卷挂载”，这意味着当一个 btrfs 文件系统的子卷挂载到属于另一个 btrfs 文件系统的挂载点时，反之亦然（参阅 Relax-and-Recover 上游 issue 497 和 openSUSE Bugzilla bug 908854）。

当 btrfs 与快照一起使用时（即，使用包含 btrfs 快照的子卷），则无法使用常规备份和恢复。主要原因是：当存在 btrfs 快照子卷时，并且你运行常规基于文件的备份软件（例如“tar”）来备份整个 btrfs 文件系统的数据时，快照子卷中的所有内容都会备份为完整的文件。例如，假设有一个 8GB 磁盘，其中 btrfs 文件系统使用了 5GB 的磁盘空间，并且有一个最近的快照。最近的快照由于 btrfs 的写时复制功能，几乎不需要磁盘空间。但是，“tar” 将创建一个大小约为 10GB 的备份，因为文件在快照子卷的路径下出现两次：在它们的常规路径下，以及在快照子卷的路径下。将无法将该 tarball 恢复到磁盘上。这意味着 btrfs 快照子卷无法像使用基于文件的备份软件那样进行常规备份和恢复。

同样的问题可能发生在实现写时复制功能的所有文件系统（例如，OCFS2）中。有关背景信息，你可以阅读关于“reflink”（与“hardlink”相对）的内容。

对于 SUSE Linux Enterprise 12 GA 上的 Relax-and-Recover 灾难恢复，需要特殊的 RPM 包 rear116，该包提供具有针对 SUSE Linux Enterprise 12 GA 中默认 btrfs 子卷结构的特殊调整和增强的 ReaR 版本 1.16，但无法支持恢复 btrfs 快照子卷（见上文）。SUSE Linux Enterprise 12 SP1 中默认 btrfs 子卷结构的更改需要对 ReaR 进行进一步的调整和增强，请参阅 Relax-and-Recover 上游 issue 556，因此对于 SUSE Linux Enterprise 12 SP1 上的 Relax-and-Recover 灾难恢复，需要特殊的 RPM 包 rear1172a，对于 SUSE Linux Enterprise 12 SP2，应至少使用 RPM 包 rear118a，最好使用最新的 ReaR 版本（参阅上方“rear / rear116 / rear1172a / rear118a / rear23a / rear27a”和“使用 Relax-and-Recover 进行版本升级”）。

帮助和支持

提前可行

只有在你的系统仍然正常运行，并且你在替换硬件上测试以使用你的恢复介质重现你的系统，并且重现的系统可以自行启动，并且所有系统服务仍然按你的特定需求工作时，才能获得帮助和支持。

事后无望

在你的系统被破坏后，无法在替换硬件上重现系统时，通常无法获得帮助和支持。

特殊的 ReaR 恢复系统提供了一组最小的工具，在重现系统时，这些工具可以在某些情况下帮助修复问题，请参阅上面的“Relax-and-Recover”部分。前提条件是 ReaR 恢复系统至少可以正确启动在你的替换硬件上。如果 ReaR 恢复系统无法启动，通常会陷入僵局。

准备好手动重现

如果最终无法重现你的系统，你必须手动重现你的基本系统，特别是带有文件系统和挂载点的分区，然后你必须手动从你的 NFS 服务器或其他备份存储位置恢复你的备份。因此，你必须至少提供你的分区、文件系统、挂载点和网络信息，以便手动重现你的系统。建议在替换硬件上手动重现你的系统作为练习，以便做好准备。

至关重要的是，提前准备好可用的替换硬件来验证你是否可以重现你的系统，因为没有“即插即用”的灾难恢复解决方案。

SUSE 对 Relax-and-Recover 的支持

SUSE 通过 SUSE Linux Enterprise 高可用性扩展 (SLE-HA) 提供 Relax-and-Recover (ReaR)，这是 SUSE 官方支持 ReaR 的唯一 SUSE 产品/扩展。

对于其他 SUSE 产品（例如，没有 HA 扩展的纯 SLES），SUSE 仅自愿支持最新的 ReaR 上游版本或最好直接使用 ReaR 上游 GitHub master 代码在 ReaR 上游 https://github.com/rear/rear 上支持 - 请参阅上面的“使用 Relax-and-Recover 进行版本升级”、“测试当前的 ReaR 上游 GitHub master 代码”、“使用 Relax-and-Recover 调试问题”和“如何为 Relax-and-Recover 做出贡献”部分。

ReaR 既不是，也不是旨在成为类似“即用型灾难恢复解决方案”的东西，请参阅上面的“不恰当的期望”部分。相反，ReaR 仅旨在成为一个框架，经验丰富的用户和系统管理员可以使用它来构建他们特定的灾难恢复程序。因此，ReaR 完全用系统管理的本机语言编写：作为 shell（bash）脚本。其意图是 ReaR 用户可以并且应该根据需要调整或扩展 ReaR 脚本，使其适用于他们的特定情况，请参阅上面的“使用 Relax-and-Recover (ReaR) 进行灾难恢复”部分。

因此，通常没有 SUSE 提供的“即用型灾难恢复解决方案”，也未得到 SUSE 的支持。特别是，SUSE 不提供带有针对特定用例的调整和/或增强的 RPM 包更新，因为通常不可能预见是否会对其他用例发生回归。相反，SUSE 会不时提供 ReaR 版本升级作为单独的 RPM 包（参阅上面的“灾难恢复的 RPM 包”部分）。

另一方面，“SUSE 支持 ReaR”，但这意味着解决方案可能是 SUSE 提供帮助，以便用户可以调整或扩展他的 ReaR 脚本，使其适用于他的特定情况（在合理的用例范围内，在合理的努力范围内）。

因此，所有 ReaR 脚本在 SUSE 的 rear* RPM 包中都标记为“config(noreplace)”（自 ReaR 版本 1.17.1 以来，参阅上面的“灾难恢复的 RPM 包”部分），以便用户更改的 ReaR 脚本不会被 RPM 包更新覆盖。RPM 包更新中与用户更改的脚本不同的新脚本将作为“.rpmnew”文件安装。在 RPM 包更新之后，用户必须检查“.rpmnew”脚本与他的更改脚本之间的差异，以确定他的更改脚本是否仍然在他的特定用例中有效，或者是否需要进一步调整，以及仔细完整的重新验证他的特定灾难恢复程序是否仍然有效，请参阅上面的“使用 Relax-and-Recover 进行版本升级”部分。

参见

相关文章

外部链接

从 "https://en.opensuse.net.cn/index.php?title=SDB:Disaster_Recovery&oldid=196247" 检索