ADVANCED · 発展COURSE 09 · BANKING ENGINEERING

銀行エンジニアリング Lab 10：Recovery Lab（バックアップ → 障害 → 復元 → 検証 → 再開）

ローカルの使い捨てDBで、バックアップから復元して再開するまでを通します。失われた取引、古い側の書込み、復元で戻る同意の失効を、自分で確かめます。

43 / 55

BANKING ENGINEERING · 銀行エンジニアリング

v8以降に実装した台帳・記帳エンジンなどを実際に動かし、正常時と異常時の両方から銀行システムの構造を学ぶ。

Prerequisite: BANKING SYSTEM

LEARNING GOALS

このページで学ぶこと

復旧演習の実行と測定値の読み方
書込停止中の顧客操作の見え方
検証が NG のときの判断

PLAIN LANGUAGE

まず、ここだけつかむ

ローカルの使い捨てDBで、バックアップから復元して再開するまでを通します。

書込停止中の顧客操作、検証のNG、二者確認、旧世代の書込みの拒否を、自分で確かめます。

測定値は、条件と一緒に読みます。

DIFFICULT PARTS, STEP BY STEP

難しいポイントを、順番にほどく

専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。

演習の記録

やさしく言うと

いつ、何を、どの条件で測ったかの記録です。

なぜ必要？

数字だけが独り歩きしないようにするためです。

Minibankでは

recovery.drills。追記専用。

事後検証

やさしく言うと

何が起き、なぜ起き、何を直すかの記録です。

なぜ必要？

責めるためでなく、次に活かすためです。

Minibankでは

recovery.postmortems。

技術的な下限

やさしく言うと

人の待ち時間を除いた、最短の時間です。

なぜ必要？

演習の時間を、そのまま本番の目標にしないためです。

Minibankでは

演習の RTO は、人の待ち時間を0として測る。

準備

演習はローカルの loopback のPostgreSQLに、使い捨てのDBを3つ作って行います。実在のDB、Hosted、Productionには触れません。

node scripts/dr/drill.mjs --out /tmp/drill.json

演習

演習	操作	観察すること
1. 結果を読む	出力の scenarios と conditions を見る	A〜G の合否、RTO と RPO の測定値と、その条件（機械・データ量・人の待ち時間は0）
2. 書込停止	管理画面『復旧・DR』で書込停止を実行	顧客の振込・預入は『復旧作業中』で断られる。読取りは続く。運用センターの Recovery が赤になる
3. 検証	照合を始め、manifest を取り、検証する	最新の検証が OK になるまで提出できない（RY004）。データを1件ずらすと、どの項目が NG になるか
4. 二者確認	提出した人で再開を試す	RY005 で断られる。別の管理責任者が再開すると、書込世代が1つ上がる
5. 旧 writer	書込世代の検査を有効にし、古い世代で書く	RY002 で断られる
6. 同意の失効	復元を経た再開のあと、以前のトークンで API を呼ぶ	OB010。外部のアプリは、顧客の新しい同意が必要
7. 古いバックアップ	古い dump から復元し、その中で manifest を取って検証する（シナリオ G）	manifest の比較が NG（外に控えた digest と食い違う）。他の項目が OK でも提出できない（RY004）
8. group だけが失われた古いバックアップ	バックアップのあとにグループの操作だけが行われ、その dump を復元する（シナリオ H）	旧方式（版 1）の digest は見逃すが、現行の方式は食い違い、MANIFEST が NG になる。提出できない（RY004）
9. 権限が増えた運用者	運用者の一覧を外に控えて復元を宣言し、復元後に、一覧では無効の人を有効に戻して検証する	EXTERNAL_OPERATORS が NG（権限が増えている人がいる。escalations に出る）。無効化すると OK に戻る（降格は書込停止中は RY001 で止まる。管理責任者の無効化は、その人を除いて有効な管理責任者が 2 人以上残る場合だけで、そうでなければ RY003。その場合は復元をやり直す＝abort_restore）。一覧にない人は NG にならず、人数だけが unlisted_active に出る。一覧を渡さずに宣言すると『検査せず』になる

振り返り

RPO の内側の取引を、なぜ同じ冪等キーで再送すると二重にならないか
書込停止と、営業日のゲートを同じ仕組みにした利点は何か
復元で戻るのは同意だけではない。運用者の権限は、外に控えた一覧を宣言で渡せば検証が見つける（一覧を渡さなければ検査は走らず、『検査せず』と出る）。digest に入らない状態（たとえば AML のケース・調査・通知、口座の凍結など）は、DB が見つけてくれないので、再開の前に人が確認する必要がある

CHECK YOUR UNDERSTANDING

3問で理解チェック

答えを頭の中で考えてから、各項目を開いて確認してください。

Q1演習で測った RTO は、本番の目標にできますか？

答え

できません。人の待ち時間などを含めて、本番の手順で測り直します。

Q2検証で NG のまま再開できますか？

答え

できません。提出の時点で断られます。

Q3演習は実在のDBに影響しますか？

答え

しません。使い捨てのローカルDBだけを使います。

ここまで読めましたか？

完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。

SOURCE TRAIL

根拠と関連教材

CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。

確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。

Implementation Status: IMPLEMENTED IN MINIBANK（この教材が扱うコードの範囲）

RELATED LESSON/docs/be-dr-writer-fencing書込停止・旧 writer・RTO と RPO
RELATED LESSON/docs/be-dr-restore-verify復元と検証
CURRENT IMPLEMENTATIONscripts/dr/drill.mjsローカルの復旧演習：バックアップ・障害・復元・冪等な再送・旧 writer の遮断・切戻しを実行して測定
CURRENT IMPLEMENTATIONsrc/app/admin/(protected)/recovery/page.tsxRecoveryPage()管理画面復旧・DR（表示は RecoveryAdminView）
CURRENT IMPLEMENTATIONscripts/banking/v17-recovery.test.mjs状態機械・書込停止・書込世代・manifest と検証・トークン失効・訂正・演習記録のDBテスト