SAP
SAP HANAバックアップ方法｜データバックアップの手順と復旧設計
SAP HANAのバックアップ方法を、データバックアップ、ログバックアップ、保存先、確認、復旧テストの観点から整理します。運用担当者が実施前に確認すべき権限と設計ポイントも解説します。
SAP HANAでは、障害発生時にデータベースを復旧できる状態を維持するため、データバックアップとログバックアップを組み合わせて運用します。単にバックアップファイルを作成するだけでは不十分で、保存先の可用性、世代管理、バックアップの整合性、復旧テストまで設計することが重要です。
この記事では、SAP HANAのバックアップ方法を初めて整理する管理者向けに、取得前の確認、データバックアップの手順、ログバックアップとの違い、失敗時の確認ポイント、復旧計画までを説明します。実際の環境では、システム構成やHANAのバージョン、ストレージ製品、バックアップエージェントの仕様に合わせて手順を調整してください。
SAP HANAバックアップの基本
SAP HANAのバックアップは、主にデータバックアップとログバックアップに分けて考えます。データバックアップは、ある時点のデータベース状態を保存するものです。一方、ログバックアップは、前回のデータバックアップ以降に発生した変更を記録し、より新しい時点への復旧を可能にします。
データバックアップとは
データバックアップには、データボリュームの内容を保存するフルバックアップや、構成によっては差分・増分に相当する方式があります。取得頻度が高いほど復旧時のログ適用量を抑えやすくなりますが、保存容量とI/O負荷は増加します。
ログバックアップとは
ログバックアップは、データベースの変更履歴を継続的に保存します。ログ領域が満杯になると、設定によってはトランザクション処理に影響するため、バックアップ先の容量と到達性を常に確認する必要があります。ログバックアップの設計は、関連するSAP HANAログバックアップの設定も参照してください。
バックアップとスナップショットの違い
ストレージスナップショットは短時間で取得できる場合がありますが、バックアップ製品やストレージに依存します。また、スナップショットだけでは別サイト保管、長期保存、世代管理、復旧手順の要件を満たせないことがあります。スナップショットを使う場合も、データベースの整合性と復旧可能性を別途検証します。
取得前に確認する項目
バックアップを開始する前に、対象データベース、取得方式、保存先、実行ユーザー、保持期間を確認します。特に本番環境では、検証用システムの設定をそのまま流用しないようにしてください。
対象範囲として、システムデータベース、テナントデータベース、関連するバックアップカタログを整理します。マルチテナント構成では、どのデータベースを対象にするかによって実行方法や必要権限が変わります。
次に、保存先の空き容量と接続状態を確認します。ローカルディスクだけでなく、共有ファイルシステム、バックアップサーバー、オブジェクトストレージなどを利用する場合は、ネットワーク経路、認証情報、暗号化、転送時間も確認します。
最後に、業務時間帯の負荷を把握します。データバックアップは通常の処理とI/Oを共有するため、ピーク時間に実行すると業務処理が遅くなる可能性があります。実行時間を決めるときは、単純な時刻ではなく、バックアップの所要時間と業務の繁忙度を基準にします。
HANAデータバックアップの手順
ここでは、SAP HANA cockpitなどの管理ツールを使ってデータバックアップを取得する場合の一般的な流れを示します。画面名や項目は製品バージョンや権限によって異なるため、実際の環境では公式ドキュメントと管理ポリシーを優先してください。
1. 対象データベースを選択する
管理ツールにログインし、バックアップ対象のシステムデータベースまたはテナントデータベースを選択します。複数のテナントが存在する場合、対象を取り違えないことが最優先です。作業前にホスト名、データベース名、システム識別子を記録しておくと、誤操作を防ぎやすくなります。
2. バックアップ設定を確認する
バックアップ先、バックアッププレフィックス、保存形式、認証情報などを確認します。既存のバックアップ運用がある場合は、同じ保存先に手動バックアップを追加することで、容量計画や世代管理に影響しないかを確認してください。
3. バックアップを開始する
取得対象と保存先を確定し、バックアップを開始します。実行中は、進捗、転送速度、エラーの有無、データベースへの負荷を監視します。開始操作が成功しても、完了まで正常だったとは限りません。
4. 完了状態を確認する
完了後は、バックアップ履歴やバックアップカタログでステータスを確認します。成功と表示されていることだけでなく、開始時刻、終了時刻、サイズ、保存先、対象データベース、バックアップIDを記録します。運用記録には、実施者と確認者も残すと監査や障害対応に役立ちます。
5. 保存先から実体を確認する
管理ツール上の履歴に加え、保存先にバックアップファイルが存在することを確認します。ファイルの所有者、アクセス権、更新時刻、容量を確認し、別のサーバーやストレージからも読み出せるかを検証します。
バックアップ取得を自動化する方法
定期バックアップは、手動操作ではなくスケジューラーやバックアップ製品で自動化するのが一般的です。自動化する場合は、成功時だけでなく失敗時の通知と再試行も設計します。
ジョブには、対象データベース、実行頻度、保存先、保持世代、開始時刻、タイムアウト、通知先を定義します。複数のジョブが同時に動くと、ストレージやネットワークの帯域を圧迫するため、フルバックアップとログバックアップの時間帯を調整してください。
運用監視では、ジョブの終了コードだけでなく、バックアップ容量の急減、所要時間の急増、ログバックアップの停止、保存先の空き容量低下を検知します。正常終了していても、ファイルが想定外の場所に保存されているケースがあるため、保存先の実体確認を監視に含めます。
自動化用のアカウントには、必要最小限の権限を付与します。個人ユーザーのパスワードに依存すると、異動やパスワード変更でジョブが停止することがあります。サービスユーザーを利用する場合も、認証情報の保管方法、更新方法、利用範囲を文書化します。
バックアップの保存先と保持期間
保存先は、障害の種類と復旧目標から逆算します。同じホスト上の別ディレクトリだけに保存すると、ホスト障害やファイルシステム障害に弱くなります。少なくとも、運用上重要なバックアップは本番データとは異なる障害ドメインに複製することを検討します。
保存先を比較するときは、次の項目を確認します。
- 書き込みと読み出しの性能
- ネットワーク断や認証失敗への耐性
- 暗号化とアクセス制御
- 保持世代と自動削除の仕組み
- 別サイトや遠隔地への複製可否
- 復旧サーバーからのアクセス可否
- 障害時のサポート体制
保持期間は、法令、業務要件、監査要件、復旧ポイント目標を組み合わせて決めます。例えば、日次のデータバックアップを一定期間保持し、ログバックアップをより短い間隔で保存する設計が考えられます。ただし、世代数を増やすほど容量と管理コストも増えるため、実容量に基づいて試算してください。
暗号化を利用する場合は、バックアップデータと鍵を同じ障害領域だけに置かないことが重要です。鍵を失うとファイルが残っていても復旧できないため、鍵のバックアップ、アクセス権、更新期限、復旧責任者を明確にします。
バックアップ成功を確認する方法
バックアップの成否は、管理画面の表示だけで判断しません。次の三段階で確認すると、形式的な成功と実際の復旧可能性を分けて評価できます。
第一に、HANAのバックアップ履歴とカタログを確認します。対象、時刻、種類、ステータス、サイズ、バックアップIDを記録します。第二に、保存先のファイルやオブジェクトを確認し、期待した世代と一致しているかを確認します。第三に、検証環境で復旧手順を実行し、データベースが起動して業務接続を受け付けられることを確認します。
復旧テストでは、単に起動できるかだけでなく、アプリケーションから接続できるか、ユーザーや権限が想定どおりか、最新のログを適用できるか、文字コードや時刻に問題がないかも確認します。テスト結果には、所要時間と発見した課題を残します。
バックアップの監視で異常を見つけたときは、SAP HANA cockpitのアラート確認もあわせて確認すると、容量不足やホスト状態などの周辺要因を切り分けやすくなります。
バックアップに失敗したときの切り分け
バックアップが失敗した場合は、再実行を繰り返す前に、エラーの発生箇所を分けて確認します。原因を記録せずに再実行すると、保存先の容量をさらに消費したり、同じ障害を見逃したりする可能性があります。
保存先の容量不足
保存先の空き容量、クォータ、世代削除ジョブを確認します。自動削除が動いていても、開いているファイル、権限不足、保持ポリシーの条件不一致によって削除されない場合があります。不要なファイルを手動削除する前に、バックアップカタログとの対応関係を確認してください。
権限または認証の問題
バックアップ実行ユーザーが対象データベースを操作できるか、保存先に書き込めるかを確認します。サービスユーザーの有効期限、認証情報の更新、共有ストレージのマウント状態も調べます。権限を広げて一時的に解決するのではなく、必要な権限を特定して恒久対応します。
ネットワークやストレージの問題
共有ストレージや遠隔地への転送では、名前解決、経路、帯域、タイムアウト、ストレージ側のエラーを確認します。バックアップの開始は成功していても、転送途中で切断されることがあります。HANA側のログだけでなく、OS、ストレージ、ネットワークのログを同じ時刻で照合します。
ログ領域やバックアップカタログの問題
ログバックアップが停止している場合は、ログ領域の使用量とバックアップ先を確認します。バックアップカタログが不要な履歴で肥大化している場合は、保持方針に従って整理します。カタログ操作は復旧に影響することがあるため、実施前に手順とバックアップ状態を確認します。
復旧計画を設計するポイント
バックアップは、復旧できて初めて価値を持ちます。復旧計画では、RPO、RTO、復旧対象、復旧先、担当者、連絡経路、判断基準を定義します。
RPOは、障害発生時にどの時点までのデータを戻せればよいかを示します。RPOが短い場合は、ログバックアップの頻度、転送遅延、保存先の可用性が重要になります。RTOは、サービスを何分または何時間で再開する必要があるかを示します。RTOが短い場合は、復旧環境、待機リソース、手順の自動化、復旧テストの頻度を検討します。
復旧手順書には、次の情報を含めます。
- 障害の影響範囲と復旧開始条件
- 対象データベースと復旧時点
- 使用するデータバックアップとログバックアップ
- 認証情報と暗号鍵の取得方法
- 復旧先ホストとストレージ
- アプリケーション停止・起動の順序
- 復旧後の整合性確認
- 利用者への完了通知と記録方法
復旧テストは、少なくとも構成変更やストレージ変更の後に実施します。担当者が変わった場合も、引き継ぎ資料だけでなく、実際の復旧操作を通じて手順を検証します。手順書に書かれたコマンドや画面遷移が、現在の環境と一致しているかも確認してください。
運用チェックリスト
日次運用では、前回のデータバックアップとログバックアップが成功しているか、保存先の容量に余裕があるか、異常通知がないかを確認します。週次または月次では、保持世代、複製状態、監視ルール、サービスユーザーの有効性を確認します。
作業前には対象と保存先を確認し、作業後にはステータス、ファイル、記録を確認します。チェックを担当者一人に依存させず、重要な本番操作では相互確認を取り入れると、対象の取り違えや記録漏れを減らせます。
HANAの管理操作や権限に不安がある場合は、関連するSAP HANAユーザー権限の確認も整理してください。バックアップの実行権限だけでなく、履歴確認、復旧操作、保存先アクセスに必要な権限を分けて管理することが大切です。
まとめ
SAP HANAのバックアップ方法を設計するときは、データバックアップだけでなく、ログバックアップ、保存先、保持期間、監視、復旧テストを一体として考えます。取得操作が成功していることと、障害時に復旧できることは同じではありません。
まず対象データベースと保存先を明確にし、定期取得を自動化します。次に、履歴と保存先の実体を確認し、定期的に検証環境で復旧テストを行います。最後に、RPOとRTOに沿って手順書を更新し、担当者が変わっても実行できる運用を整えます。公式情報を確認しながら、自社のHANAバージョンとストレージ構成に適した手順へ具体化してください。
よくある質問
実務では：SAP HANAのバックアップはどの頻度で取得しますか
頻度は、許容できるデータ損失、バックアップ時間、保存容量、業務負荷で決めます。データバックアップを定期的に取得し、ログバックアップをより短い間隔で保存する構成が一般的ですが、最適な値は環境ごとに異なります。
実務では：データバックアップだけで復旧できますか
取得時点までの復旧であればデータバックアップを使える場合がありますが、より新しい時点へ戻すにはログバックアップが必要になることがあります。復旧要件に応じて、両方の取得状態と保存期間を確認してください。
実務では：バックアップが成功なら復旧も保証されますか
保証されるとは限りません。保存先の破損、鍵の紛失、権限不足、復旧環境の差異などで復旧できない可能性があります。定期的な復旧テストで、実際に使えることを検証してください。
実務では：バックアップ先は本番サーバー内で十分ですか
本番サーバー内だけの保存は、ホスト障害やランサムウェア、ファイルシステム障害への耐性が不足する場合があります。別の障害ドメインや遠隔地への複製を、業務要件とコストに応じて検討します。