SAP
SAP HANA Cloudのバックアップとリカバリを実践的に理解する
SAP HANA Cloudのバックアップ方式、リカバリの選択、障害発生時の初動、設定確認、復旧テストまでを日本語で体系的に解説します。
SAP HANA Cloudで業務データを保護するには、バックアップを取得するだけでなく、障害の種類に応じた復旧方法と復旧後の確認手順まで設計する必要があります。本記事では、SAP HANA Cloudにおけるバックアップの考え方、リカバリの選び方、運用時の確認ポイントを、管理者や試験学習者が整理しやすい形で説明します。
なお、SAP HANA Cloudの管理、監視、アラート確認にはSAP HANA Cloud CentralやSAP HANA database explorerを使用します。オンプレミス環境の管理ツールであるSAP HANA cockpitを、SAP HANA Cloudの管理・監視・アラート用途として扱わないことが重要です。オンプレミスとの違いは、SAP HANA Cloudとの比較ガイドでも確認できます。
SAP HANA Cloudのバックアップとリカバリとは
バックアップとは、データベースをある時点の状態に戻せるよう、データやログを保護する仕組みです。リカバリとは、取得済みのバックアップやログを使って、データベースを利用可能な状態へ戻す操作を指します。両者は別の作業ですが、復旧可能性を確保するという目的で一体として設計します。
SAP HANA Cloudでは、データバックアップとログバックアップを組み合わせて、障害発生前の状態へ近づけます。データバックアップはデータベース全体の基準点を作り、ログバックアップはその後に発生した変更を補います。したがって、直近の完全なデータバックアップだけを確認しても、実際にどの時点まで戻せるかは判断できません。
重要なのは、復旧目標を先に定義することです。どの程度のデータ損失を許容できるかはRPO、サービスを何分または何時間以内に再開する必要があるかはRTOで表します。RPOとRTOが明確であれば、バックアップ保持期間、復旧方式、テスト頻度を現実的に決められます。
バックアップの仕組みを理解する
SAP HANA Cloudのバックアップ設計では、主にデータバックアップ、ログバックアップ、保持期間、保存先、暗号化やアクセス制御を確認します。設定値は契約形態やサービス仕様、リージョン、データベース構成によって異なるため、実際の環境ではSAP HANA Cloud Centralに表示される情報と公式ドキュメントを基準にしてください。
データバックアップは、データベースの永続化データを保護するための基準になります。大規模なデータベースでは、バックアップに要する時間やストレージ使用量が運用に影響するため、業務のピーク時間、データ量の増加、保持期間を合わせて評価します。バックアップが成功したという通知だけでなく、対象データベース、実行時刻、保持状態も記録すると監査や障害対応に役立ちます。
ログバックアップは、データバックアップ後のトランザクション変更を保護します。ログの生成量が多い環境では、ログバックアップの遅延や保存領域の消費が問題になる可能性があります。バックアップ履歴だけでなく、ログバックアップが継続して実行されているか、エラーが繰り返されていないかを定期的に確認してください。関連する運用観点はSAP HANAのログバックアップでも整理できます。
保持期間は、誤操作やデータ破損が発見されるまでの時間を考えて決めます。短すぎる保持期間では、障害に気付いた時点で必要な復旧時点が消えていることがあります。一方、長すぎる保持期間はコストや管理負荷を増やします。法令、社内規程、業務の締め処理、バックアップ容量を合わせて、定期的に見直すことが大切です。
バックアップを保護するには、管理者権限を必要最小限にし、誰が設定を変更できるかを明確にします。バックアップの削除や保持期間の変更は、通常のデータ操作とは異なる高い影響を持つため、変更申請、承認、実施記録を残す運用が適しています。権限設計を確認する場合はSAP HANA Cloudのユーザー管理も参考になります。
リカバリの種類と選択
リカバリ方法は、発生した問題と必要な復旧時点によって選びます。代表的な考え方は、特定時点への復旧、直近の状態への復旧、バックアップからのデータベース復元です。名称や利用できる選択肢はサービスの画面や時期によって変わる場合があるため、操作前に対象環境の案内を確認してください。
特定時点への復旧は、誤削除やアプリケーション障害の直前など、指定した時刻の状態へ戻したい場合に検討します。復旧時点を決める際は、障害が発生した時刻ではなく、障害のあるデータが作成された時刻や、最後に正常と確認できた時刻を基準にします。時刻の基準、タイムゾーン、業務ログを照合することが重要です。
直近の状態への復旧は、可能な限り新しい状態を取り戻したい場合に適しています。ただし、障害原因となった処理や破損データまで含めて復旧する可能性があるため、単に最新であることだけを理由に選んではいけません。アプリケーションログ、監視通知、データ更新履歴を確認して、復旧時点を判断します。
データベース全体の復元が必要な場合は、対象インスタンス、復旧時点、接続情報、アプリケーションへの影響を整理します。復旧中は接続できない、または一時的に利用制限が発生する可能性があるため、関係者への告知と作業時間の確保が必要です。復旧後はデータベースが起動しているだけでなく、アプリケーションが正常に接続できることも確認します。
復旧方式を選ぶ前に、次の情報を一覧化します。
- 障害を検知した時刻
- 最後に正常だった時刻
- 誤操作や異常処理が発生した時刻
- 必要な復旧時点
- 許容できるデータ損失
- 業務を再開すべき期限
- 復旧後に再実行が必要な処理
この一覧があれば、感覚的に最新バックアップを選ぶのではなく、RPOとRTOに沿って判断できます。データベース復旧の一般的な考え方はSAP HANAデータベースのリカバリとも比較して学習できます。
障害発生時の初動手順
障害発生時は、最初に状況を固定します。慌てて再起動、データ削除、設定変更を行うと、原因調査に必要な証拠や復旧の選択肢を失う可能性があります。検知時刻、エラーメッセージ、実行中だった処理、影響を受けたユーザー、直前の変更を記録してください。
次に、障害の範囲を切り分けます。データベース全体が利用できないのか、一部のアプリケーションだけが失敗しているのか、認証やネットワークに問題があるのかを確認します。単なる接続障害をデータ破損と誤認すると、不要な復旧作業によって業務停止を拡大させることがあります。
サービス状態やデータベースの状態はSAP HANA Cloud Centralで確認し、データベース内部の情報やSQLによる調査が必要な場合はSAP HANA database explorerを使用します。SAP HANA cockpitはSAP HANA Cloudの管理ツールではないため、Cloud環境の復旧確認に使う前提で手順書を作成しないでください。
復旧操作を実施する前に、関係者へ影響範囲と予定を伝えます。特に、復旧によって失われる可能性がある更新、停止時間、復旧後に必要な再処理を明示します。承認が必要な環境では、緊急変更の手順に従い、作業者と承認者を分けて記録します。
復旧後は、データベースの状態、接続、主要なスキーマ、重要テーブル、アプリケーション処理、バッチ、監視を順に確認します。画面が開くだけでは復旧完了とはいえません。業務担当者による受入確認と、復旧時点以降のデータ再投入や連携再開も含めて完了判定を行います。
バックアップ設定を確認する
日常点検では、最後に成功したデータバックアップの時刻、ログバックアップの継続状態、保持期間、保存容量、エラー通知を確認します。点検結果は日付、対象データベース、確認者、異常の有無、対応内容とともに残します。履歴を残すことで、障害発生時にバックアップがいつから正常だったかをすぐに判断できます。
監視では、バックアップ失敗だけでなく、実行時間の急増、ログの蓄積、保存領域の逼迫、設定変更、復旧操作の実行も対象にします。監視通知を設定する場合は、通知先と一次対応者を明確にし、夜間や休日にも対応できるエスカレーションを用意します。アラート設計の考え方はSAP HANA Cloudのアラートで補足しています。
チェックリストは、次のように分けると運用しやすくなります。
- 毎日確認する項目：最新バックアップ、ログ状態、容量、エラー
- 毎週確認する項目：履歴、保持期間、通知先、変更記録
- 毎月確認する項目：復旧手順、担当者、RPOとRTO、容量予測
- 定期的に実施する項目：復旧テスト、手順書レビュー、権限レビュー
点検項目は多ければよいわけではありません。実際に異常を検出でき、担当者が行動に移せる項目に絞ることが大切です。確認画面、ログ、チケット番号、判断基準を手順書に記載すると、担当者が変わっても品質を維持できます。
よくあるトラブルと対処
バックアップが失敗する場合は、まず対象データベースと失敗時刻を確認し、同じエラーが継続しているかを調べます。保存領域、サービス状態、設定変更、メンテナンスの影響を切り分け、短時間の一時エラーと継続的な設定・容量問題を区別します。エラーを消すことだけを目的に再実行を繰り返すのではなく、原因と再発防止策を記録してください。
ログバックアップの遅延や蓄積が見られる場合は、ログ生成量の急増、長時間実行トランザクション、アプリケーションの異常ループ、保存領域の状態を確認します。原因を特定せずにログを削除したり、保持設定を短縮したりすると、必要な復旧時点を失う危険があります。影響が大きい場合は、サービスのサポート手順に従ってエスカレーションします。
復旧後にアプリケーションが動かない場合は、データベースの稼働状態だけでなく、接続先、認証情報、ネットワーク許可、証明書、スキーマ、ジョブ、外部連携を確認します。データベース復旧によって、復旧時点より後の更新が存在しなくなっている場合もあるため、業務側の再入力や再連携が必要かを判断します。
想定した時点へ戻せない場合は、バックアップの保持期間、ログの連続性、時刻の解釈、対象データベース、権限を再確認します。バックアップが存在することと、希望する時点へ復旧できることは同じではありません。復旧テストでこの差を確認し、実際の制約をRPOの説明に反映させます。
運用設計と復旧テスト
復旧手順は、障害時に初めて読んでも実行できる粒度で作成します。対象環境、前提条件、連絡先、判断基準、操作順序、確認項目、切り戻し方針、完了条件を記載してください。画面の名称や権限は変更されることがあるため、手順書には作成日と更新日を付け、定期的に見直します。
復旧テストでは、本番データを不用意に変更しないよう、承認済みの検証環境やサービス機能を利用します。テストの目的は、バックアップが存在することを確認するだけではありません。復旧にかかる時間、必要な権限、接続設定、アプリケーションの整合性、データ損失の範囲、担当者間の連絡を検証します。
テスト結果には、開始時刻、復旧対象、選択した時点、終了時刻、確認した業務処理、発見した問題、改善策を記録します。RTOを超えた場合は、操作の効率化だけでなく、担当者の待ち時間、承認、ネットワーク、アプリケーション再起動などのボトルネックを分解して対策します。
また、ランサムウェアや認証情報の漏えいを想定する場合は、バックアップへのアクセス権限と管理者アカウントの保護も確認します。バックアップがあっても、攻撃者が削除・改変できる状態では復旧の信頼性が低下します。通常運用の利便性と、障害時の独立性のバランスを取ることが必要です。
まとめ
SAP HANA Cloudのバックアップとリカバリでは、データバックアップ、ログバックアップ、保持期間、復旧時点、RPO、RTOを一つの設計として考えます。障害時は状況を記録し、影響範囲を切り分け、適切な復旧時点を選んだうえで、復旧後の業務確認まで実施します。
日常運用では、バックアップの成功履歴だけでなく、ログの継続性、容量、通知、権限、変更記録を確認してください。そして、SAP HANA Cloud CentralとSAP HANA database explorerを前提に手順を整備し、SAP HANA cockpitをCloud管理ツールとして混同しないことが重要です。
最も確実な対策は、定期的な復旧テストです。テストによって初めて、設定上の復旧可能性と、実際に業務を再開できる能力との差を把握できます。テスト結果を手順、監視、権限、RPO、RTOへ反映し、継続的に改善しましょう。