{"meta":{"title":"バックアップからの復元","intro":"以前に作成したバックアップ スナップショットを使用して、 GitHub Enterprise Server インスタンスを復元します。","product":"エンタープライズ管理者","breadcrumbs":[{"href":"/ja/enterprise-server@3.17/admin","title":"エンタープライズ管理者"},{"href":"/ja/enterprise-server@3.17/admin/backing-up-and-restoring-your-instance","title":"バックアップと復元"},{"href":"/ja/enterprise-server@3.17/admin/backing-up-and-restoring-your-instance/restoring-from-a-backup","title":"バックアップから復元する"}],"documentType":"article"},"body":"# バックアップからの復元\n\n以前に作成したバックアップ スナップショットを使用して、 GitHub Enterprise Server インスタンスを復元します。\n\nGitHub Enterprise Server インスタンスは、コマンド ラインを使用してバックアップから復元できます。 バックアップ サービスでは、構成やユーザー データを含む完全なインスタンスの復元がサポートされています。\n\n> \\[!WARNING] バックアップから復元すると、インスタンスの**既存データがすべて上書き**されます。 この操作を元に戻すことはできません。\n\n## スナップショット バージョンの要件\n\n復元できるスナップショットは、ターゲット インスタンスのバージョンより最大 2 つ前の機能バージョンまでのみです。\n\n例えば次が挙げられます。\n\n* バージョン 3.17 のスナップショットは、3.17.x、3.18.x、または 3.19.x を実行しているターゲットに復元できます。\n* 3.17 のスナップショットを 3.20 に復元することは、2 バージョンより後であるため、できません。\n\nまた、新しいバージョンから古いバージョンに復元することもできません。 たとえば、3.18 スナップショットを 3.17 インスタンスに復元しようとすると、失敗します、次のように`Error: Snapshot can not be restored to an older release of GitHub Enterprise Server.`\n\n## \\[前提条件]\n\nバックアップを復元する前に:\n\n1. ターゲット インスタンスで**メンテナンス モードを有効にします**。 「[メンテナンスモードの有効化とスケジューリング](/ja/enterprise-server@3.17/admin/administering-your-instance/configuring-maintenance-mode/enabling-and-scheduling-maintenance-mode)」を参照してください。\n2. スナップショットが格納されているバックアップ ストレージに**アクセスできることを確認します**。\n3. **干渉するサービスを一時的に停止する**: 高可用性 (HA) をお使いの場合、レプリケーションが停止されていることを確認します。\n4. \\*\\*\n   GitHub Actionsの準備\\*\\*— 有効になっている場合は、ターゲット インスタンスが正しい外部ストレージで構成されていることを確認します。 詳しくは、「[GitHub Actionsを有効にした状態での復元](/ja/enterprise-server@3.17/admin/backing-up-and-restoring-your-instance/restoring-with-github-actions-enabled)」をご覧ください。\n\n## 復元操作の開始\n\nスナップショットから復元するには:\n\n1. `admin` ユーザーとしてターゲット インスタンスに SSH で接続します。\n\n2. 次のいずれかのコマンドを実行します。\n\n   * 最新のスナップショットを復元します。\n\n     ```shell\n     ghe-restore\n     ```\n\n   * 特定のスナップショットを復元します。\n     `<SNAPSHOT_TIMESTAMP>` を復元するスナップショットのタイムスタンプ (例: `YYYYMMDDTHHMMSS`) に置き換えます。\n\n     ```shell\n     ghe-restore -s <SNAPSHOT_TIMESTAMP>\n     ```\n\n   * (省略可能)アプライアンスの構成、証明書、およびライセンス データをバックアップから上書きします。\n     `-c` オプションでは、データベースまたはリポジトリの復元は制御されません。\n\n     ```shell\n     ghe-restore -c          # Latest snapshot\n     ghe-restore -s <SNAPSHOT_TIMESTAMP> -c  # Specific snapshot\n     ```\n\n3. \\*\\*\n   \\[Management Console]で最終処理を行います。\\*\\*\n\n   * すべての構成設定 (ネットワーク、認証、TLS など) を確認します。\n   * **\\[Save settings]** をクリックしてそれらを適用し、サービスを開始します。\n   * このステップが完了するまで、インスタンスは完全には動作しません。\n\n4. **復元されたインスタンスを検証**して、すべてが意図したとおりに動作していることを確認します。\n\n5. **HA をお使いの場合**は、最初にスタンドアロン インスタンスでの復元を済ませます。 次に、HA を再構成します。\n\n   * 同期の問題 (`ghe-repl-status` での古い UUID など) が発生する場合は、`ghe-repl-teardown` を実行します。\n   * ヘルプについては、 GitHub のサポートにお問い合わせください。\n\n6. 復元によって以前のトークンが無効になったので、**セルフホステッド GitHub Actions ランナーを再登録**します。\n\n## スナップショットのローテーションと保持\n\nスナップショットは、データ保持の設定に基づいて自動的に除去されます。\n\n* 最新の n 個のスナップショットのみが保持されます (構成に応じて)。\n* バックアップが成功するたびに、古いスナップショットが削除されます。\n* スナップショットには、簡単に参照できるように、タイムスタンプ (`YYYYMMDDTHHMMSS`) を使って名前が付けられます。\n* 変更されていないファイルについては、完全復元の機能を維持しながら効率的に格納するため、ハード リンクが使われます。\n\n## 復元失敗のトラブルシューティング\n\n復元操作が失敗する場合は、次のことを調べます。\n\n* **バックアップの完全性**: スナップショットが中断されたり破損したりしていないことを確認します。\n* **ストレージのアクセス**: インスタンスでバックアップ ボリュームのマウントと読み取りが可能であることを確認します。\n* **バージョンの不一致**: スナップショットのバージョンとターゲット インスタンスの間に互換性があることを確認します。\n* **ログ**: `/var/log/github-backup/restore-verbose-[timestamp].log` でエラーを確認します。\n\n\\[Management Console]に一般的なエラーが表示された場合は、インスタンスに SSH 接続して詳細なログにアクセスします。"}