GitHub Enterprise Server Backup Utilities v3.9.6

Bug Fixes

• When restoring an instance using the ghe-restore command from GitHub Enterprise Server Backup Utilities, restoration of files in /user/data/storage failed with a xrealloc: cannot allocate (...) bytes error.

Backups and Disaster Recovery

• Administrators running ghe-backup will no longer see "Verifying Routes" messages. Route verification has been found to be unnecessary and has been disabled by default. Administrators who prefer to see these messages can enable route verification by setting GHE_ROUTE_VERIFICATION to "true" in their backup-utils configuration file.
• To prevent problems associated with incomplete backups, the ghe-restore process will exit with an error if the snapshot being restored is incomplete.

GitHub Enterprise Server Backup Utilities v3.12.0

Changes

• When using GitHub Enterprise Server 3.9.10 or newer, 3.10.8 or newer, or 3.11.5 or newer, with a high availability (HA) configuration,
  you can backup the MySQL database from a HA replica by setting ghe-config mysql.backup.replica <replica-hostname> on your primary node.
  We recommend that replica-hostname resides in the same region as the backup host in order to reduce latency. [Updated 2024-03-01]
• When using GitHub Enterprise Server 3.9.10 or newer, or 3.11.5 or newer, with a cluster configuration,
  backup-utils will backup the MySQL database from one of the MySQL replica nodes instead of the primary node.
• ghe-backup will provide a clear error message if an offline node in a cluster configuration is detected by ghe-cluster-host-check.

Backups and Disaster Recovery

• ghe-backup or ghe-restore commands could fail to delete progress files created by older versions of GitHub Enterprise Server Backup Utilities.

GitHub Enterprise Server Backup Utilities v3.11.1

Bug Fixes

• On an instance with multiple nodes, backups failed silently if a node was offline or unavailable.
• When restoring a backup using the ghe-restore command, the restore operation could fail due to the root disk filling completely. [Updated 2024-02-29]

Changes

• When using GitHub Enterprise Server 3.9.10 or newer, 3.10.8 or newer, or 3.11.1 or newer, with a high availability (HA) configuration, you can backup the MySQL database from a HA replica by setting ghe-config mysql.backup.replica <replica-hostname> on your primary node. We recommend that replica-hostname resides in the same region as the backup host in order to reduce latency. [Updated 2024-03-01]
• When using GitHub Enterprise Server 3.9.10 or newer, or 3.11.1 or newer, with a cluster configuration, backup-utils will backup MySQL from one of the MySQL replica nodes instead of the primary node.

Backups and Disaster Recovery

• ghe-backup or ghe-restore commands could fail to delete progress files created by older versions of GitHub Enterprise Server Backup Utilities.

GitHub Enterprise Server Backup Utilities v3.10.3

Bug Fixes

• On an instance with multiple nodes, backups failed silently if a node was offline or unavailable.
• When restoring a backup using the ghe-restore command, the restore operation could fail due to the root disk filling completely. [Updated 2024-02-29]

Changes

• When using GitHub Enterprise Server 3.9.10 or newer, or 3.10.8 or newer, with a high availability (HA) configuration, you can backup the MySQL database from a HA replica by setting ghe-config mysql.backup.replica <replica-hostname> on your primary node. We recommend that replica-hostname resides in the same region as the backup host in order to reduce latency. [Updated 2024-03-01]
• When using GitHub Enterprise Server 3.9.10 or newer with a cluster configuration, backup-utils will backup MySQL from one of the MySQL replica nodes instead of the primary node.

Backups and Disaster Recovery

• In the Incremental MySQL Backups and Restores documentation, the variable for the number of incremental backups was incorrectly given as GHE_INCREMENTAL_BACKUP_MAX. This has been corrected to GHE_INCREMENTAL_MAX_BACKUPS.
• ghe-backup or ghe-restore commands could fail to delete progress files created by older versions of GitHub Enterprise Server Backup Utilities.
• For better compatibility across Linux distributions, the host operating system version displayed in output is obtained from /etc/os-release.

GitHub Enterprise Server Backup Utilities v3.9.5

Bug Fixes

• On an instance with multiple nodes, backups failed silently if a node was offline or unavailable.
• On an instance with Actions enabled, incorrect backup and restore settings prevented the storage container name from being restored. This made the logs from that container inaccessible, and caused Actions to create a new storage container in a different location.
• When restoring a backup using the ghe-restore command, the restore operation could fail due to the root disk filling completely. [Updated 2024-02-29]

Changes

• When using GitHub Enterprise Server 3.9.10 or newer with a high availability (HA) configuration, you can backup the MySQL database from a HA replica by setting ghe-config mysql.backup.replica <replica-hostname> on your primary node. We recommend that replica-hostname resides in the same region as the backup host in order to reduce latency.
• When using GitHub Enterprise Server 3.9.10 or newer with a cluster configuration, backup-utils will backup MySQL from one of the MySQL replica nodes instead of the primary node.

Backups and Disaster Recovery

• ghe-backup or ghe-restore commands could fail to delete progress files created by older versions of GitHub Enterprise Server Backup Utilities.
• For better compatibility across Linux distributions, the host operating system version displayed in output is obtained from /etc/os-release.

GitHub Enterprise Server Backup Utilities v3.8.5

Bug Fixes

• On an instance with multiple nodes, backups failed silently if a node was offline or unavailable.
• On an instance with Actions enabled, incorrect backup and restore settings prevented the storage container name from being restored. This made the logs from that container inaccessible, and caused Actions to create a new storage container in a different location.

Backups and Disaster Recovery

• During backups using a version of Backup Utilities 3.8, the log displayed the following warning: management console argon2 secret not set.
• For better compatibility across Linux distributions, the host operating system version displayed in output is obtained from /etc/os-release.

GitHub Enterprise Server Backup Utilities v3.11.0

Bug Fixes

• ghe-backup-myql and ghe-restore-mysql will now exit 1 on errors.
• On an instance with Actions enabled, incorrect backup and restore settings prevented the storage container name from being restored. This made the logs from that container inaccessible, and caused Actions to create a new storage container in a different location.
• When backups are run for HA instances in both primary and replica nodes a .sync-in-progress file will be created. This will disable NetworkMaintenance jobs from running and queueing up when backups are running from the primary node.

Changes

• Estimated transfer sizes will be calculated on appropriate nodes for clustered environments.
• Added support for finding the parallel command from the moreutils tool suite on more Linux distributions, including Arch Linux and Alpine Linux.
• ghe-restore avoids unnecessary rsync operations when restoring to non-clustered environments.
• ghe-backup and ghe-restore output their total runtime
• rsync compression is now disabled by default. The -z flag has been removed from the ghe-rsync command in multiple files to improve transfer speed and reduce CPU usage. To enable rsync compression globally, add GHE_RSYNC_COMPRESSION_ENABLED=yes to the backup.config file.
• Updates the Host OS version output to use /etc/os-release for better compatibility with other Linux distributions.

Backups and Disaster Recovery

• When a NFS mount is detected for snapshots on backup hosts, backup logs will show a warning to notify the user that such a setup may incur performance issues as highlighted in storage requirements documentation.

GitHub Enterprise Server Backup Utilities v3.10.2

Bug Fixes

• When using GitHub Enterprise Server Backup Utilities, a host check will test the availability of all nodes before running any operations on them and output a warning if a node is unreachable. Previously if a node was unreachable the host check could silently fail.
• When using GitHub Enterprise Server Backup Utilities, user permissions assigned to the temporary progress files in /tmp have been updated to allow access by other users. Previously, having backup and restore operations performed by different users could cause failed deletion error messages for temporary files.
• On an instance with Actions enabled, incorrect backup and restore settings prevented the storage container name from being restored. This made the logs from that container inaccessible, and caused Actions to create a new storage container in a different location.

Changes

• Adds support for finding the parallel command from the moreutils tool suite on more Linux distributions, including Arch Linux and Alpine Linux.

Backups and Disaster Recovery

• When a NFS mount is detected for snapshots on backup hosts, backup logs will show a warning to notify the user that such a setup may incur performance issues as highlighted in storage requirements documentation.

GitHub Enterprise Server Backup Utilities v3.9.4

Bug Fixes

• On an instance with Actions enabled, incorrect backup and restore settings prevented the storage container name from being restored. This made the logs from that container inaccessible, and caused Actions to create a new storage container in a different location. This bug fix will ship in backup-utils v3.9.5. [Updated 2024-01-17]

Backups and Disaster Recovery

• When a NFS mount is detected for snapshots on backup hosts, backup logs will show a warning to notify the user that such a setup may incur performance issues as highlighted in storage requirements documentation.

GitHub Enterprise Server Backup Utilities v3.8.4

Bug Fixes

• On an instance with Actions enabled, incorrect backup and restore settings prevented the storage container name from being restored. This made the logs from that container inaccessible, and caused Actions to create a new storage container in a different location. This bug fix will ship in backup-utils v3.8.5. [Updated 2024-01-17]