Amazon Web Services ブログ
バックアップ用オンプレミス Db2 サーバーを Amazon RDS for Db2 と同期する
本記事は 2026 年 3 月 19 日 に公開された「Synchronizing a Backup on-premises Db2 Server with Amazon RDS for Db2」を翻訳したものです。
Amazon Relational Database Service (Amazon RDS) for Db2 は、プロビジョニング、パッチ適用、バックアップ、スケーリングといった手間のかかる作業を自動化し、リレーショナルデータベースの管理をシンプルにするフルマネージドサービスです。運用効率を高め、マルチ AZ 配置による高可用性を実現し、セキュリティを強化します。そのうえでインフラの保守ではなくアプリケーション開発に集中できます。
本記事では、セルフマネージドの Db2 インスタンスをアーカイブログの継続的な適用によって Amazon RDS for Db2 と同期させ続けるハイブリッドアーキテクチャの構築方法を説明します。これにより、クラウドネイティブなマネージドサービスの利点を損なうことなく、戦略的な配置の選択肢を維持できます。
ソリューションの概要
本ソリューションは、Amazon RDS for Db2 と同期を維持するオプションのセルフマネージド Db2 緊急バックアップサーバーを構築するハイブリッド構成です。基本的な仕組みとしては、Amazon RDS for Db2 インスタンスがアーカイブログを Amazon Simple Storage Service (Amazon S3) バケットにレプリケートし、セルフマネージドのオンプレミス Db2 インスタンスがそのアーカイブログを適用し続けます。先回りで同期を続けることで、バックアップがリアルタイムで最新の状態に保たれ、予期しない障害が発生した際にすぐに稼働させられます。
ソリューションは 3 つのステージで構成されます。
ステージ 1: Amazon RDS for Db2 でデータベースを構築する
- Amazon RDS for Db2 にデータベースをリストアする
- 緊急用セルフマネージドバックアップサーバーにデータベースをリストアする
- Amazon RDS for Db2 にアーカイブログを適用し続ける
- 緊急用セルフマネージドバックアップサーバーにアーカイブログを適用し続ける

ステージ 2: Amazon RDS for Db2 へ移行する
- 最後のロールフォワードログを適用し、ロールフォワード処理を完了する
- RDS for Db2 に接続できるようになる
- アプリケーションの接続先を Amazon RDS for Db2 に切り替える
- 従来のセルフマネージド Db2 サーバーを停止するか、別の用途に転用する
ステージ 3: Amazon RDS for Db2 との継続的なバックアップ同期を確立する
- 緊急バックアップサーバーをアーカイブログと同期させ続ける
- 緊急バックアップサーバーを常にロールフォワード保留モードに保つ
- オプション: セルフマネージドサーバーへ切り戻す状況が生じた場合は、最後のログを適用してロールフォワード操作を完了し、データベースに接続できるようにする

前提条件
RDS for Db2 のアーカイブログを Amazon S3 にコピーできるのは、データベース作成時にバックアップ期間が設定されている場合のみです。アーカイブログを生成するには、バックアップ保持期間を有効にする必要があります。
注: your-db-instance-identifier と日数 (有効な値は 1 ~ 35 日) を指定してください。
以降のセクションでは、RDS for Db2 のアーカイブログファイルを Amazon S3 バケットにコピーする手順を説明します。
Amazon S3 へのアーカイブログコピーを設定する前に、以下を用意してください。
- 稼働中の Amazon RDS for Db2 インスタンス
- バックアップとアーカイブログを保存する Amazon S3 バケット
- Amazon S3 統合に適した AWS Identity and Access Management (IAM) 権限 (次のセクションで詳しく説明します)
- 互換性のある Db2 バージョンで稼働するセルフマネージド Db2 インスタンス (Amazon EC2、他のクラウドプロバイダー、またはオンプレミス上)
- Amazon S3 からセルフマネージド Db2 サーバーへファイルをダウンロードするためのネットワーク接続
Amazon S3 統合と権限を設定する
Amazon RDS for Db2 が S3 バケットにアーカイブログをコピーできるようにするには、適切な IAM 権限を設定する必要があります。この手順は、標準的な Amazon RDS for Db2 の Amazon S3 統合と同様です。
以下の手順を実行します。
- Amazon RDS for Db2 に S3 バケットへのアクセスを許可する IAM ポリシーを作成します。
注: <amzn-s3-demo-bucket> を実際の S3 バケット名に置き換えてください。
- 作成したポリシーを使って IAM ロールを作成します。
- Amazon RDS がこのロールを引き受けられるように、次の信頼関係を追加します。
- この IAM ロールを、AWS Management Console または AWS Command Line Interface (AWS CLI) を使って RDS for Db2 インスタンスに関連付けます。
Amazon S3 へのアーカイブログコピーを有効にする (ステージ 1)
この最初のステージでは、Amazon RDS for Db2 がアーカイブログを S3 バケットに自動でレプリケートするよう設定し、継続的な同期の基盤を築きます。有効にすると、アーカイブログが継続的に S3 にアップロードされ、トランザクションデータのリアルタイムストリームが生成されます。このストリームを適用することで、ハイブリッドアーキテクチャ全体でデータベースの一貫性を保てます。
IAM 権限を設定したら、RDS for Db2 インスタンスでアーカイブログのコピーを有効にできます。以下の手順を実行します。
- RDS for Db2 の
RDSADMINデータベースに接続し、アーカイブログのコピー先となる S3 ロケーションを設定します。<my_rds_db2_backups>を実際の S3 バケット名に置き換え、目的の <prefix path> を指定してください。 - 対象のデータベースでアーカイブログのコピーを有効にします。
<database_name>を実際のデータベース名 (例:RLSDB1) に置き換えてください。 - 設定を確認するには、アーカイブログコピーのステータスをチェックします。
対象のデータベースで
ARCHIVE_LOG_COPYのステータスがENABLEDになっていることを確認します。
アーカイブログを Amazon S3 にコピーする詳細については、Copying archive logs to Amazon S3 を参照してください。
セルフマネージド Db2 インスタンスにデータベースをリストアする (ステージ 2)
このステージでは、オンラインバックアップイメージからリストアしてセルフマネージド Db2 インスタンスのベースラインを確立します。バックアップイメージには、移行時に取得した元のバックアップか、Amazon RDS for Db2 から新たに取得したバックアップのいずれかを使用します。リストア操作を行うと、データベースはロールフォワード保留状態になり、Amazon S3 からのアーカイブログの継続的なストリームを受け取って適用できる状態になります。
セルフマネージドの緊急バックアップ Db2 サーバーに適用できるオンラインバックアップイメージが必要です。この場合、2 つの選択肢があります。
緊急バックアップサーバーに同じオンラインバックアップを適用する
移行の過程で、現在のオンプレミス Db2 サーバーからオンラインバックアップを取得し、同じオンラインバックアップを Amazon RDS for Db2 と、もう 1 台の緊急バックアップ用セルフマネージド Db2 サーバーの両方に適用します。
Amazon RDS for Db2 からオンラインバックアップを取得する
Amazon RDS for Db2 インスタンスからオンラインバックアップを取得し、オンプレミスの Db2 インスタンスに適用できます。
このコマンドにより Amazon S3 上にバックアップイメージが作成されます。このイメージをリストアしたうえでアーカイブログを使って継続的に更新し、別のお客様管理の Db2 サーバーに反映できます。
Amazon RDS for Db2 との継続的なバックアップ同期を確立する (ステージ 3)
この最終ステージでは、S3 からアーカイブログを定期的にダウンロードし、ロールフォワード操作によってセルフマネージド Db2 インスタンスに適用することで、継続的な同期を実現します。データベースをロールフォワード保留モードに保ち、新しいログを定期的に適用することで、Amazon RDS for Db2 インスタンスとセルフマネージドバックアップサーバーの間でリアルタイムの同期を維持でき、さまざまなビジネスシナリオに対応できる運用上の柔軟性が得られます。
セルフマネージドの Db2 で、S3 バケット用のストレージエイリアスを作成します。
ストレージアクセスのカタログ登録の詳細については、IBM Db2 catalog storage access documentation を参照してください。
バックアップイメージが Amazon S3 上にある場合のデータベースのリストア
restore コマンドの詳細については、IBM Db2 restore documentation を参照してください。
バックアップイメージがローカルファイルシステム上にある場合のデータベースのリストア
WITHOUT ROLLING FORWARD を省略すると、データベースはロールフォワード保留状態のままになります。
アーカイブログを適用する (ロールフォワード)
オンラインバックアップをリストアすると、データベースはロールフォワード保留状態になります。ここからアーカイブログを継続的に適用して、RDS インスタンスとの同期を保てます。
ログを継続的に適用するには、以下の手順を実行します。
- セルフマネージドシステムで、アーカイブログ用のディレクトリを作成します。
- S3 からアーカイブログをダウンロードします。
- ログを適用します。
特定の時点までログを適用するには、次のコードを使用します。
継続的な同期を維持する
Amazon S3 のアーカイブログの監視は、お客様の責任で行う必要があります。アーカイブログを削除すると判断した場合は、セルフマネージド Db2 のデータベースを最初からやり直す必要があります。また、削除したアーカイブログを復元する方法はありません。
セルフマネージドのデータベースを Amazon RDS と同期させ続けるには、以下の手順を実行します。
- 新しいアーカイブログを定期的にダウンロードするスケジュールジョブを設定します。
- 新しいログが届いたら適用します。
後でさらにログを適用し続けたい場合は、
and stopを使用しないでください。 - データベースを接続可能な状態にする準備ができたら、次のコードを使用します。
and stop 句を指定すると、ロールフォワード処理が完了し、データベースが接続可能になります。
アーカイブログのコピーを無効にする
アーカイブログのコピーを無効にする必要がある場合は、次のコードを使用します。
アーカイブログのコピーステータスを監視する
アーカイブログのコピーステータスを定期的に確認します。
監視すべき主なフィールドは以下のとおりです。
ARCHIVE_LOG_COPYはENABLEDと表示されるはずですARCHIVE_LOG_LAST_UPLOAD_FILEは最後にアップロードされたログファイルを示しますARCHIVE_LOG_LAST_UPLOAD_FILE_TIMEは最後のアップロードのタイムスタンプを示しますARCHIVE_LOG_COPY_STATUSはアップロードが成功していればUPLOADINGと表示されるはずです
よくある問題のトラブルシューティングと解決策
このセクションでは、よくある問題とその解決策について説明します。
設定エラー
主に Amazon S3 の設定の問題により、次のようなエラーメッセージが表示されることがあります。
S3_INVALID_ARN_FORMAT– Amazon S3 の Amazon リソースネーム (ARN) の形式が無効です。Amazon S3 の ARN が AWS パーティションに対して正しい形式になっているか確認してください。S3_NON_S3_SERVICE– ARN が Amazon S3 のものではありません。有効な S3 バケットの ARN を指定してください。S3_REGION_MISMATCH– アーカイブログコピーの設定エラー: S3 バケットのリージョンが RDS インスタンスのリージョンと一致しません。S3 バケットが RDS インスタンスと同じリージョンにあることを確認してください。S3_ACCOUNT_MISMATCH– S3 バケットのアカウントが AWS アカウントと一致しません。S3 バケットが RDS インスタンスと同じ AWS アカウントに属していることを確認してください。S3_BUCKET_NOT_EXISTS– S3 バケットが存在しません。バケットを作成してから再試行してください。S3_BUCKET_OWNERSHIP_MISMATCH– S3 バケットが AWS アカウントによって所有されていません。バケットが RDS インスタンスと同じ AWS アカウントに属していることを確認してください。S3_BUCKET_PUBLIC_ACCESS– S3 バケットが一般公開されています。セキュリティ上の理由から、バケットのパブリックアクセスを無効にしてください。S3_BUCKET_ACCESS_VALIDATION_FAILED– S3 バケットの権限を検証できません。IAM ロールにこのバケットへアクセスするために必要な権限があるか確認してください。
Amazon S3 関連の設定の問題の詳細については、Viewing Amazon RDS events を参照してください。
IAM 権限のエラー
アーカイブログコピーのステータスが CONFIGURATION_ERROR と表示される場合や、バックアップ操作が権限エラーで失敗する場合は、次のようにトラブルシューティングします。
- IAM ポリシーに
s3:PutObject、s3:GetObject、s3:ListBucket、s3:DeleteObjectの権限が含まれているか確認します - IAM ロールが RDS インスタンスに正しく関連付けられているか確認します
- 信頼関係で
rds.amazonaws.comがロールを引き受けられるようになっているか確認します - S3 バケットポリシーに矛盾する拒否ステートメントがないか確認します
アーカイブログが Amazon S3 に表示されない
ARCHIVE_LOG_COPY が有効になっているのに Amazon S3 にログが表示されない場合は、次のようにトラブルシューティングします。
- 設定で Amazon S3 の ARN が正しく指定されているか確認します
- データベースにログを生成するアクティブなトランザクションがあるか確認します
- RDS for Db2 のエラーログでコピーの失敗がないか確認します
- S3 バケットが存在し、同じリージョンにあるか (またはクロスリージョンレプリケーションが設定されているか) を確認します
ロールフォワードがログの欠落で失敗する
ロールフォワード操作が「log file not found」エラーで失敗する場合は、次のようにトラブルシューティングします。
- バックアップのタイムスタンプから対象のタイムスタンプまでのすべてのアーカイブログがダウンロードされているか確認します
- ログシーケンス番号に抜けがないか確認します
- オーバーフローログパスが正しく指定されているか確認します
- Db2 インスタンスのユーザーがログディレクトリに対する読み取り権限を持っているか確認します
データベースがロールフォワード保留状態のままになる
リストア後にデータベースに接続できない場合は、次のようにトラブルシューティングします。
and stop句を指定してロールフォワード操作を完了します- 後でさらにログを適用したい場合は、データベースを開く準備ができたときにのみ
and stopを使用します db2 list history rollforward for<dbname> を使って、未完了のロールフォワード操作がないか確認します
Amazon S3 ストレージエイリアスの接続の問題
ストレージエイリアスを使って Amazon S3 から直接リストアできない場合は、次のようにトラブルシューティングします。
- セルフマネージド Db2 サーバーで AWS 認証情報が正しく設定されているか確認します
- S3 エンドポイントへのネットワーク接続を確認します
db2 list storage accessを使って、ストレージエイリアスが正しくカタログ登録されているか確認します- S3 バケット名とオブジェクトパスが正しいか確認します
ベストプラクティス
以下のベストプラクティスの導入を検討してください。
- 定期的なテスト – リストアとロールフォワードの手順を定期的にテストし、災害復旧計画が想定どおりに機能することを確認します。
- Amazon S3 コストの監視 – アーカイブログはすぐに蓄積されます。Amazon S3 のライフサイクルポリシーを導入し、不要になった古いログをアーカイブまたは削除します。
- ログ適用の自動化 – cron ジョブやスケジュールタスクを使ってログのダウンロードと適用を自動化し、手作業を減らします。
- ログの連続性の維持 – バックアップのタイムスタンプから現在までのすべてのログをそろえておきます。ログが欠落するとロールフォワードチェーンが途切れます。
- 同期にはオンラインバックアップを使用する – Amazon S3 へのアーカイブログ転送を設定する際はオンラインバックアップを使用し、ロールフォワード操作との互換性を確保します。
- タイムスタンプの記録 – バックアップのタイムスタンプと最後に適用したログを記録しておき、トラブルシューティングと復旧計画に役立てます。
- セキュリティ – S3 の保管中データ (SSE-S3 または SSE-KMS) と転送中データ (S3 アクセスの SSL/TLS) に暗号化を使用します。
クリーンアップ
ロールフォワード処理が完了したら、Amazon S3 バケットからアーカイブログを削除して、割り当てられた領域を回収できます。このソリューションをテスト目的で使用している場合は、Amazon S3 バケット、RDS for Db2 インスタンス、EC2 インスタンス、および IAM などのその他のリソースを必ず削除してください。
まとめ
RDS for Db2 のアーカイブログを Amazon S3 バケットにコピーすることで、セルフマネージドインフラ上にデータベースの同期コピーを維持する仕組みが得られます。この機能により、移行の計画、災害復旧の構築、開発環境の作成において、Amazon RDS のマネージドの利点とセルフマネージド Db2 インスタンスの制御性の両方を柔軟に活用できます。
本記事で説明した手順に従うことで、セルフマネージドの Db2 データベースを RDS インスタンスと同期させ続ける堅牢なデータレプリケーションパイプラインを、最小限のレイテンシーと運用負荷で構築できます。
Amazon RDS for Db2 の詳細については、Amazon RDS for Db2 ユーザーガイドを参照してください。
謝辞
本記事を丁寧にレビューしてくれた Rajib Sarkar と Umair Hussain に感謝します。
著者について
この記事はSolutions Architect の矢木 覚が翻訳しました。