Porta VM 災害バックアップと復元

このページでは、以下を扱います。

• Porta VM がデータベースバックアップを作成・保存する方法
• 手動でバックアップを取得する方法
• バックアップから復元する方法
• レプリケーショングループ内の 1 台または複数のマシンに影響するデータ損失からの復旧方法

そもそもなぜ障害が発生したのかを診断するには、Porta VM Troubleshooting guide を参照してください。

注意

このページの復旧手順には、マシンのデータベースを消去する破壊的なステップが含まれます。3 時間以内に作成された自動バックアップが安全かつ無傷であると分かっている場合を除き、開始前に必ず手動バックアップを取得してください。

自動バックアップの仕組み

Porta は 3 時間ごとに、プライマリ以外のマシン（通常は arbiter）でデータベースのバックアップを作成し、porta コンテナ内の次の場所に保存します。

/var/www/storage/app/Porta-Backups

各バックアップは、データベースの SQL ダンプを含む ZIP アーカイブです。アーカイブ名の形式は次のとおりです。

machine_type-machine-connection_name-backup-Y-m-d-H-i-s.zip

たとえば、2026-05-20 の 14:30 に arbiter で作成されたバックアップは、arbiter-machine-mysql-3-backup-2026-05-20-14-30-00.zip という名前になります。

ノート

これらのアーカイブは、壊滅的なデータ損失からの災害復旧を目的としています。ショーデータのアプリケーションレベルのエクスポートの代わりにはなりません。Porta のショーデータ、メディア参照、テンプレート定義はすべて同じデータベースに存在し、まとめて復元されます。

代替セットアップ

トポロジーによって場所と頻度が変わります。

• 単一マシンのセットアップ: バックアップは単一マシンで作成されます。
• 独立したバックアップマシンを持つ単一マシン: バックアップは両方のマシンで独立して作成されます。
• 3 台マシンのレプリケーショングループ: バックアップはデフォルトで arbiter で実行されます。各マシンの porta コンテナ内で最新のバックアップ ZIP を探して確認してください。

コンテナとポートのリファレンス

マシンの役割	データベースコンテナ	MySQL ポート	レプリケーションポート
Main	porta-db	3306	33061
Backup	porta-db-2	3307	33062
Arbiter	porta-db-3	3308	33063

復旧前のレプリケーションヘルスの確認

破壊的な復旧ステップの前に、レプリケーショングループの現在の状態を記録し、後で復旧が機能したことを確認できるようにします。

• porta_all_group_status は、すべてのマシンが報告するレプリケーショングループを表示します。実行するマシンに正しい /etc/hosts エントリが必要です。
• porta_group_status は、このマシンのみが報告するレプリケーショングループを表示します。
• porta_main_db_logs、porta_backup_db_logs、porta_arbiter_db_logs は、各役割の MySQL エラーログを表示します。ライブ出力を追跡するには _follow バリアントを使用します。

手動でバックアップを作成する

特にデータベースのリセットのような破壊的な操作の前には、いつでも手動バックアップを取得してください。

VM 内で次を実行します。

porta_backup_db

生成されたバックアップは、自動バックアップと同じ命名形式で、porta コンテナ内の /var/www/storage/app/Porta-Backups に保存されます。

ヒント

手動バックアップヘルパーは、自動スケジュールと同じ artisan コマンド（php artisan backup:run --only-db --disable-notifications）を使用するため、出力はスケジュールされたバックアップと互換性があります。

バックアップから復元する

VM 内で次を実行します。

porta_restore_db

ヘルパーは、ローカルのバックアップディレクトリにある利用可能なバックアップファイルの一覧を表示します。復元したいバックアップに対応する番号を入力して Enter を押します。

注意

復元すると、対象マシンの現在のデータベース内容が上書きされます。対象マシンが正常なレプリケーショングループの一部である場合、グループの残りと調整せずにこのマシンのデータを削除すると、レプリケーション状態の不一致を引き起こす可能性があります。複数のマシンが影響を受ける場合は、multi-node disaster recovery 手順を使用してください。

シングルノードの災害復旧

この手順は、レプリケーショングループ内の 1 台のマシンがデータを失ったが、グループ内の他のマシンが正常で、データの正式なコピーを持っている場合に使用します。

この場合、バックアップファイルを使用する必要はありません。壊れたデータベースは単にリセットでき、その後、新しいメンバーとして既存のグループに参加し、レプリケーションが残存マシンからデータを補充します。

1. グループの残りが正常であることを確認します。

   porta_all_group_status

   少なくとも 1 台のマシンが MEMBER_STATE ONLINE かつ MEMBER_ROLE PRIMARY を示している必要があります。もう一方の残存マシンは ONLINE であるはずです。

2. 壊れたマシンでのみ、データベースが少なくとも実行されている場合は（レプリケーションが失敗していても）手動バックアップを取得します。これは、そのマシンにグループの他にないデータがある場合に備えた予防措置です。

   porta_backup_db

3. 壊れたマシンで、そのデータベースをリセットします。

   警告

   porta_reset_db は、このマシンのデータベースコンテナ内のすべてのデータを消去します。復旧対象のマシンでのみ実行してください。

   porta_reset_db

4. コンテナが復帰するまで待ちます。既存のグループに参加し、残存マシンからデータのレプリケーションを開始します。所要時間は転送するデータ量によります。

5. グループを再確認します。

   porta_all_group_status

   復旧したマシンが ONLINE に達したら、復元は完了です。

Multi-node disaster recovery

この手順は、2 台以上のマシンがデータを失った場合、またはサイト全体がダウンし、正式な現行データを保持しているマシンがなくなった場合に使用します。

1. 復元元にしたいバックアップを保持しているマシンを特定します。理想的には、役割に関係なく最新のバックアップを持つマシンです。

2. いずれかのマシンのデータベースコンテナが現在停止している場合は、データにアクセスできるように起動します。レプリケーションの開始は失敗しますが、これは想定どおりです。データベースサービス自体が実行されている必要があるだけです。

   docker start porta-db    # or porta-db-2, porta-db-3 depending on role

3. 起動できる各マシンで、データが疑わしくても手動バックアップを取得します。これは、復旧可能なトランザクションを失わないための予防措置です。

   porta_backup_db

   バックアップはデータベースコンテナではなく porta コンテナに保存されるため、ここでバックアップを取得しても次のステップのリセットには干渉しません。

4. 次のステップがクリーンな状態から始まるよう、各マシンのデータベースコンテナを停止します。各マシンから:

   docker stop porta-db    # or porta-db-2, porta-db-3

5. 目的のバックアップを保持しているマシンで、そのマシンのデータベースをリセットします。

   警告

   porta_reset_db は、このマシンのデータベースコンテナを消去します。/var/www/storage/app/Porta-Backups 内のバックアップ ZIP は、データベースコンテナではなく porta コンテナに存在するため残ります。

   porta_reset_db

6. 同じマシンで、選択したバックアップから復元します。

   porta_restore_db

   プロンプトが表示されたら、ステップ 1 で特定したバックアップを選択します。

7. 復元が完了するまで待ちます。このマシンが正式なプライマリになりました。

8. 他の各マシンで、新しいグループに新規メンバーとして再参加し、復元されたプライマリからレプリケートするよう、データベースをリセットします。

   porta_reset_db

9. 各マシンはグループに参加し、復元されたプライマリからデータのレプリケーションを開始するはずです。次で確認します。

   porta_all_group_status

   すべてのマシンが ONLINE に達したら、復元は完了です。

Unreal Engine を使用したフェイルオーバー復旧

Porta を実行している PX に障害が発生すると、接続された RX 上でレンダリングしている Unreal プロジェクトを、ショーを継続できるようバックアップ PX に向ける必要があります。これは RX デスクトップ上のバッチファイルで制御されます。

マシンの完全障害 — 電源またはネットワークの喪失

メイン PX が完全に電源またはネットワーク接続を失った場合:

1. RX で、デスクトップのバッチファイル make px2 primary.bat を実行して、実行中の Unreal プロジェクトをバックアップ PX に切り替えます。
2. メイン PX を修理する間、バックアップ PX でショーを継続します。
3. メイン PX が復旧したら、RX で make px1 primary.bat を実行して切り戻します。

マシンの部分障害 — サービスまたはパフォーマンスの低下

メイン PX はまだ実行中だが、ソケットサーバーが劣化しているか、パフォーマンスが低下している場合:

1. 障害が発生した PX で、Porta ソケットサーバーを停止します。

   docker stop porta-socket

2. RX で make px2 primary.bat を実行して、実行中の Unreal プロジェクトをバックアップ PX に切り替えます。

3. メイン PX を調査する間、バックアップ PX でショーを継続します。

4. メイン PX が再び正常になったら、ソケットサーバーを再起動します。

   docker start porta-socket

   その後、RX で make px1 primary.bat を実行して切り戻します。