Hyper Backupで「exception occurred」というエラーが表示されると、原因を特定する前に設定を総点検したくなる。だが、多くの場合、復元先のバージョン互換性とバックアップ元の整合性を先に確認すれば、作業の半分は解決する。ただし、エラーが発生するタイミングが「タスク実行中」か「復元中」かで見るべきポイントは変わる。
まず、このエラーは特定の一因で起こるわけではない。バックアップ先の空き容量不足、ネットワークの瞬断、データベースの不整合、あるいは単純にパッケージのバージョンが古いだけでも表示される。だからこそ、闇雲に再起動や再インストールを繰り返す前に、環境を絞り込むことが欠かせない。
エラーの出るタイミングで原因のあたりをつける
Hyper Backupのエラーは、大きく三つの場面に分けて考えると整理しやすい。バックアップタスクの実行中、復元ウィザードの途中、そして整合性チェックの完了時だ。
タスク実行中に「exception occurred」が出るなら、書き込み先の応答遅延や容量制限を疑う。たとえば、NASの共有フォルダをバックアップ先にしている場合、そのフォルダが別のプロセスでロックされていると書き込めない。クラウドストレージを指定しているなら、API制限や認証情報の期限切れも候補になる。
復元中にエラーが出る場合は、バックアップデータそのものの破損か、復元先のファイルシステムの不整合が多い。特に、バックアップ元と復元先でDSMのメジャーバージョンが異なると、パッケージの構成情報が正しく戻せないことがある。公式のHyper Backup テクニカルスペックにも、システム全体の復元はリモートのSynology NASに限られるといった制限が明記されている。
整合性チェックで引っかかるなら、バックアップジョブの設定変更や、対象フォルダの権限変更が影響している可能性が高い。チェックを無効にすれば一時的に回避できるが、データの信頼性を損なうため、原因を取り除くまでは無効化しないほうがよい。
エラーを再現させる前に揃えるべき環境
エラーの原因を探るとき、真っ先に手をつけたいのはバックアップタスクの「状態」と「ログ」の突き合わせだ。DSMのパッケージセンターでHyper Backupが最新版であることを確認し、設定 | Hyper Backupの手順に沿って、通知設定とログ出力を有効にしておく。
バックアップタスクの状態とログを見る
DSMのメイン画面からHyper Backupを開き、該当するタスクの「バージョンリスト」を表示する。ここで「不完全」や「破損」と表示されているバージョンがあるなら、それ以降の増分が正常に取れていないことを示す。
同時に、「タスクの設定」から「スケジュール」と「バックアップ先」を見直す。たとえば、バックアップ先をUSBドライブにしている場合、ドライブがスリープから復帰するまでの時間が足りずに書き込みが失敗することがある。公式のHyper Backup についてのよくある質問でも、外部ストレージ使用時の注意点として、接続の安定性が挙げられている。
バックアップ先の空き容量とファイルシステム
クラウドストレージを利用している場合は、各サービスの管理画面で容量を確認する。ローカルやリモートNASを指定しているなら、File Stationで共有フォルダのプロパティを開き、空き容量を調べる。Hyper Backupは増分バックアップと重複排除で容量を節約するが、バージョン数が増えると一時的に大きな空き領域を必要とする。
また、バックアップ先のファイルシステムがBtrfs推奨であることにも注意したい。ext4でも動作するが、整合性チェックやスナップショットとの連携を考えると、Btrfsのほうがエラー検出の面で有利だ。
ネットワーク経路と名前解決
リモートNASやrsyncサーバーをバックアップ先にしている場合、IPアドレスではなくホスト名で指定していると、DNSの応答遅延がエラーの引き金になることがある。一時的にIPアドレス直指定に切り替えて、同じエラーが出るか試すのも有効な切り分けだ。
復元前に見ておくべき公式の制限事項
Hyper Backupは多機能だが、復元にはいくつかの制限がある。これを把握せずに操作を始めると、作業の途中で「対応していない」と表示されて手が止まる。
システム全体のバックアップは、同じアーキテクチャのSynology NASにしか復元できない。ARMモデルで取得したバックアップをx86モデルに復元することはできない。また、暗号化された共有フォルダを復元する場合は、暗号化キーを事前にエクスポートしておく必要がある。
パッケージの復元に失敗するケースでは、復元先のNASに同じパッケージがすでにインストールされていると競合することがある。Hyper Backupの復元ウィザードは、上書きするかどうかを尋ねてくるが、ここで「はい」を選ぶと設定が初期化される場合があるため、事前に復元先のパッケージ設定をバックアップしておくほうが安全だ。
エラーを防ぐためのバックアップ設計
「RAIDはバックアップではない」という前提は、Synologyの公式ドキュメントでも繰り返し強調されている。Hyper Backupを使う場合も、RAIDの冗長性だけに頼らず、別の場所にバックアップを取る設計が基本になる。
バックアップの多重化とローテーション
同じデータを二つの異なるメディアに保存する「3-2-1ルール」を基準にすると、Hyper Backupの設定も決めやすい。たとえば、一次バックアップはローカルのUSB HDDに、二次バックアップはSynology C2 Storageに置く。
バージョンローテーションの設定も、エラー防止に直結する。Smart Recycleを有効にしておけば、毎時・毎日・毎週の最新バージョンを自動で保持するため、手動で削除する手間が省ける。カスタム保持ポリシーでは、最大7つのルールを設定できるが、あまり細かく設定すると管理が煩雑になる。最初はSmart Recycleで運用し、必要に応じてカスタムに移行するのが現実的だ。
整合性チェックのスケジュール
Hyper Backupには、バックアップデータの整合性をチェックする機能がある。これを定期的に実行しておけば、破損を早期に発見できる。ただし、チェック中はバックアップタスクが停止するため、業務時間外にスケジュールを組む必要がある。
チェックの頻度は、データの更新頻度と容量に応じて変える。数百GBを毎日更新する環境なら週1回、数TBのアーカイブ用途なら月1回でも十分だろう。
それでも解決しないときの最終判断
ここまでの確認を経てもエラーが消えない場合、買い替えや別のバックアップ手段を検討する段階に入る。ただし、その前に試せることはまだある。
サポートに問い合わせる前に準備すること
Synologyのサポートに問い合わせる際は、以下の情報をまとめておくとスムーズだ。
- エラーが発生した日時とDSMのバージョン
- Hyper Backupのバージョン
- バックアップタスクのログ（エクスポートしたもの）
- バックアップ先の種類と空き容量
- エラーが発生する直前に行った操作
サポートに送る前の切り分けとして、別のNASや別のクラウドサービスに新規タスクを作成し、同じデータをバックアップしてみるのも有効だ。これで問題が再現しなければ、元のバックアップ先かネットワーク経路に原因があると絞り込める。
買い替えか、待つかの判断基準
現在使用しているNASがサポート期間内で、DSMやHyper Backupのアップデートが継続されるなら、まずはソフトウェア面の改善を待つ価値がある。特に、エラーが特定のDSMバージョンで多数報告されている場合、次のアップデートで修正される可能性が高い。
一方で、NASのハードウェアが老朽化しており、ディスクのSMART情報に警告が出始めているなら、バックアップ先としての信頼性が下がっている。この場合は、新しいNASへの移行を視野に入れたほうが結果的に安上がりになることもある。
エラーを未然に防ぐ日常の運用
最後に、Hyper Backupを安定して使い続けるための日常的な確認ポイントを挙げる。
通知設定の見直し
DSMのコントロールパネルから「通知」を開き、Hyper Backupのイベントをメールやプッシュ通知で受け取れるようにしておく。特に「タスク失敗」と「容量警告」は必ず有効にしたい。
定期的な復元テスト
バックアップは「取れていること」よりも「戻せること」が重要だ。月に一度、重要度の低いファイルを一つ選び、実際に復元できるか試してみる。このテストを習慣にしておけば、いざというときに手順を忘れずに済む。
ファームウェアとパッケージの更新
DSMとHyper Backupは、常に最新の状態を保つ。ただし、メジャーアップデートの直後は不具合が報告されることもあるため、リリースノートを確認してから適用するほうが安全だ。
これらの確認を日常に組み込んでおけば、「exception occurred」のエラーに遭遇しても、落ち着いて対処できる。復元で詰まる前に、まずはバックアップ先の状態とタスクログを見直す。その一手間が、データを守る最後の砦になる。
コメント