Backup GitHub (Every Repo, Regularly)

Source & Credit

This page was sparked by a public-service reminder from Morgan Linton (@morganlinton): backup GitHub — every repo, regularly. If you have never done it, or not recently, do it today.

Original post: x.com/i/status/2077119086749000102

Useful thread notes folded into the options below: free bulk clone with ghorg; production/SOC 2 path with Cloudback; the distinction between git clones and GitHub metadata (issues, PRs, wikis); self-hosted Forgejo/Gitea daily syncs; and the real-world risk when people switch jobs or a company goes under.

Why This Matters

• Git is distributed — GitHub is not. Every working clone is a partial safety net for git history. It is not a backup of issues, PRs, Actions history, project boards, wikis, releases assets, or org settings.
• Access disappears. Job changes, revoked SSO, deleted orgs, account lockouts, and company shutdowns take “your” code and context with them unless you already mirrored it elsewhere.
• Accidents and malice. Force-pushes, bad migrations, ransomware on a laptop that only held the “main” clone, and compromised tokens all hit harder without an off-platform copy.
• Compliance. Teams that care about SOC 2 / disaster recovery need scheduled, restorable backups — not “I think I have a clone on my Mac.”

Thread insight (paraphrased): most people only feel this after it is already painful. Treat backup as boring hygiene, not a postmortem project.

What Are You Actually Backing Up?

Thread callout from the discussion: a local clone does not protect issues, PRs, and other GitHub-specific data. ghorg is excellent for bulk repo (and optional wiki) backups — pair it with a metadata strategy if that history matters.

Option Map (Pick by Need)

1. ghorg (Recommended Free Default)

Open-source CLI to clone or backup large numbers of org/user repositories into one directory. Supports GitHub, GitLab, Bitbucket, Gitea, Codeberg/Forgejo, and more. Morgan’s reminder pointed here specifically — free, neat, no affiliation required to recommend it.

Install (pick one)

# macOS
brew install ghorg

# Go
go install github.com/gabrie30/ghorg@latest

# Config sample
mkdir -p $HOME/.config/ghorg
curl -fsSL https://raw.githubusercontent.com/gabrie30/ghorg/master/sample-conf.yaml \
  > $HOME/.config/ghorg/conf.yaml
# Set GHORG_GITHUB_TOKEN (repo scopes; authorize SSO if needed)

Everyday clone (searchable local copies)

# All repos for a user
ghorg clone YOUR_USERNAME --clone-type=user

# All repos for an org
ghorg clone YOUR_ORG

# Re-run later: pulls + cleans local changes by default
# Use --no-clean if you actively work inside the ghorg tree

True backup mode (mirror + wiki + submodules)

ghorg clone YOUR_ORG --backup --clone-wiki --include-submodules

# Optional: skip large blobs if you only need structure/history sketch
# ghorg clone YOUR_ORG --backup --git-filter=blob:none

--backup uses git clone --mirror. Restoring a working tree from a mirror layout is a short git init / checkout sequence (documented in ghorg’s README).

Automate

• reclone.yaml — store multiple clone commands; run ghorg reclone.
• reclone-cron — scheduled runs.
• post_exec_script — ping healthchecks / Slack on success or fail.
• stats — optional CSV of clone metrics over time for audit.

Best for: personal projects, multi-org freelancers, “I want everything on disk tonight.”

2. Cloudback (Budget / Compliance Path)

From Morgan’s follow-up: if you have budget or need a production / SOC 2–style story, use a dedicated product. Cloudback markets automatic daily backups and restores for GitHub (and GitLab, Azure DevOps, Linear), including repository and metadata (issues, PRs, files), BYOS (bring your own storage), encryption options, and compliance-oriented features.

• Code alone is not enough for incident response — metadata is where decisions and history live.
• Off-platform or customer-owned storage reduces “both eggs in GitHub’s basket.”
• Good fit when auditors ask “how do you restore the org?” and “who can prove backups ran?”

Best for: companies, agencies, regulated work, multi-person orgs that cannot rely on one laptop clone.

3. Self-Hosted Mirror (Forgejo / Gitea / GitLab)

Thread pattern: run Forgejo (or Gitea/GitLab) and daily-sync from GitHub. More ops overhead than ghorg-on-disk, but you get a browsable forge you control — PRs/issues can be recreated or migrated depending on tooling.

• Use forge “mirror” features, or push mirrors from CI.
• Keep the mirror host offline from day-to-day developer laptops when possible (ransomware separation).
• Codeberg / self-hosted Forgejo also work as secondary remotes for open work.

Best for: people who already run a home lab or company forge and want continuous independent hosting.

4. Classic Git Options (No Extra Product)

Mirror clone one repo

git clone --mirror git@github.com:ORG/REPO.git
cd REPO.git
# Push to a second host when you have one:
# git push --mirror git@backup-host:ORG/REPO.git

Same idea as duplicating a repo with full history — see How to duplicate a GitHub repository.

Always push to two remotes

git remote add backup git@backup-host:ORG/REPO.git
git remote set-url --add --push origin git@github.com:ORG/REPO.git
git remote set-url --add --push origin git@backup-host:ORG/REPO.git
# Now git push updates both (verify with: git remote -v)

git bundle (air-gapped / cold storage)

git bundle create repo-backup.bundle --all
# Later:
git clone repo-backup.bundle restore-dir

Great for periodic cold copies to encrypted external drives or object storage.

GitHub CLI loop (simple DIY)

# Requires gh auth login
mkdir -p ~/github-backups && cd ~/github-backups
gh repo list YOUR_USERNAME --limit 1000 --json nameWithOwner -q '.[].nameWithOwner' \
  | while read repo; do
      dir=$(echo "$repo" | tr '/' '_')
      if [ -d "$dir.git" ]; then
        git -C "$dir.git" remote update
      else
        git clone --mirror "git@github.com:$repo.git" "$dir.git"
      fi
    done

5. Metadata & Platform Exports

• GitHub organization migrations / exports — use when moving orgs or need archive packages that include more than bare git.
• Issue/PR exporters — scripts or tools that dump issues to Markdown/JSON for knowledge backup (pairs well with a Company Brain style archive).
• Releases & assets — large binaries may need separate download (API or gh release download); pure git mirrors may omit or bloat depending on LFS setup.
• Git LFS — if you use LFS, confirm backup pulls LFS objects, not just pointers.
• Actions artifacts / caches — usually not critical; treat as rebuildable unless compliance says otherwise.

6. Extra Hardening Suggestions

• 3-2-1 rule: 3 copies, 2 media types, 1 offsite (e.g. local ghorg + external drive bundle + S3/Backblaze/self-host).
• Encrypt cold backups (age, gpg, or encrypted disk images) before they leave your desk.
• Separate credentials: backup token is read-only where possible; do not reuse your daily PAT with full write scopes on a cron host.
• Test restore quarterly. An untested backup is a rumor. Restore one repo to a throwaway folder on a schedule.
• Document the runbook in the same place as other ops notes — agents and future-you need a clear path (see agentic setup checklist for self-healing docs habits).
• Protect the backup host. A mini PC or VPS used for agents (SSH + VPS patterns) is a fine place for scheduled ghorg — lock it down, monitor disk, alert on cron failure.
• Org as code: branch protection, teams, and app install config in Terraform reduce “settings only lived on GitHub” risk.

Suggested Stacks by Situation

Action Checklist

Related Guides

Inspired by Morgan Linton (@morganlinton). View the original post on X → · ghorg by gabrie30 · Cloudback at cloudback.it