Hyper Backupのジョブを仕掛けたまま就寝し、翌朝ログを開いてみると、ジョブが途中で止まっている。あるいは、管理画面に「タスクが異常終了しました」という通知が残り、肝心のバックアップ先には不完全なデータだけが転送されている。DS118でこのような状況に陥ったとき、原因の候補として最初に浮かぶのはネットワークの瞬断やHDDのエラーかもしれない。しかし、DS118の限られたメモリ容量と、バックアップタスクが消費するリソースの関係を意識していないと、設定をいくら見直しても同じところで詰まり続ける。
ここでは、バックアップの失敗や復元時のトラブルを「発生前」「発生時」「再発防止」の順に整理し、DS118の公式仕様やサポート情報を踏まえて、確認すべき設定と判断の分かれ道を具体的に示す。
バックアップが止まる前に見ておきたい、DS118のリソースと制約
DS118は1ベイのNASであり、搭載メモリは1GB DDR4と公表されている。この数値は、Synologyが公開しているDS118のデータシートでも確認できる。1GBという容量は、ファイルサーバーとしての通常運用には足りても、複数のアプリケーションを同時に動かしたり、大規模なバックアップタスクを実行したりする場面では、簡単に限界を迎える。
実際に、Hyper Backupがメモリ不足でクラッシュする事例は、DS118に限らずエントリークラスのNASで繰り返し報告されている。DS118の場合、メモリを増設するスロットは用意されておらず、ユーザーが容量を増やす手段はない。つまり、バックアップを安定して完了させるには、タスクが使うメモリを減らす方向で設定を詰めるしかない。
バックアップ対象の総容量より「ファイル数」がメモリを圧迫する
Hyper Backupは、バックアップを実行する際にファイルのインデックスを作成し、変更を追跡するためにメタデータをメモリ上に展開する。そのため、たとえ総容量が数テラバイトでも、数百万個の小さなファイルを含むフォルダを一括でバックアップしようとすると、インデックス処理だけで1GBのメモリを使い切ってしまうことがある。
この現象は、DSMのリソースモニターでメモリ使用率が100%に張り付き、その後ジョブが強制終了するという流れで現れる。公式のナレッジセンターでも、Hyper Backupのパフォーマンスに関するトラブルシューティングでは、バックアップ対象のファイル数とメモリ使用量の関係が注意点として挙げられている。
最初に確認したい、Hyper Backupの「タスク設定」と「バックアップ探索」
バックアップが途中で落ちる前に、あるいは一度失敗した後に、まず見直すべきはHyper Backupのタスク設定画面にある「バックアップ探索」の項目だ。ここでは、バックアップ元として指定した共有フォルダのうち、実際にバックアップするサブフォルダやファイル形式をフィルタリングできる。
たとえば、写真や動画のフォルダをまるごと指定するのではなく、「今年度分だけ」「拡張子がRAWのファイルだけ」といった単位に分割すると、1回のジョブで処理するファイル数が大幅に減る。結果としてメモリ消費が抑えられ、DS118でも最後まで走り切る可能性が高まる。
バックアップが落ちた直後に見るべきログとリソースモニター
Hyper Backupのジョブが異常終了したとき、多くの人はすぐに同じジョブを再実行したくなる。しかし、原因を特定しないまま再実行しても、同じタイミングで同じように落ちるだけだ。まずはDSMの「ログセンター」と「リソースモニター」を開き、落ちた瞬間の記録を追う。
ログセンターで「OOM Killer」の痕跡を探す
DS118に限らず、LinuxベースのOSではメモリが枯渇するとOOM Killer（Out of Memory Killer）と呼ばれる機能がプロセスを強制終了する。DSMのログセンターで「カーネル」カテゴリのログを表示し、「Out of memory」や「Killed process」といった文字列を検索すると、Hyper BackupのプロセスがOOM Killerによって停止させられたかどうかがわかる。
もし該当するログが見つかれば、メモリ不足が原因である可能性は極めて高い。その場合、先に述べたファイル数の分割に加えて、バックアップの実行時間帯に動いている他のパッケージを停止するという手もある。DS118のメモリは1GBしかないため、Hyper Backupと同時にCloud SyncやVideo Stationが動いていると、それだけでメモリが逼迫する。
リソースモニターで「スワップ」の発生を確認する
リソースモニターの「パフォーマンス」タブでは、メモリ使用量とともにスワップメモリの使用状況が表示される。スワップとは、物理メモリが不足したときにHDDの一部を仮想的なメモリとして使う仕組みだが、HDDはメモリよりはるかに遅いため、スワップが頻発するとバックアップの速度が極端に低下し、最終的にタイムアウトや異常終了を招く。
Hyper Backupの実行中にスワップ使用量が急増している場合、それは物理メモリが足りていない証拠だ。この状態が続くと、HDDへの負荷も高まり、SMART値の悪化やディスク自体の寿命を縮めるリスクも出てくる。
復元でつまずく前に、バックアップデータの整合性をどう確認するか
バックアップが完了したように見えても、そのデータが本当に復元できるかどうかは別問題だ。特に、メモリ不足でジョブが一度でも異常終了した履歴がある場合、バックアップ先のリポジトリが破損している可能性を疑う必要がある。
Hyper Backupの「整合性チェック」を計画的に実行する
Hyper Backupには、バックアップタスクの設定画面から手動で実行できる「整合性チェック」機能が用意されている。このチェックは、バックアップ先に保存されたデータブロックを検証し、破損や欠落がないかを確認するものだ。ただし、整合性チェック自体もメモリとCPUを使うため、DS118で実行する際は、他のタスクが動いていない深夜帯にスケジュールするのが無難だ。
整合性チェックでエラーが検出された場合、そのバックアップタスクは信頼できない。復元を試みる前に、まずは別のバックアップ先を用意し、新規にフルバックアップを取り直すことを検討したい。
復元テストは「一部のファイルだけ」で試す
いきなり全データを復元するのではなく、まずは任意のフォルダやファイルを1つ選び、復元先を「元の場所」ではなく「別の共有フォルダ」に指定してテストする。これにより、復元プロセス自体がメモリ不足で落ちるかどうかを、最小限のリスクで確認できる。
復元テスト中もリソースモニターを監視し、メモリ使用量が限界に近づいていないかをチェックする。もしテスト段階でメモリ不足の兆候が出るようなら、本格的な復元はさらにファイルを分割するか、よりメモリに余裕のある別のNASにバックアップデータを移してから行うといった対策が必要になる。
メーカー資料とサポート情報をどこまで信用するか
DS118のバックアップと復元に関する設定を詰める際、公式の情報源として最も信頼できるのは、Synologyのナレッジセンターとダウンロードセンターだ。ダウンロードセンターでは、DS118に対応するDSMのバージョンやパッケージ、ドキュメントが一元管理されている。
互換性リストとデータシートの読み方
バックアップ先として外付けHDDを使う場合、DS118のUSBポートに接続するドライブがSynologyの互換性リストに掲載されているかどうかは、事前に確認しておきたいポイントだ。互換性リストにないドライブが即座に使えないわけではないが、認識不良や速度低下が起きたときに、メーカーサポートを受けられない可能性がある。
また、DS118のデータシートには、対応するファイルシステムや最大内部ボリュームサイズ（108TB）といった情報が記載されている。バックアップ先の容量を計画する際には、これらの制限を超えていないかを確認する必要がある。
ファームウェアとパッケージの更新履歴を追う
Hyper Backup自体の不具合が原因でジョブが落ちるケースもゼロではない。Synologyのダウンロードセンターでは、DSMのバージョンごとにリリースノートが公開されており、Hyper Backupに関する修正が含まれているかどうかを確認できる。
バックアップの失敗が特定のDSMバージョンやHyper Backupのバージョンに集中している場合、アップデートによって問題が解決することもある。ただし、DS118はエントリーモデルであり、最新のDSMにアップデートするとシステム全体のメモリ使用量が増える可能性もあるため、アップデート前には必ず現在の設定をバックアップしておくことが推奨される。
買い替えか、設定の工夫か——判断の分かれ道
ここまでの内容を踏まえても、DS118でのバックアップが安定しない場合、最終的には「より上位のモデルに買い替える」か「DS118のままで運用を続ける」かの判断を迫られる。
買い替えを検討すべきタイミング
以下の条件に複数当てはまるなら、DS118から2ベイ以上のメモリ増設が可能なモデルへの移行を考えた方が、結果的に時間とデータの安全を買うことになる。
- バックアップ対象のファイル数が100万を超え、分割してもジョブが落ちる
- バックアップ中は他のサービスをすべて停止しないと完了しない
- 整合性チェックで毎回エラーが検出される
- バックアップのたびにリソースモニターを見張るのが常態化している
DS118は、Synologyの製品ページでも「パーソナルクラウド」として位置づけられており、大規模なバックアップ運用を想定した設計ではない。購入時の用途と現在のデータ量がかけ離れてきたのなら、無理に使い続けるよりは適切なモデルに移行する方が合理的だ。
設定の工夫で乗り切るためのチェックリスト
一方、バックアップ対象がそれほど巨大でないにもかかわらず落ちる場合は、設定の見直しで改善する余地が残っている。以下の項目を順に確認し、一つずつ試してほしい。
- バックアップタスクをファイルの種類やフォルダごとに分割したか
- バックアップの実行時間帯に、他のパッケージ（Cloud Sync、Video Stationなど）を停止したか
- Hyper Backupのバージョンが最新かどうかをダウンロードセンターで確認したか
- バックアップ先のファイルシステムがDS118の対応形式（EXT4、NTFSなど）に合致しているか
- 外付けドライブを使う場合、USBケーブルや電源供給に問題がないか
これらをすべて試しても安定しない場合は、DS118のメモリ制約が根本的な原因であると割り切り、買い替えか、バックアップ対象の抜本的な整理に踏み切る必要がある。
再発防止のために、次に記録すべきこと
バックアップの失敗や復元のトラブルは、一度解決しても、データの増加やDSMのアップデートをきっかけに再発することが多い。次に同じ症状が出たときに素早く原因を特定できるよう、最低限「ジョブが落ちた時刻」「そのときのメモリ使用率」「スワップの発生有無」「ログセンターのエラー内容」の4点をメモしておく習慣をつけると、サポートに問い合わせる際の手がかりにもなる。
コメント