移行の準備段階で起きる「想定外」の正体
HyperBackupを使って別のNASへデータを移そうと考えたとき、多くの人が「バックアップタスクを作ればあとは自動でやってくれる」と期待する。しかし実際に動かし始めると、保存先のドライブが勝手に切り替わって重複が発生したり、容量を圧迫してタスクが止まったり、といったトラブルが報告されている。
こうした問題の多くは、移行前にデータとアプリの整理をどこまで済ませておくか、HyperBackupのタスク設計を移行後の構成に合わせてどう見直すか、という点でつまずく。特に「外部ドライブを接続するたびにバックアップ先が変わってしまう」という相談は、移行元と移行先の両方で共有フォルダ構成やアプリの設定を引き継ぐ際に、HyperBackupが参照するパスやボリューム情報が原因になっているケースが多い。
ここでは、移行を始める前に確認しておきたいポイントを、実際に起こりがちな失敗の流れに沿って整理する。
まず現状のバックアップタスクと保存先を洗い出す
HyperBackupのタスク一覧を開き、現在動いているジョブの数と保存先をすべて書き出すところから始める。このとき、タスク名だけではなく、バックアップ元として選択している共有フォルダ、アプリケーション、システム設定の範囲をメモしておく。
バックアップ先が「切り替わる」現象を疑う
外部USBドライブを複数使っている環境では、HyperBackupがドライブを識別する方法に注意が必要だ。Synologyの公式仕様によると、HyperBackupはバックアップ先としてローカル共有フォルダや外部デバイスを指定できるが、タスク作成時に選択した「フォルダパス」が基準になる。そのため、異なる外付けドライブに同じフォルダ名が存在すると、接続のたびに新しいドライブが認識されてバックアップ先が切り替わることがある。
この現象を防ぐには、バックアップ先のフォルダ名をユニークにするか、USB Copyなど別の手段でデータを集約したうえでHyperBackupタスクを一本化する方法が有効だ。公式のHyper Backup テクニカルスペックにも、サポートされるバックアップ先として「ローカル共有フォルダー」「外部デバイス」が明記されているが、複数の外部ストレージを同時に扱う際の優先順位や排他制御については、利用者側で設計する必要がある。
重複と容量圧迫が起きる仕組み
バックアップ先が意図せず切り替わると、同じデータが別のドライブに重複して保存される。HyperBackupは増分バックアップと重複排除の機能を持つが、これはあくまで「同一タスク内のバージョン管理」に対して働く。タスクそのものが別の保存先を参照してしまうと、重複排除は効かず、単純に容量を二重に消費する。
移行前にこの状態に陥っている場合、まずはHyperBackupのログから「タスクがどのパスに書き込んだか」を確認し、不要なバックアップ先を切り離す。ログはDSMの「ログセンター」からHyperBackupの操作ログをフィルタすると追いやすい。
移行先NASの構成を決める前にアプリとデータの依存関係を整理する
HyperBackupでシステム全体をバックアップしている場合、移行先で復元する際にはパッケージの互換性が問題になる。たとえば、移行元がDSM 7.3で稼働しているのに、移行先がDSM 6.2のままでは、HyperBackupでバックアップしたパッケージ設定をそのまま復元できないことがある。
パッケージとシステム設定の扱い
公式のHyper Backup クイック スタート ガイドでは、バックアップソースとして「フォルダー」「パッケージ」「LUN」「システム全体」が選べる。移行を前提にするなら、システム全体のバックアップは最終手段とし、まずは共有フォルダとアプリケーションの設定を個別にバックアップしておく方が安全だ。
特に、Surveillance StationやActive Backup for Businessなど、ライセンスやエージェント設定を含むパッケージは、単純なファイルコピーでは復旧できない。HyperBackupのパッケージバックアップ機能を使えば、対応パッケージの設定ごと保存できるが、復元先のDSMバージョンやアーキテクチャが一致している必要がある。SynologyのSynology NAS 間でデータを移行するには（DSM 6.0 以降）？でも、移行前に両方のNASでHyperBackupとHyperBackup Vaultのバージョンを揃えるよう案内されている。
共有フォルダの権限と暗号化
共有フォルダ単位でバックアップする場合、暗号化共有フォルダはHyperBackupが復号した状態でバックアップするため、復元時に暗号化キーを再設定する必要がある。また、フォルダごとのアクセス権限はバックアップに含まれるが、移行先でユーザーやグループの構成が異なると、権限が正しく引き継がれない。
移行前に、移行元の「ユーザーとグループ」設定をエクスポートしておき、移行先で同じユーザー名・UIDのアカウントを作成してから復元するのが確実だ。
移行のタイミングを決める「買うべきか待つべきか」の判断
HyperBackupを使った移行を検討するとき、必ずしも今すぐ新しいNASを購入する必要はない。以下の条件に当てはまる場合は、購入を急がずに現行機の整理を優先したほうが結果的にコストを抑えられる。
- 現在のNASの容量が逼迫しているが、重複や不要なバックアップバージョンを整理すればまだ余裕が生まれる
- 移行先のNASで使いたいパッケージの対応状況が公式で確認できていない
- 移行元のDSMが古く、HyperBackupのバージョンが移行先と大きく異なる
一方、次のようなケースでは早めの移行を検討する価値がある。
- 現在のNASがハードウェア保守期間を過ぎており、セキュリティアップデートが提供されなくなった
- ファイルシステムがext4で、どうしてもbtrfsのスナップショットや整合性チェックを導入したい
- パフォーマンス不足でHyperBackupの整合性チェックが実用的な時間で終わらない
公式サポートで確認する境界
移行先のNASを選ぶときは、Synologyの製品互換性リストでHDDやSSD、メモリ、拡張ユニットの対応状況を必ず確認する。HyperBackupの動作とは直接関係ないように思えても、バックアップ先のボリュームが非対応ドライブで構成されていると、リストア時に読み取りエラーが発生するリスクがある。
また、RAIDはバックアップではないという前提を忘れずに、HyperBackupの保存先とは別に外部バックアップを設計しておく。移行作業中は一時的にバックアップが手薄になるため、作業前に必ず最新のバックアップを取得し、復旧手順を文書化しておく。
実際の移行手順を時系列で追う
ここからは、HyperBackupを使った移行を作業の流れに沿って見ていく。
移行前日までに済ませること
1. 移行元NASでHyperBackupの全タスクを停止し、最終バックアップを手動実行する
2. バックアップデータの整合性チェックを実行し、破損がないことを確認する
3. 移行元NASの「設定のバックアップ」からシステム構成をエクスポートする
4. 移行先NASを初期セットアップし、DSMとHyperBackupを最新バージョンに更新する
5. 移行先NASにHyperBackup Vaultをインストールし、バックアップ先としての受け入れ準備をする
移行当日の手順と起こりがちなトラブル
HyperBackupの復元は、想定以上に時間がかかることがある。特にシステム全体のバックアップを復元する場合、ネットワーク速度だけでなく、移行先NASのCPU性能やRAIDの再構築がボトルネックになる。
復元中に「容量不足」で失敗するケースも多い。HyperBackupは復元先のボリューム空き容量がバックアップデータのサイズより小さいと処理を中断する。事前に移行先NASのボリュームサイズを確認し、必要ならHDDを増設してから始める。
また、復元後にアプリケーションが正常に起動しない場合は、パッケージセンターで該当パッケージを一度停止し、修復または再インストールを試みる。設定だけが復元されて実行バイナリが古いままになっていることがあるためだ。
移行後の動作確認とログの読み方
復元が完了したら、まずHyperBackupのタスクを一つだけ有効化し、テストバックアップを実行する。このとき、保存先が意図したフォルダや外部ドライブになっているかをログで確認する。
DSMのストレージマネージャでSMART情報とRAIDの状態をチェックし、移行元から引き継いだ共有フォルダの権限が正しく反映されているかも検証する。
それでもバックアップ先が切り替わる場合の最終チェック
HyperBackupの設定を見直しても外部ドライブの切り替わりが直らない場合、USBポートの物理的な問題や、ドライブのマウントポイントがOSレベルで競合している可能性がある。
このようなときは、以下の点を順に確認する。
- 外付けドライブのファイルシステムが移行先NASでサポートされているか（SynologyはNTFS、ext4、FAT32などをサポートするが、exFATは有料パッケージが必要）
- USBハブを経由せず、NAS本体のポートに直接接続しているか
- ドライブレターやボリュームラベルが重複していないか
どうしても解決しない場合は、HyperBackupに頼らず、File Stationを使った手動コピーやrsyncによる同期に切り替えることも選択肢になる。ただし、その場合はバージョン管理や増分バックアップの機能を失うため、別途スナップショットやクラウドバックアップで補う必要がある。
次に再発したときに記録するべき項目
HyperBackupのタスクが再び不安定になったときは、「タスク名」「発生時刻」「エラーメッセージ」「接続していた外部ドライブの型番とファイルシステム」「DSMのバージョン」の5点をメモし、Synologyのサポートチケットを起票する際に添えるとスムーズだ。
コメント