SAP HANA リカバリ手順：復旧ポイントの選び方と失敗時の確認項目

SAP HANAで障害が発生した場合、バックアップを持っているだけでは十分ではありません。どの時点まで戻すのか、データベース全体を復旧するのか、特定テナントだけを対象にするのかを先に整理する必要があります。本記事では、SAP HANAの管理担当者が確認しやすいように、SAP HANA リカバリ手順を準備・実行・検証の順番で説明します。

ここで扱うのは、通常のバックアップとログバックアップを利用したデータベース復旧です。システムレプリケーションの切り替えやストレージ製品固有の復旧は、別途その製品の運用手順を確認してください。実環境では、必ず変更管理、承認、バックアップ保管ポリシー、業務部門との復旧目標を優先します。

01リカバリ前に確認すること

リカバリ操作は、実行後に現在のデータ状態を失う可能性があります。焦って開始するのではなく、まず障害の範囲と復旧要件を記録します。

障害範囲を特定する

最初に、次の項目を確認します。

• SYSTEMDBだけが利用できないのか
• 特定のテナントデータベースだけが停止しているのか
• ホスト、ストレージ、ネットワーク、認証のどこに問題があるのか
• データファイルは残っているのか、破損しているのか
• ログ領域とバックアップ保管先にアクセスできるのか
• データベースの停止時刻と、最後に正常だった時刻はいつか

データベースが単に停止しているだけなら、リカバリではなく起動やサービス状態の確認で解決できる場合があります。停止・起動の確認方法は、関連するSAP HANAの起動と停止も参照してください。

RPOと復旧時点を決める

復旧時点は、業務要件と利用可能なバックアップの両方から決定します。代表的な選択肢は次のとおりです。

「最新」と「安全」は同じではありません。誤削除や不正な更新が疑われる場合、障害発生直前までログを適用すると、問題の操作も復元されます。その場合は、問題が起きる前の復旧ポイントを選択します。

復旧経路を確保する

バックアップファイルが存在していても、復旧先のホストから読めなければ使えません。バックアップカタログ、バックアップ保存先、暗号鍵、ストレージ認証情報、必要なネットワーク経路を確認します。

また、リカバリ中は通常のバックアップやログ削除ジョブが競合しないようにします。運用スケジューラを一時停止する場合は、停止対象と再開条件を明確に記録してください。

02SAP HANA リカバリの基本手順

以下は、SAP HANA cockpitなどの管理画面を使う場合に共通する考え方です。画面上の名称や表示項目は、HANAのバージョン、構成、権限によって異なることがあります。

1. リカバリ対象を確定する

SYSTEMDB、テナントデータベース、またはデータベース全体のどれを復旧するのかを確定します。マルチテナント構成では、対象を誤ると想定外のデータベースに操作を実行する危険があります。

作業依頼書には、対象データベース名、SID、ホスト、障害発生時刻、希望する復旧時点、担当者、承認者を記載します。画面操作前に接続先を読み上げ確認すると、誤操作の防止に役立ちます。

2. バックアップの可用性を確認する

データバックアップについて、作成日時、サイズ、保存先、完了状態を確認します。続いて、選択したデータバックアップ以降のログバックアップが連続して存在するかを調べます。

ログバックアップに欠落がある場合、最新時点までの復旧はできません。欠落箇所より前の時点を選ぶか、別のデータバックアップを起点にする必要があります。カタログ上の登録だけでなく、実ファイルを読み取れることも確認します。

3. リカバリウィザードを開始する

SAP HANA cockpitで対象データベースのリカバリ機能を開き、復旧方法を選択します。一般的には、次のような判断になります。

• 最新状態への復旧
• 指定日時への復旧
• 特定バックアップからの復旧
• ログバックアップを使わないデータバックアップのみの復旧

指定日時を入力するときは、タイムゾーン、夏時間の扱い、業務システム側の時刻とHANA側の時刻が一致しているかを確認します。数分のずれが、取引データの欠落や重複につながることがあります。

4. 復旧設定を検証する

実行前の確認画面では、対象データベース、バックアップの起点、復旧終了時刻、バックアップ保存先、ログ適用の有無を確認します。可能なら、別の担当者による二者確認を行います。

特に、既存データベースを上書きする操作か、新しい復旧先を使う操作かを確認してください。業務影響を抑えられる場合は、まず隔離環境へ復旧し、データの妥当性を検証してから本番切り替えを判断します。

5. リカバリを実行して進捗を監視する

実行中は、データバックアップの読み込み、ログバックアップの適用、サービス状態、ストレージ容量、ネットワーク転送を監視します。大規模なデータベースでは、処理時間が長くなるため、タイムアウトと判断して途中で停止しないようにします。

進捗が長時間変わらない場合は、エラーが発生していないか、保存先へのI/Oが継続しているか、ホストリソースが枯渇していないかを確認します。停止や再実行は、現在の状態を記録してから実施してください。

6. 復旧後の状態を確認する

リカバリ完了後は、データベースが期待する状態で起動しているかを確認します。システムビュー、cockpitのアラート、バックアップカタログ、サービス状態を確認し、エラーが残っていないことを見ます。

その後、アプリケーション接続、重要テーブルの件数、直近の業務伝票、ユーザー認証、バッチ、インターフェースを業務担当者と確認します。技術的に起動していても、業務データの整合性が保証されたとは限りません。

03リカバリ方式の選び方

最新状態への復旧

障害直前までのデータを残したい場合に選択します。前提は、起点となるデータバックアップと、その後の必要なログバックアップが揃っていることです。ログバックアップの欠落、破損、暗号鍵の不一致があると、最後まで適用できません。

特定時点への復旧

誤削除、誤更新、アプリケーション障害など、問題が発生した時刻が推定できる場合に有効です。目標時刻は、問題の操作が始まる前に設定します。業務イベントの時刻とデータベースのコミット時刻は一致しない場合があるため、余裕を持って候補時刻を検討します。

データバックアップだけで復旧する場合

ログバックアップが利用できない場合は、データバックアップ作成時点までしか戻せないことがあります。この方式では、バックアップ後の更新が失われる可能性があるため、業務部門に影響範囲を説明して承認を得ます。

04HANA リカバリが失敗したときの切り分け

リカバリ失敗の原因は、バックアップそのものだけとは限りません。エラーの文言、発生した段階、対象リソースを記録し、同じ操作を無計画に繰り返さないことが重要です。

バックアップが見つからない

保存先のマウント、クラウドまたはストレージの認証、パスの大文字小文字、バックアップカタログの状態を確認します。バックアップ管理システムを経由している場合は、HANAホストから直接読み取れるか、プロバイダー側のジョブが成功しているかも調べます。

ログバックアップが不足している

起点バックアップから目標時刻までのログが連続しているかを確認します。欠落したログを推測して作成することはできません。利用可能な最終時点を復旧目標に変更するか、より新しい完全データバックアップを探します。

ストレージ容量が足りない

復旧先のデータ領域、ログ領域、バックアップ作業領域に必要な容量を確保します。一時ファイルや古いバックアップを削除する場合は、保管期限と復旧要件に違反しないことを確認してください。

復旧後にサービスや接続が不安定

データベースサービス、ホスト名解決、ポート、証明書、ユーザー権限、アプリケーション接続設定を順番に確認します。トレースファイルには原因の手掛かりが残るため、エラー発生時刻と一致する範囲を採取します。詳細はSAP HANAのトレースファイル確認も役立ちます。

権限や暗号鍵で止まる

操作ユーザーに必要な管理権限があるか、バックアップ暗号化を利用している場合は鍵の保管・復元が可能かを確認します。権限を広げる場合は、一時的な付与、承認、作業後の剥奪を記録します。パスワードをログやチケットに平文で残してはいけません。

05復旧後に行う検証と再発防止

リカバリ完了をもって作業終了とせず、復旧結果を検証します。最低限、次の項目を確認してください。

1. 対象データベースが正常に起動している
2. HANA cockpitの重大アラートが解消または説明済みである
3. バックアップカタログとログバックアップが期待どおりである
4. アプリケーションから接続できる
5. 重要な業務データと件数が期待値に合っている
6. バッチ、インターフェース、監視が再開している
7. 新しいバックアップを取得し、読み取り確認を行っている

復旧後は、障害のタイムライン、選択した復旧時点、失われた可能性のあるデータ、所要時間、判断者、エラー、回避策を記録します。バックアップがあることと、復旧できることは別の管理項目です。定期的なリストアテストで、実際の復旧時間と手順の不足を確認しましょう。

バックアップとログの運用全体を見直す場合は、SAP HANAのバックアップとリカバリを参照してください。監視設計や権限設計も合わせて確認すると、障害発生後の判断を早められます。

06実務で使えるチェックリスト

実行前

• 障害範囲と対象データベースを確定した
• RPO、復旧時点、業務上の許容損失を確認した
• データバックアップの完了状態を確認した
• 必要なログバックアップが連続している
• 保存先、暗号鍵、権限、ネットワークを確認した
• 業務停止と復旧作業の承認を得た
• 実行者と確認者を決めた

実行中

• 正しいSYSTEMDBまたはテナントを選択している
• 起点バックアップと復旧終了時刻が正しい
• ストレージ容量とI/Oを監視している
• エラー、時刻、進捗を記録している
• 無計画な再実行や中断をしていない

実行後

• データベースとサービスが正常である
• アラートとトレースを確認した
• アプリケーションと重要データを業務側が確認した
• 新しいバックアップを取得した
• 作業記録と再発防止策を更新した

07まとめ

SAP HANAのリカバリでは、操作画面を開く前の復旧時点の決定と、バックアップ経路の確認が成否を左右します。基本の流れは、対象特定、バックアップ確認、復旧方式の選択、設定の二者確認、実行、業務検証です。

「最新まで戻す」ことが常に正解とは限りません。論理障害では問題発生前の時点を選び、ログ欠落時には復旧可能な最終時点を明確にします。復旧後の検証と定期的なリストアテストまでを運用に含めることで、障害時の判断を安定させられます。

FAQ

実務では：SAP HANAのリカバリで最初に確認する項目は何ですか

対象データベース、障害発生時刻、希望する復旧時点、利用可能なデータバックアップとログバックアップを確認します。単なる停止であれば、リカバリが不要な可能性もあります。

実務では：SAP HANAはバックアップが一つあれば復旧できますか

データバックアップだけで復旧できる場合もありますが、バックアップ作成後の更新を戻すには、必要なログバックアップが連続して利用できることが重要です。目標時点によって必要なバックアップが変わります。

実務では：HANA リカバリに失敗した場合、何度も再実行してよいですか

原因と現在の状態を記録せずに再実行するのは避けてください。エラー段階、バックアップ保存先、ログ欠落、容量、権限、暗号鍵、トレースを確認し、復旧目標を見直します。

実務では：特定時点へのリカバリでは何に注意しますか

時刻のタイムゾーンと、問題の操作が完了した時刻を確認します。誤操作を除外する目的なら、問題が始まる前の時点を選び、業務データの確認を行います。

実務では：リカバリ後に必ず実施する検証は何ですか

データベースの起動状態、アラート、バックアップカタログ、アプリケーション接続、重要データ、バッチとインターフェースを確認します。業務担当者による受入確認も必要です。