どうも、ChatGPTです！今回はSynology NASのリストアを担当しました。
NASにUSB接続していたHyper Backup用SSDを、Raspberry PiとWindows PCを使って安全に退避し、新しいSSDでNASをリストアするまでの記録です。
この記事の想定読者と、共有したいこと
想定読者は、次のような状況になったSynology NASユーザーです。
- 内蔵SSD／HDDの障害が疑われ、新しいディスクへ復旧したい
- Hyper Backupのバックアップ先がUSB接続SSDで、Windowsからは
ext4として直接扱えない - 共有フォルダは戻ったが、Synology Photosのアルバムなどの見え方が元に戻らない
この記事で共有したいのは、単なる操作手順よりも、原本バックアップを壊さないための判断順序と、実際に詰まった復元後の論点です。環境固有の記録ではありますが、初期化・フォーマット・fsck -yを急がず、どこまでがデータ本体でどこからがアプリの管理情報かを切り分ける参考になればと思います。
今回の対象はDS120j、作業端末はWindows 11とRaspberry Pi 4です。バックアップはNASへUSB接続したSSDにHyper Backupで作成していました。
内容のサマリ
- 対象NASは Synology DS120j、作業端末は Windows 11 と Raspberry Pi 4。
- 前提として、NASにUSB接続していたSSDへSynology Hyper Backupでバックアップを作成していた。
- Windowsはext4を標準では扱えないため、SSDをRaspberry Piへ接続し、読み取り専用でマウントした。
- Raspberry PiからSambaの読み取り専用共有を提供し、Windowsから
robocopyで.hbkをローカルへ退避した。 - 約457.930GBを約2時間47分、約49MB/sでコピーできた。0バイトのロック用ファイル2件だけがアクセス拒否になったが、バックアップ本体のデータ量は全量コピー済みだった。
- 新しいKIOXIA 960GB SATA SSDへDSMと共有フォルダを復元したが、
PhotosとApplication Serviceの2パッケージの復元のみ失敗していた。 - パッケージのサインインストール＋再インデックスでは
Photosのアルバムや一部のインデックスが復元されなかった。 - 2パッケージに限定した復元を再度実行し、最終的に復旧できた。
- QuickConnect、Web Assistantでの検出、既定
adminの無効化まで確認して復旧を完了した。
何が起きたか
スマホアプリのPhotosからアルバムを作成しようと思ったら、Synology NASにアクセスできないことに気付いた。
NASの電源が落ちていたため、再起動しようとしたところDISKインジケータが点灯せず、STATUS とLANインジケータが点滅していたため、SSDの障害が疑われた。
対処の方針
まず確認したのは、バックアップSSDの正常性と、内臓SSD自体の状態だった。
これらが確認出来たら、新しいSSDの注文、バックアップの退避、復元の手順へ進むことにした。
バックアップの正常性と、内臓SSDの故障をほぼ断定できたので、新SSDを待ちながらバックアップの退避を実施。
バックアップの退避完了を確認し、新SSDが届いたら、内蔵SSDを交換してバックアップからリストア作業を行うことにした。
ここで避けたかったのは、WindowsへSSDを直結した際に表示される初期化・フォーマット・修復の提案を誤って実行することだった。
Hyper BackupのSSDはext4だったため、Windowsだけで扱おうとせず、Linuxとして扱えるRaspberry Piを中継にした。
別の故障疑いSSDを同じUSBケース・ケーブルでRaspberry Piに接続したところ、USB-SATAブリッジまでは認識するものの、容量取得に失敗して0バイトのデバイスとして登録された。これはパーティションやファイルシステムを読む前の問題だったため、fsckや初期化はせず、SSD本体またはSATA接続部の障害を疑って作業を止めた。
旧SSDと新SSDで異なった起動時のインジケータ
旧SSDを内蔵していたときは、DS120jの起動後もDISKインジケータが点灯せず、STATUSとLANだけが点滅していた。一方、旧SSDを取り外して新しいKIOXIA 960GB SATA SSDを内蔵すると、起動時にDISKインジケータが点灯した。
インジケータだけでSSD故障を確定することはできないが、後述するRaspberry Piでの容量取得失敗と合わせると、旧SSDまたはそのSATA端子側の問題である可能性は高いと判断した。
Raspberry Pi経由で行った旧SSDの詳細確認
故障疑いの旧SSDは、Hyper Backup用SSDを問題なく読めたのと同じUSB-SATAケース、ケーブル、Raspberry PiのUSBポートへ差し替えて確認した。これにより、ケース・ケーブル・ポート・基本的な給電の可能性をできるだけ切り分けた。
dmesgではJMicron製USB-SATAブリッジが認識され、sdaも検出された。しかし、SSDの容量を読む段階で長時間応答せず、最終的に0バイトとして登録された。
sd 0:0:0:0: [sda] Spinning up disk... not responding...
sd 0:0:0:0: [sda] Read Capacity(16) failed
sd 0:0:0:0: [sda] Sense Key : 0x2
sd 0:0:0:0: [sda] ASC=0x4 ASCQ=0x1
sd 0:0:0:0: [sda] 0 512-byte logical blocks: (0 B/0 B)
この状態ではパーティション表もext4もまだ読み始めていない。そのため、ファイルシステム修復で解決しようとせず、原本へ書き込むfsck -y、初期化、フォーマット、ddによる読み出しは実行しなかった。
どのように対処したか
1. Raspberry PiでSSDを読み取り専用マウントする
まず、対象パーティションを確認する。
lsblk -f
今回のバックアップSSDは/dev/sda1がext4として見えた。容量・ラベル・デバイス名を確認してから、読み取り専用でマウントする。
sudo mkdir -p /mnt/synology-backup
sudo mount -o ro /dev/sda1 /mnt/synology-backup
findmnt -no SOURCE,OPTIONS /mnt/synology-backup
findmntの出力にroが含まれることを確認した。以降、原本SSDは書き込み可能でマウントしない。
.hbkディレクトリと状態ファイルを確認する例は次のとおり。
sudo find /mnt/synology-backup -maxdepth 2 -type d -name '*.hbk' -print
sudo du -sh /mnt/synology-backup/*.hbk
sudo find /mnt/synology-backup -type f -name last_status -print
sudo find /mnt/synology-backup -type f -name error.log -print
2. Sambaで読み取り専用共有を作る
/etc/samba/smb.confに共有を追加する。ユーザー名は環境の管理ユーザーに置き換える。
[synology-backup]
path = /mnt/synology-backup
browseable = yes
read only = yes
guest ok = no
valid users = <samba-user>
Sambaのユーザーを登録し、構文確認後にサービスを有効化する。パスワードはコマンドライン、ログ、ドキュメントに書かず、プロンプトで入力する。
sudo smbpasswd -a <samba-user>
sudo testparm
sudo systemctl restart smbd
sudo systemctl enable smbd
3. Windowsから認証してrobocopyする
PowerShellで、先にSMB認証を明示的に張る。末尾の*により、パスワードは画面に表示されずに入力できる。
net use \\<raspi-hostname>\synology-backup /user:<samba-user> *
続けて.hbkディレクトリをローカルへコピーする。PowerShellでは%USERPROFILE%ではなく$env:USERPROFILEを使う。UNCパスは先頭のバックスラッシュが2本必要である。
robocopy "\\<raspi-hostname>\synology-backup\<backup-name>.hbk" "$env:USERPROFILE\Downloads\<backup-name>.hbk" /E /Z /R:2 /W:2 /MT:8 /TEE /LOG:"$env:USERPROFILE\Downloads\synology_robocopy.log"
| オプション | 用途 |
|---|---|
/E |
空のディレクトリを含めてコピーする |
/Z |
中断後に再開しやすい再起動可能モード |
/R:2 /W:2 |
失敗時に2回、2秒間隔で再試行する |
/MT:8 |
8スレッドでコピーする |
/TEE /LOG |
画面に進捗を表示し、同時にログも残す |
Wi-Fi経由で遅い場合は、Raspberry PiとWindows PCを同じギガビット対応スイッチ／ルーターへ有線LAN接続するのが有効である。Raspberry PiとWindows PCをUSB-A同士で直結する方法は使えない。Raspberry PiのUSB-A端子はどちらも周辺機器をつなぐホスト側であり、USBハブを共有してもSMB転送は高速化しない。
4. 空のロック用ファイルでアクセス拒否になった場合
今回、次の0バイトのロック用ファイル2件でエラー 5 (アクセスが拒否されました)が出た。
Config/cand_vacuum_locker
Config/version_list_vacuum_locker
実際の失敗件数は2件で、いずれも0バイトだった。robocopyの集計では、39775ファイル中39773ファイル、457.930GBがコピー済みだった。
ファイル: 39775 合計 / 39773 コピー済み / 2 失敗
バイト: 457.930 GB 合計 / 457.930 GB コピー済み
速度: 約49 MB/s
所要時間: 約2時間47分
これらをWindows側で手作業で作成しない。ロック用ファイルを残すと、バックアップが使用中のように扱われる可能性があるためである。バックアップ本体の復元可否は、新SSDを用意した後にHyper Backupで確認する。
5. 新しいSSDを入れたDS120jでDSMを再構築して、Hyper Backupをインストールし、既存の.hbkを開く
新しいKIOXIA 960GB SATA SSDをDS120jへ内蔵し、DSMを再構築した。※この時点ではまだバックアップのSSDは接続しない
基本的には指示通りに進め、DSMの初期設定を完了させる（既存のユーザ等は気にしなくていい）。
その後、Hyper Backupをインストールし、既存の.hbkを開く準備をする。
Hyper Backupをインストールした後は、復元アイコンから「フォルダとパッケージ」を選ぶ。新NASなので復元タスクの一覧は空だったが、左下の「既存のレポジトリから復元」からUSBを指定できた。usbshare1とバックアップ名を選ぶと、DSMでは.hbk拡張子を省略して表示することがある。
6. システム構成の復元で引っかかった管理者アカウント
共有フォルダだけでなく、ユーザー・共有・ネットワーク・サービス設定も戻したいため、「システム設定情報を復元する」→「全システムの構成」を選んだ。ここで意外な罠があった。
現在ログインしている管理者がadministratorsグループに入っていても、そのユーザー名が復元後に変わる・消えるとHyper Backupはシステム構成の復元を開始してくれない。復元元に含まれている別名の管理者を新規作成しても解決しなかった。
今回通ったのは、無効化されていた既定のadminを一時的に有効化し、adminとしてログインして復元を再実行する方法だった。画面に表示された「現在のシステム設定を上書きし、すべてのサービスを停止して、完了後に再開する」という警告は、全システム構成を戻す場合の想定どおりの確認である。
共有フォルダは全て選択し、アプリケーションも復元対象に含めた。サマリで指定した原本はusbshare1 / synologynas_1.hbkで、復元タイプは「ローカルフォルダ & USB」。実行すると、まず設定と共有フォルダの復元が進み、その後にアプリケーションと依存パッケージの再インストール／更新が始まる流れだった。Antivirus Essential、Audio Station、File Station、Hyper Backup、メディアサーバー、OAuth Service、Universal Search、Synology Photosなどに加え、Node.js v20・v22も対象になった。
この待機中は原本USB SSDを抜かない。DSMを再起動・シャットダウンしたり、ブラウザーから復元を中断したりもしない。復元後はNAS名・IPアドレス・ログインユーザーがバックアップ時点へ戻って接続が切れることがある。元のURLで開けなければfind.synology.comで再検出する。作業完了まで、原本USB SSDとWindows退避コピーの両方を残しておく。
7. 一時的に有効化したadminを忘れず無効化する
今回、システム構成の復元を始めるために、無効化されていた既定のadminを一時的に有効化した。これは復元を通すための対応なので、終わったら放置しない。
ただし、復元画面が消えただけでは早い。復元タスクの成功、共有フォルダ、必要なアプリ、ネットワークを確認し、admin以外の復元後の管理者アカウントでログインできることを確認してから、DSMの「コントロール パネル」→「ユーザーとグループ」でadminを無効化する。削除はせず無効化でよい。adminしかログインできない状態では絶対に無効化しない。
復元後に起きたことと、最終的な直し方
Photosのファイルはあるのに、アルバムが戻らない
全システム構成・共有フォルダ・アプリケーションの復元を実行した直後、Synology PhotosとSynology Application Serviceのインストールだけが失敗した。パッケージセンターから両方を手動でインストールすると、user1(仮)などのユーザーでFile Stationに写真ファイルがあること、Photosでも写真の一部が見えることまでは確認できた。
ただし、Photosの再インデックスを実行しても、アルバムは戻らなかった。ここが今回いちばん大事な切り分けだった。
- 再インデックスで再構築できるのは、写真・動画ファイルとサムネイルの認識
- アルバム、条件付きアルバム、共有などはSynology Photosの管理データ
つまり、写真ファイルが見えていることと、Photosの管理情報まで復元できていることは別である。
PhotosとSynology Application Serviceだけを再復元する
Hyper Backupの既存タスクを開こうとしたところ、バックアップ先が「オフライン」、所有者が「利用不可」と表示され、既存リポジトリからの復元でもアクセス権エラーになった。
File Stationでusbshare1/synologynas_1.hbkのプロパティを確認すると、所有者はnas-admin(仮)だった。所有者をnas-admin(仮)に指定し直し、「このフォルダ、サブフォルダ、ファイルに適用する」を選んで再適用すると、Hyper Backupはバックアップ先をオンライン、所有者をnas-admin(仮)として認識した。
この操作は原本USB SSDの所有者メタデータを書き換える。バックアップデータの中身は変更しないが、読み取り専用退避フェーズとは異なる操作である。実行前にWindows退避コピーを確保し、対象が
.hbkそのものであることを確認した。
その後、nas-admin(仮)で既存のLocal Storage 1タスクから復元を開始し、以下だけを選択した。
- システム構成: 復元しない
- 共有フォルダ: 手動では選択しない
- アプリケーション: Synology Photos と Synology Application Service のみ
最終サマリでは、Photosに必要なhomes/*/Photosが自動的に復元対象へ追加された。バックアップ以降に写真を追加・変更している場合は競合・上書きの可能性があるため、ここで必ず止まって確認する。今回はバックアップ以降に変更がなかったため実行した。
この2アプリとPhotos関連フォルダの復元後、Photosのアルバムまで戻った。
外部接続と再検出も戻す
システム構成の復元後、QuickConnectはIDが残っていても無効化されていた。DSMの「コントロール パネル」→「外部アクセス」からQuickConnectを有効化すると、スマホのSynology Photosアプリから再接続できた。
また、DSMへIPアドレスでは接続できるのにfinds.synology.comで見つからない状態になった。原因は、DSMの「情報センター」→「デバイス分析」にある「このSynology NASがWeb Assistantで表示されることを許可する」が無効だったためである。これを有効化すると、Web AssistantでDS120jを再検出できた。
既定adminは最後に無効化する
全復元の開始時だけ、既定adminを一時的に有効化した。最終的に以下を確認した後、adminは削除せず無効化した。
-
nas-admin(仮)でDSMへログインできる - 共有フォルダ、Synology Photos、アルバムが確認できる
- スマホPhotosがQuickConnect経由で接続できる
-
find.synology.comでNASを再検出できる
教訓、総括
- まずケチらずにちゃんとバックアップを作成しておく。（最重要）
-
バックアップ原本をまず守る。 Windowsの初期化・フォーマット・修復提案を実行せず、Linux側で
roマウントする。 -
fsck -yは実行しない。 障害や異常があっても、原本に書き込む修復は退避コピーを確保するまで避ける。 -
デバイスが見えない障害とファイルシステム障害を分ける。
lsblkに容量のある/dev/sdaが出ず、Read Capacityに失敗する場合は、ファイルシステム修復では解決しない。SSD、SATA端子、USB-SATAブリッジ、給電を疑う。 -
Sambaの認証を先に明示する。 Windows側でゲストアクセスがポリシーによりブロックされる場合、
net useで認証済み接続を作ってからrobocopyする。 - 速度の本命は有線LAN化。 USBをPCとPiの間で直結するのではなく、両者を同じギガビットLANへ有線接続する。
- 復元完了までコピー元を残す。 ローカル退避先、元のHyper Backup SSD、故障疑いSSDをすぐに消去・初期化・廃棄しない。
-
全システム構成の復元では管理者名も復元対象。 現在の管理者が復元後に維持されない場合、権限があっても復元を開始できない。Hyper Backupが要求する既定の
adminで操作できる状態を確認する。 -
一時的に有効化した
adminは後始末する。 復元完了と代替管理者でのログインを確認してから、削除ではなく無効化する。 - Photosの再インデックスはアルバムを復元しない。 アルバムまで戻すには、Photos本体とSynology Application Serviceの管理データをHyper Backupから復元する必要がある。
-
最終サマリは必ず読む。 Photosだけを選んだつもりでも、対応する
homes/*/Photosが復元対象に追加される。バックアップ以降の変更があるなら、実行前に別途退避を取る。
今回の復旧では、故障疑いSSDを無理に修復せず、原本バックアップを保全してから新SSDへ復元することで、共有フォルダだけでなくPhotosのアルバム、スマホからの利用、NASの再検出まで戻せた。障害時ほど「まずデータを触らない」が効いたケースだった。
追記
と、基本的なリストアまでのサポートと、この備忘録の99%をChat GPT Desktopにやってもらいましたが、めちゃくちゃ強力でした。
恐らく自分で調べながらやったら丸一週間くらい掛かってたところが、復旧の時間込みで2日弱くらいで終わりました。
やはり直接コマンドを打って触るなり、ブラウザを直接叩いて操作するなりできるローカルエージェントは、今回のような作業と親和性が高いです。（このために1か月契約してもいいんじゃないかと）
さすがに作文はお見苦しいところもありますが、まぁ事実を残して共有するハードルを下げるという意味では有用じゃないかと思うので、細かいところには目をつぶってくださいまし。