Synology NASのバックアップを担うHyperBackupでエラーや認識不良に直面すると、まず「どの設定を直せばいいのか」に意識が向きがちだ。しかし、その前に立ち止まって考えるべきは「本当にHyperBackup自体の問題なのか」という視点である。NASのバックアップが失敗する原因は、アプリケーションの不具合だけとは限らない。ネットワークの一時的な切断、ストレージプールの容量不足、バックアップ先の認証情報の期限切れ、あるいは互換性のないHDDやSSDの組み合わせが、HyperBackupのエラーとして表面化することも多い。
この記事では、HyperBackupでエラーや認識不良が出たときに、むやみに設定を変更したり、タスクを再作成したりする前に確認すべき比較軸と、安全な確認順を整理する。比較軸とは「症状が起きた条件」「NAS本体とバックアップ先の状態」「タスクの設計」の三つだ。これらを順に照合することで、不要なデータの上書きや復元失敗を避けながら、原因を絞り込める。
症状が出た条件を切り分ける
HyperBackupのエラーは、特定の時間帯や特定のバックアップ先でのみ発生するケースが少なくない。まずは「いつ」「どこで」「何が」起きたのかを固定することから始める。
エラー発生時のパターンを記録する
DSMの通知センターやHyperBackupのタスクログには、エラーが発生した日時と簡単なエラーコードが残る。たとえば「バックアップ先に接続できません」「容量が不足しています」「整合性チェックに失敗しました」といったメッセージだ。これらのログを確認する際は、単発のエラーなのか、連続して同じエラーが出ているのかを区別する。
一時的なネットワークの不安定さが原因であれば、同じ時間帯に他のパッケージや共有フォルダへのアクセスにも影響が出ていないか、DSMのリソースモニターでLANのトラフィックを確認する。また、バックアップ先がクラウドストレージの場合、API制限やサービス側のメンテナンスが重なっていないかも、各サービスのステータスページで調べておくとよい。
バックアップ先ごとにエラーの傾向を比べる
HyperBackupは複数のバックアップ先をサポートしている。ローカル共有フォルダ、リモートSynology NAS、rsyncサーバー、各種パブリッククラウドサービスなど、バックアップ先によって必要な認証方法やネットワーク経路が異なる。もし特定のバックアップ先だけエラーが出るなら、その接続設定や認証情報、ファイアウォールのルールを優先的に確認する。
一方、すべてのバックアップ先で同じエラーが出る場合は、NAS本体のストレージやファイルシステム、あるいはHyperBackupパッケージ自体の問題を疑う。この切り分けが、後の手順を大きく左右する。
NAS本体とバックアップ先の状態を照合する
症状のパターンがつかめたら、次にNAS本体とバックアップ先の健全性を確認する。ここで重要なのは、HyperBackupの設定を変更する前に、データを預かる基盤が正常かどうかを見極めることだ。
ストレージプールとボリュームの空き容量
HyperBackupのエラーで意外と多いのが、バックアップ先の容量不足である。しかし、見落としがちなのがNAS本体側の空き容量だ。HyperBackupはバックアップ処理中に一時ファイルやスナップショットをNASのボリューム上に作成するため、ローカルの空き容量が不足するとタスクが中断する。
DSMの「ストレージマネージャー」でストレージプールとボリュームの使用率を確認し、少なくともバックアップ対象データの10%以上の空き容量を確保できているかを見る。また、バックアップ先がリモートNASやクラウドの場合も、同様に空き容量を確認する。容量不足が疑われるなら、不要なバックアップバージョンをローテーションポリシーに従って整理するか、バックアップ対象を絞り込む。
HDD/SSDの互換性とSMART情報
Synology NASでは、メーカーが公開している互換性リストに掲載されたHDDやSSDの使用が推奨されている。互換性リストにないドライブを使っていると、HyperBackupに限らず、ストレージプールの異常や読み書きエラーが発生するリスクが高まる。公式の互換性リストはSynology製品互換性リストで確認できる。
また、ストレージマネージャーの「HDD/SSD」タブで各ドライブのSMART情報を確認し、不良セクタや読み取りエラーが増加していないかを調べる。SMARTで警告が出ているドライブがある場合、HyperBackupのエラーはそのドライブに起因している可能性が高い。この状態でバックアップタスクを再実行すると、データが正常に読み取れず、バックアップ自体が破損する恐れがある。
ネットワークとファイアウォールの設定
バックアップ先がローカルネットワーク外にある場合、ルーターやファイアウォールの設定がHyperBackupの通信をブロックしていないかを確認する。特に、リモートSynology NASへバックアップする際に使用するポート番号（デフォルトでは6281、またはDSMのHTTPSポート）が開放されているか、VPN経由の場合はトンネルが正常に確立されているかをチェックする。
クラウドサービスを利用している場合、プロキシサーバーの設定や、DSMの「外部アクセス」にあるルーター設定が適切かも見直す。ネットワークの問題は、同じバックアップタスクが特定の時間帯だけ失敗する、という形で現れやすい。
タスク設計の前提を見直す
NAS本体とバックアップ先に明らかな異常が見つからない場合、HyperBackupのタスク設計そのものに原因が潜んでいることがある。ここでは、バックアップの信頼性を左右する三つの比較軸を取り上げる。
RAIDとバックアップの分離
RAIDはディスク障害に対する冗長性を提供するが、誤操作やランサムウェアによるデータ破壊からは保護できない。そのため、RAIDとは別に外部バックアップを取ることが大前提となる。HyperBackupでエラーが出ている場合、バックアップ先が同じNAS内の別ボリュームや、USB接続の外付けHDDになっていないかを確認する。
理想的には、バックアップ先を物理的に異なる場所に置くか、クラウドストレージを併用する。SynologyのC2 StorageはHyperBackupと統合されており、重複排除や暗号化にも対応している。バックアップ先を分散させておけば、一方が使えなくなっても他方から復元できる。
バージョン管理と整合性チェックの頻度
HyperBackupは最大65,535バージョンまで保持できるが、バージョン数が多すぎると管理画面の応答が遅くなり、整合性チェックにも時間がかかる。逆に、保持バージョンが少なすぎると、エラーに気づいた時点で正常なバージョンがすでにローテーションで削除されている恐れがある。
タスク設定の「バージョンローテーション」では、Smart Recycleかカスタム保持ポリシーを選択できる。カスタムポリシーでは、毎時・毎日・毎週のバージョンをそれぞれ何世代残すかを細かく指定できるが、設定が複雑になるほど想定外の挙動を招きやすい。まずはSmart Recycleで運用し、必要に応じて調整するのが安全だ。
また、定期的な整合性チェックは、バックアップデータの破損を早期に発見するために有効だが、チェックの実行中はバックアップタスクが停止したり、NASの負荷が高まったりする。エラーが多発している時期は、整合性チェックのスケジュールを一時的に停止し、手動で実行して問題の有無を確認する手順も検討する。
バックアップ対象と除外リストの適正化
HyperBackupでは、ファイル名や拡張子を指定してバックアップから除外できる。この除外リストが意図せず必要なファイルを弾いていないか、あるいは逆に、不要な一時ファイルやキャッシュを大量にバックアップしていないかを確認する。
特に、仮想マシンやデータベースのライブバックアップを行う場合、アプリケーション側で整合性を保つための設定が必要になる。HyperBackup単体ではアプリケーションレベルの整合性を保証できないため、該当するパッケージのバックアップ手順をSynologyナレッジセンターで事前に調べておく。
型番・世代・対応条件を照らす
HyperBackupはDSMのバージョンやNASの機種によって利用できる機能が異なる。特に、システム全体のバックアップやベアメタル復元は、対応機種が限られている。
DSMとHyperBackupのバージョン互換性
DSMのメジャーアップデート後にHyperBackupのエラーが増えた場合、パッケージのバージョンが古いままになっていないかをパッケージセンターで確認する。また、バックアップ先が別のSynology NASの場合、双方のDSMバージョンが大きく離れていると、バックアップや復元に制限が生じることがある。
公式のHyper Backupテクニカルスペックには、バックアップ元とバックアップ先の対応関係や制限事項がまとめられている。たとえば、システム全体のバックアップはリモートSynology NASにのみ保存可能で、クラウドストレージには保存できない、といった制限が明記されている。
バックアップ先の対応プロトコルと認証方式
クラウドストレージを利用する場合、サービス側のAPIや認証方式の変更がHyperBackupの接続エラーを引き起こすことがある。Google DriveやDropboxなどのOAuth認証が期限切れになっていないか、S3互換ストレージのアクセスキーとシークレットキーが有効かを定期的に確認する。
リモートNASへバックアップする際は、接続先のIPアドレスやDDNSのホスト名が変わっていないか、相手側のHyperBackup Vaultが正常に動作しているかもチェックする。
買い替え・移行が効くケースを見極める
ここまでの確認でハードウェアの故障や深刻な互換性の問題が見つかった場合、NAS自体の買い替えや、バックアップソフトの乗り換えを検討する段階に入る。
NASの買い替えを検討する目安
- SMARTで複数のドライブに警告が出ており、RAIDのリビルド中にさらにエラーが増加している
- ストレージプールの空き容量が常に逼迫し、バックアップ対象データの増加に追いつかない
- 使用しているNASがDSMのサポート対象外となり、HyperBackupの更新が提供されなくなった
こうした状況では、新しいNASにデータを移行し、HyperBackupのタスクを再構築する方が結果的に安全な場合が多い。移行時には、HyperBackupで作成したバックアップデータを新しいNASから直接参照できるか、あるいはHyperBackup Explorerを使ってPCに復元してから移行するかを、事前にSynologyナレッジセンターで確認しておく。
バックアップソフトの乗り換えを検討する目安
- 特定のクラウドストレージとの接続が頻繁に切れ、ファームウェア更新でも改善しない
- バックアップ対象が特殊なデータベースや仮想環境で、HyperBackupのアプリケーション整合性バックアップでは要件を満たせない
- 大規模なバックアップ環境で、重複排除や圧縮の効率が極端に悪い
HyperBackup以外の選択肢としては、SynologyのActive Backup for Businessや、汎用のrsync、rcloneなどがある。ただし、乗り換えにはバックアップポリシーの再設計と、既存のバックアップデータの移行が必要になるため、移行期間中のリスクを考慮して判断する。
エラーを再発させないための日常点検
最後に、HyperBackupのエラーを未然に防ぐために、日常的に確認しておきたいポイントを整理する。
通知設定とログの定期確認
DSMの通知設定で、HyperBackupのタスク失敗や容量警告をメールで受け取れるようにしておく。また、月に一度はHyperBackupのタスク一覧を開き、各タスクの最終実行日時と結果を確認する習慣をつける。
バックアップデータの定期的な復元テスト
バックアップが正常に完了していても、実際に復元できるかどうかは別問題だ。四半期に一度は、重要度の低いファイルを選んで実際に復元し、データの整合性と復元手順を確認する。HyperBackupにはマルチバージョンエクスプローラが搭載されており、過去の任意のバージョンからファイルをダウンロードできる。
ファームウェアとパッケージの更新管理
DSMとHyperBackupの更新は、リリースノートを確認した上で、できるだけ早く適用する。ただし、大規模なバージョンアップの直後は不具合が報告されることもあるため、更新直前にバックアップタスクを手動で実行し、正常に完了することを確かめてから適用するのが安全だ。
HyperBackupのエラーは、単なる設定ミスからハードウェアの故障まで、原因の幅が広い。しかし、症状が出た条件を固定し、NAS本体とバックアップ先の状態を照合し、タスク設計の前提を見直すという三つの比較軸を順にたどれば、データを危険にさらすことなく原因を絞り込める。バックアップの最終目的は「必要なときにデータを取り戻せること」だ。エラーが出たときこそ、その原点に立ち返って確認を進めたい。
コメント