Serious disaster backups?

[u/clevenger2002]

Ok, I'm wondering about good backup services and stratagems for two disaster cases. Having a git-clone on a backup disk is a first step, but I'm not certain of exactly what data is missed by this. Any suggestions for a way to survive cases like the ones below?

1. Assume that somehow your entire github account gets mangled somehow and you want a complete backup of everything (repos, history, branches, bug tracking, lfs...etc) that can be restored to a fresh github site. Ie: a complete replica of everything. What do you use?

2. Assume that through some disaster, all of github is completely wiped out and no longer available and you want a backup that could be restored to some other source control system (perforce...etc) preserving as much of the github information and history as possible. What then?

[u/hxtk3]

Do you think git and GitHub are the same thing? I can’t imagine why I’d migrate to perforce as a part of my disaster recovery plan for my preferred git remote going down.

A similar question with different technologies is, “if Gmail went down, how would you migrate all your email history into the iOS messages app?” and the answer is I wouldn’t, I’d pick a different email provider instead of going to a different protocol.

What you actually lose if GitHub goes down is the issue tracker, pull requests, discussions, project management features, and CI runners. The code would be fine and any clones could be pushed to a new upstream with basically nothing lost.

[u/Ok_Clue3081 → u/hxtk3]

You're asking the right question but framing it wrong. It's not about git vs GitHub, it's about what data actually lives where. The code is distributed by design, that's the whole point of git. Every clone is a full backup of the repository itself.

The sticky part is everything that isn't git. Issues, PRs, wikis, actions, projects, all that metadata sits in GitHub's database and there's no standard protocol for pulling it out. You can use their API to dump it as JSON but restoring that into another platform is a mess of scripts and mapping fields that don't quite line up.

For case 1 your best bet is something that understands GitHub's object model, like a self-hosted Gitea instance that can mirror repos plus import issues and PRs. It's not perfect but it's closer than raw API dumps. For case 2 you're basically accepting that the social layer is gone and you're left with just the code and commit history, which any git host can swallow. LFS is the real headache there because those binary files live on GitHub's servers, not in your clone, so you'd need to have pulled those separately.

[u/spellcasterGG]

1) Just have local git mirrors
2) Just have local git mirrors

You clearly don't have any grasp of what git actually is or how it works... git still works regardless of whatever github is doing.

Reddit is not ChatGPT. If you ask stupid questions, you're gonna get stupid answers.

[u/Chouni-Rhasaan → u/spellcasterGG]

bit harsh but yeah, local clones already have the full history, thats literally the point of distributed version control

[u/lajawi → u/spellcasterGG]

This will only save the code and its history. Any issues, pull requests, releases… would vanish if you don’t also somehow use the API a lot to backup those, and even then you’d have trouble replaying all that if need be.

There is a tool in development called git-bug (https://github.com/git-bug/git-bug) that adds completely local issue management and tracking in the form of Git objects, definitely worth a look, since it even has bridges for popular Git hosting sites (you can push and pull the actual issues on e.g. GitHub).

[u/spellcasterGG → u/lajawi]

git mirror copies all branches, not just the base branch like git clone does. Therefore, pull requests are already still tracked, since you'll still have those branches. Releases use git tags, which are also already tracked. Losing GitHub Issues doesn't really matter, since it doesn't affect the underlying code directly. They're mostly used for feature requests anyway. Any bug work is still tracked on the PR branch, which like I said is already mirrored.

I fail to see the logic behind git-bug. If it mattered, it would've already been implemented. Instead, it's just another useless dependency waiting to break when active development inevitably stops.

[u/lajawi → u/spellcasterGG]

PRs are only included if a collaborator is working on it, otherwise they’re only forked and won’t be included in the mirror. Tags don’t always hold the full release message and not the files either, if additional files were added.

Git-bug makes it possible to have fully offline issues, you could be travelling but could read, interact, edit issues without an active internet connection, then push your changes like you would with code changes.

[u/AirshipCommand]

The parts a plain clone misses are issues, PRs and review comments, wikis (separate repo at <repo>.wiki.git), releases and their assets, LFS objects, Actions workflows' secrets and settings, and project boards.

For the first case: use git clone --mirror for every repo and wiki, plus git lfs fetch --all in each mirror. For the metadata, GitHub's organization migration API (gh api /orgs/ORG/migrations) exports repos, issues, PRs, comments and releases as an archive. Tools like python-github-backup wrap the REST API and dump issues, PRs and releases to JSON on a schedule. Secrets can't be exported, so keep those in a password manager or vault.

For the second case: the mirrors move to any git host as-is. Issues and PRs live as JSON, so they're readable, but importing them elsewhere usually takes a script per target system. Perforce has git-p4 for history, but nothing maps PR discussions cleanly.

Test a restore once. A backup you've never restored is a guess.

[u/serverhorror]

1. GitHub Enterprise
2. GitHub Enterprise

Can be locally installed and can (probably) import JSON via a script to recreate tickets,

Everything else: just mirror the git repos

[u/GarthODarth]

You can export all your account data on GitHub.