Here’s the uncomfortable truth most engineering teams learn the hard way: a git clone only copies your code. Your years of issues, pull request discussions, project boards, wikis, and Actions workflows are not in that clone — and if the organization or repository they live in disappears, so do they. GitHub is the system of record for how your team actually builds software. This guide covers what GitHub backup really means, what most teams miss, and how to build a recovery plan that survives the day you need it.
What is “GitHub backup,” really?
Ask ten engineers what backing up GitHub involves and most will say “we mirror the repos.” That covers commits, branches, and tags. It does not cover the layer where your team’s real institutional knowledge lives.
Everything below is stored by GitHub and is not captured by a standard git mirror:
| Category | Examples | In a git clone? |
|---|---|---|
| Code | Commits, branches, tags, git history | Yes |
| Issues | Issue bodies, comments, labels, assignees, milestones | No |
| Pull requests | PR descriptions, review threads, approvals, requested changes | No |
| Project management | Project boards, milestones, saved views | No |
| Documentation | Wikis, repository settings, README metadata | No |
| Automation | Secrets references, webhooks | No |
| Organization | Teams, membership, roles, branch protection rules | No |
That second column is the point. When a repository is deleted or an org is misconfigured, the code is often the easiest thing to recover — someone probably has a clone on a laptop. The three years of PR discussions explaining why the architecture looks the way it does? That context is gone, and no clone brings it back.
The GitHub shared responsibility model
This is the assumption worth challenging: “It’s in the cloud, so GitHub backs it up.” GitHub protects its own infrastructure — uptime, redundancy, disaster recovery of the platform. What GitHub does not do is protect you from yourself or your integrations.
Under the shared responsibility model, the SaaS vendor is responsible for platform availability. The customer is responsible for recovering their own user-generated data. GitHub says as much in its terms of service, which state the company “will not be liable for any loss of profits, use, goodwill, or data.” Read that twice. The platform running is their job. Your data being recoverable is yours.
The threats that cause GitHub data loss almost all originate in your environment, not GitHub’s:
- Accidental deletion: a repo or branch force-deleted, an org member removed with their content.
- Bad automations: a misconfigured Actions workflow or script that rewrites history or wipes issues at scale.
- Compromised credentials: a leaked personal access token or OAuth app deleting or exfiltrating repositories.
- Departing admins: an owner offboarded before ownership transfers, taking access (and sometimes content) with them.
- Ransomware and malicious actors: increasingly targeting source control directly.
“But GitHub has a 90-day restore window”
True, and worth understanding precisely. GitHub lets you restore a deleted repository for up to 90 days after deletion, provided the repository network hasn’t been changed and the name isn’t reused. That’s a genuine safety net for the specific case of “someone deleted a whole repo and nobody touched anything since.”
It is not a backup. It doesn’t help you recover a single overwritten issue, roll back a branch to last Tuesday, retrieve a PR thread that was edited, or restore anything after 90 days. It’s a narrow, all-or-nothing courtesy, not a recovery plan you can build compliance or continuity commitments on. Treating it as one is like assuming your building’s fire alarm also puts out the fire.
What good GitHub backup looks like
The gold standard for backup predates the cloud, and it still holds: the 3-2-1 rule. Adapted for SaaS, it means three copies of your data, in two separate locations, with at least one copy independent of GitHub itself.
That last point is the one teams skip. Backing up your GitHub data to another GitHub-controlled surface is like backing up your hard drive to your hard drive. If the account is compromised or the platform has a bad day, both copies are exposed at once. An independent copy is what gives you an air gap between the live system and your recovery point.
A recovery plan worth the name should let you answer yes to all of these:
- Can you restore metadata, not just code — issues, PRs, comments, labels, milestones?
- Can you restore a single item without rolling back an entire repository?
- Is at least one copy stored outside GitHub’s control?
- Can you meet your retention and compliance requirements, not just GitHub’s defaults?
- Was the backup running before the incident? (You can’t restore what you never captured.)
Where Rewind fits
Rewind was built for exactly this gap. Our GitHub backup heritage goes back to BackHub, now part of Rewind. We back up your repositories and the metadata layer around them: issues, pull request discussions, comments, labels, milestones, and more, so the context survives alongside the code.
That data is stored independently of GitHub, giving you the air gap the 3-2-1 rule calls for. When something goes wrong, you get surgical, item-level restore with strong metadata preservation and version comparison before you commit to a restore — so you’re not force-choosing between “roll back everything” and “recover nothing.” Retention defaults to 365 days and is configurable up to 99 years for teams with long regulatory horizons. Setup is roughly three clicks, and a single Rewind install can protect up to 16 integrations or sites.
One honest caveat: Rewind restores what it was capturing. You have to install it before a loss to recover from it. The best time to set up GitHub backup was when you created the org. The second best time is today.
Frequently asked questions
Does GitHub back up my data for me?
GitHub backs up its own platform for availability. Under the shared responsibility model, recovering your own repositories, issues, and metadata after deletion or corruption is your responsibility, not GitHub’s.
Isn’t a git clone or mirror enough?
No. A clone captures code, commits, and branches, but not issues, pull request discussions, project boards, wikis, or Actions configuration. That metadata is where most of your team’s decision history lives.
What about GitHub’s 90-day restore for deleted repositories?
It’s real but narrow — it only recovers a fully deleted repository under specific conditions, within 90 days, and it can’t restore individual items or older states. It’s a safety net, not a backup strategy.
Can I back up a whole GitHub organization?
Yes. A proper GitHub backup tool protects repositories and their metadata across your organization and stores copies independently. Rewind can protect up to 16 integrations or sites from a single install.
How long is backup data retained?
With Rewind, retention defaults to 365 days and is configurable up to 99 years, which lets regulated teams align backup retention to their compliance obligations rather than a vendor’s defaults.
Protect the context, not just the code
Your code is the easy part to recover. The issues, reviews, and decisions around it are what actually make your repositories valuable, and they’re the first things a git clone leaves behind. Build a plan that captures all of it, stores it independently, and lets you restore exactly what you lost.
Talk to a SaaS resilience expert at Rewind to see how item-level GitHub restore works, or subscribe to Retro, our newsletter, for practical resilience guidance every month.
Dave North">
