Backups

How to Back Up GitHub Repos, Issues and Pull Requests

By Takuma Arimura · Updated

Most small teams assume their GitHub work is safe because “it’s all in Git.” The code is. The context usually isn’t: the issue where a customer reported the bug, the pull request discussion behind a decision, the wiki page with your deploy steps.

Those live in GitHub’s database, not in your repository. A laptop clone won’t bring them back if a repo is deleted, an admin account is compromised, or someone with the wrong permissions cleans up “old” issues.

Here’s what GitHub gives you natively, where it stops, and how to back up repositories and their metadata automatically.

Quick answer: For most small teams, SimpleBackups is the most practical choice. It backs up repositories plus issues, pull requests, wikis, releases and gists on a schedule you set, stores the copies in cloud storage you own, and can restore from its dashboard. Its first paid plan is $49/month billed monthly. If you want the lowest price for a very small org, Rewind Backups for GitHub (formerly BackHub) starts at $12/month for up to 3 organization members. If someone on your team is comfortable with the command line, the free python-github-backup tool on a schedule is the DIY route.

What GitHub can do natively

A mirror clone copies the Git repository

GitHub’s backup guide recommends git clone --mirror for the repository itself. Here’s what that covers:

“A Git repository includes all of the files and folders associated with a project, along with each file’s revision history.”

— Backing up a repository

That’s code, branches, tags and history. Issues, pull request conversations, reviews, labels, milestones and releases aren’t part of the Git repository, so a clone, mirror or not, doesn’t include them. Wikis are the exception: GitHub says “Wikis in GitHub are stored as Git repositories,” so you can clone them separately.

Migration archives include metadata, but can’t be restored

The same guide describes migration archives, generated through the REST API, which do include issues, pull requests and other metadata. They come with two warnings:

“Migration archives do not include all data related to a repository. For example, Git Large File Storage objects, discussions, or packages are not included.”

— Backing up a repository

“There is no supported, documented way to restore migration archives on GitHub, so these backups are only suitable for archiving purposes.”

— Backing up a repository

They’re also a manual API job, and per GitHub’s user migrations API docs, an archive is “available to download for seven days.”

Deleted repositories can sometimes be restored

If a repository is deleted, GitHub keeps it for a while:

“A deleted repository can be restored within 90 days, unless the repository was part of a fork network that is not currently empty.”

— Restoring a deleted repository

The same page notes that “Restoring a repository will not restore team permissions.” And this safety net only covers whole repositories. Individual issues are a different story:

“People with admin permissions in a repository can permanently delete an issue from a repository.”

— Deleting an issue

There’s no trash for issues.

Where GitHub stands on responsibility

GitHub’s Terms of Service are direct about this. “You are responsible for Your Content and any harm resulting from it,” and GitHub provides the service “as is” and “as available,” without warranty of any kind. If an account is closed, GitHub says it will delete “the Content of your repositories within 90 days of cancellation or termination,” and “This information cannot be recovered once your Account is canceled.” GitHub’s backup guide itself points to the Backup Utilities category on GitHub Marketplace for automated tools.

What’s missing from the native options

  • No automatic metadata backup. Issues, PRs, reviews and releases are only exportable through a manual API call.
  • No restore for metadata. GitHub itself says migration archives can’t be restored.
  • No undo for deleted issues. Deletion is permanent.
  • The 90-day repo restore has limits. Fork networks block it, team permissions don’t come back, and it doesn’t help if the account itself is gone.

GitHub backup tools compared

ToolMetadata coveredScheduleWhere backups are storedRestore into GitHubFree plan / trialStarting price
SimpleBackupsIssues, PRs, wikis, releases and assets, gists, collaborators, classic projectsYou set it (up to every 12h on Lite, hourly on Plus)Your own storage (S3, SFTP, drives) or theirsYes, from the dashboard (overwrites selected repos)Free Basic plan, but it includes 0 Git repos$49/mo monthly, 25 repos
Rewind Backups for GitHubIssues, PRs, wikis, releases, projects, milestones, branch protectionsDailyRewind’s cloudYes, repository plus metadata14-day trial$12/mo for up to 3 org members, then $4/user
GitProtectVery broad, including V2 Projects, Actions, LFSConfigurableTheir cloud or your own cloud / on-premYes, granular, also to GitLab, Bitbucket or Azure DevOps14-day trialSee pricing page
BackupLABSIssues, PRs, wikis, releases, gists, project boardsDaily (twice daily on Pro)BackupLABS’ cloudYes, as a new cloned repository14-day trialSee pricing page
ProBackupNone (repos, branches, commits only)DailyProBackup’s storageNo (not yet)7-day trial$25/mo billed annually
python-github-backup (DIY)Issues, PRs, wikis, releases, discussions, gistsWhatever you scheduleWherever you put itNo (JSON files)Free, open source$0 + your time

Prices and plan limits checked against each vendor's pricing page in October 2026. Plans change, so confirm on the linked pages before you buy.

SimpleBackups

What it is

SimpleBackups is a backup service for databases, servers and SaaS apps. Its GitHub backup covers personal and organization accounts. The main design choice: backups land in your own storage account, not the vendor’s.

How it works with GitHub

You connect GitHub through SimpleBackups’ GitHub app and pick repositories. According to its GitHub documentation, you can add Wikis, Issues (with comments), Pull Requests, Releases, release Assets, Collaborators and “classic GitHub projects,” plus an option to back up gists.

One caveat on projects: GitHub sunset Projects (classic) on GitHub.com in August 2024 and migrated them to the new Projects. SimpleBackups’ docs only list classic projects, so don’t count on it for your current project boards. Its GitHub page also lists LFS objects.

Per the pricing page, Lite ($49/month, 25 repositories) allows backups up to every 12 hours, and Plus ($99/month, 100 repositories) up to hourly. Paying yearly saves 20%. Extra repositories cost $10/month per 10. The free Basic plan includes 0 Git repositories, so GitHub backup needs a paid plan.

Restore

Restores run from the dashboard: open a backup run, choose “Automatic restore,” pick repositories and start. SimpleBackups’ restore overview describes it as restoring “repositories, issues, pull requests and metadata.” The GitHub docs carry a clear warning: “Restoring a backup will overwrite the contents of the selected repositories. This action cannot be undone.”

Strengths

  • Backups in storage you control, so they survive a lost GitHub account and a lost vendor account.
  • Covers the metadata most teams care about: issues, PRs, wikis, releases.
  • Schedule and retention are configurable, not fixed at once a day.
  • Also covers databases, Notion, GitLab and Linear.

Limits

  • No free tier for GitHub. $49/month is steep if you only have a handful of repos.
  • Restore overwrites the selected repository. There’s no documented “restore to a new repo” option, so test on a scratch repo first.
  • Only classic projects are listed. Current GitHub Projects and Discussions aren’t mentioned in its docs.

Who it’s for

Small teams and startups that want metadata backups in their own cloud account, especially if they also need database backups.

Rewind Backups for GitHub

What it is

Rewind Backups for GitHub, formerly BackHub, is a GitHub-focused backup app installed from the GitHub Marketplace.

How it works with GitHub

Rewind runs automatic daily backups. Its product page lists issues and pull requests (“Description, creation date, creator, open or closed status, comments, assignee, assigned labels and milestones”), wikis, releases with attachments, branch protection rules and repository settings. Git LFS is “Early Access, by request, on Rewind Enterprise plans.”

Restores work at the repository level: “The repository is the unit of restore, and Rewind brings one back whole in a single action.”

Strengths

  • Cheapest paid option for tiny orgs: $12/month for up to 3 organization members, then $4/month per user (Marketplace listing).
  • Covers projects and branch protections.

Limits

  • Per-member pricing grows with your team, even members who rarely touch code.
  • Backups live in Rewind’s cloud; there’s a data export, but your primary copy isn’t in your own storage.
  • Daily only. The Individual plan keeps 30 days of history; 365 days requires Enterprise.

Who it’s for

Small GitHub organizations that want the lowest-effort, lowest-cost metadata backup and don’t need copies in their own storage.

GitProtect

GitProtect has the broadest coverage on paper, including “V2 Projects,” Actions, Dependabot, teams, webhooks and LFS. It can store backups in its cloud or yours, and restore granularly to GitHub or even to GitLab, Bitbucket or Azure DevOps. It’s built for larger organizations and priced by repository count, so it’s usually more than a small team needs. See the pricing page.

BackupLABS

BackupLABS backs up repositories, gists, PRs, issues, labels, releases, project boards and wikis, daily on Essential and every 12 hours on Pro. Its restore approach is cautious: “We never overwrite live code. We Restore as Clones to a new repository.” That’s a good fit if you worry about restores clobbering current work. It also covers Trello, Jira and Notion. Pricing wasn’t displayed on its page at the time of writing, so check with the vendor.

ProBackup

ProBackup supports GitHub, but only partly. Its GitHub page says it backs up “Repositories, Branches, Commits and Repository snapshots,” while “Issues, Projects and Discussions” are not backed up. It also says: “It is currently not possible to restore any data for GitHub.”

That covers the part of GitHub you can already protect for free with a mirror clone. It’s a reasonable extra only if you already pay for ProBackup for Airtable, Notion or Trello and want repo snapshots under the same license. It isn’t a fit if you need issues and PRs.

How to choose

  • You want metadata backups in your own S3 bucket or drive: SimpleBackups.
  • You’re a 2–3 person org and want the cheapest metadata backup: Rewind ($12/month).
  • You’re afraid a restore will overwrite live work: BackupLABS, which restores as a new cloned repository.
  • You need current GitHub Projects, Actions config and LFS covered: GitProtect or Rewind Enterprise.
  • You already use ProBackup for other tools: Its GitHub backup adds repo snapshots, but add something else for issues and PRs.
  • You have someone comfortable with a terminal and $0 budget: python-github-backup on a schedule (below).

Whatever you choose, back up the whole organization, not just the main repo.

How to set up automatic GitHub backups with SimpleBackups

These steps follow SimpleBackups’ GitHub documentation. The interface may have changed since.

  1. Create an account. Sign up at SimpleBackups and choose a plan that includes Git repositories (Lite or higher).
  2. Connect storage. Add the storage where backups should go, such as an S3-compatible bucket or a drive you own. Use a bucket that isn’t tied to the same admin account as GitHub.
  3. Connect GitHub. From the App backup page, create a new GitHub connection and click Connect GitHub. Name it if you’ll connect several accounts.
  4. Authorize the app. GitHub shows the permissions SimpleBackups requests. Write permissions are used only when you trigger a restore. Click Install & Authorize.
  5. Approve it for your organization. If your org uses SAML SSO, an owner must grant access under the organization’s SAML SSO settings, or backups fail with “Resource protected by SAML enforcement.”
  6. Choose repositories. Pick All Repositories so new repos are included automatically, or Specific Repositories.
  7. Turn on metadata. Under Backup Options, enable Wikis, Issues, Pull Requests, Releases and Assets. Enable Backup Gists if your team keeps scripts there.
  8. Set the schedule and retention. Daily is a sensible default; keep at least 30 days of copies.
  9. Test a restore. Restoring overwrites the selected repositories, so restore into a throwaway test repo first and check that issues and PR comments came back.

The free DIY option: python-github-backup on a schedule

python-github-backup is an open-source command-line tool that can back up “an entire Github organization, repository or user account, including starred repos, issues, discussions and wikis.” Wikis are saved as Git clones and issues as JSON files. Flags such as --issues, --pulls, --wikis, --releases and --lfs control what’s included. Private repositories (--private) and attachments (--attachments) must be requested explicitly, because --all doesn’t include them.

A minimal setup:

  1. Create a fine-grained personal access token with read-only access to the repositories you want.
  2. Run github-backup YOUR-ORG -f YOUR_TOKEN --all --private -o ./backup on a small server or in a scheduled GitHub Actions workflow.
  3. Copy the output to cloud storage outside GitHub, such as S3 or Google Drive.

If you use GitHub Actions as the scheduler, note two caveats from GitHub’s workflow trigger docs: scheduled runs “can be delayed during periods of high loads,” and “In a public repository, scheduled workflows are automatically disabled when no repository activity has occurred in 60 days.” Keep the backup workflow in a private repo, and check that it’s still running.

If you only need code, the plain version is GitHub’s own git clone --mirror (plus git lfs fetch --all if you use LFS) in the same kind of scheduled job.

The tradeoff: there’s no restore. You get readable JSON files, but putting issues back into GitHub is a scripting project. You also own monitoring and retention.

FAQ

Does GitHub back up my repositories for me?

Not in a form you can restore from yourself, beyond restoring a deleted repository within 90 days in most cases. Deleted issues and closed accounts can’t be rolled back, and GitHub’s terms say you’re responsible for your content.

Does git clone back up issues and pull requests?

No. A clone, including git clone --mirror, copies the Git repository: files, branches, tags and history. Issues, PR discussions, reviews and releases are stored in GitHub’s database and need the API, a migration archive or a backup tool.

Can I restore a deleted GitHub issue?

Not from GitHub. Admins can permanently delete issues, and there’s no trash. You need a backup that captured the issue before it was deleted, from a tool like SimpleBackups or Rewind, or from your own python-github-backup JSON files.

Can I use GitHub’s migration archive as a backup?

For archiving, yes; for recovery, not really. GitHub says they exclude LFS objects, discussions and packages, and there’s “no supported, documented way to restore” them. They’re also only downloadable for seven days.

How often should I back up GitHub?

Daily is enough for most small teams. If you run support or planning in GitHub Issues, consider twice daily. Either way, test a restore once a quarter.

Is GitHub backup worth it for a three-person startup?

If your issues and PRs hold product decisions, customer reports or compliance evidence, yes. The cheapest paid options start around $12/month, and the DIY route is free. If you only care about code, a scheduled mirror clone may be enough.


This page contains affiliate links. If you buy through them, we may earn a commission at no extra cost to you. See our disclosure. GitHub is a trademark of GitHub, Inc. This site isn’t affiliated with or endorsed by GitHub.

Backing up other team tools? See our guides to Notion backups and Trello backups.