此版本的 GitHub Enterprise 已停止服务 2021-09-23. 即使针对重大安全问题,也不会发布补丁。 要获得更好的性能、改进的安全性和新功能,请升级到 GitHub Enterprise 的最新版本。 如需升级方面的帮助,请联系 GitHub Enterprise 支持

在设备上配置备份

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

关于 GitHub Enterprise Server 备份实用程序

GitHub Enterprise Server 备份实用程序 是在单独主机上安装的备份系统,会通过安全的 SSH 网络连接定期生成 您的 GitHub Enterprise Server 实例 的备份快照。 您可以使用快照将现有的 GitHub Enterprise Server 实例从备份主机还原为上一个状态。

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

更多关于功能、要求和高级用法的详细信息,请参阅 GitHub Enterprise Server 备份实用程序 自述文件

基本要求

要使用 GitHub Enterprise Server 备份实用程序,您必须将 Linux 或 Unix 主机系统与 您的 GitHub Enterprise Server 实例 分开。

您还可以将 GitHub Enterprise Server 备份实用程序 集成到现有环境中,以便长期、永久地存储重要数据。

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

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

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

根据您的使用情况(例如用户活动和选定的集成),可能需要更多资源。

安装 GitHub Enterprise Server 备份实用程序

:为确保还原的设备立即可用,即使采用 Geo-replication 配置,也应针对主要实例执行备份。

  1. 下载最新的 GitHub Enterprise Server 备份实用程序 版本并使用 tar 命令解压文件。

    $ tar -xzvf /path/to/github-backup-utils-vMAJOR.MINOR.PATCH.tar.gz     
  2. 将包含的 backup.config-example 文件复制到 backup.config,并在编辑器中打开。

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

    Note: If your 您的 GitHub Enterprise Server 实例 is deployed as a cluster or in a high availability configuration using a load balancer, the GHE_HOSTNAME can be the load balancer hostname, as long as it allows SSH access (on port 122) to 您的 GitHub Enterprise Server 实例.

  4. GHE_DATA_DIR 值设为您希望存储备份快照的文件系统位置。

  5. 打开主要实例的设置页面(网址为 https://HOSTNAME/setup/settings),并将备份主机的 SSH 密钥添加到已授权 SSH 密钥列表中。 更多信息请参阅访问管理 shell (SSH)

  6. 使用 ghe-host-chec 命令确认与 您的 GitHub Enterprise Server 实例 的 SSH 连接。

    $ bin/ghe-host-check        
  7. 要创建初次完整备份,请运行 ghe-backup 命令。

    $ bin/ghe-backup        

有关高级用法的更多信息,请参阅 GitHub Enterprise Server 备份实用程序 自述文件

排定备份

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

如果备份尝试重复,ghe-backup 命令将中止并显示错误消息,指示存在同时备份。 如果出现这种情况,建议降低已排定的备份的频率。 更多信息请参阅 GitHub Enterprise Server 备份实用程序 自述文件的“排定备份”部分。

还原备份

如果主要站点发生的故障或灾难性事件的时间较长,要还原 您的 GitHub Enterprise Server 实例,请提供另一个 GitHub Enterprise 设备并从备份主机执行还原。 在还原设备之前,您必须将备份主机的 SSH 密钥作为已授权 SSH 密钥添加到目标 GitHub Enterprise 设备。

Note: When performing backup restores to 您的 GitHub Enterprise Server 实例, the same version supportability rules apply. You can only restore data from at most two feature releases behind.

For example, if you take a backup from GHES 3.0.x, you can restore it into a GHES 3.2.x instance. But, you cannot restore data from a backup of GHES 2.22.x onto 3.2.x, because that would be three jumps between versions (2.22 > 3.0 > 3.1 > 3.2). You would first need to restore onto a 3.1.x instance, and then upgrade to 3.2.x.

要通过上一个成功快照还原 您的 GitHub Enterprise Server 实例,请使用 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.

:网络设置不包含在备份快照中。 您必须根据环境的要求在目标 GitHub Enterprise Server 设备上手动配置网络。

您可以将以下附加选项与 ghe-restore 命令结合使用:

  • -c 标志会重写目标主机上的设置、证书和许可数据,即使已配置也不例外。 如果您要为测试设置暂存实例,并且希望在目标设备上保留现有配置,请省略此标志。 更多信息请参阅 GitHub Enterprise Server 备份实用程序 自述文件的“使用备份和还原命令”部分。
  • -s 标志允许您选择其他备份快照。