はじめに
小さな店舗は注文サービスで顧客、商品、数量を関連付けています。準備されたインシデントの後、2 件の注文が失われました。無関係な公開カタログを置き換えず、必要なデータを復旧してください。人物と記録はすべて合成データで、マルウェアはありません。
バックアップは復旧用のコピーです。アーカイブはファイルをまとめ、チェックサムはそのバイト列を要約します。信頼できる参照値がある場合にだけチェックサムが役立つ理由を学び、一時配置領域を使って実際の SQLite データベースを復元します。これは限定的な復旧演習であり、完全なインシデント対応手順ではありません。
必要なのは基本的なコマンド入力とタブ切り替えだけです。Workstation と App Server は、開始ディレクトリが異なる同じ訓練ホスト上の別セッションで、別のマシンではありません。ブラウザー表示には Order Service を使います。
損傷したサービスデータを保存する
このステップでは、欠けた業務データを理解し、サービスを変更する前にロールバック用コピーを保存します。
Order Service を開きます。通常、各行は注文番号と顧客、状態、商品、数量を結び付けます。必要な復旧時点には次の 3 件があります。
| 注文 | 顧客 | 状態 | 商品 | 数量 |
|---|---|---|---|---|
| 4101 | Mina | packed | notebook | 1 |
| 4102 | Jon | packed | notebook | 2 |
| 4103 | Asha | packed | notebook | 3 |
現在は 4101 だけです。Public catalog をクリックすると、マグカップ、ノート、トートバッグが引き続き表示されるはずです。このアップロードはデータベースと無関係で、復旧後も残す必要があります。その後、注文ページに戻ります。
API はプログラムが使うサービスの窓口です。Workstation で curl が API に要求します。-f はサーバーエラーを失敗とし、-s は進捗を隠し、-S はエラーを引き続き表示します。127.0.0.1 はこの訓練ホスト自身、8080 はサービスポートです。
curl -fsS http://127.0.0.1:8080/api/orders
結果は JSON 配列、つまり角括弧で囲まれた行の一覧です。Mina の行しかありません。要求成功は業務データの完全性を意味しません。
App Server に切り替えます。pwd は現在のディレクトリを表示します。
pwd
/srv/order-service が表示されます。SQLite はアプリのテーブルを orders.db に保存します。この準備済みサービスには書き込み処理がなく、要求ごとにデータベースを開き直すため、ここでは安全にコピーできます。稼働中の本番データベースには、アプリと整合性を保つバックアップ手順が必要です。
cp はコピー元、コピー先の順に指定します。誤った復元を取り消せるよう、現在のデータベースをアプリのディレクトリ外に保存します。
cp /srv/order-service/orders.db /home/labex/project/recovery/damaged-before-recovery.db
通常、出力がなければコピーは完了しています。復旧後にこのコマンドを繰り返さないでください。復旧済みデータベースでロールバック用コピーを上書きしてしまいます。損傷状態は保存できましたが、サービスはまだ復旧していません。
信頼できる復旧アーカイブを選ぶ
このステップでは、変更されたバックアップを除外し、検証済みで適切なアーカイブを一時配置ディレクトリへ置きます。
Workstation に切り替えます。cd はディレクトリを移動し、ls は内容を一覧表示します。絶対パスは / で始まり、現在のディレクトリに左右されません。
cd /home/labex/project/recovery/backups
ls
3 つの .tar.gz アーカイブがあります。tar がファイルをまとめ、gzip が圧縮します。名前は復旧時刻を表しますが、最新のものが安全で適切とは限りません。
cat はテキストファイルを表示します。バックアップ管理者から独立して提供された復旧時点を読みます。
cat /opt/backup-custodian/recovery-points.txt
0800 は注文 4102 と 4103 より前です。0900 は必要な復旧時点を含みます。1000 は後ですが、完全性の確認が必要です。
完全性とは、参照値に対してバイト列が変わっていないことです。SHA-256 は比較値であるダイジェストを生成します。管理者のマニフェストは root 所有で、通常編集できる復旧フォルダーの外にあります。独立した保護経路で届いたことを前提とし、署名や鍵配布は教えません。管理者権限はローカル所有権を越えられるため、この訓練ホストを改ざん不能な信頼の基点と考えないでください。
sha256sum -c はファイル名とダイジェストの組を読み、現在のディレクトリのファイルを比較します。独立したマニフェストを使います。
sha256sum -c /opt/backup-custodian/SHA256SUMS
0800 と 0900 は OK、1000 は FAILED と表示されます。非ゼロ終了と警告は想定内です。少なくとも 1 つが変更されています。その候補を展開しないでください。
隣のマニフェストはバックアップと一緒に編集できます。結果を比較します。
sha256sum -c SHA256SUMS
3 つとも OK です。アーカイブを書き換えられる人は隣のチェックサムも置き換えられます。信頼できないダイジェストとの一致は真正性を証明しません。古い 0800 は未変更ですが必要な記録がありません。未変更で要件も満たす 0900 を選びます。
一時配置により、稼働サービスに触れる前に復旧データを調べられます。mkdir -p はディレクトリを作り、既に存在していても使えます。
mkdir -p /home/labex/project/recovery/stage
検証済み候補をコピーします。
cp orders-0900.tar.gz /home/labex/project/recovery/stage/orders-0900.tar.gz
コピー元を誤入力すると cp はファイルが見つからないと報告します。ls で確認して再試行します。評価するのは配置された実際のバイト列であり、検証したという文章ではありません。
一時配置したデータベースを調べる
このステップでは、アーカイブのメンバーを調べ、想定する 1 ファイルだけを展開し、変更せずにデータベースを読みます。
Workstation で一時配置領域へ移動します。
cd /home/labex/project/recovery/stage
tar -tvzf は gzip アーカイブを一覧表示します。t は一覧、v は種類と権限、z は gzip、f はアーカイブ指定です。一覧表示だけでは展開されません。
tar -tvzf orders-0900.tar.gz
メンバーは orders.db だけで、権限欄が通常ファイルを表す - で始まるはずです。絶対パス、.. のパス要素、リンク、想定外のファイルがあれば停止します。信頼できる訓練アーカイブが通常ファイル 1 つだけなので、この検査が役立ちます。任意のアーカイブ向けの完全な安全展開方針ではありません。不審なバックアップ内のプログラムは実行しないでください。
展開には t の代わりに x を使い、詳細表示の v は省きます。末尾の orders.db は対象をこのメンバーに限定し、--no-same-owner は自分の所有権を保ちます。
tar -xzf orders-0900.tar.gz --no-same-owner orders.db
SQLite は関連するテーブルを 1 ファイルに保存します。用意された db-view は読み取り専用で開き、内部整合性と関連付けを検査して、結合した業務行を表示します。SQL を書いたり編集したりする必要はありません。一時配置ファイルのパスを渡します。
/opt/c11-runtime/db-view /home/labex/project/recovery/stage/orders.db
Integrity: ok、Relationships: ok に続き、必要な 3 件が表示されます。有効なデータベースでも復旧時点が違う可能性があるため、顧客、状態、数量もステップ 1 と比べます。
パスが誤っている場合は空のデータベースを作らず、エラーになります。pwd と ls を確認して再試行します。データが違えば、独立したマニフェストへ戻り、正しいアーカイブを選んでから再展開します。稼働サイトはまだ損傷しています。一時配置だけではアプリは復旧しません。
稼働サービスを復旧してテストする
このステップでは、指定データベースだけを置き換え、公開ファイルを保ちながら実際の要求で復旧を確認します。
App Server に切り替えます。ロールバック用コピーはこのディレクトリの外にあり、一時配置したデータベースも検査済みです。そのデータベースだけを指定データパスへコピーします。
cp /home/labex/project/recovery/stage/orders.db /srv/order-service/orders.db
コピー元とコピー先は別ファイルです。無関係なアップロードを保つ必要があるため、一時配置ディレクトリ全体を /srv/order-service に上書きしないでください。この準備済み読み取り専用アプリは要求後にデータベースを閉じるので、デーモンの再起動は不要です。他のアプリでは所定の保守や再起動が必要な場合があります。
バックアップや restored テキストファイルの存在に頼らず、アプリへ問い合わせます。
curl -fsS http://127.0.0.1:8080/api/orders
4101、4102、4103 が正しい顧客、packed 状態、数量 1、2、3 で返ります。Order Service を開いて更新すると、同じ記録が表に表示されるはずです。
無関係な公開ファイルも確認します。
curl -fsS http://127.0.0.1:8080/uploads/catalog.txt
Public catalog: mugs, notebooks, tote bags
ブラウザーで Public catalog をクリックし、同じ内容を確認します。復旧とは、必要な業務データが戻り、無関係な正常動作も続くことです。
Database unavailable が表示されたら、一時配置データベースを再確認し、正しい絶対パスで単一ファイルを再コピーします。誤りを調べる間、元の損傷状態へ戻すには保存したコピーを使えます。
cp /home/labex/project/recovery/damaged-before-recovery.db /srv/order-service/orders.db
最後のコマンドは意図的に復旧を取り消します。使った場合は、完了前に検証済みの一時配置データベースを稼働パスへ再コピーしてください。ロールバック用ファイルは後の調査用に残します。
まとめ
ロールバック用コピーを保存し、独立した信頼できるマニフェストとバックアップのバイト列を比較し、適切な復旧時点を選んで SQLite データベースを一時配置で調べました。その後、実際のサービスを復旧し、関連付けと無関係な公開ファイルを確認しました。最新、未変更、適切は別の性質です。安全な復旧には正しい組み合わせが必要です。
