元の店舗の隣に復元した店舗を開く

はじめに

PAPER & FORM には4件の注文がありますが、保存済みバックアップは R-103 までです。その以前の状態を元の店舗の隣で開き、注文明細を調べ、復元サービスが独立して新しいテスト注文を受け付けることを証明します。

このラボは独立して始まります。元のデータベースと backups/cutoff.dump は、前のガイドと同じ3件の注文の復元点を含む状態で準備されています。基本的なターミナル操作が必要で、データベースと接続の概念は改めて説明します。コマンドは Workstation、元のサービスは Original Shop、テスト先は Restored Copy を使います。

復元、リセットしてよいのは破棄可能な shop_copy データベースだけです。ソース、提供プログラム、バックアップ、無関係な uploads/ ファイルを保ってください。データはすべて架空で、決済やメール操作はありません。1つの訓練インスタンスの2つのデータベースは論理エクスポートと分離を示すもので、完全な災害復旧、ハードウェア冗長化、PITR ではありません。

独立した空のターゲットだけに復元する

このステップでは、区切り時点の注文の動くコピーを開きます。まず Original Shop の Orders を開きます。R-101 から R-104 まで4件あります。R-103 は Rae の Print pair 2点で合計 $36.00 です。R-104 は Sol の注文で、保存時点の後に追加されました。元の店舗には残し、復元アーカイブには含めないでください。

Restored Copy を開きます。さび色の帯に shop_copy と表示されます。ホームページは利用できますが、Orders には独立データベースが空だと表示されます。ホームページの応答だけでは店舗の復元を証明できません。

Workstation に切り替えます。pwd で現在のディレクトリを表示します。

pwd

/home/labex/project/shop-backup

./shopctl identity は実際の接続を読みます。保存サービスはデータベース、ホスト、ポート、アカウントを指定します。shop-source は読み取り専用 d09_reader で shop_source に、shop-copy は書き込み可能な d09_copy で shop_copy に接続します。同じ 127.0.0.1:5432 のサーバーですが、コピーロールはソースには接続できません。

./shopctl identity

pg_restore --list はデータベースに書かずカスタムアーカイブを読みます。ソース名と orders、order_items の項目を確認してください。

pg_restore --list backups/cutoff.dump

データベースは構造化レコードを保存し、商品明細行は親の注文に結び付きます。カスタム形式アーカイブには定義、データ、新規番号用シーケンス、関連を維持する制約が含まれます。バイナリを psql に渡すのではなく、pg_restore で復元します。準備済みのダンプと復元クライアントはどちらも PostgreSQL 14 です。

ヘルパーの empty は実際のターゲットを表示し、ユーザーテーブルやシーケンスがあるデータベースを拒否します。空でない先には残すべき作業があるかもしれません。--clean や --create は使わないでください。既存オブジェクトを削除したり、アーカイブの元のデータベース名を使ったりする場合があります。

次のコマンドの && は空チェックに成功した場合だけ右側を実行します。--dbname=service=shop-copy が独立ターゲットを明示します。--no-owner --no-privileges は元のアカウントや権限の導入を避けます。--single-transaction はインポートを1つの単位にし、失敗時にロールバックします。--exit-on-error は最初のデータベースエラーで停止します。ガード付きコマンド全体を実行してください。

./shopctl empty && pg_restore --dbname=service=shop-copy --no-owner --no-privileges --single-transaction --exit-on-error backups/cutoff.dump

ターゲット情報の後に EMPTY: restore may proceed が表示されます。成功した pg_restore は通常何も出力しません。再試行で REFUSED: target is not empty が出た場合、最初のインポートが成功済みかもしれません。リセットする前にコピーを調べてください。

records copy は実際に関連付けられた注文と商品明細を読みます。

./shopctl records copy

R-101、R-102、R-103 があり、合計 $98.00、R-104 はないはずです。Restored Copy で Orders、R-103、領収書を開き、Print pair 2点と $36.00 を確認します。Original Shop にも戻り、Sol の R-104 が残り、全注文の合計が $124.00 のままか確認してください。

間違ったアーカイブを使った場合や失敗を再試行する場合、リセットするのは本コースの破棄可能な先だけです。ヘルパーは接続先を表示し、正確な名前を求めます。次は任意の回復コマンドで、成功後に毎回実行するものではありません。

./shopctl reset-copy shop_copy

破棄するのは shop_copy だけです。その後ガード付き復元を繰り返します。元の店舗をリセット、削除したり、広範囲なデータベース削除コマンドを使ったりしないでください。チェックは実際のコピーを観察するだけで、代わりに復元はしません。

元の店舗を変えずコピーに書き込めると証明する

このステップではコピーに実際に書き込みます。読み取り表示が正しくても、復元したシーケンス、関連、書き込み接続が壊れている可能性があります。独立コピーで本当のテスト注文を作り、2つの店舗を比較します。Restored Copy の Collection を開き、フォームへ進みます。送信前に Writing to: shop_copy · RESTORED COPY とさび色の帯を読みます。Original Shop ではこのテストを送信しないでください。

値を正確に入力します。

Place order ↗ を選びます。R-901 は商品1点、合計 $18.00 です。領収書をダウンロードし、shop_copy とあることを確認します。新しい注文は復元したシーケンスと外部キー関連を使います。事前作成のページを置いたわけではありません。同じ番号の再送信は Already recorded となり、重複注文は作りません。

同じコピーで Orders を開きます。R-101、R-102、R-103、R-901 があり、R-104 はないはずです。Original Shop の Orders には R-101 から R-104 が残り、R-901 はありません。両アプリが同じデータベースに書くなら、帯の違いだけでは不十分です。

Workstation に切り替え、両方の接続情報と実際のデータを読みます。

./shopctl identity

./shopctl records copy

./shopctl records source

コピーは合計 $116.00、ソースは $124.00 のままです。すべての行が永遠に同じであると比較するのは誤りです。R-104 は後続のソースだけに、R-901 は復元コピーだけに属します。共有する区切りレコードと、各側で許される違いを比較してください。

元のフォームは R-901 を書き込まず拒否します。タブを間違えた場合は Check the destination を読み、Restored Copy に切り替えて送信してください。未知の番号も拒否されるので、フォームを直して再試行します。既存 R-901 の名前、商品、数量を間違えた場合は ./shopctl correct copy R-901 が実際のターゲットを表示し、このテストだけを Copy test / Print pair / 1 に修正します。他のコピー注文とソースの全データは保たれます。破棄可能コピーだけを最初からやり直す場合は、ステップ1の正確な reset-copy shop_copy を使って再復元し、テストを1回だけ追加してください。

最終チェックは両方の稼働データベースとサイトを読み、無関係なアップロードを保ち、別の破棄可能データベースでアーカイブを試します。テスト注文の作成や稼働コピーの修理は代行しません。これで完全なデータ、明確な区切り、独立した書き込み可能な復元の証拠がそろいました。

まとめ

実際のソースとターゲットを識別し、空の宛先を確認して、カスタムアーカイブをトランザクションで復元し、完全な注文明細を読みました。コピーだけの新規注文が、独立して書き込めるサービスを証明し、元の店舗は後続注文を保ちました。この演習は論理復元の実証で、完全な本番復旧戦略ではありません。