Introducing Bacula GitHub Cloud
Complete GitHub Backup Through Bacula

We are releasing Bacula GitHub Cloud — a production-grade Rust orchestrator that backs up GitHub repositories, wikis, LFS objects, releases, gists, package registries, and over twenty categories of API metadata into your existing Bacula deployment, using standard hooks and no Bacula patches.

GitHub is not a backup

Source code is infrastructure. Repositories accumulate years of commit history, documented decisions in issues and pull requests, release binaries, Actions workflows, and organisation metadata that has real operational value. Yet most teams treat GitHub as their archive.

GitHub does not guarantee recovery from accidental deletion, ransomware, or account suspension. Their own documentation is explicit: the platform is not a backup service. When something goes wrong — a force-push that wipes history, a deleted organisation, an account compromise — the window for recovery is short and the outcome is uncertain.

If you already run Bacula to protect servers, databases, and storage, your GitHub data should live under the same retention policies, access controls, and disaster recovery guarantees. Bacula GitHub Cloud makes that possible without introducing new infrastructure or custom tooling.

What it is

Bacula GitHub Cloud is two self-contained static binaries — github-backup and github-restore — with no runtime dependencies beyond git and git-lfs. The backup binary runs as a Bacula ClientRunBeforeJob hook: before each backup job, it mirrors everything from your configured GitHub organisations to a local staging directory. Bacula's FileDaemon then sweeps that directory into tape or long-term storage exactly as it would any other FileSet.

The restore binary works in reverse. Select a point-in-time from bconsole, let Bacula recover the staging files from disk, and the binary pushes code, wikis, LFS objects, releases, labels, milestones, issues, and discussions back to GitHub automatically. Every completed step is recorded in a bundled SQLite database, so an interrupted restore resumes from exactly where it stopped.

What gets backed up

A plain git mirror preserves commit history. Bacula GitHub Cloud goes further:

• 01
  Full git mirror and wikis Bare --mirror clone on first run; incremental git remote update --prune on every subsequent run. Separate wiki mirror per repository.
• 02
  Git LFS objects and release binaries Content-addressed LFS store — only missing objects downloaded. Release assets streamed and deduplicated by size comparison.
• 03
  Issues, pull requests, and discussions Incremental export via ETags and since= timestamps — only changed records re-fetched. Labels, milestones, review comments, and approval records included.
• 04
  Actions workflows, run logs, and variables Workflow definitions, run history, per-job logs, secrets (names only — values are never accessible via API), variable values, and artifact metadata.
• 05
  Security alerts Code scanning, Dependabot, and secret scanning alerts exported per repository alongside the rest of the metadata.
• 06
  Gists and package registries Bare git mirror of each gist plus metadata and comments (opt-in). OCI image layers, npm tarballs, Maven JARs, RubyGems, and NuGet packages (opt-in).

Incremental, rate-limit safe, and observable

From the second run onwards, every API call uses HTTP ETags and since= filtering stored in a bundled SQLite database. Only genuinely changed data is re-fetched, regardless of repository count.

All parallel workers share an async-safe rate-limit budget. When remaining allowance drops below a configurable threshold, every task pauses automatically and resumes after GitHub's reset window — the tool never hits the 5,000 req/hr cap.

After each run, a Prometheus-compatible metrics.prom file is written for ingestion via Node Exporter's textfile collector. A last_run.json summary records repository counts, failure counts, API calls made, run duration, and staging directory size. Optional Slack and PagerDuty failure alerts are available via environment variables.

Getting started

V=v0.10.0
OS=linux-x86_64
AR=bacula-ghe-cloud-${V}-${OS}.tar.gz

# Verify and install
sha256sum -c ${AR}.sha256
gpg --verify ${AR}.asc ${AR}
tar -xzf ${AR}
sudo cp bacula-ghe-cloud-${V}/github-backup \
        bacula-ghe-cloud-${V}/github-restore \
        /usr/local/bin/

Wire it into your Bacula Director with a single ClientRunBeforeJob directive pointing at github-backup --config /etc/github-backup/config.yaml. The full configuration reference, Bacula Director example, and administrator guide are included in the repository.

Where to find it

Bacula GitHub Cloud is published under the BSD 2-Clause licence. Pre-built, GPG-signed binary tarballs are available on the release page. The current release is v0.10.0.

This is the same tooling we use internally. It is production-tested, actively maintained, and ships through the same quality pipeline as everything else we publish — GPG-signed releases, SHA256 checksums, and a signed bill of materials on every tag.

Questions about integrating Bacula GitHub Cloud into your backup infrastructure? We are available via the contact form below.

Get in touch