GitHub Backup Utils: What They Are and How to Use Them

GitHub Backup Utils: What They Are and How to Use Them

If you have searched for "github backup utils," you have probably landed on GitHub's own open-source backup utility. It sounds like exactly what you need: a tool to back up your GitHub repositories. But there is a catch that trips up a lot of developers.

GitHub Backup Utilities, hosted at github/backup-utils on GitHub, is an enterprise-only tool. It does not work with github.com or GitHub Enterprise Cloud. It is built exclusively for GitHub Enterprise Server, the self-hosted version of GitHub that organizations run on their own infrastructure.

In this article, we will break down what github-backup-utils actually is, how it works, what it can and cannot do, and what alternatives exist if you are on github.com. If you are looking for a broader overview of how to protect your code, check out our complete guide to backing up GitHub repositories.

What Is GitHub Backup Utils?

GitHub Backup Utilities (often shortened to backup-utils) is an open-source backup and recovery system designed specifically for GitHub Enterprise Server (GHES). It is maintained by GitHub and provides a set of command-line tools that create snapshot-based backups of your entire GHES instance.

The project has been around for years and is the officially recommended way to implement a disaster recovery strategy for self-hosted GitHub Enterprise deployments. It is not a simple repository cloner. It captures the full state of your GitHub Enterprise Server, including data that goes well beyond Git repositories.

What Does It Back Up?

GitHub Backup Utils captures a comprehensive snapshot of your Enterprise Server instance:

  • Git repository data -- all repositories, including wikis and gists

  • MySQL database -- issues, pull requests, comments, users, teams, organizations, and all metadata

  • Redis data -- background job queues and cached data

  • Elasticsearch indices -- search indexes for code, issues, and other content

  • Configuration settings -- your GHES instance configuration

  • GitHub Actions data -- workflow runs and logs (on supported versions)

  • GitHub Packages data -- hosted packages and container images

  • Audit log data -- security and compliance records

This is a full-instance backup, not just a code backup. That distinction matters when you are running GitHub as critical infrastructure for your organization.

How GitHub Backup Utils Works

The backup system operates through two primary commands: ghe-backup and ghe-restore. The architecture is straightforward but requires specific infrastructure.

The Backup Host

You need a dedicated Linux host that is separate from your GitHub Enterprise Server instance. This backup host runs the backup-utils software and connects to your GHES instance over SSH. The backup host stores all snapshots locally, and you can configure how many snapshots to retain.

Typical hardware requirements for the backup host depend on the size of your GHES instance, but GitHub recommends the backup host have at least the same storage capacity as your primary instance.

Running a Backup with ghe-backup

The ghe-backup command initiates a snapshot of your GHES instance. Here is what a basic workflow looks like:

# Clone the backup-utils repository
git clone https://github.com/github/backup-utils.git

Copy and edit the configuration file

cp backup.config-example backup.config

Set your GHES hostname

GHE_HOSTNAME="github.your-company.com"

Run the backup

bin/ghe-backup

The first backup performs a full transfer of all data. Subsequent backups are incremental, transferring only the data that has changed since the last snapshot. This makes regular scheduled backups practical even for large instances.

You would typically set up a cron job to run ghe-backup on a schedule:

# Example: run backup every 6 hours
0 */6 * * * /opt/backup-utils/bin/ghe-backup

Restoring with ghe-restore

When disaster strikes, ghe-restore lets you restore a snapshot to a new or existing GHES instance:

# Restore the latest snapshot to a new instance
bin/ghe-restore github-restore.your-company.com

The restore process requires the target to be a freshly configured GHES instance. You cannot restore to an instance that already has data on it without first putting it into maintenance mode and resetting it.

Configuration Options

The backup.config file supports several important settings:

# The hostname of your GHES instance
GHE_HOSTNAME="github.your-company.com"

Path to store backup snapshots

GHE_DATA_DIR="/data/github-backups"

Number of snapshots to retain

GHE_NUM_SNAPSHOTS=10

Additional SSH options if needed

GHE_EXTRA_SSH_OPTS="-o ServerAliveInterval=60"

Setup Requirements

Getting github-backup-utils running requires several prerequisites:

  1. A GitHub Enterprise Server instance -- this is the non-negotiable requirement. You must be running the self-hosted version of GitHub Enterprise.

  2. A separate backup host -- a Linux server (Ubuntu, Debian, CentOS, or similar) with enough disk space to hold your snapshots.

  3. SSH access -- the backup host needs SSH access to the GHES instance's administrative shell. This typically requires adding the backup host's SSH key to the GHES management console.

  4. Network connectivity -- the backup host must be able to reach the GHES instance on the SSH port.

  5. Compatible versions -- backup-utils versions are tied to GHES versions. You need to run a compatible version of backup-utils for your GHES release.

The setup is not trivial. It requires infrastructure knowledge, SSH configuration, storage planning, and ongoing maintenance of the backup host itself.

Key Limitations of GitHub Backup Utils

Here is where things get important, especially if you arrived at this article looking for a way to back up your GitHub repositories.

It Only Works with GitHub Enterprise Server

This is the biggest limitation and the one most people miss. GitHub Backup Utils is designed exclusively for GitHub Enterprise Server -- the self-hosted, on-premises version of GitHub. It does not work with:

  • github.com -- the standard GitHub service that most developers use

  • GitHub Enterprise Cloud -- the managed enterprise version hosted by GitHub

  • GitHub Free, Pro, or Team plans -- none of these are supported

If you are on any of these plans, github-backup-utils simply will not work for you. There is no workaround. The tool relies on SSH access to the GHES administrative interface, which does not exist on github.com or GitHub Enterprise Cloud.

Other Limitations Worth Noting

  • Infrastructure overhead -- you need to provision and maintain a separate backup host

  • No cloud storage integration -- backups are stored locally on the backup host; you need to separately handle offsite replication

  • Manual monitoring -- there is no built-in alerting or dashboard; you need to build your own monitoring around it

  • Restore complexity -- restoring requires a fresh GHES instance, which means provisioning new infrastructure during what is already a stressful incident

What If You Are on github.com?

This is the question that most people searching for "github backup utils" actually need answered. You are on github.com, you want to back up your repositories, and you just found out the official tool does not apply to you.

You have a few options, and we cover them in depth in our comparison of the best GitHub backup tools. Here is a summary of your choices.

Manual Git Clones

The simplest approach is to clone your repositories yourself:

git clone --mirror https://github.com/your-org/your-repo.git

The --mirror flag creates a bare clone that includes all branches, tags, and refs. You could script this and run it on a schedule. The downsides: you have to maintain the script, handle authentication, manage storage, track new repositories, and deal with failures. It also only backs up Git data -- you lose issues, pull requests, wikis, and other metadata.

GitHub's Built-in Export

GitHub lets you request an export of your account data through the settings page. This is a manual process, not automated, and it is not designed for regular backups. It is more of a data portability feature.

Third-Party Backup Tools

Several tools exist to automate GitHub backups for github.com users. These range from open-source scripts to fully managed SaaS solutions. The right choice depends on how many repositories you have, how critical they are, and how much time you want to spend on maintenance.

For a detailed breakdown of what is available, see our guide to backing up all your GitHub repositories.

Gitbackups: Automated Backups for github.com

Gitbackups is built specifically for the use case that github-backup-utils does not cover: automated, scheduled backups of your github.com repositories to S3-compatible storage.

Here is how it works:

  1. Connect your GitHub account using an access key, SSH key, or personal access token

  2. Select which repositories to back up (or back up all of them)

  3. Set a backup schedule that fits your workflow

  4. Your repositories are automatically backed up to S3-compatible storage on that schedule

There is no infrastructure to manage, no backup host to maintain, and no scripts to debug at 2 AM when something breaks.

Comparison: github-backup-utils vs Gitbackups

If you are trying to decide which tool fits your situation, this table lays it out:

Feature

github-backup-utils

Gitbackups

Works with github.com

No

Yes

Works with GitHub Enterprise Server

Yes

No

Works with GitHub Enterprise Cloud

No

Yes

What it backs up

Full instance: Git data, MySQL, Redis, Elasticsearch, configs

Git repositories to S3-compatible storage

Who it is for

GHES administrators

Developers and teams on github.com

Setup complexity

High -- requires dedicated host, SSH config, version matching

Low -- connect account, pick repos, set schedule

Scheduling

Manual cron job setup

Built-in scheduling

Storage destination

Local disk on backup host

S3-compatible storage

Monitoring

DIY

Built-in

Cost

Free (open source), but requires infrastructure

SaaS pricing based on plan

Maintenance

You maintain the backup host and scripts

Fully managed

The tools serve fundamentally different audiences. If you are running GitHub Enterprise Server on your own infrastructure, github-backup-utils is the right choice and the officially supported one. If you are on github.com -- which is the vast majority of GitHub users -- it is not an option, and Gitbackups fills that gap.

Choosing the Right Backup Strategy

The right approach depends on your situation:

Use github-backup-utils if:

  • You run GitHub Enterprise Server (self-hosted)

  • You have the infrastructure team to maintain a backup host

  • You need full-instance backups including MySQL, Redis, and configuration data

  • You are comfortable with command-line tools and cron-based scheduling

Use Gitbackups if:

  • You use github.com (Free, Pro, Team, or Enterprise Cloud)

  • You want automated, scheduled backups without managing infrastructure

  • You need your backups stored in S3-compatible storage

  • You prefer a managed solution over maintaining scripts and servers

Use both if:

  • You run a hybrid setup with both GHES and github.com repositories

No matter which path you take, the important thing is that you have a backup strategy in place. Code is one of the most valuable assets any team produces, and losing it to an accidental deletion, a compromised account, or a service outage is entirely preventable.

Wrapping Up

GitHub Backup Utils is a solid, well-maintained tool for its intended purpose: backing up GitHub Enterprise Server instances. But it is not a general-purpose GitHub backup tool, and it will not help you if you are on github.com.

If you are a github.com user looking for automated repository backups, Gitbackups gives you scheduled backups to S3-compatible storage without the infrastructure overhead. Connect your account, choose your repos, set your schedule, and your code is protected.

For more on building a complete backup strategy, start with our guide to backing up GitHub.

Gitbackups

You can add a great description here to make the blog readers visit your landing page.