Windows Server 2022 で Azure Backup（MARS エージェント）を使って「全ドライブのバックアップ」と「システム状態（System State）バックアップ」を別時刻で回していると、System State 側だけ毎日いったん失敗し、数十分後に自動再実行されて成功するケースがあります。原因はバックアップジョブの同時実行競合で、解消するには System State の開始時刻を「タスク スケジューラ」側でずらすのが近道です。
今回の質問で起きていること（結論：バックアップジョブの競合）
状況を整理すると、次のような運用になっています。
| 種類 | 開始時刻 | 対象 | 結果 | 補足 |
|---|---|---|---|---|
| 通常バックアップ | 毎日 11:30 | 全ドライブ | （多くの場合）成功 | データ量や I/O 次第で長引く |
| System State バックアップ | 毎日 2:30 | システム状態 | いったん失敗 → 自動再試行で成功 | 失敗時のエラーが通知メールになりやすい |
System State 側の失敗メッセージは次の内容です。
The operation failed because another job is running on Windows Server Backup. This job will be retried on its own. (0x18734)
これは文字どおり「Windows Server Backup 側で別ジョブが走っていて、System State バックアップが開始できなかった」ことを示します。つまり、バックアップそのものの品質や資格情報の問題ではなく、実行タイミングの重なりが原因です。
そして厄介なのが、失敗した後に自動で再実行されて成功するため、運用上は守れているように見える一方で、毎日“失敗扱い”の通知が飛んでくる点です。アラートがノイズ化すると、本当に見なければいけない障害が埋もれやすくなるので、ここは素直にスケジュールをずらして解消するのが安全です。
なぜ Windows Server Backup の「スケジュール バックアップ」に出てこないのか
ここがハマりポイントです。同じ「バックアップ」でも、次の2系統で管理されています。
| 項目 | 管理元 | 画面・場所 | 編集できる内容 | 今回の System State は？ |
|---|---|---|---|---|
| Windows Server Backup のスケジュール | Windows Server Backup | Windows Server Backup コンソール 「スケジュール バックアップ」 | 通常のボリューム/フォルダーなど | 原則ここには出てこない |
| Azure Backup（MARS エージェント）のジョブ | MARS エージェント | Windows タスク スケジューラ （Microsoft > OnlineBackup） | Azure へのバックアップ実行タイミング | こちらで動いている |
System State バックアップは、見た目は Windows Server Backup の機能に見えますが、Azure Backup（Recovery Services / MARS エージェント）が別のタスクとしてスケジュールし、Windows のタスク スケジューラで実行管理されている構成が一般的です。
そのため、Windows Server Backup の「スケジュール バックアップ」画面でいくら探しても見つからず、時刻変更もできません。時刻を変えるには、タスク スケジューラ側のトリガーを編集します。
【解決】タスク スケジューラで System State バックアップの開始時刻を 3:15 に変更する
ここからが具体的な手順です。目的は「毎日 2:30」に動いている System State タスクの開始時刻を「毎日 3:15」に変更し、他ジョブとの競合を避けることです。
手順の全体像
- タスク スケジューラを開く
- Microsoft > OnlineBackup 配下のタスクを探す
- 2:30 トリガーのタスクを特定する
- トリガーの開始時刻を 3:15 に変更する
- 動作確認（次回実行・履歴・ログ）
1. タスク スケジューラを起動する
- スタートメニューで「タスク スケジューラ」と検索して起動します。
- ショートカットとしては「taskschd.msc」を実行してもOKです。
2. 該当フォルダを開く（Microsoft > OnlineBackup）
左ペインで次の場所まで展開します。
- タスク スケジューラ ライブラリ
- Microsoft
- OnlineBackup（環境によっては「Online Backup」と表示される場合があります）
ここに Azure Backup（MARS エージェント）が作成したタスクが並びます。名前は環境差がありますが、代表的には「Microsoft-OnlineBackup」など、OnlineBackup に関連するタスクです。
3. 2:30 実行のタスクを特定する（ここが最重要）
タスクが複数ある場合は、名前だけで判断せず、トリガーと操作で確実に特定します。
- 対象タスクをダブルクリック（または右クリック→プロパティ）
- 「トリガー」タブを開く
- 「毎日 2:30」になっているトリガーがあるタスクを探す
さらに確実にするなら、「操作」タブも確認してください。ここに「どのプログラム（またはスクリプト）を実行しているか」が出ます。System State 用のタスクであれば、Azure Backup の実行コンポーネント（MARS エージェント側）に紐づく動作になっていることが多いです。
見分けるコツを表にまとめます。
| 確認ポイント | 見る場所 | 判断の目安 | よくあるミス |
|---|---|---|---|
| 開始時刻 | トリガー | 「毎日 2:30」がある | 別タスクの 2:30 を掴む（同時刻タスクが複数） |
| 実行内容 | 操作 | Azure Backup / OnlineBackup 系の実行 | 関係ない管理タスクを編集する |
| アカウント | 全般 | SYSTEM またはローカル管理者で実行 | 権限不足で“今度は別理由で失敗”を作る |
4. 「トリガー」から開始時刻を 2:30 → 3:15 に変更する
該当タスクを特定できたら、次の手順で時刻を変更します。
- 対象タスクのプロパティを開く
- 「トリガー」タブを開く
- 「毎日 2:30」のトリガーを選択して「編集」
- 「開始」を2:30 → 3:15へ変更
- 必要に応じて「有効」がオンになっていることも確認
- OKで保存し、プロパティもOKで閉じる
これで System State バックアップは毎日 3:15 に開始されるようになり、他のバックアップジョブと重なりにくくなります。その結果、競合による「一度失敗 → 自動再試行で成功」という流れが止まり、不要な失敗通知メールの解消が期待できます。
変更後に必ずやるべき確認（“直ったつもり”を防ぐ）
スケジュール変更は簡単ですが、運用としては「変更したからOK」ではなく、次の観点で確認しておくと安心です。
| 確認項目 | 確認方法 | OKの目安 | NG時の対処 |
|---|---|---|---|
| タスクが 3:15 で動くか | タスク スケジューラの「次回実行時刻」「最終実行時刻」 | 次回実行が 3:15 になっている | トリガー編集漏れ／別タスクを編集した可能性 |
| 実行結果が成功か | タスクの「最終実行結果」や履歴 | 成功（0x0 等）になっている | 実行アカウントや権限、タスクの設定を見直す |
| エラー通知が止まったか | Azure 側のアラート/通知メール | 0x18734 の失敗通知が出ない | まだ競合している／別時間帯のジョブと重複 |
| バックアップウィンドウに余裕があるか | バックアップ所要時間の把握 | 他ジョブと重ならない | 開始時刻をさらに 15〜30 分ずらす |
特に、全ドライブのバックアップが日によって伸びる環境（更新処理、I/O が重い、VSS の影響、バックアップ先の性能など）では、3:15 にしてもギリギリ重なる可能性があります。運用開始後しばらくは、所要時間の傾向を見て「さらに 15〜30 分後ろにずらす」判断ができるよう、ログの見え方を整えておくと事故が減ります。
よくあるつまずきと対処（2:30を変えたのに改善しない場合）
時刻変更だけで解消することが多い一方、環境によっては追加の見直しが必要になることがあります。代表的なパターンをまとめます。
別タスクを編集していた（System State のタスクではなかった）
OnlineBackup 配下にタスクが複数あると、似た名前のものを編集してしまいがちです。必ず「トリガーが 2:30」「操作が Azure Backup 実行系」の両方で特定してください。2:30 のタスクが複数ある場合は、さらに「操作」タブの実行内容で絞り込みます。
トリガーが無効（無効化）になっている
トリガーの編集画面で「有効」がオフになっていると、設定しても実行されません。変更時にチェックし、必要ならオンにします。
実行アカウントが不適切で失敗している
タスクの「全般」タブで、実行ユーザーが SYSTEM またはローカル管理者相当になっているか確認します。権限不足になると、今度は別の理由で失敗通知が増えることがあります。
バックアップが重なっている相手が “全ドライブ” とは限らない
競合相手が毎日 11:30 のバックアップとは限りません。例えば次のような処理が深夜帯に走っていると、バックアップの開始・終了に影響します。
- Windows Update（再起動やコンポーネント更新）
- ウイルス対策ソフトのフルスキャン
- ディスク最適化、ログローテーション、バッチ処理
- ストレージ側（NAS等）のメンテナンス
バックアップの“競合”は、バックアップ同士だけではなく「I/O を食う処理」との競合でも所要時間が伸び、結果的に重なってしまうことがあります。
タスクの「既に実行中の場合」の設定が不適切
同じタスクが重複起動しないように、タスクの「設定」タブにある「既にタスクが実行中の場合」の挙動も一度確認しておくと安心です。意図しない二重起動が起きると、「別ジョブが動いている」系の警告が増える原因になります。
GUIが不安な人向け：コマンドで“対象タスクを見える化”する
GUI 操作は確実ですが、運用者が複数いる現場では「どのタスクを触ったか」が曖昧になりがちです。変更前の棚卸しとして、次のようにコマンドで確認しておくと、手戻りが減ります。
schtasks で OnlineBackup 配下を一覧する例
schtasks /Query /TN "\Microsoft\OnlineBackup" /FO LIST /V環境によってはタスク名を完全一致で指定する必要があるため、まずは Task Scheduler 上のパスを見て、該当タスクのフルパスを確認してから実行するとスムーズです。
PowerShell でタスクとトリガーを確認する例
Get-ScheduledTask -TaskPath "\Microsoft\OnlineBackup\" |
Select-Object TaskName, TaskPath, State「どのタスクが何時に動くか」を見たい場合は、トリガー情報も併せて確認します（環境差があるため、まずは取得できるプロパティを確認しながら進めるのが安全です）。
運用のコツ：バックアップ時間の設計で“通知ノイズ”を減らす
今回のような 0x18734 は、「エラーそのもの」よりも「通知が毎日届く」ことが現場の負担になります。スケジュールを見直すときは、次の考え方が効きます。
コツ1：バックアップ同士は“余白”を持たせる
目安としては、直前ジョブの想定終了時刻から 15〜30分は余白を確保するとトラブルが減ります。日々のバックアップ所要時間がブレるなら、余白は広めが安全です。
コツ2：重要度の高いバックアップ（System State）を“確実に動く場所”へ置く
System State は復旧局面で効くバックアップです。特に AD DS を抱えるサーバーや、役割が多いサーバーでは影響が大きいので、システム負荷が落ち着く時間帯に置くのが基本です。今回の「3:15」にずらすのは、まさにその考え方に沿っています。
コツ3：変更したら“数日分の結果”を見てから固定する
変更翌日だけ成功しても、週次・月次の処理が走る日だけ失敗することがあります。最低でも数日、できれば 1〜2 週間ほど結果を観察し、「もう少し後ろにずらした方が安定する」などの調整余地を残しておくと、長期的な運用が楽になります。
まとめ：System State の時刻は「タスク スケジューラ」で変える
Windows Server 2022 の Azure Backup（MARS エージェント）で System State バックアップが「0x18734（別ジョブ実行中）」になり、再試行で成功しているなら、原因はジョブ競合の可能性が高いです。そして、System State のスケジュールは Windows Server Backup の「スケジュール バックアップ」には出てこないため、タスク スケジューラ（Microsoft > OnlineBackup）で該当タスクのトリガー時刻を変更するのが正攻法です。
開始時刻を 3:15 などにずらして競合を避けることで、不要な失敗通知メールが減り、バックアップ監視の精度も上がります。バックアップは“取れていること”と同じくらい、“異常を見逃さない運用”が大切なので、通知ノイズを潰す改善として取り組む価値は大きいです。
コメント