バックアップの「成功」を信じすぎない：Azure Backup の運用監視と復元テスト、その先の承認フロー

バックアップは、取れていることよりも、戻せることに価値があります。この記事では、Azure Backup を例に、運用で見落としやすい監視の要点と、復元テストの進め方をまとめます。

症状：ジョブは成功しているのに、戻せなかった

「ジョブは毎日成功していたが、いざ復元しようとしたら、必要なデータが入っていなかった」「保持期間が、想定より短かった」という問題は、珍しくありません。

失敗のアラートは、ジョブが動いたときにしか出ません。バックアップの対象が増えたのに、保護の設定をしていない、という漏れは、アラートでは気づけません。保護されていないリソースの一覧を、定期的に見直します。

Recovery Services コンテナーの論理的な削除（ソフトデリート）を確認する。現在は既定で有効で、Microsoft Learn によれば無効にできません（Recovery Services コンテナー）。削除済みデータの保持期間は既定14日、14〜180日で変更でき、14日を超える分は通常のバックアップ料金がかかる。誤削除や、悪意のある削除から、一定期間は戻せる
重要なデータには、変更・削除できない保管（不変コンテナー）も検討する

年に1〜2回は、実際に復元します。復元手順を、初めて試すのが障害の当日、という状況を避けます。確認するのは、次の3点です。

誰がいつ、バックアップの設定を変えたか。復元の操作が、いつ行われたか。これを、ログとして残すことが、監査では求められます。

データの保護を固めても、社内では、別の場所で仕事が止まります。

データを守る仕組みと、仕事の流れを見える化する仕組みは、別の問題です。

KASANERU の申請・承認機能は、出した申請が、いま誰のところで止まっているかを、画面で確認できます。止まっている申請は、管理者が一覧で見られます。差し戻しと却下の区別があり、誰がいつ承認したかは、申請ごとに記録が残ります。経費・購入の申請では、その部署の予算の残りも、画面で確認できます。

詳しくは、稟議・申請の承認ワークフローをご覧ください。30日間、無料で試せます。