Amazon RDSのバックアップ・メンテナンス・設定管理

Amazon RDSの運用では、障害から戻すためのバックアップと、サービスを維持するためのメンテナンスを分けて考えます。バックアップは誤操作やデータ破損からの復旧、長期保管、別リージョンへの復旧環境づくりに使います。メンテナンスはAWSが管理する基盤やデータベースエンジンを更新し、設定グループはエンジンの動作や利用可能な追加機能を制御します。

復旧手段を選ぶときは、いつの状態へ戻したいかを示すRPO（目標復旧時点）と、サービスをどれくらいの時間で再開したいかを示すRTO（目標復旧時間）を確認します。PITRは保持期間内の指定時点へ戻す手段、スナップショットは取得時点のコピー、リードレプリカの昇格は待機済みの複製先を独立したDBにする手段です。それぞれ復旧できる時点と手順が異なります。

自動バックアップと保持期間

RDSの自動バックアップを有効にすると、DBストレージのバックアップとトランザクションログが管理され、保持期間内の指定時点へ復元するポイントインタイムリカバリ（PITR）が可能になります。自動バックアップの保持期間は通常0〜35日です。0日に設定すると、自動バックアップとPITRは無効になります。既定値は一般に7日ですが、DBの作成方法やエンジンなどにより設定条件が異なることがあるため、対象DBの設定を確認します。

初回のバックアップではDBの全体を基準として取得し、後続の自動バックアップでは変更分を追跡します。バックアップとトランザクションログの詳細な取得・保管はRDSが管理するため、利用者がログファイルを手動で集める必要はありません。RDSは通常、トランザクションログを数分間隔で保管し、バックアップ保持期間中の時点へ復元できるようにします。したがって「ログが常にちょうど5分ごとに保存され、必ず過去3日分だけ復元できる」と一律に捉えるのではなく、RDSが表示する復元可能な時間範囲とエンジン固有の条件を確認してください。

保持期間を短くすると、PITRで戻せる過去の範囲も短くなります。自動バックアップの保管範囲を超える長期保管や、決めた時点を残す用途には手動スナップショットまたはAWS Backupのバックアッププランを検討します。料金は保持するバックアップデータ量、リージョン、コピーなどの条件で変わるため、固定金額ではなくAmazon RDSの料金で確認します。

手動スナップショット

手動DBスナップショットは、運用者が任意のタイミングで取得するDBストレージの復旧用コピーです。大きなスキーマ変更やメジャーバージョンアップの前に戻り先を確保したり、短い自動バックアップ保持期間を超えて特定時点を保管したりする用途に使えます。手動スナップショットは自動的には期限切れにならず、利用者が削除するまで保持されます。AWSの現行ガイドでは、1リージョンあたり最大100個の手動スナップショットを保持できます。ストレージ料金も発生するため、不要になったスナップショットを棚卸しし、必要に応じてクォータの最新条件を確認します。

手動スナップショットは、別リージョンへコピーしたり、条件を満たすスナップショットを別アカウントと共有したりできます。暗号化されたスナップショットでは、コピー先リージョンのKMSキーとキーポリシー、共有先アカウントの権限を準備します。AWS管理の既定KMSキーで暗号化されたスナップショットは、そのまま別アカウントと共有できないため、共有可能なカスタマーマネージドKMSキーを使ったコピーが必要になります。

自動バックアップから別リージョンへのコピーが必要なら、対応するRDSのクロスリージョン自動バックアップやAWS Backupの機能を使えます。自動バックアップを一度手動スナップショットに変換しなければ別リージョンへコピーできない、という制約がすべての方式に当てはまるわけではありません。スナップショットのコピーではDBデータが複製されますが、移行先リージョンに同じカスタムパラメータグループやオプショングループが自動で用意されるとは限りません。移行先のエンジンとバージョンに合う設定グループを確認して割り当てます。スナップショットから復元すると、元のオプショングループが既定で関連付けられる場合がありますが、オプショングループはVPCにも結び付きます。別VPCへ復元する場合は、そのVPCで使えるグループを用意します。永続オプションや恒久オプションが含まれる場合は、復元先グループにも同じオプションが必要になることがあります。

AWS Backupを利用すると、バックアッププランで取得頻度、保持、バックアップボールト、コピー先をまとめて管理できます。スナップショットバックアップは対象サービスが対応していれば時間単位でスケジュールでき、継続的バックアップではPITRを構成できます。現行の対応表では、RDSのSingle-AZとMulti-AZ DBインスタンスは継続的バックアップとPITRに対応しますが、RDS Multi-AZ DBクラスターは対応していません。また、RDS Multi-AZ DBクラスターはAWS Backupでのコピー操作にも対応していません。利用するRDSの配置方式、AWS Backupの対応機能、スケジュール間隔、保持条件を確認し、RDS標準の自動バックアップと二重に管理しないよう方針を定めます。

PITRとスナップショットからの復元

PITRでは、保持期間内の復元可能な時間範囲から目標時刻を指定します。誤った更新やアプリケーションの不具合が発生する前の状態を別インスタンスとして起動し、必要なデータを確認してから接続先を切り替える使い方ができます。正確な最古時刻・最新時刻はDBごとに異なるため、復元時にコンソールやAPIが示す範囲を使います。

スナップショットからの復元もPITRも、既存DBインスタンスの内容をその場で巻き戻す操作ではありません。いずれも新しいDBインスタンスが作成されます。新しいインスタンスには新しいエンドポイントが割り当てられ、サブネットグループ、セキュリティグループ、パラメータグループ、オプショングループ、暗号化キーなどの構成を確認する必要があります。アプリケーションの接続設定やDNSを更新し、復旧先に切り替えた後も、旧インスタンスをすぐに削除せずデータの整合性を確認する運用が有効です。

復元に要する時間は、DBのサイズ、ストレージ、エンジン、リージョン、サービス負荷などで変わります。「PITRなら数分」「スナップショットなら必ず数十分」と固定せず、復元試験で実測してRTOを評価します。AWS Backupからの復元でも、新たにDBリソースを作成して接続先を切り替える作業を計画します。

バックアップとリードレプリカの復旧時間

バックアップは、過去のある時点へ戻す機能です。復元には新しいDBインスタンスの作成とデータ準備が必要なので、復旧までに時間がかかる場合があります。これに対してリードレプリカは、プライマリから継続的に複製されたDBを平常時から用意し、必要に応じて昇格できます。低いRTOが重要で、特に数分以内の再開を目標にする場合は、レプリカを昇格する構成がバックアップからの復元より短時間で復旧できる候補になります。

ただし、リードレプリカはバックアップの代わりではありません。一般に非同期複製のため、障害直前の変更がまだ反映されていない可能性があります。昇格の実行、接続先の更新、アプリケーションの再接続も必要です。障害を自動検知するか、昇格を誰が判断するか、DNSのTTLや接続プールをどう扱うかを含めて復旧手順を準備します。復旧目標を達成できるかは、実際のフェイルオーバー演習で測定します。

方式	戻せる状態	主な目的	検討事項
自動バックアップによるPITR	保持期間内の指定時点	誤操作、論理破損、データの巻き戻し	新しいDBを作成し、必要なデータや接続先を切り替える
手動スナップショット	スナップショット取得時点	長期保管、変更前の退避、リージョン間コピー	保持管理、コピー時間、KMSキーと設定グループ
リードレプリカの昇格	複製済みデータの時点	低RTOの復旧、読み取り複製先の独立運用	非同期の遅延、昇格、接続切り替え。PITRの代替ではない
Multi-AZの自動フェイルオーバー	同じDBの最新状態	AZやインスタンス障害時の可用性	論理削除や誤更新を元に戻す機能ではない

メンテナンスウィンドウと停止影響

RDSはマネージドサービスとして、基盤の保守やデータベースエンジンの一部更新を実施します。利用者はDBごとに週次のメンテナンスウィンドウを指定し、利用への影響が比較的小さい時間帯を選べます。RDSのメンテナンスウィンドウは通常30分の時間枠であり、リージョンごとに定められた8時間のブロック内から選択します。既定値はDB作成時に割り当てられ、任意の「毎晩8時間の保守時間」と同じ意味ではありません。メンテナンスの所要時間や実行開始時刻は内容により変わり、指定枠内で完了する保証でもありません。

パッチ適用や変更によっては、短い停止、接続断、レイテンシー増加が起こることがあります。アプリケーションには接続エラーへの対応や再試行を実装し、保守の告知やRDSイベントを監視します。メンテナンスの延期は一時的な選択肢ですが、セキュリティ更新などを長く先送りすると、後で適用が必須になる場合があります。実際の影響と延期可否を確認し、予定された時間に運用担当者が対応できるようにします。

Multi-AZ DBインスタンスのメンテナンスは、作業の種類によって手順が違います。OS更新では、通常スタンバイ側を先に保守し、スタンバイをプライマリへ昇格した後、旧プライマリを新しいスタンバイとして保守します。これにより、両方のDBを同時に停止することを避けやすくしますが、フェイルオーバー時に短時間の接続断が起こる可能性があります。

一方、通常のデータベースエンジンバージョンアップグレードでは、Multi-AZ DBインスタンスのプライマリとセカンダリが同時に変更され、アップグレード完了までDBが利用できなくなる場合があります。OS更新のスタンバイ先行手順を、エンジンアップグレードにも当てはめないでください。RDS for SQL ServerのMulti-AZではローリングアップグレードが行われ、停止はフェイルオーバーの時間に抑えられる場合があります。また、対応するMySQL、PostgreSQL、MariaDBではBlue/Green Deploymentsを使ってアップグレード時の停止を短縮できる構成があります。Multi-AZ DBクラスター、Auroraクラスター、単一AZのDBも更新順序や影響が異なるため、DBの配置モードとエンジンを確認して計画します。

エンジンのアップグレード

RDSは対応するマイナーバージョン更新を自動適用する設定を提供します。自動マイナーアップグレードの有効・無効、適用時期、対象バージョンはエンジンとバージョンによって条件があり、メンテナンスウィンドウとの関係も確認します。メジャーバージョンアップグレードはアプリケーション互換性や廃止機能、拡張、パラメータグループファミリーへの影響が大きいため、一般に利用者が実行時期と移行方法を計画して開始します。利用可能な自動化オプションがある場合も、互換性検証と事前の復旧策を省略してよいわけではありません。

本番環境のアップグレード前には、手動スナップショットを取得し、検証環境でアプリケーションの動作を確認します。パラメータグループやオプショングループがアップグレード先エンジンのファミリーに適合するかを調べ、利用中の拡張、ドライバー、SQL構文、接続設定を検証します。アップグレード後に戻す場合、スナップショットから新しいDBを復元する方式になることがあり、元のインスタンスへ単純にバージョンを戻せるとは限りません。

パラメータグループ

DBパラメータグループは、エンジンの動作や性能に関する設定値をまとめたものです。対応するデフォルトグループを使うほか、要件に合わせてカスタムグループを作り、DBインスタンスに関連付けられます。エンジンやメジャーバージョンには対応するパラメータグループファミリーがあるため、アップグレードや移行時にはファミリーの一致を確認します。

通常のRDS DBインスタンスにはDBパラメータグループを割り当てます。AuroraやRDS Multi-AZ DBクラスターでは、クラスター全体の設定を持つDBクラスターパラメータグループと、個々のDBインスタンスに適用するDBパラメータグループを使う構成があります。どちらを変更するか、クラスター全体に揃える設定とインスタンスごとの設定を区別します。

パラメータには、変更後すぐ反映される動的パラメータと、DBインスタンスの再起動後に反映される静的パラメータがあります。変更を保存しただけで全設定が即時有効になるわけではありません。各パラメータの適用タイプ、コンソール上の適用状態、再起動による接続断を確認して変更計画を立てます。パラメータグループ自体を変更しても、変更先の値や反映条件によっては再起動が必要です。

オプショングループ

オプショングループは、対応するエンジンに追加機能や連携オプションを導入するときに使います。DBパラメータグループが主にエンジン設定値を扱うのに対し、オプショングループは利用可能なオプションの追加と構成を管理します。対象エンジンとバージョンに対応したグループをDBインスタンスに関連付けます。すべてのエンジンがオプショングループを使うわけではなく、RDS for PostgreSQLはオプショングループではなく拡張機能やモジュールを使います。

オプションの追加・変更は、内容によって即時に反映される場合と、メンテナンスウィンドウまたは再起動後に反映される場合があります。すべてのオプションが無停止で適用されるわけではありません。オプショングループをコピーしたり別リージョンで再作成したりするときは、オプションの対応状況、ライセンス、設定値、関連するセキュリティ権限などを移行先で改めて確認します。

設定管理	主な役割	適用先と注意点
パラメータグループ	DBエンジンの設定値や動作を調整する	エンジンファミリーを合わせる。静的パラメータは再起動が必要
DBクラスターパラメータグループ	クラスター全体に関する設定を管理する	AuroraやRDS Multi-AZ DBクラスターで使用。個々のDBインスタンス用グループとは別に扱う
オプショングループ	エンジンの追加機能やオプションを管理する	対応エンジン・バージョンに注意。変更に再起動が必要なことがある

試験での見分け方

• 数日前の状態に戻したい: 保持期間内の自動バックアップとPITRを使う。任意の復元時刻を指定できるが、新しいDBが作成される。
• 指定時点を長期保管したい: 手動スナップショットを使い、不要になった時点で削除する。保持上限、コピー先、暗号化キーを管理する。
• 誤操作の直前へ戻したい: 自動バックアップの復元可能時間範囲を確認してPITRする。Multi-AZだけでは論理的な誤操作から戻せない。
• RTOを短くする必要がある: レプリカを事前に用意して昇格する方式を検討する。非同期の複製遅延と、昇格後のアプリケーション切り替えを含めて時間を計測する。
• スナップショットから既存DBへ直接上書きする: できない。新規DBのエンドポイントやネットワーク、セキュリティグループを準備して接続先を切り替える。
• 毎日1回の自動バックアップと別の保管を行いたい: 手動スナップショットまたはAWS Backupのバックアッププランを使う。頻度や保持期間は対象サービスの対応条件を確認する。
• メンテナンスウィンドウは毎週8時間停止する: 誤り。通常は8時間のブロック内にある30分の枠を選ぶ。実際の影響は更新内容と配置方式による。
• Multi-AZ DBインスタンスのOS更新: 通常はスタンバイを先に更新し、昇格後に旧プライマリを更新する。短い接続断への対策は必要。
• Multi-AZ DBインスタンスのエンジン更新: 通常はプライマリとセカンダリを同時に変更し、完了まで停止し得る。SQL Serverのローリングアップグレードなど、エンジン固有の例外を区別する。
• DB設定値を変えたい: パラメータグループを確認し、動的か静的かに応じて適用する。追加機能が目的ならオプショングループを確認する。PostgreSQLの拡張はオプショングループではなく拡張機能として扱う。
• 別リージョンへDBをコピーする: データのコピーだけで完了と考えない。KMSキー、パラメータグループ、オプショングループ、ネットワーク、接続先を移行先で整える。

AWS公式ドキュメント

• Amazon RDSでのバックアップと復元
• RDS DBインスタンスの自動バックアップ
• 指定した時刻へのDBインスタンスの復元（PITR）
• DBスナップショットからの復元
• DBスナップショットのコピー
• DBインスタンスのメンテナンス
• Amazon RDS DBインスタンスのアップグレード
• DBパラメータグループの操作
• オプショングループの操作
• AWS Backupの機能対応表
• AWS Backupのバックアップ頻度と保持期間
• AWS Backupの継続的バックアップとPITR