在实例上配置备份

作为灾难恢复计划的一部分，你可通过配置自动备份来保护 你的 GitHub Enterprise Server 实例 中的生产数据。

本文内容

关于 GitHub Enterprise Server Backup Utilities

GitHub Enterprise Server Backup Utilities 是安装在单独主机上的备份系统，它通过安全的 SSH 网络连接定期对 你的 GitHub Enterprise Server 实例 进行备份快照。 你可以使用快照将现有的 GitHub Enterprise Server 实例从备份主机还原为上一个状态。

只有自上一个快照之后添加的数据将通过网络传输并占用额外的物理存储空间。 要最大限度地减小对性能的影响，会以最低 CPU/IO 优先级在线执行备份。 你不需要排定维护窗口来执行备份。

GitHub Enterprise Server Backup Utilities 的主要版本和版本号与 GitHub Enterprise Server 的功能版一致。 我们支持这两种产品的四个最新版本。 有关详细信息，请参阅“GitHub Enterprise Server 发行版”。

有关功能、要求和高级使用情况的更多详细信息，请参阅 GitHub Enterprise Server Backup Utilities 项目文档中的 GitHub Enterprise Server Backup Utilities README。

先决条件

要使用 GitHub Enterprise Server Backup Utilities，必须将主机系统与 你的 GitHub Enterprise Server 实例 分开。 有关如何配置系统的详细信息，请参阅 github/backup-utilss 存储库中的要求。

你还可以将 GitHub Enterprise Server Backup Utilities 集成到现有环境中，以便长期、永久地存储重要数据。

建议将备份主机和 你的 GitHub Enterprise Server 实例 放置在相距较远的地理位置。 这样可以确保在主要站点发生重大事故或网络故障的情况下通过备份进行还原。

物理存储要求将因 Git 仓库磁盘使用情况以及预计的增长情况而异：

硬件建议
vCPU4
内存8 GB
存储等于为主要实例分配的存储空间的五倍

根据你的使用情况（例如用户活动和选定的集成），可能需要更多资源。

有关详细信息，请参阅 GitHub Enterprise Server Backup Utilities 项目文档中的 GitHub Enterprise Server Backup Utilities 要求。

安装 GitHub Enterprise Server Backup Utilities

要在备份主机上安装 GitHub Enterprise Server Backup Utilities，请从 github/backup-utils 存储库下载与 GitHub Enterprise Server 版本兼容的最新版本 GitHub Enterprise Server Backup Utilities。 例如，如果运行的是 GitHub Enterprise Server 3.8.4 版，请在 3.10 系列中下载最新版本的 GitHub Enterprise Server Backup Utilities。 这之所以可行是因为 GitHub Enterprise Server Backup Utilities 的所有版本都能向后兼容 2 个版本，这意味着 GitHub Enterprise Server Backup Utilities 3.10 系列可用于备份和还原运行 3.8、3.9 或 3.10 版的 GitHub Enterprise Server 实例。

下载压缩存档后便可提取并安装内容。 有关详细信息，请参阅 github/backup-utils 存储库中的《入门指南》。

如果有现有的备份配置文件 backup.config，请确保将该文件复制到新提取和安装的 GitHub Enterprise Server Backup Utilities 的位置。

GitHub Enterprise Server Backup Utilities 创建的备份快照会写入 backup.config 文件中 GHE_DATA_DIR 数据目录变量设置的磁盘路径。 这些快照需要存储在支持符号链接和硬链接的文件系统上。

Note

建议确保快照未保存在 GitHub Enterprise Server Backup Utilities 安装目录的子目录中，以避免在升级 GitHub Enterprise Server Backup Utilities 版本时意外覆盖数据目录。

  1. 从 github/backup-utils 存储库的“发布”页面下载相关的 GitHub Enterprise Server Backup Utilities 版本。

  2. 要使用 tar 提取存储库，请运行以下命令。

    tar -xzvf /path/to/github-backup-utils-vMAJOR.MINOR.PATCH.tar.gz

  3. 若要更改为本地存储库目录，请运行以下命令。

    cd backup-utils

  4. 若要将包含的 backup.config-example 文件复制到 backup.config，请运行以下命令。

    cp backup.config-example backup.config

  5. 若要自定义配置，请在文本编辑器中编辑 backup.config。

    1. 如果以前使用 Git 升级 GitHub Enterprise Server Backup Utilities，请确保将现有配置从 backup.config 复制到新文件中。 有关详细信息，请参阅“升级 GitHub Enterprise Server Backup Utilities”。

    2. 将 GHE_HOSTNAME 值设置为主要 GitHub Enterprise Server 实例的主机名或 IP 地址。

      Note

      如果使用负载均衡器将 你的 GitHub Enterprise Server 实例 部署为群集或部署在高可用性配置中，则 GHE_HOSTNAME 可以是负载均衡器主机名，只要负载均衡器允许通过端口 122 对 你的 GitHub Enterprise Server 实例 进行 SSH 访问。

      若要确保恢复的实例立即可用，即使在异地复制配置中，也请以主实例为目标执行备份。

    3. 将 GHE_DATA_DIR 值设置为要存储备份快照的文件系统位置。 建议选择与备份主机同一文件系统上的位置。

  6. 若要授予备份主机对实例的访问权限，请在 http(s)://HOSTNAME/setup/settings 上打开主实例的设置页，并将备份主机的 SSH 密钥添加到授权的 SSH 密钥列表中。 有关详细信息，请参阅“访问管理 shell (SSH)”。

  7. 在备份主机上，使用 ghe-host-check 命令验证与 你的 GitHub Enterprise Server 实例 的 SSH 连接。

    ./bin/ghe-host-check

  8. 若要创建初始完整备份，请运行以下命令。

    ./bin/ghe-backup

有关高级使用情况的更多详细信息，请参阅 GitHub Enterprise Server Backup Utilities 项目文档中的 GitHub Enterprise Server Backup Utilities README。

升级 GitHub Enterprise Server Backup Utilities

升级 GitHub Enterprise Server Backup Utilities 时，必须选择适用于当前版本的 GitHub Enterprise Server 的版本。 安装的 GitHub Enterprise Server Backup Utilities 的版本必须至少与 你的 GitHub Enterprise Server 实例 的版本相同，并且不能超出后者两个版本。 有关详细信息，请参阅 GitHub Enterprise Server Backup Utilities 项目文档中的 GitHub Enterprise Server 要求。

  1. 验证 GitHub Enterprise Server Backup Utilities 的安装方法。 以前版本的 GitHub Enterprise Server Backup Utilities 支持在本地 Git 存储库中进行安装和更新，但此方法已不再受支持。

    1. 在备份主机上，导航到 GitHub Enterprise Server Backup Utilities 目录，通常为 backup-utils。

    2. 若要检查 Git 存储库中是否存在有效的工作目录，请运行以下命令。

      git rev-parse --is-inside-work-tree

  2. 要确定如何升级 GitHub Enterprise Server Backup Utilities，请查看 git rev-parse --is-inside-work-tree 的输出。

    • 如果输出为 true，则已通过克隆项目的 Git 存储库安装 GitHub Enterprise Server Backup Utilities。 若要升级，请复制 backup.config 中的现有配置，然后按照“安装 GitHub Enterprise Server Backup Utilities”中的说明进行操作。
    • 如果输出包含 fatal: not a git repository (or any of the parent directories)，则表示已从压缩的存档文件中提取 GitHub Enterprise Server Backup Utilities。 若要升级，请按照“安装 GitHub Enterprise Server Backup Utilities”中的说明进行操作。

排定备份

可以使用 cron(8) 命令或类似的命令调度服务在备份主机上调度定期备份。 配置的备份频率将决定你的恢复计划中的最坏情况恢复点目标 (RPO)。 例如，如果你已排定在每天午夜运行备份，则在发生灾难的情况下，可能丢失长达 24 小时的数据。 建议在开始时采用每小时备份日程，从而确保在主要站点数据受到破坏时，最坏情况下最多会丢失一小时的数据。

如果备份尝试重叠，ghe-backup 命令将以错误消息中止，指示存在同时备份。 如果出现这种情况，建议降低已排定的备份的频率。 有关详细信息，请参阅 GitHub Enterprise Server Backup Utilities 项目文档中的 GitHub Enterprise Server Backup Utilities README 的“计划备份”部分。

还原备份

如果主站点发生长时间中断或灾难性事件，可以通过预配另一个实例并从备份主机执行还原来还原 你的 GitHub Enterprise Server 实例。 在还原实例之前，必须将备份主机的 SSH 密钥作为授权的 SSH 密钥添加到目标 GitHub Enterprise 实例。

将备份还原到 你的 GitHub Enterprise Server 实例 时，最多只能从后面的两个功能版本中还原数据。 例如，如果从 GitHub Enterprise Server 3.0.x 获取备份，则可以将备份还原到运行 GitHub Enterprise Server 3.2.x 的实例。 无法将数据从 GitHub Enterprise Server 2.22.x 的备份还原到运行 3.2.x 的实例，因为这样会跨过三个版本（2.22 到 3.0 到 3.1 到 3.2）。 需要先还原到运行 3.1.x 的实例，然后升级到 3.2.x。

备份快照中不包含网络设置。 还原后，必须在目标 GitHub Enterprise Server 实例上手动配置网络。

先决条件

  1. 确保在主实例上启用了维护模式，并且所有活动进程都已完成。 有关详细信息，请参阅“启用和排定维护模式”。
  2. 停止高可用性配置中所有副本节点上的复制。 有关详细信息，请参阅“关于高可用性配置”。
  3. 预配新的 GitHub Enterprise Server 实例以用作备份还原的目标。 有关详细信息，请参阅“设置 GitHub Enterprise Server 实例”。
  4. 如果 你的 GitHub Enterprise Server 实例 启用了 GitHub Actions，则必须先在替换实例上配置 GitHub Actions 的外部存储提供程序。 有关详细信息，请参阅“在启用 GitHub Actions 的情况下备份和恢复 GitHub Enterprise Server”。

启动还原操作

若要使用上次成功的快照从备份主机还原 你的 GitHub Enterprise Server 实例，请使用 ghe-restore 命令。 可以将以下附加选项与 ghe-restore 一起使用。

  • 即使已配置 -c 标志，该标志也会覆盖目标主机上的设置、证书和许可证数据。 如果你要为测试设置暂存实例，并且希望在目标设备上保留现有配置，请省略此标志。 有关详细信息，请参阅 github/backup-utils 存储库中 GitHub Enterprise Server Backup Utilities README 的“使用备份和还原命令”部分。
  • -s 标志让你能够选择不同的备份快照。

运行 ghe-restore 后，该命令将确认还原，然后在操作期间输出详细信息和状态。

$ ghe-restore -c 169.154.1.1
> Checking for leaked keys in the backup snapshot that is being restored ...
> * No leaked keys found
> Connect 169.154.1.1:122 OK (v2.9.0)

> WARNING: All data on GitHub Enterprise appliance 169.154.1.1 (v2.9.0)
>          will be overwritten with data from snapshot 20170329T150710.
> Please verify that this is the correct restore host before continuing.
> Type 'yes' to continue: yes

> Starting restore of 169.154.1.1:122 from snapshot 20170329T150710
# ...output truncated
> Completed restore of 169.154.1.1:122 from snapshot 20170329T150710
> Visit https://169.154.1.1/setup/settings to review appliance configuration.

（可选）若要验证还原，请配置 IP 例外列表以允许访问指定 IP 地址列表。 有关详细信息，请参阅“启用和排定维护模式”。

在高可用性配置的实例上，在还原到现有实例或空实例上的新磁盘后，ghe-repl-status 可能会报告 Git 或 Alambic 复制由于服务器 UUID 过时而不同步。 这些过时的 UUID 可能是由于高可用性配置中已停用的节点仍存在于应用程序数据库中，但在还原的复制配置中不存在。

若要在还原完成后、开始复制之前进行修复，可以使用 ghe-repl-teardown 删除过时的 UUID。 如果需要进一步的帮助，请访问 GitHub Enterprise 支持。

监视备份或还原进度

在备份或还原操作期间，可以使用备份主机上的 ghe-backup-progress 实用工具来监视操作的进度。 实用工具按顺序打印每个作业的进度。

若要监视备份主机上的进度，请从包含 GitHub Enterprise Server Backup Utilities 的目录中运行以下命令。

Shell
bin/ghe-backup-progress

默认情况下，实用工具会连续打印进度，直到操作完成。 可以按任意键返回提示。

（可选）可以运行以下命令来打印当前进度、上次完成的作业，然后立即退出。

Shell
bin/ghe-backup-progress --once