IBM Bob

バックアップのリストア

データ損失からの復旧、環境の移行、または正常な状態への復元のために、バックアップから IBM Bob PostgreSQL データベースをリストアします。

この手順を使用して、バックアップファイルから IBM Bob および関連 PostgreSQL データベースをリストアします。リストアプロセスには、バックアップの整合性確認、環境の準備、ターゲットデータベースの再作成、バックアップコンテンツのリストア、およびアプリケーションサービスをサービスに戻す前のリストアデータの検証が含まれます。
警告:

データベースをリストアすると、選択したバックアップファイルのデータで既存のデータベースの内容が置き換えられます。アクティブなデータベースへの書き込みはリストアプロセスを破損する可能性があるため、開始前にアプリケーションサービスを停止する必要があります。本番環境での復旧を実行する前に、必ず非本番環境でリストア手順をテストしてください。

始める前に

データベースをリストアする前に、以下を確認してください。

バックアップの整合性を確認する

 
# バックアップ PVC にアクセスします
oc run backup-verify -n <bob-instance-namespace> --image=busybox --rm -it --restart=Never \
  --overrides='{
    "spec": {
      "containers": [{
        "name": "backup-verify",
        "image": "busybox",
        "command": ["sh"],
        "stdin": true,
        "tty": true,
        "volumeMounts": [{
          "name": "backup",
          "mountPath": "/backups"
        }]
      }],
      "volumes": [{
        "name": "backup",
        "persistentVolumeClaim": {
          "claimName": "bob-db-backup-pvc"
        }
      }]
    }
  }'

# Pod 内で実行します:
cd /backups/bob-db
gunzip -t backup_bob_20260902_020000.sql.gz  # gzip 整合性のテスト
cat backup_bob_20260902_020000.sql.gz.meta   # メタデータを確認

バックアップの詳細を確認する
  • バックアップのタイムスタンプが期待するリストアポイントと一致すること。
    •
  • データベース名が正しいこと。
    •
  • バックアップサイズが適切であること。
    •
  • メタデータファイルが存在し、読み取り可能であること。
    •

リストア前のバックアップを作成する

リストアを開始する前に、現在のデータベース状態をバックアップしてください。

 
oc exec -n <bob-instance-namespace> bob-db-1 -- \
  pg_dump -U postgres bob | gzip > pre-restore-backup-$(date +%Y%m%d_%H%M%S).sql.gz

リストア手順

リストア中にデータベースへの書き込みを防ぐために、IBM Bob のすべてのアプリケーションサービスを停止します。

# Bob サービスをスケールダウンします
oc scale deployment bob-admin-service --replicas=0 -n <bob-instance-namespace>
oc scale deployment bob-api-service --replicas=0 -n <bob-instance-namespace>
oc scale deployment bob-ui-service --replicas=0 -n <bob-instance-namespace>

# Pod が終了したことを確認します
oc get pods -n <bob-instance-namespace> -l app.kubernetes.io/name=bob

PostgreSQL データベースとバックアップストレージの両方にアクセスできる一時リストア Pod を作成します。

# PostgreSQL イメージを取得します
POSTGRES_IMAGE=$(oc get cluster bob-db -n <bob-instance-namespace> -o jsonpath='{.spec.imageName}')

# リストア Pod を作成します
oc run postgres-restore -n <bob-instance-namespace> --image=$POSTGRES_IMAGE --rm -it --restart=Never \
  --overrides='{
    "spec": {
      "containers": [{
        "name": "restore",
        "image": "'$POSTGRES_IMAGE'",
        "command": ["bash"],
        "stdin": true,
        "tty": true,
        "env": [
          {"name": "PGHOST", "value": "bob-db-rw"},
          {"name": "PGPORT", "value": "5432"},
          {"name": "PGUSER", "value": "postgres"},
          {"name": "PGPASSWORD", "valueFrom": {"secretKeyRef": {"name": "bob-db-app", "key": "password"}}}
        ],
        "volumeMounts": [{
          "name": "backup",
          "mountPath": "/backups"
        }]
      }],
      "volumes": [{
        "name": "backup",
        "persistentVolumeClaim": {
          "claimName": "bob-db-backup-pvc"
        }
      }]
    }
  }'

リストア Pod 内で、バックアップファイルを確認してデータベース接続をテストします。

# 利用可能なバックアップを一覧表示します
ls -lh /backups/bob-db/

# バックアップファイルを確認します
BACKUP_FILE="/backups/bob-db/backup_bob_20260902_020000.sql.gz"
gunzip -t $BACKUP_FILE
echo "バックアップファイルは有効です"

# メタデータを確認します
cat ${BACKUP_FILE}.meta

# データベース接続をテストします
psql -c "SELECT version();"

ほとんどの復旧シナリオでは、古いデータや競合するデータが削除されるように、空のデータベースにリストアします。

警告:

このステップにより、現在のデータベースの内容が完全に削除されます。

psql -c "DROP DATABASE IF EXISTS bob;"
psql -c "CREATE DATABASE bob;"

バックアップの内容を PostgreSQL にロードしてデータベースをリストアします。

# バックアップを解凍してリストアします
gunzip -c $BACKUP_FILE | psql -d bob

# バックアップのサイズによっては数分かかる場合があります

アプリケーションをサービスに戻す前に、リストアが正常に完了したことを確認します。

# リストアされたデータベースに接続します
psql -d bob

# テーブルが存在することを確認します
\dt

# 主要テーブルの行数を確認します
SELECT COUNT(*) FROM users;
SELECT COUNT(*) FROM projects;
SELECT COUNT(*) FROM conversations;

# 最新のデータを確認します
SELECT * FROM users ORDER BY created_at DESC LIMIT 10;

# psql を終了します
\q

データベースの検証が正常に完了したら、IBM Bob サービスを再起動してリストアされたデータベースへの再接続を許可します。アプリケーションの起動ログでエラーや移行失敗がないか監視してください。

# リストア Pod を終了します
exit

# Bob サービスをスケールアップします
oc scale deployment bob-admin-service --replicas=1 -n <bob-instance-namespace>
oc scale deployment bob-api-service --replicas=3 -n <bob-instance-namespace>
oc scale deployment bob-ui-service --replicas=2 -n <bob-instance-namespace>

# Pod が実行中であることを確認します
oc get pods -n <bob-instance-namespace> -l app.kubernetes.io/name=bob

# アプリケーションログを確認します
oc logs -n <bob-instance-namespace> -l app.kubernetes.io/name=bob --tail=50

ユーザーの再接続を許可する前に、エンドツーエンドのアプリケーション検証を完了します。

# アプリケーションエンドポイントをテストします
curl -k https://bob.example.com/health

# ユーザーログインが機能することを確認します
# データアクセスが機能することを確認します
# 主要機能が機能することを確認します

検証に成功すると、リストアプロセスが完了したことを示します。

ベストプラクティス

  • 最初は必ず非本番環境でテストしてください。
    •
  • 開始前に現在のデータベース状態のリストア前バックアップを作成してください。
    •
  • 開始前にバックアップの整合性を確認してください。
    •
  • ダウンタイムを計画してユーザーに通知してください。
    •
  • リストアプロセスと結果を文書化してください。
    •
  • リストア後のデータ整合性を確認してください。
    •
  • リストア後はアプリケーションを注意深く監視してください。
    •

よくあるリストアの問題

問題原因解決策
ストレージ不足リストア操作に必要なディスクスペースが不足していますリストア前に PVC を拡張するかストレージスペースを解放してください。
接続タイムアウトネットワーク接続の問題またはデータベースの可用性の問題データベースの接続性を確認し、必要に応じてタイムアウト値を増やしてください。
アクセス権限エラーリストアユーザーに必要なデータベース権限がありませんリストア操作を実行する前にリストアユーザーに必要な権限を付与してください。
このトピックはいかがですか？

このページ

始める前にリストア手順ベストプラクティスよくあるリストアの問題