0Pricing
SQL Academy · レッスン

復元をテストする

復元できないバックアップは役に立ちません

「復元をテストする」はCoddyKit上の無料SQL Academyレッスンです。 これはレッスン3/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはSQL Academy学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 SQL Academyコースには全4レッスンが含まれています。

復元できないバックアップには価値がない

多くのチームは自動バックアップの設定に時間をかけますが、そのバックアップを実際にデータのリカバリに使えるかどうかを確認していません。リストア時に失敗するバックアップは、バックアップとして役に立ちません。

このレッスンでは、リストアテストの実践方法を説明します。実際の災害に直面して手遅れになる前に、バックアップが機能することを確認する方法を学びます。

リストアテストでは何を行うのか

リストアテストでは、バックアップファイルを取得してデータベース（通常は別のテストインスタンス）に読み込み、そのデータベースにクエリを実行してデータが完全かつ一貫していることを確認します。

手順は次のとおりです。1) バックアップファイルを取得します。2) サンドボックス環境にリストアします。3) 検証クエリを実行します。4) 本番環境と結果を比較します。

比較用の基準スナップショットを作成する

リストアを検証するには、まず基準が必要です。つまり、復元したコピーと比較できる、本番環境の既知の件数とチェックサムを用意します。

本番データベースで次の処理を実行し、結果を記録します。

SELECT
  'orders'        AS tbl, COUNT(*) AS row_count FROM orders
UNION ALL
SELECT
  'customers'     AS tbl, COUNT(*) AS row_count FROM customers
UNION ALL
SELECT
  'order_items'   AS tbl, COUNT(*) AS row_count FROM order_items;

リストア後の行数を検証する

バックアップをテストデータベースにリストアしたら、同じクエリを実行して数値を比較します。件数が一致すれば、リストアの基本的な構造は正常です。

ここで不一致があれば、本番環境に触れる前に、バックアップまたはリストアの過程でデータが失われたことがすぐにわかります。

-- Run on the RESTORED test database
SELECT
  'orders'        AS tbl, COUNT(*) AS row_count FROM orders
UNION ALL
SELECT
  'customers'     AS tbl, COUNT(*) AS row_count FROM customers
UNION ALL
SELECT
  'order_items'   AS tbl, COUNT(*) AS row_count FROM order_items;

最新データを確認する

行数で確認できるのは量であり、データの新しさではありません。復元したデータベースに最近のレコードが含まれていることを確認してください。バックアップには、取得した時点までのデータが反映されているはずです。

SELECT
  MAX(created_at) AS latest_order,
  MIN(created_at) AS oldest_order,
  COUNT(*)        AS total_orders
FROM orders;

参照整合性を検証する

行数が一致していても、リストアによって孤立行が残ることがあります。これは、親が存在しなくなった子レコードです。バックアップまたはリストア中に外部キーが適用されていない場合に、この問題がよく発生します。

孤立した注文明細を検出するには、LEFT JOINを使用します。

SELECT
  oi.id       AS orphaned_item_id,
  oi.order_id AS missing_order_id
FROM order_items oi
LEFT JOIN orders o ON o.id = oi.order_id
WHERE o.id IS NULL;

チェックサムで破損を検出する

重要なテーブルでは、データのチェックサムを生成してビットレベルの破損を検出します。PostgreSQLでは、行全体をキャストした値とMD5を組み合わせることができます。

本番環境と復元したコピーのチェックサムが異なる場合、どこかの時点でデータが変更または破損しています。

SELECT
  MD5(string_agg(row_data, ',' ORDER BY row_data)) AS table_checksum
FROM (
  SELECT CAST(ROW(id, customer_id, total, created_at) AS TEXT) AS row_data
  FROM orders
) sub;

リストア検証テーブルを作成する

リストアテストの履歴を追跡するには、専用の検証ログテーブルを作成します。各テストの実行について、バックアップ日、復元後の行数、検証の合否を記録します。

CREATE TABLE IF NOT EXISTS restore_validation_log (
  id             SERIAL PRIMARY KEY,
  backup_taken_at TIMESTAMP NOT NULL,
  restored_at    TIMESTAMP NOT NULL DEFAULT NOW(),
  table_name     VARCHAR(100) NOT NULL,
  expected_rows  INT NOT NULL,
  actual_rows    INT NOT NULL,
  passed         BOOLEAN NOT NULL
);

検証結果を挿入する

リストアテストのたびに、検証ログへ1行を挿入します。これにより、バックアップをテストしたことを証明する監査証跡が得られ、時間の経過に伴う合格または不合格の傾向も確認できます。

INSERT INTO restore_validation_log
  (backup_taken_at, table_name, expected_rows, actual_rows, passed)
VALUES
  ('2024-06-09 02:00:00', 'orders',      15482, 15482, TRUE),
  ('2024-06-09 02:00:00', 'customers',    8201,  8201,  TRUE),
  ('2024-06-09 02:00:00', 'order_items', 47310, 47310, TRUE);

検証履歴をクエリする

リグレッションを見つけるために、検証ログを定期的に確認します。先週は合格したバックアップが今週は失敗した場合、バックアップパイプラインに問題があることを示しているため、直ちに調査する必要があります。

SELECT
  backup_taken_at,
  table_name,
  expected_rows,
  actual_rows,
  passed,
  CASE
    WHEN passed THEN 'OK'
    ELSE 'MISMATCH - investigate!'
  END AS status
FROM restore_validation_log
ORDER BY backup_taken_at DESC, table_name;

ポイントインタイムリカバリの検証

最新のデータベースはポイントインタイムリカバリ（PITR）に対応しており、ベースバックアップとWAL（Write-Ahead Log）アーカイブを使って、任意の時点にリストアできます。

PITRが機能していることを検証するには、既知のタイムスタンプにリストアし、そのタイムスタンプより後に作成されたレコードが復元したデータベースに表示されないことを確認します。

-- After a PITR restore to '2024-06-09 03:00:00',
-- this order (created at 03:45) should NOT exist:
SELECT id, created_at, total
FROM orders
WHERE created_at > '2024-06-09 03:00:00'
ORDER BY created_at
LIMIT 5;
-- Zero rows = PITR worked correctly

理解度チェック

バックアップのリストア後に孤立した子レコードを検出するには、次のクエリのうちどれが最も役立ちますか。

レッスンのまとめ：リストアのテスト

このレッスンでは、リストアテストがあらゆるバックアップ戦略に不可欠である理由と、SQLを使った実装方法を学びました。

  • 基準スナップショット — テスト前に本番環境の行数を記録します。
  • 行数の比較 — 復元したデータベースで同じクエリを実行し、比較します。
  • 新しさの確認 — 最新のレコードが、想定されるバックアップ期間と一致することを確認します。
  • 参照整合性 — LEFT JOINを使って孤立した子行を見つけます。
  • チェックサム検証 — MD5集約によってビットレベルの破損を検出します。
  • 検証ログテーブル — 監査可能な履歴として、すべてのテスト実行を追跡します。
  • PITR検証 — ポイントインタイムリカバリが正しい時点に到達することを確認します。

バックアップの品質は、最後に成功したリストアテストで決まります。これらのチェックを定期的にスケジュールし、失敗は重大なインシデントとして扱ってください。

よくある質問

「復元をテストする」レッスンは無料ですか？

はい。「復元をテストする」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、SQL Academyコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 SQL Academyコースには全4レッスンが含まれています。

「復元をテストする」で何を学びますか？

復元できないバックアップは役に立ちません ブラウザで直接実行するハンズオンコードでSQL Academyを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

SQL Academyを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのSQL Academyは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン3/4です。

「復元をテストする」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このSQL Academyレッスンでコードを書いて実行できますか？

はい。すべてのSQL Academyレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. 論理バックアップと物理バックアップ
  2. ポイントインタイムリカバリ
  3. 復元をテストする
  4. ディザスタリカバリ計画
← SQL Academyに戻る