Hyper Backupでバックアップを組むとき、多くの利用者は「タスクを作ってスケジュールを入れたら、あとは自動で守ってくれる」と期待する。ところが実際にトラブルが起きると、復元の段階で「例外が発生しました」というエラーに直面したり、バージョンが思ったように残っていなかったりする。この記事では、復元で詰まる前に見ておきたい設定と、買い替えや追加投資の判断材料を、検証メモの形で整理する。
検証の条件を固定する
まず、何を固定し、何を一つだけ変えるかを決める。今回の検証では、以下の前提を据える。
- 使用するHyper Backupのバージョン：DSM 7.3にバンドルされるHyper Backup 4.0系
- バックアップ対象：共有フォルダ内の一般ファイル（写真、動画、ドキュメント）
- バックアップ先：同一ネットワーク内の別のSynology NAS（Hyper Backup Vault使用）
- ネットワーク：1GbE有線、スイッチ経由
- バックアップ元NASのファイルシステム：Btrfs
この条件を固定したうえで、バックアップタスクの設定項目を一つずつ変えながら、復元時の挙動とエラーの出方を観察する。
バックアップタスクの設定を一つずつ変える
圧縮と暗号化の組み合わせ
最初に試すのは、転送時圧縮とクライアント側暗号化の有無だ。公式のHyper Backup テクニカルスペックによれば、Hyper Backupは「軍事等級のAES-256およびECC Curve25519暗号化技術によるクライアント側データ暗号化」と「クライアントサイドバックアップデータ圧縮」をサポートする。
- 圧縮なし・暗号化なし：バックアップ速度は最も速く、CPU負荷も低い。復元時もエラーは出にくいが、データは平文で保存される。
- 圧縮あり・暗号化なし：バックアップデータは小さくなるが、圧縮率はファイルの種類に左右される。すでに圧縮済みのJPEGや動画ファイルでは効果が薄い。復元時のエラーは圧縮なしと同等。
- 圧縮あり・暗号化あり：CPU負荷が高まり、バックアップ時間が延びる。復元時には暗号化パスワードが必須で、パスワードを忘れると復元不能になる。また、暗号化を有効にすると、Hyper Backup Explorerでの復元時にパスワード入力が必要になる点を確認しておきたい。
観察結果：暗号化を有効にしたタスクで、復元時に「例外が発生しました」というエラーが出るケースが報告されている。これは暗号化パスワードの入力ミスや、バックアップ先のファイルシステムの不整合が原因になることが多い。暗号化を使うなら、必ずパスワードを安全な場所に記録し、定期的に復元テストを行うべきだ。
バージョン保持ポリシーの影響
次に、バージョンローテーションの設定を変えてみる。公式仕様では「最大65,535バージョンのバックアップデータを保持」でき、「Smart Recycle」や「カスタマイズされた保持ポリシー」を選べる。
- Smart Recycle：毎時、毎日、毎週の最新バージョンを自動で保持する。設定は簡単だが、必要なバージョンが思わぬタイミングで削除されることがある。
- カスタム保持ポリシー：最大7つのルールで、保存期間とバージョン間隔を細かく指定できる。例えば「過去7日間は毎日のバージョンを残し、過去4週間は週1回のバージョンを残す」といった設定が可能だ。
観察結果：カスタム保持ポリシーで「すべてのバージョンを無期限に保持」に近い設定をすると、バックアップ先の容量を圧迫し、バックアップタスクが途中で止まる原因になる。復元時に必要なバージョンが欠けているトラブルは、保持ポリシーの設定ミスが多い。復元したい時点のバージョンが確実に残るよう、ポリシーは復元要件から逆算して決める必要がある。
整合性チェックのスケジュール
Hyper Backupには「データとインデックスの整合性チェック」機能があり、バックアップデータの破損を検出できる。このチェックを定期的に実行するかどうかで、復元時の信頼性が変わる。
- チェックなし：バックアップは高速だが、気づかないうちにデータが破損しているリスクがある。
- 週1回のチェック：バックアップ先のストレージに負荷がかかるが、破損を早期に発見できる。
観察結果：整合性チェックを一度も実行していない状態で復元を試みると、インデックス破損により「例外が発生しました」というエラーが出ることがある。公式のHyper Backup クイックスタートガイドでも、定期的な整合性チェックが推奨されている。最低でも月1回はスケジュールに組み込みたい。
バックアップ先の環境を変える
ローカル共有フォルダ vs リモートNAS
バックアップ先をローカル共有フォルダ（同一NAS内の別ボリューム）にした場合と、リモートNASにした場合で、復元時のエラー発生率を比較する。
- ローカル共有フォルダ：ネットワークの影響を受けないため、バックアップ・復元ともに高速で安定している。ただし、NAS本体の故障時にはバックアップごと失われるため、RAIDとは別の外部バックアップとしての意味は薄い。
- リモートNAS（Hyper Backup Vault）：ネットワーク越しの転送になるため、途中で接続が切れるとタスクが失敗する。復元時にも、リモートNASの電源が入っていない、IPアドレスが変わった、ファイアウォールでブロックされた、といった理由で接続できないことがある。
観察結果：リモートNASへの復元で「例外が発生しました」が出る場合、まずリモートNASのHyper Backup Vaultが起動しているか、バックアップタスクで指定したIPアドレスまたはDDNSで到達できるかを確認する。ネットワークの不安定さが原因なら、バックアップタスクの「再試行」回数を増やすか、スケジュールを夜間などネットワークが空いている時間に変更すると改善することがある。
クラウドストレージを絡めた場合
公式仕様では、バックアップ先としてSynology C2 StorageやDropbox、Google Drive、S3互換ストレージなど、複数のパブリッククラウドサービスをサポートする。クラウドをバックアップ先に選ぶと、復元時の挙動はさらに変わる。
- クラウド側のAPI制限：サービスによっては、一定時間内のリクエスト数に制限がある。大量のファイルを復元しようとすると、API制限に引っかかりエラーになる。
- データ転送量のコスト：クラウドからのダウンロードには、サービスによってデータ転送料金が発生する。復元が長期化すると、想定外のコストがかかることがある。
観察結果：クラウドからの復元中に「例外が発生しました」が出た場合、クラウド側のステータスページで障害が起きていないか、API制限に達していないかを確認する。また、Hyper Backupのログには「[Hyper Backup] Failed to restore data from cloud」といったメッセージが残るため、DSMのログセンターで詳細を追う。
復元手順のどこでエラーが出るかを分類する
タスク選択直後のエラー
復元ウィザードでバックアップタスクを選択した直後にエラーが出る場合、バックアップ先のパスにアクセスできていない可能性が高い。リモートNASの共有フォルダの権限や、クラウドの認証情報が切れていないか確認する。
バージョン一覧の表示で止まる
バックアップバージョンの一覧が表示されるまでに時間がかかったり、途中でエラーになる場合は、バックアップ先のストレージに負荷がかかっているか、インデックスが破損している。この場合、整合性チェックを手動で実行し、破損があれば修復を試みる。
ファイルのダウンロード中に止まる
特定のファイルを復元しようとしたときにエラーが出るなら、そのファイルがバックアップ時にロックされていた、またはバックアップ先で破損している可能性がある。別のバージョンから同じファイルを復元できるか試す。
公式仕様と実使用のギャップを埋める
公式のHyper Backup テクニカルスペックには、対応するバックアップソースやディスティネーション、バージョン数、暗号化方式が明記されている。しかし、実際の運用では以下の点が追加の確認ポイントになる。
- バックアップ元NASのCPU性能：圧縮や暗号化を有効にすると、エントリークラスのNASではCPU使用率が100%に張り付き、他のサービスに影響が出る。
- バックアップ先のファイルシステム：Hyper Backupはバックアップデータを独自形式（.hbk）で保存する。このため、バックアップ先がext4でもBtrfsでも動作するが、バックアップ先のファイルシステムが壊れると復元できなくなる。
- DSMのバージョン不一致：バックアップ元とバックアップ先のDSMバージョンが大きく異なると、復元時に互換性の問題が起きることがある。公式のHyper Backup FAQでは、メジャーバージョンが異なる場合の制限についても触れられている。
買い替え・追加投資の判断分岐
ここまでの検証を踏まえ、今の環境でHyper Backupを使い続けるか、新たに機器を購入するかの判断基準を整理する。
今の環境で続ける場合に確認すること
- バックアップタスクのログを定期的にチェックし、警告やエラーが蓄積していないか確認する。
- 最低でも3ヶ月に1回は、実際にファイルを復元するテストを行う。
- バックアップ先のストレージ容量に余裕があるか、保持ポリシーと実使用量を照らし合わせる。
追加で購入を検討するケース
- バックアップ先の容量が足りず、保持ポリシーを緩めてもすぐに一杯になる。
- バックアップ元NASのCPUが非力で、圧縮や暗号化を有効にすると他のサービスが止まる。
- リモートバックアップのネットワークが遅く、増分バックアップでも翌朝まで終わらない。
購入を見送るケース
- 現在のバックアップが正常に動作しており、復元テストも問題なく完了している。
- バックアップ先の容量が十分で、あと1年以上は保持ポリシーを維持できる見込みがある。
- 単に「例外が発生しました」というエラーが一度出ただけで、再試行で解決した。
検証を終えての記録
今回の検証では、以下の条件で復元の成否を分ける要因を観察した。
- 固定条件：DSM 7.3、Hyper Backup 4.0系、共有フォルダのバックアップ、リモートNAS（Vault）
- 変更した項目：圧縮・暗号化の有無、保持ポリシー、整合性チェックの頻度、バックアップ先の種類
- 確認すべきログ：DSMのログセンター > アプリケーション > Hyper Backup
- 復元テストの手順：Hyper Backupを起動 > 復元アイコン > タスク選択 > バージョン選択 > 復元先フォルダ指定
復元で詰まったときは、まず「バックアップ先に接続できるか」「暗号化パスワードは正しいか」「整合性チェックは通っているか」の3点を確認する。これらをクリアしてもエラーが続くなら、公式のSynologyナレッジセンターでエラーコードを検索し、該当する制限事項やトラブルシューティングを参照する。
最終的に、Hyper Backupの復元信頼性を高めるには、バックアップ設計の段階で「復元を前提にした設定」を選ぶことが最も重要だ。暗号化のパスワード管理、保持ポリシーの文書化、定期的な復元テストのスケジュール化を、バックアップタスク作成と同時に組み込んでおけば、いざというときに慌てずに済む。
コメント