SAP HANAのログバックアップ設定とログ領域がいっぱいになった場合の対処法

SAP HANAでは、データボリュームに保存されるデータバックアップとは別に、トランザクションログを継続的に保護する仕組みが必要です。ログバックアップが正常に動作していないと、データベースの再起動や障害発生時に、最後のデータバックアップ以降の変更を復旧できなくなる可能性があります。

この記事では、ログバックアップ設定の考え方、保存先の確認、SAP HANA cockpitとSQLを使った監視、ログ領域がいっぱいになった場合の安全な対処を説明します。環境やHANAのバージョンによって画面名やSQLの列名が異なるため、実行前に対象システムの公式ドキュメントと運用手順を確認してください。

01ログバックアップの役割

SAP HANAのログには、データベースに対する変更が記録されます。通常、変更されたログセグメントはログバックアップとして永続ストレージへ退避され、障害復旧時にはデータバックアップとログバックアップを組み合わせて利用します。

基本的な復旧の流れは、次のように考えると分かりやすいでしょう。

1. 最後に取得した完全または差分のデータバックアップを復元する
2. そのバックアップ以降に取得されたログバックアップを順番に適用する
3. 必要に応じて、障害直前までのログを適用する
4. データベースを検証し、業務接続を再開する

したがって、データバックアップが毎日成功していても、ログバックアップが停止していれば、復旧可能な時点が古くなることがあります。ログバックアップは単独のバックアップではなく、データバックアップと組み合わせて使う復旧要素です。

02HANAログバックアップの設定項目

ログバックアップの設定では、主に保存先、バックアップ方式、実行間隔、保存期間、バックアップツールとの連携を確認します。HANA 2.0では、ファイルベースのバックアップに加えて、バックアップサーバーや認定された外部バックアップ製品を利用する構成もあります。

代表的な確認項目は次のとおりです。

保存先を変更する場合は、設定変更だけでなく、旧保存先に残るバックアップの扱いも決めます。新しい保存先へ切り替えた後、旧バックアップをすぐ削除すると復旧チェーンが分断されることがあるため、保持期間、バックアップカタログ、削除手順を確認してから作業します。

保存先を決めるときの考え方

保存先は、HANAサーバーのローカルディスクだけで判断しません。障害の種類によっては、データベースサーバー自体が利用できなくなるため、別ホスト、別ストレージ、別サイトへのコピーが必要になる場合があります。

また、ログバックアップの書き込み速度がログ生成速度を下回ると、未処理のログが蓄積します。ピーク時のトランザクション量、ネットワーク帯域、暗号化や圧縮の処理時間を含めて設計することが重要です。

03ログバックアップ設定を確認する手順

設定確認は、まず管理ツールで全体像を把握し、その後SQLやOSレベルの情報で裏付ける順序が安全です。いきなり設定を変更せず、現在の保存先、最終成功時刻、失敗理由、未処理ログの量を記録します。

SAP HANA cockpitで確認する

SAP HANA cockpitを利用できる場合は、対象データベースを開き、バックアップとリカバリに関する画面を確認します。画面の名称はバージョンやロールによって異なることがありますが、次の情報を探します。

• 最新のログバックアップの開始時刻と終了時刻
• 成功、警告、失敗のステータス
• バックアップ先とバックアップサイズ
• 失敗時のエラー内容
• データバックアップおよびログバックアップの履歴
• バックアップカタログの状態

監視画面で成功と表示されていても、保存先の実体が読めるとは限りません。ストレージのマウント、アクセス権、空き容量、ネットワーク接続を別途確認します。SAP HANA cockpitのアラート確認も併用すると、容量不足やバックアップ異常を早期に発見しやすくなります。

SQLで履歴と設定を確認する

SQLによる確認では、バックアップカタログやシステムビューを参照します。利用できるビュー、列名、必要な権限はバージョンや構成によって異なるため、下記は調査の方向性を示す例として扱ってください。

-- バックアップ履歴を確認する例
SELECT TOP 20
       BACKUP_ID,
       ENTRY_TYPE_NAME,
       STATE_NAME,
       SYS_START_TIME,
       SYS_END_TIME,
       DESTINATION_PATH
  FROM SYS.M_BACKUP_CATALOG
 ORDER BY SYS_START_TIME DESC;

ログバックアップだけに絞り込む場合も、環境で使用されているエントリタイプの表記を確認してから条件を指定します。ビューの列が存在しない場合は、SYS.TABLE_COLUMNSや対象HANAバージョンのリファレンスで定義を調べてください。

SQLで確認したいポイントは、単に最新行があるかどうかではありません。一定間隔で成功しているか、失敗が連続していないか、バックアップサイズが急増していないか、保存先のパスが期待どおりかを時系列で見ます。

コマンドラインで確認する

OSやHANAのコマンドラインを使用する場合は、対象インスタンス、実行ユーザー、環境変数を間違えないことが重要です。hdbsqlなどを使う場合でも、運用環境の認証方式と監査ルールに従い、パスワードをコマンド履歴へ残さないようにします。

バックアップ履歴の確認には、GUIとSQLの結果を突き合わせます。GUIで表示される時刻がローカル時刻、SQLの時刻がUTCである可能性もあるため、タイムゾーンをそろえて判断します。

04ログバックアップが失敗する主な原因

ログバックアップの失敗は、HANA内部だけでなく、OS、ネットワーク、ストレージ、外部バックアップ製品のいずれでも発生します。エラーメッセージを見ずに保存先を変更したり、ログファイルを削除したりすると、復旧に必要な情報を失うおそれがあります。

保存先の容量不足

最も分かりやすい原因の一つが、バックアップ保存先の空き容量不足です。ただし、保存先のファイルシステムだけでなく、共有ストレージのクォータ、スナップショット予約領域、inode、マウントポイントの親ファイルシステムも確認します。

容量不足を解消する際は、まず保持ポリシーに従って不要なバックアップを削除できるか確認します。手動で任意のログファイルを削除するのではなく、HANAが提供するバックアップ管理機能や、認定バックアップ製品のライフサイクル管理を利用してください。

権限またはマウントの問題

保存先がマウントされていない、所有者やグループが変わった、共有ストレージへの認証が失効した、といったOS側の問題もあります。HANAのサービスユーザーが対象ディレクトリへ作成、書き込み、読み取りできるかを、セキュリティポリシーに沿って確認します。

ネットワークまたは外部製品の問題

外部バックアップサーバーを利用している場合は、名前解決、ポート、証明書、エージェント、バックアップメディアの状態を確認します。HANAのジョブログだけでなく、バックアップ製品の管理画面やエージェントログにも原因が出ていることがあります。

ログ生成量の急増

大量の更新、バッチ、インポート、長時間トランザクション、アプリケーション障害などにより、通常よりログ生成量が増える場合があります。ログバックアップ自体が成功していても、生成速度が退避速度を上回れば未処理ログは増え続けます。

この場合は、バックアップ設定だけでなく、原因となった業務処理、ストレージ性能、ネットワーク帯域、圧縮方式を調査します。原因を確認せずにログ領域だけ拡張すると、問題を先送りするだけになることがあります。

05ログ領域がいっぱいになった場合の対処

「hana ログ領域 いっぱい」という状態では、データベースの書き込みやトランザクションに影響が出る可能性があります。最初に、アプリケーション処理を継続してよいか、業務責任者と運用責任者で判断します。緊急時でも、証拠となるログとバックアップ履歴を保存してから変更を行います。

最初に確認する項目

1. ログバックアップが最後に成功した時刻
2. 最後に成功したデータバックアップの時刻
3. 未処理ログの量と増加速度
4. 保存先の空き容量とマウント状態
5. 長時間トランザクションの有無
6. バックアップカタログに不整合がないか
7. ストレージや外部バックアップ製品の障害有無

ログ領域の再利用を妨げている原因が、ログバックアップの失敗なのか、長時間トランザクションなのか、別のバックアップ処理なのかを分けて考えます。原因によって安全な対応が異なります。

安全な復旧アプローチ

保存先の容量不足であれば、承認済みの保持ポリシーに従って古いバックアップを整理し、必要なら一時的に容量を追加します。ログバックアップが失敗している場合は、エラー原因を解消して、復旧チェーンを壊さない形で再実行します。

長時間トランザクションが原因の場合は、処理の所有者を確認し、強制終了の影響を評価します。トランザクションを終了させるとロールバックに追加のログや時間が必要になることもあるため、単純にセッションを切断しないでください。

緊急時にログファイルをOSから直接削除すること、バックアップカタログを手動で編集すること、原因不明のままデータベースを再起動することは避けます。復旧不能やデータ不整合につながる可能性があるため、SAPのサポート手順や組織の緊急変更手順に従います。

06トラブルシューティングの切り分け

次の順序で切り分けると、設定ミスと基盤障害を分離しやすくなります。

1. 時系列を作る：最後の成功、最初の失敗、容量が増え始めた時刻を記録する
2. 保存先を確認する：パス、マウント、空き容量、権限、クォータを調べる
3. エラーを照合する：HANAの履歴、アラート、トレース、外部製品ログを同じ時刻で比較する
4. 生成量を確認する：通常日と障害発生日のログ量を比べる
5. 復旧可能性を確認する：データバックアップとログバックアップが連続しているか検証する
6. 小さく検証する：設定変更後にテストバックアップと履歴確認を実施する

トレースやログを共有する場合は、ホスト名、ユーザー名、接続先、業務データなどの機密情報をマスキングします。ログを編集する場合でも、時刻、エラーコード、処理の順序を壊さないように、原本を保管してから複製を作成します。

07バックアップとリカバリの運用設計

ログバックアップ設定は、単独の管理作業ではなく、バックアップとリカバリ全体の一部です。復旧時に誰が判断し、どのバックアップを使い、どこまでの時点へ戻し、どのように業務データを検証するかを手順書に明記します。

最低限、次の運用を定期的に確認します。

• ログバックアップの成功率と遅延
• 保存先の容量と増加傾向
• データバックアップとの復旧チェーン
• バックアップカタログの可読性
• バックアップからのリストアテスト
• ランサムウェアや誤削除を想定した分離保管
• 担当者不在時の連絡経路

リストアテストでは、バックアップが存在することだけでなく、実際に復元できること、必要なログを適用できること、アプリケーションが整合性を確認できることを検証します。テスト結果には、開始時刻、使用したバックアップ、適用したログ、所要時間、発見した課題を記録します。

08設定確認チェックリスト

作業前後に、次のチェックリストを利用できます。

作業前

• 変更理由と対象データベースを記録した
• 現在の保存先と最終成功時刻を記録した
• データバックアップとログバックアップの保持期間を確認した
• 変更承認と作業時間帯を確認した
• ストレージ、ネットワーク、外部製品の担当者を把握した

作業後

• テストまたは予定されたログバックアップが成功した
• バックアップ履歴に新しい成功記録がある
• 保存先に期待するファイルまたは外部製品の記録がある
• アラートが解消された
• ログ領域の使用量が安定した
• 復旧手順書と監視設定を更新した

09まとめ

SAP HANAのログバックアップを安定させるには、保存先を設定するだけでは不十分です。ログ生成量、退避速度、保存容量、保持期間、バックアップカタログ、復旧テストを一体として管理する必要があります。

ログ領域がいっぱいになった場合は、ログファイルを直接削除するのではなく、最後の成功時刻、失敗理由、保存先、長時間トランザクション、外部バックアップ製品を順に確認します。設定変更後は必ず履歴と実際の復旧可能性を検証し、再発防止として容量監視と定期的なリストアテストを組み込みましょう。

10よくある質問

ログバックアップとデータバックアップは同じものですか？ いいえ。データバックアップはデータの基準点を作り、ログバックアップはその後の変更を復旧するために使います。通常は両方がそろって初めて、期待する時点への復旧が可能になります。

ログバックアップの保存先を変更しても問題ありませんか？ 事前に保持期間、復旧チェーン、旧保存先のバックアップ、アクセス権を確認すれば変更できます。切り替え直後にはテストを行い、履歴と保存先の両方を確認してください。

ログ領域がいっぱいになったらログファイルを削除できますか？ OSから直接削除する方法は避けてください。バックアップの状態やトランザクションの状況を確認し、承認済みのHANAまたはバックアップ製品の管理手順で容量を回復します。

SAP HANA cockpitだけで原因を特定できますか？ cockpitは重要な履歴やアラートを確認できますが、OSのマウント、ストレージ、ネットワーク、外部バックアップ製品のログまで確認する必要がある場合があります。

設定変更後に何を確認すべきですか？ 新しいログバックアップが成功したこと、保存先へ書き込まれたこと、アラートが解消したこと、ログ領域の使用量が安定したことを確認します。可能であれば復旧テストも実施します。