GitHubはバックアップすべき第1位

ほとんどのITチームやプラットフォームチームに、バックアップの最優先事項は何かと尋ねると、同じリストが返ってくるでしょう。GitHubはたいてい中間に位置するか、「GitHubは自分自身をレプリケートするので大丈夫です。

そのランキングは違う時代の名残です。GitHubは今や、ほとんどのエンジニアリング組織において最も価値があり、最も速度の速い唯一の記録システムであり、メールやファイル共有、そしてほとんどのクラウドホスティングアプリを差し置いて、バックアップの優先順位リストのトップに属するものです。

GitHubがトップに躍り出た理由

GitHubにあるものが変わった最新のGitHub orgには、アプリケーション コード、Infrastructure-as-Code、CI/CDパイプライン、デプロイ設定、ランブック、セキュリティ ポリシー、顧客向けSDK、AIプロンプト、そして日々のエンジニアリングを自動化するエージェント定義など、ビジネスの運用設計図が保管されています。かつてレポを失うことはコードを失うことを意味しました。今日、レポを失うことは、会社の運営方法の仕様を失うことを意味します。

ベロシティは劇的に向上しました。毎日のワークフローにCopilot、Cursor、Claude Codeを使用することで、2023年には1日に200のコミットを生成していた50人のエンジニアの組織は、今では日常的に600～1,000のコミットを生成しています。エージェントは夜通しコミットします。エージェントは週末もコミット。以前は作成に1週間かかっていたものが、今では1日で作成できるようになり、1つの破壊的なインシデントが、以前よりも多くの仕事を一掃する可能性があることも意味します。

障害モードはさらに悪化しました。 GitHub のネイティブな保護機能 (ブランチ保護、レプリケーション、90 日間の削除済みレポウィンドウ) は実在しますが、狭いものです。GitHubは認証されたサービスアカウントからのプッシュを正当なものとみなします。.github/ワークフローをループに書き換えてリリースの成果物を破壊するエージェントからは回復できません。

GitHubのバックアップが実際に生き残るために必要なこと

重要な破壊的イベントは、ほとんどが悪意のあるものではありません。

• cleanup エージェントが、古く見えるけれど古くないブランチを削除しました。
• A refactor agent は、間違ったリベースの後に main に強制プッシュします。
• Migration スクリプトは、12 個のレポジトリにわたって履歴を書き換えます。
• 漏洩したエージェント・トークンが、誰にも気づかれないうちにブランチ、タグ、リリースを削除するために使用されます。
• CI ワークフローは、エージェントが生成した破壊的な git コマンドを実行します。

どの場合も、GitHubにとっては正当な被害です。認証されています。認証されています。GitHub自身の保護機能では、プッシュが間違っていたことを知る術はありません。

理論的な例

ある中堅のフィンテック企業がGitHubで18のレポジトリを運用しており、毎晩バックアップを取っています。彼らはテストを実行し、組織全体に自動修正を適用するコーディングエージェントを持ち、メインのモノレポの管理者スコープを保持するサービスアカウントで認証されています。

土曜日の午前2時、エージェントは大規模なPRを処理中にリベースロジックのバグにぶつかりました。書き換えられた履歴がmainに強制的にプッシュされ、prodですでに実行されている3つの本番用Hotfixを含む、前週からの142のコミットが破棄されました。人間が見ているわけではありません。ブランチ保護ルールもプッシュをブロックしません。

チームは月曜の朝に気づきました。最後のバックアップは金曜日の真夜中に実行されました。そのスナップショットと事件の間に、エージェントは47のPRをマージしていました。47件すべてがソース管理から消えました。Hotfixはまだ本番環境で生きていますが、それらのソースはもはやどのリポジトリにも存在しません。

復旧には3日かかります。2つのHotfixはきれいにリビルドできず、ゼロから書き直しました。1時間ごとのバックアップであれば、損失は47分の作業で済んだでしょう。

積極的なバックアップ・ケイデンス。バックアップ ツールでは、RPO (recovery point objective) という用語を使います。わかりやすく言うと、何かが壊れた場合にどれだけの仕事を失うことができるかということです。バックアップが毎晩実行されるなら、RPOは24時間です。エージェント時代のGitHubにとって、毎晩では遅すぎます。時間単位が限界です。クリティカルなモノレポであれば、30分は守備範囲です。どのベンダーにも、その最小ケイデンスがどの程度なのか、そしてそれがレポ全体（課題、PR、設定を含む）に適用されるのか、それともコードだけに適用されるのかを尋ねてみてください。

全面的なカバレッジ。コードだけをバックアップすると、4時間のインシデントが4日のインシデントになります。課題、PR、ディスカッション、アクション ワークフロー、リリース、LFS オブジェクト、ブランチ保護ルール、チーム メンバーシップやアプリのインストールなどの org レベルの設定が必要です。.github/ワークフローを失うだけで、依存しているエージェントの設定を失うことになります。

不変性。バックアップシステムが同じ認証情報を信頼している場合、レポジトリを削除できる侵害された管理者トークンは、多くの場合バックアップも削除できます。エアギャップまたはオブジェクトロックされたコピーはオプションではありません。これらは、悪い日と、開発者のノートPCからリビルドする悪夢との違いです。

テストされたリカバリ。少なくとも四半期に一度は、重要でないレポをエンドツーエンドでリストアしてください。実際にかかる時間を測定してください。リストアしたことのないバックアップは、計画ではなく推測です。

シフト

ほとんどの組織では、GitHubはコードリポジトリであり、二次的な成果物が付随しているという前提でバックアップを行っています。それはもはやGitHubではありません。GitHubは、ほとんどの企業が運用する最も高速な運用システムであり、その価値の蓄積速度は、ほとんどのチームが継承してきたバックアップ体制を凌駕しています。

GitHubを優先順位リストのトップに移動します。積極的なバックアップ計画、全面的なカバレッジ、不変性、テストされたリカバリは、その優先順位を現実のものにする機能です。これらがなければ、「GitHubをバックアップする」というのはチェックボックスであって、計画ではありません。