GitHubこそ、何よりも優先してバックアップすべきものです

ITチームやプラットフォームチームの多くに、バックアップにおける最優先事項を尋ねると、ほぼ同じリストが挙がります。それは、電子メール、ファイル共有、ERPソフトウェア、そしてもちろんインフラストラクチャ（ハードウェア、ソフトウェア、ネットワークコンポーネント）です。 GitHubは通常、その中間に位置するか、あるいは次のような言葉で片づけられてしまいます。「GitHubは自動的にレプリケートされるので、問題ありません。」 

その順位付けは、もはや過去の遺物です。 GitHubは今や、ほとんどのエンジニアリング組織において、最も価値が高く、変化の激しい記録システムとなっており、メール、ファイル共有、そしてほとんどのクラウドホスト型アプリよりも優先順位が高く、バックアップの優先順位リストのトップに位置すべきものです。 

なぜ GitHub がトップに躍り出たのか 

GitHub に格納される内容が変わったからです。 現代の GitHub 組織には、ビジネスの運用青写真が格納されています。アプリケーションコード、インフラストラクチャ・アズ・コード、CI/CD パイプライン、デプロイ設定、ランブック、セキュリティポリシー、顧客向け SDK、AI プロンプト、そして日頃のエンジニアリング業務を自動化するエージェント定義もますます増えています。 かつてリポジトリを失うことは、単に一部のコードを失うことを意味していました。しかし今日、リポジトリを失うことは、企業の運営方法に関する仕様そのものを失うことを意味する可能性があります。 

開発速度は劇的に向上しました。 Copilot、Cursor、Claude Codeが日常のワークフローに組み込まれた結果、2023年に1日200コミットを生成していた50人のエンジニアからなる組織は、現在では日常的に600～1,000コミットを生成するようになりました。エージェントは夜通しコミットを行います。エージェントは週末もコミットを行います。 以前は作成に1週間かかっていたものが、今では1日で作成できるようになりました。これは同時に、たった1回の破壊的なインシデントによって、かつてないほど多くの作業が失われる可能性があることを意味します。 

障害の発生形態はさらに深刻化しました。 GitHubのネイティブな保護機能（ブランチ保護、レプリケーション、削除済みリポジトリの90日間の復元期間）は確かに存在しますが、その範囲は限られています。認証済みのサービスアカウントから行われたため、GitHubが正当とみなすフォースプッシュに対しては、復旧できません。 また、.github/workflows を書き換えてリリース成果物を破壊するループに陥らせるエージェントによる攻撃からも復旧できません。さらに、午前3時に200のブランチを削除するために悪用された、侵害された個人アクセストークンによる被害からも復旧できません。 

なんと GitHubのバックアップが実際に耐えなければならない事態とは 

重要な破壊的イベントの多くは、悪意によるものではありません。 それらはごくありふれたものであり、エージェントの登場によってさらに一般的になりました： 

• クリーンアップ・エージェントは、古そうに見えたものの実際にはそうではなかったブランチを削除してしまいます。&
• リファクタリングエージェントが、リベースに失敗した後、main ブランチへ強制プッシュを行ってしまいます。 
• 移行スクリプトが、十数個のリポジトリにわたって履歴を書き換えます。 
• 侵害されたエージェントトークンが、誰にも気づかれる前にブランチ、タグ、またはリリースを削除するために使用されます。 
• CIワークフローが、エージェントによって生成された破壊的なGitコマンドを実行します。 

いずれの場合も、GitHub にとってはその操作が正当なものに見えます。認証は完了していました。 承認も済んでいます。GitHub自身の保護機能では、そのプッシュが不正であったことを知る術がありません。 

理論上の例 

中堅のフィンテック企業がGitHub上で18のリポジトリを運用しており、毎晩バックアップが行われています。 同社には、組織全体でテストを実行し、自動修正を適用するコーディングエージェントがあります。このエージェントは、メインのモノレポに対して管理者権限を持つサービスアカウントで認証されています。これは、きめ細かな権限設定が次四半期のプロジェクトとして予定されていたためです。 

土曜日の午前2時、エージェントが大きなプルリクエストを処理中に、リベースロジックのバグに遭遇しました。その結果、書き換えられた履歴をmainブランチに強制プッシュしてしまい、前週の142件のコミットが破棄されてしまいました。その中には、本番環境で既に稼働していた3つのホットフィックスも含まれていました。 監視している人間はいませんでした。プッシュをブロックするブランチ保護ルールも存在しませんでした。

チームが事態に気づいたのは月曜日の朝でした。最後の正常なバックアップは金曜日の深夜に実行されていました。 そのスナップショットとインシデントの間に、エージェントは47件のプルリクエストをマージしていました。その47件すべてがソース管理から消えてしまいました。ホットフィックスは本番環境でまだ稼働していますが、それらに関する「真実の源」はどのリポジトリにももはや存在しません。 

復旧には3日間を要しました。 ホットフィックスのうち2つは、クリーンに再構築できず、一から書き直されることになりました。1時間ごとのバックアップがあれば、損失は47分間の作業に抑えられたはずです。 

GitHubのバックアップソリューションに求めるべきもの 

もし GitHubがバックアップの最優先事項である場合、そのソリューションには以下の4つの要素が必要です： 

頻繁なバックアップ間隔。 バックアップツールでは、RPO（リカバリポイント目標）という用語を使用します。平たく言えば、何か問題が発生した場合に、どの程度の作業データを失っても許容できるかを、時間単位で測定したものです。 バックアップが毎晩実行される場合、RPOは24時間となります。エージェント時代のGitHubにおいては、毎晩という頻度は遅すぎます。最低でも1時間ごとの実行が求められます。重要なモノリポジトリの場合、30分ごとの実行であれば妥当と言えます。 どのベンダーに対しても、最小のバックアップ間隔がどれくらいか、またそれがリポジトリ全体（イシュー、プルリクエスト、設定を含む）に適用されるのか、それともコードのみに適用されるのかを確認してください。 

全面的なカバレッジ。コードのみをバックアップすると、4時間のインシデントが4日間に及ぶ事態となります。 イシュー、プルリクエスト、ディスカッション、Actionsワークフロー、リリース、LFSオブジェクト、ブランチ保護ルール、そしてチームメンバーシップやアプリのインストールといった組織レベルの設定も必要です。 .github/workflows だけを失うだけでも、依存しているエージェントの設定が失われる可能性があります。 

不変性。リポジトリを削除できる管理トークンが侵害された場合、バックアップシステムが同じ認証情報を信頼していれば、バックアップも削除されてしまうことがよくあります。 エアギャップ化されたコピーやオブジェクトロックされたコピーは、単なるオプションではありません。それらは、単なる「不運な一日」と、「開発者のノートパソコンから再構築しなければならない」という悪夢との違いを分けるものです。 

検証済みの復旧。重要度の低いリポジトリを、少なくとも四半期に一度、エンドツーエンドで復元してください。 実際にどれくらいの時間がかかるかを測定してください。一度も復元したことがないバックアップは、推測に過ぎず、計画とは言えません。 

変化 

ほとんどの組織は、GitHubを「いくつかの二次的な成果物が添付されたコードリポジトリ」という前提に基づいてバックアップしています。 しかし、GitHubはもはやそのような存在ではありません。GitHubは、多くの企業が運用する中で最も高速なオペレーショナルシステムであり、その価値が蓄積される速度は、ほとんどのチームが受け継いできたバックアップ体制の対応速度を上回っています。 

GitHubを優先順位リストの最上位に据えてください。積極的なバックアップ頻度、全面的なカバレッジ、不変性、そして検証済みの復旧機能こそが、その優先順位を現実のものにする要素です。 これらがなければ、「GitHubをバックアップしています」というのは、単なるチェック項目に過ぎず、計画とは言えません。