バックアップは問いです。リストアがそれに答えます。

最初の演習は意図的に小さく保つ

この演習では、おもちゃのノートデータベースと1つの添付ファイルを作成し、両方を取得してから、新しいデータベースとディレクトリにリストアします。PostgreSQL 17 サーバーと一致するクライアントユーティリティ、Bash、GNU coreutilsを備えた使い捨ての Linux マシンを使用してください。本番データを含まず、本番アプリケーション、送信メール、スケジュールされたジョブへの接続があってはなりません。この演習で作成したアーカイブのみを使用してください。

コマンドは、事前に構成された非スーパーユーザーのデータベースロールを前提としています。名前は restore_labで、テストデータベースの作成が許可され、同じ名前のOSログインがローカルで認証できる必要があります。PostgreSQLソケットは /var/run/postgresql ポート 5432 にあります。管理者にそのアカウントを使い捨て環境で準備してもらってください。このガイドはデータベースアクセスルールを変更しません。何かを作成する前にエンドポイントを確認してください:

psql -h /var/run/postgresql -p 5432 -U restore_lab -d postgres -c '\conninfo' &&
pg_dump --version &&
pg_restore --version

ホスト、アカウント、バージョンが予想外の場合は中止してください。この最初のドリルでは、クライアントとサーバーを同じメジャーバージョンに保ってください。 pg_dump 自身のメジャーバージョンより新しいサーバーをダンプすることはできず、古いリストアターゲットは一般に互換性が保証されていません。参照: pg_dump のバージョン制限。各ブロックを個別に実行し、エラーが発生したら停止してください。 && ガードは、貼り付けたブロック内の後続コマンドが失敗後に実行されるのを防ぎます。データベースやディレクトリの作成に失敗した後は、決して次のブロックに進まないでください。

レコードとそれに対応するファイルを作成する

名前 offvps_restore_source と offvps_restore_target は未使用でなければなりません。既存のデータベースは、停止して新しい隔離された演習を選ぶ理由であり、それを削除する理由ではありません。新しいファイルシステムワークスペースとソースデータベースを作成します:

umask 077 &&
lab=$(mktemp -d "$PWD/offvps-restore.XXXXXX") &&
mkdir "$lab/source" "$lab/source/uploads" "$lab/bundle" "$lab/restore" &&
createdb -h /var/run/postgresql -p 5432 -U restore_lab \
  --template=template0 offvps_restore_source

新しいワークスペースは、既存のディレクトリへの上書きを避けます。 mktemp は一意のディレクトリを作成し、 createdb は選択したテンプレートから新しいデータベースを作成します。次の2つのマーカーを保存してください:

psql -X -v ON_ERROR_STOP=1 -h /var/run/postgresql -p 5432 \
  -U restore_lab -d offvps_restore_source \
  -c "CREATE TABLE notes (
        id integer PRIMARY KEY,
        body text NOT NULL,
        attachment text NOT NULL
      );
      INSERT INTO notes VALUES (1, 'restore-marker-01', 'marker.txt');" &&
printf '%s\n' 'restore-marker-01' > "$lab/source/uploads/marker.txt"

レコードはどのファイルがノートに属するかを示し、両方に同じマーカーが含まれます。これにより、添付ファイルの欠落や不一致のコピーが可視化されます。 -X 個人の psql 起動設定を回避し、 ON_ERROR_STOP SQLエラーで停止します。参照: psql スクリプトオプション。このおもちゃのデータセットに書き込むアプリケーションはありません。

データベースとファイルを1つのリカバリセットとして取得する

pg_dump -h /var/run/postgresql -p 5432 -U restore_lab \
  --format=custom --file="$lab/bundle/notes.dump" offvps_restore_source &&
cp -a "$lab/source/uploads" "$lab/bundle/uploads" &&
pg_restore --list "$lab/bundle/notes.dump"

カスタム形式アーカイブは次で読み取られます: pg_restore。プレーンなSQLダンプは別のリストア手順に従います。アーカイブを一覧表示すると、期待されるテーブルとデータエントリが存在することを確認できます。一貫したデータベースダンプは、外部アップロードを自動的に同期するものではありません。実際のアプリでは、文書化されたメンテナンスまたは書き込み一時停止手順を使用して、ファイルツリーとデータベースが同じ時点を記述するようにしてください。おもちゃの演習はすでに静穏です。

バンドルの横に、データベースのバージョン、アプリケーションリリース、キャプチャ開始/終了、ファイルパスを記録してください。実際の認証情報は、適切なアクセス制御の下で別途保管してください。データベースごとのダンプはグローバルロールやテーブルスペースをキャプチャしません。実際のリカバリ計画では、それらも考慮する必要があります。範囲は次で説明されています: PostgreSQLのSQLダンプガイド.

既存のものをクリーンアップせずに新しいターゲットにリストアする

createdb -h /var/run/postgresql -p 5432 -U restore_lab \
  --template=template0 offvps_restore_target &&
pg_restore -h /var/run/postgresql -p 5432 -U restore_lab \
  --dbname=offvps_restore_target --no-owner --no-acl \
  --single-transaction "$lab/bundle/notes.dump" &&
mkdir "$lab/restore/uploads" &&
cp -a "$lab/bundle/uploads/." "$lab/restore/uploads/"

ターゲットデータベースは空で作成されます。リストアは意図的に次を省略します: --clean。これは既存のオブジェクトを削除する可能性があります。 --single-transaction により、この小さなデータベースのリストアはユニットとして成功するか、部分的な変更を適用せずに停止します。並列ジョブとは組み合わせられません。 --no-owner と --no-acl このテストロールの所有権を簡素化するため、このドリルはアプリケーションの本番ロールや権限を検証しません。参照: pg_restore.

ファイルコピーは新しいリストアディレクトリを対象とし、ソースはそのまま残します。GNU cp -a はファイル属性の保持を試みます。実際のアプリケーションを実行するアカウントの所有権とアクセスを確認してください。バイトのコピーはアプリケーション権限のテストではありません。参照: cp のアーカイブオプション.

終了コードだけでなく関係を確認する

psql -X -h /var/run/postgresql -p 5432 -U restore_lab \
  -d offvps_restore_target -c "SELECT id, body, attachment FROM notes;" &&
cat "$lab/restore/uploads/marker.txt"

期待される結果は、ID 1、本文 restore-marker-01 および添付ファイル marker.txtを含む1行、および次を含むファイルです: restore-marker-01。ソースに元の行とファイルがまだ含まれていることを確認してください。実際のアプリでは、隔離されたインスタンスをリストアされたデータベースとアップロードディレクトリに向け、代表的なレコードを開き、添付ファイルを取得し、意図されたログイン権限をテストしてください。その間、コールバック、メール、ジョブは封じ込めてください。

証明したことと残っていることを書き留める

上記の期待される出力は演習基準であり、OffVPS によってすでに観察された結果ではありません。最初のドリルはすべてのファイルを1台のマシンに保持するため、そのマシンの損失からの保護は提供しません。実際の計画には、別の障害ドメインにある保護されたコピー、使用可能な復号キー、保持、テスト済みの取得パスが必要です。後のクリーンアップ前に、正確な使い捨てデータベース名とディレクトリを確認してください。本番はそのプロセスの外に保ってください。

重要な変更の後に演習を繰り返し、失敗を成功と同じくらい注意深く記録してください。オプションのバックアップサービスは、アプリケーションのリカバリ時間を証明するものではありません。次に進んでください: スケジュールされたタスクの計画 キャプチャを自動化する準備ができたら、別のリストアドリルは維持したままにしてください。