GitHubにバックアップは必要？「90日」の復元期限と標準機能の限界
「ソースコードはGitHubに置いてあるから安全」と考えている開発チームは少なくありません。
しかし、業務でGitHubを利用する場合は、標準機能だけに頼らず、バックアップを検討することが重要です。削除したリポジトリを標準機能で復元できるのは原則90日以内で、復元できる範囲にも制限があるためです。AIエージェントがリポジトリを操作するようになった今、その重要性はさらに高まっています。
本記事では、標準機能でどこまで戻せるのか、バックアップ方法ごとの違い、独立バックアップを選ぶ5つの条件を解説します。
INDEX
この記事のポイント
- 削除したリポジトリを復元できるのは原則90日以内。フォークネットワークの状況によっては復元できず、チームの権限設定も戻らない
- git clone（mirror clone）ではコードと履歴を保存できるが、Issueやプルリクエスト、設定などは含まれない
- 誤操作、アカウントの乗っ取り、AIエージェントの誤動作に備えるには、GitHubから独立した場所にバックアップを持つことが有効
GitHubで削除したリポジトリを復元できるのは「90日以内」
GitHub公式ドキュメントによると、削除したリポジトリは、削除から90日以内であれば復元できます。ただし、無条件に復元できるわけではありません。
- フォークネットワークに属していたリポジトリは、ネットワーク内のほかのリポジトリが残っている場合、そのままでは復元できない
- リポジトリを復元しても、チームの権限設定は復元されない
つまり、削除に気づくのが遅れた場合や、リポジトリの構成によっては、標準機能だけでは元の状態に戻せない可能性があります。
GitHubが管理しているのは、サービスを提供するためのプラットフォームやインフラです。利用者の誤操作や意図的な削除で失われたデータについては、利用者側でも復旧の方法を用意しておく必要があります。
git cloneだけではGitHubのバックアップにならない理由
データ損失の原因は、リポジトリの削除だけではありません。force pushで履歴が書き換えられると、それまでブランチから参照されていたコミットが履歴上から外れてしまうことがあります。ブランチ保護機能で制限できますが、設定と権限管理が正しく維持されていることが前提です。
「git cloneしておけばバックアップになる」という考え方にも注意が必要です。mirror cloneでは、リポジトリのファイルとコミット履歴をバックアップできます。一方、Issue、プルリクエスト、リポジトリ設定など、GitHub上のすべてのデータが含まれるわけではありません。Wikiも別途バックアップが必要です。
GitHubには一部のメタデータを書き出せる移行アーカイブもありますが、Git LFSオブジェクト、Discussions、Packagesなどは含まれません。公式ドキュメントでも、移行アーカイブをGitHubへ復元するためのサポートされた方法は提供されていないとされています。
レビューや議論の履歴、設定も、開発を続けるための資産です。「コードが残っていること」と「開発環境を復旧できること」は、分けて考える必要があります。
GitHubで削除・上書きが起きる3つの場面
データが失われるきっかけは、特別なものとは限りません。
- AIエージェントの誤操作：2025年7月、Replitのエージェントが本番環境のデータベースを削除する事象が発生し、同社は開発用と本番用のデータベースを分離するなど安全対策を強化しました。GitHubでも、AIエージェントにリポジトリへの書き込み権限を与える場合は、意図しない変更や削除への備えが必要です。
- 退職者対応・権限整理：アカウントの整理や組織再編の際に、必要なリポジトリや設定を誤って削除・変更してしまう可能性があります。
- アカウントの乗っ取り：認証情報が漏えいし、権限を持つアカウントが第三者に悪用されれば、リポジトリや設定を削除・改ざんされるおそれがあります。
共通するのは、「本番のGitHub環境を操作できる主体」によってデータが失われる点です。だからこそ、本番環境とは別の場所に、復旧できるデータを保持しておくことが重要になります。
GitHubをバックアップする3つの方法と違い
- mirror cloneと自作スクリプト（AWS S3などに保存）：費用を抑えられますが、守れるのは主にコードと履歴です。Issueやプルリクエストまで含めるには作り込みが必要で、保守や復元テストも自社で担うことになります。
- GitLabなど別プラットフォームへのミラーリング：コードの冗長化には有効です。ただし、同期方法によっては、元リポジトリの変更や削除がミラー側にも反映されるため、過去の任意の時点へ復元するバックアップとは役割が異なります。
- 独立したバックアップ専用サービス：メタデータを含む継続的なバックアップ、暗号化や改ざん防止（イミュータブル化）、時点を指定した復元を、運用負担を抑えながら維持できます。
GitHubの独立バックアップに求められる5つの条件
バックアップサービスを検討する際は、次の5点を確認するとよいでしょう。
- GitHubから独立していること：本番環境とは別のインフラに保存し、本番側の障害やアカウント侵害の影響を切り離します。
- バックアップが改ざん・削除されにくいこと：イミュータブルな仕組みにより、誤操作や不正アクセスがバックアップ自体に及ぶリスクを抑えます。
- コード以外のデータも保護できること：プルリクエスト、Issue、設定など、どこまでが対象になるかを確認します。
- 必要な時点に戻せること：誤った変更や削除が行われる前の健全な状態（known-good-state）から復旧できることが重要です。
- 必要な期間保持できること：標準の90日に依存せず、自社の運用やコンプライアンス要件に合わせて保持期間を決められるかを確認します。
KeepitならGitHubのデータを独立クラウドで保護
Keepitは、GitHubやAzure DevOpsをはじめ、Microsoft 365、Google Workspace、Jira、Confluenceなどのデータを、一つのプラットフォームから保護できるSaaSデータ保護サービスです。
GitHubでは、リポジトリ（ブランチ・コミット・タグ）に加え、プルリクエスト、Issue、リポジトリ設定、チームなどを自動的にバックアップし、GitHubとは独立したKeepitのクラウドに保存します。バックアップデータはイミュータブルかつエアギャップされた環境で保護され、特定時点への復元や柔軟な保持期間の設定にも対応しています。
対応するデータの範囲は順次拡大しています。自社で守りたいデータが対象に含まれるかどうかは、資料請求またはお問い合わせでご確認ください。
GitHubのバックアップに関するよくある質問（FAQ）
Q1. GitHubにもバックアップは必要ですか？
A1. 業務で利用している場合は、標準機能だけに頼らず、バックアップを検討することをおすすめします。削除したリポジトリを標準機能で復元できるのは原則90日以内で、対象にも制限があるためです。Issueやプルリクエスト、設定まで復旧したい場合は、GitHubとは別にバックアップを用意することが選択肢になります。
Q2. git clone（mirror clone）しておけばバックアップとして十分ですか？
A2. ソースコードとコミット履歴の保存には有効ですが、プルリクエストやIssue、リポジトリ設定など、GitHub上のすべてのデータが含まれるわけではありません。Wikiも別途バックアップが必要です。
Q3. GitHubで削除したリポジトリはいつまで復元できますか？
A3. 標準機能では、原則として削除から90日以内です。フォークネットワークの状況によっては復元できない場合があり、復元してもチームの権限設定は戻りません。
Q4. AIエージェントを利用する際、どのようなデータ損失リスクがありますか？
A4. 書き込み権限を持つAIエージェントが、指示の不備や状況の誤認によって、ブランチの強制上書きやリポジトリの削除を実行してしまうリスクがあります。権限を必要最小限に絞ったうえで、独立した環境へのバックアップで備えることが有効です。
まとめ：自社のGitHubで確認したい3つのこと
「GitHubに保存していること」と「必要なデータをいつでも復旧できること」は同じではありません。まずは、次の3点を確認してみてください。
- 削除や上書きに90日以上気づかなかった場合でも、復旧する手段があるか
- Issue、プルリクエスト、設定など、コード以外のデータをどこまで保護できているか
- AIエージェントや外部ツールに、どこまでの書き込み・削除権限を与えているか
一つでも不安が残る場合は、GitHubとは独立したバックアップで補うことが、復旧力を高める一つの方法です。Keepitの資料請求・お問い合わせでは、GitHubの保護範囲や導入の進め方をご案内しています。