VPN が戻っても NAS のバックアップは失敗し続けた
緑のトンネルは完了したリカバリ ポイントではありません。タスクの状態、保存先の準備状況、整合性チェックの時間帯をこの順に確認してください。
VPN は 06:10 に再接続し、ダッシュボードはトンネルを緑で表示し、夜間バックアップにはまだ新しいリカバリ ポイントがありません。それは矛盾ではありません;調整されたことのない二つのスケジュールです。復旧するトンネルはネットワークのイベントです。完了するバックアップは独自の状態マシンを持つアプリケーションのイベントであり、中断された実行は一時停止、取り消し、またはまったく別の何かの後ろでキューに入れられた可能性があります。
ウィンドウはトンネルのインジケーター ランプではなく、完了したリカバリ ポイントを基準に計画してください。
開始時刻ではなくリカバリ ポイントから始める
要件は、受け入れられたバージョンの期限として書きます:指定した時刻までにタスク自身の整合性チェックに合格する新しいリカバリ ポイントです。次に、想定される所要時間、通常の変動、一回の中断された試行をさかのぼって計算します。起動時刻は約束ではありません;スケジューラが試した瞬間にすぎません。期限はチャット メッセージではなくバックアップ ポリシーに置いてください。誰かの記憶の中にしか存在しない数値は監視のしきい値ではありません。
所要時間の見積もりにはタスクの履歴を使います。チャンク処理、重複排除、インデックス作業は実行の一部なので、変更バイト数をリンク速度で割るとウィンドウを過小評価し、後でネットワークの問題のように見えます。
中断がジョブに与える影響
Hyper Backup は再開できる作業とできない作業を区別します:文書化された動作では、接続が切れると再開可能なタスクは一時停止し、再開不可能なタスクは取り消されます。どちらの状態も VPN クライアントからは見えず、トンネルを再接続しても修復されません。次回のスケジュール実行が前回の停止位置から続くと想定する前に、タスクの状態と記録された理由を読んでください。
手動の一時停止とネットワーク中断ではライフサイクルが異なる場合があります。オペレーターがタスクを一時停止した場合、ネットワークを再接続しても何も変わりません。
保存先には独自の要件がある
復旧したトンネルは、暗号化された共有フォルダーをマウントせず、期限切れのバックアップ資格情報を更新せず、保存先のメンテナンスを完了しません。これらは別個の準備チェックであり、どれか一つでも緑のトンネルを失敗したジョブに変えられます。リカバリ スケジュールを責める前に、保存先に到達でき書き込みできることを確認してください。
保存先の NAS 自体が再起動した場合、バックアップ タスクが起動する時点でサービスがまだ起動中かもしれません。短い準備チェックは、失敗した実行と再試行より安上がりです。
整合性チェックは同じ時間帯を奪い合う
整合性チェックはネットワーク障害がまったくなくてもウィンドウを消費します。DSM はタスクごとに一つのアクティブなプロセスを文書化しており、スケジュールされたバックアップはそのタスクの整合性チェックの後ろで待機し、約三時間の最大待機の後にスキップされることがあります。二つのスケジュールは観測された所要時間に応じて間隔を空け、スキップされた実行は VPN が再び失敗した証拠ではなくスケジューリング上の所見として扱ってください。
通知は実際の配信方法で有効にし、読む担当者を割り当ててください。開始されなかったジョブと途中で失敗したジョブは、同じアラートを出さないかもしれません。
朝のチェックはコピーについて行う
朝の問いは、トンネルが上がっているかではなく、現在の復元可能なコピーがあるかです。最後に受け入れられたバージョンの経過時間を期限と照らし合わせ、そのバージョンの小さなファイルで安全なリストア テストを行います。おかしいと思われるものを調査する間は、以前の良好なバージョンを保持してください。
タイムスタンプは一つのタイム ゾーンで記録し、スケジューラのゾーン、保存先のゾーン、ダッシュボードを読む人のゾーンを含めてください。これらの調査の多くはネットワーク障害ではなく時計の差で終わり、そのメモが次回それを可視化します。