ボリューム変換（thick→thin→thick）後に共有フォルダーが消えた

rhardih · 2026 年 1 月 4 日午後 5:27

たぶん、とても愚かなことをしてしまったかもしれません。

TS-673を使っていて、これまではデータ用の大きなメインボリューム1つとログ用1つだけで運用していました。スナップショットは今まで有効にしたことがなく、今日初めて有効にしようと決めました。

唯一の問題は、スナップショット用に割り当てる空き容量がなかったので、まずは少しサイズを小さくしなければならなかったことです。

おそらくここが最初の悪い決断だったと思います。サイズを小さくするために、ボリュームを「シック」から「シン」に変換し、いくらかの容量を回収しました。この操作はかなり早く終わり、特に問題はなさそうでした。それから、スナップショット用に5%を確保し、スナップショットを作成しました。すべて正常に動作しているように見えました。

ただ、シンボリュームのまま使い続けるのが少し怖かったです。物理的な容量以上にデータを書き込むとデータ破損のリスクがあるとどこかで読んだ気がしたので、今度は適切に小さくなったサイズで「シック」ボリュームに戻したいと思いました。スナップショット用の確保領域がボリュームサイズを制限するので、これが2つ目の悪い決断だったかもしれません。

とにかく変換を始めたのですが、ものすごく時間がかかり、7時間以上かかったかもしれません。なぜか52.7%で長い間止まっていました。

終わった後、ファイルマネージャーで中身を見ようとしたとき、心が沈みました。共有フォルダーは以前のように表示されますが、どれかをクリックするとエラーが出ます：

システムメッセージ

ファイルまたはフォルダーが存在しません。

不思議なことに、homesだけは動作しますが、中には何もファイルがなく、新しく作成されたようです。共有フォルダー設定ではすべて残っています。

いつもの場所を見ても、やはり共有フォルダーはすべて消えています：

[~] # ls -la /share/Multimedia
lrwxrwxrwx 1 admin administrators 28 2025-11-22 10:22 /share/Multimedia -> CE_CACHEDEV1_DATA/Multimedia
[~] # ls -la /share/CE_CACHEDEV1_DATA/
total 0
drwxrwxrwx  6 admin administrators  120 2026-01-04 16:34 ./
drwxrwxrwt 32 admin administrators 1000 2026-01-04 17:29 ../
drwxrwxrwx  7 admin administrators  160 2026-01-04 17:05 homes/
drwxr-xr-x  2 admin administrators   40 2026-01-04 16:34 .snapshot/
drwx------  3 admin administrators   60 2026-01-04 08:52 .system/
drwxr-xr-x  3 admin administrators   60 2026-01-04 15:22 .wfm/

ただし、ボリュームの使用容量を見ると、正しいTB数が使われているように見えます。20TB中17TB使用中です。

そこで、シンボリュームから作成したスナップショットを見てみると、そちらにはすべてのファイルが残っているようです。「ファイルステーションで開く」リンクをクリックすれば、すべてを参照できるようですが、ディスク容量が足りないと言われて何もリストアできません。

システム上でも直接確認できます：

[~] # ls -la /mnt/snapshot/1/10001/Multimedia/
total 124
drwxrwxrwx 16 admin    administrators 4096 2026-01-04 08:23 ./
drwxrwxrwx 57 admin    administrators 4096 2026-01-04 08:12 ../
drwxrwx—  2 admin    administrators 4096 2025-11-29 21:31 .AppleDB/
drwxrwx—  8      500 everyone       4096 2024-12-31 12:05 Audio/
drwxrwx—  3 admin    administrators 4096 2025-09-05 17:29 Downloads/
drwxrwx—  7 admin    administrators 4096 2025-09-05 17:42 Dump/
drwxrwx—  2 httpdusr administrators 4096 2013-06-18 22:17 .hccache/
drwxrwx—  2 admin    administrators 4096 2018-11-01 18:32 Network Trash Folder/
drwxrwx— 16 admin    administrators 4096 2024-07-23 22:26 Pictures/
drwxrwx—  2 admin    administrators 4096 2015-10-18 18:25 .__qini/
drwxrwx—  2 admin    administrators 4096 2025-09-28 18:48 Recycle/
drwxrws–T  3      500 everyone       4096 2018-03-26 14:41 .TemporaryItems/
drwxrwx—  2 admin    administrators 4096 2018-11-01 18:32 Temporary Items/
drwxrwx—  5 httpdusr everyone       4096 2021-09-17 21:41 .__thumb/
drwxrwx—  2 admin    administrators 4096 2025-01-21 17:42 .upload_cache/
drwxrwx—  8      500 everyone       4096 2025-11-07 17:25 Video/

今のところ「リストア」オプションしか試しておらず、「リバート」は怖くて触れていません。「ボリュームスナップショットのリバート」はスナップショット自体に何かしてしまいそうで、それはまずいと思っています。また、スナップショット作成時に設定していないはずの暗号化パスワードも聞かれます。

再起動も怖くてできません。スナップショットの中身にまたアクセスできるか分からず、それができなくなったら終わりだからです。

今はそのスナップショットの一部を外付けドライブにリストアしている最中ですが、全データを移すだけのストレージが手元にありません。何か元に戻すためのアドバイスがあれば、ぜひ教えていただきたいです。

NB. 上記のファイルパスでは「@」記号を削除しています。コミュニティが人をメンションしていると勘違いし、上限があるようなので……

rhardih · 2026 年 1 月 4 日午後 5:31

現在のプールの状況について、もう少し詳しく説明します：

[~] # vgs
  VG    #PV #LV #SN Attr   VSize   VFree
  vg1     1   6   0 wz--n-  21.80t     0
  vg256   1   2   0 wz--n- 912.54g 88.84g
[~] # lvs -a
  LV                      VG    Attr       LSize   Pool Origin                  Data%  Meta%  Move Log Cpy%Sync Convert
  lv1                     vg1   Vwi-aot---  20.40t tp1                          100.00
  lv1312                  vg1   -wi-ao----   2.23g
  lv2                     vg1   Vwi-aot---  17.75g tp1                          1.60
  lv544                   vg1   -wi------- 144.00g
  snap10001               vg1   Vwi-aot---  21.50t tp1  lv1                     80.52
  tp1                     vg1   twi-aot---  21.59t                              99.10  2.91
  [tp1_tierdata_0]        vg1   vwi-aov---   4.00m
  [tp1_tierdata_1]        vg1   vwi-aov---   4.00m
  [tp1_tierdata_2]        vg1   Cwi-aoC---  21.59t      [tp1_tierdata_2_fcorig] 99.98                  0.00
  [tp1_tierdata_2_fcorig] vg1   owi-aoC---  21.59t
  [tp1_tmeta]             vg1   ewi-ao----  64.00g
  lv256                   vg256 Cwi-aoC--- 799.57g                              99.98  0.46
  [lv256_cdata]           vg256 Cwi-ao---- 799.57g
  [lv256_cmeta]           vg256 ewi-ao----  15.00g
  lv545                   vg256 -wi-------   9.12g

NA9D · 2026 年 1 月 4 日午後 5:55

まず第一に、私見ですが、シンボリューム（thin volumes）が最適だと思います。これにより、より柔軟な運用が可能になります。

シンボリュームでは、ボリュームサイズを物理ディスク容量より大きく設定することができますが、もちろんその容量を超えてしまうと問題が発生します。ただし、容量の管理を注意深く行えば、それは簡単に回避できます。

なぜこの問題が発生したのかは分かりませんが、ボリュームのリサイズや構成変更の際に何か問題が起きた可能性があります。また、記憶が曖昧ですが、シックボリューム（thick volumes）とシンボリュームでスナップショットの制限があったと思います。これは、スナップショットがシンボリュームの未使用だが「割り当て済み」の領域に存在でき、その領域が消費されるとスナップショットが削除されるためです。シックボリュームではその柔軟性がありません。

いずれにせよ、スナップショットがあるのは素晴らしいことです！リバート（revert）は基本的にスナップショットの復元です。言葉が少し分かりづらいですね。

基本的には、ユニット上でスナップショットをボリュームとして開き、データをコピーできるはずです。ただし、何か作業を始める前に、スナップショットを外付けドライブにクローンしておくことをおすすめします。そうすれば、すべてのバックアップが取れます。

SteveKo · 2026 年 1 月 6 日午前 9:36

こんにちは、弊社の内部チームが本件を調査し、分析を行います。状況をより正確に把握するために、現在のデータ使用状況について詳しくご教示いただけますでしょうか。

総容量21.8TBのうち、現在どれくらい使用されていますか？
主にどのような種類のデータを保存されていますか（例：大容量のメディアファイル、数多くの小さなドキュメント、バックアップなど）？

ご協力ありがとうございます。

rhardih · 2026 年 1 月 6 日午後 5:24

それは良さそうですね。

現在、メインの21.33TBボリュームでは使用量が17.03TB、セカンダリの16.97GBボリュームでは47.91MBとなっています。
実際、ご指摘のすべての種類のファイルが混在しています。大きなメディアファイルも多く、小さなファイルもたくさんあります。また、複数のMacのTime Machineバックアップも保存されています。

NA9D · 2026 年 1 月 6 日午後 6:28

あっ！問題がここにあるかもしれません。

あなたの総容量は21.8TBです。スペース警告は80%に設定されています。21.8の80%はおおよそ17.44です。

スペース警告に引っかかっていると思います。これを下げてみると、うまくいくはずです。

それはおかしいですね。ボリュームは16.97TBの間違いですか？

でも、総容量は21.8TBと言いましたよね。

つまり、シンボリュームのストレージスペースをオーバーサブスクライブしています。最初のボリューム（21.33TB）で80%使用に近づいていて、さらにデータを書き込もうとしているので、全ボリュームの合計が80%を超えようとしています。

ボリューム警告サイズを下げることもできますが、デュアルボリュームが物理的な容量以上のスペースを奪い合う状況になるので、総容量に近づく際は注意してください…

rhardih · 2026 年 1 月 6 日午後 7:41

すみません、タイプミスしました。本当は「MB」と書くべきでした。そこにはほとんどログデータがありません。

メインボリュームはほぼ80%のレベルにありますが、アラート設定は実際に通知以外の意味がありますか？

NA9D · 2026 年 1 月 6 日午後 7:45

わかりました。つまり、厚いボリュームと薄いボリュームがあるということですね。さらに、そこにスナップショットがあり、そのスナップショットの保持情報はありません。

おそらく、スナップショットが小さいボリュームの拡張を妨げているのだと思います。スナップショットが未割り当て領域の残りを占有していて、設定によって削除できない状態になっているのではないでしょうか。

rhardih · 2026 年 1 月 6 日午後 7:59

小さい方の薄いボリュームは本来成長するものではなく、ログ用としてのみ使われる予定だったので、合計で50MB未満になっています。

スナップショットの保持について何を意味しているのかよく分かりませんが、「永久に保持する」にマークしてあることは確認しました。今ではそこだけが古いファイルを見つけられる場所なので、本当に削除されないことを期待しています。もし消えたら、それで全て終わりです。

dosborne · 2026 年 1 月 6 日午後 9:34

スレッド全体を読まずに言いますが、スナップショットだけをバックアップ手段にしているのであれば、それはおすすめしません。もしファイルが重要なら、外部の場所（リムーバブルドライブ、セカンドNAS、クラウドなど）にバックアップするべきです。

Becker2020 · 2026 年 1 月 6 日午後 10:04

こんにちは、

プールが満杯になっていると思います。

https://www.qnap.com/en/how-to/faq/article/why-is-my-storage-pool-full-when-there-is-still-free-space-in-my-thick-volume

これが次の問題です

https://www.qnap.com/en/how-to/faq/article/what-does-it-mean-when-a-volume-status-is-readdelete-and-what-can-i-do

NA9D · 2026 年 1 月 7 日午前 12:37

はい、しかし薄型ボリュームは定義上「成長」します。スペースは割り当てられていますが、そのスペースは必要になるまでボリュームの一部にはなりません。

その通りです！厚型ストレージボリュームにどれだけデータがあるか分かりませんが、成長するにつれてスナップショットも成長します。スナップショットは未使用・未割り当てのスペースに存在するので、@Becker2020さんが指摘したように、プールがいっぱいになったわけです。未使用スペースがもう残っていません。

そして、スナップショットは便利ですが、ドライブが故障したらスナップショットも失われます。最低限、他の場所にバックアップを取るべきです。スナップショットは定期的に取得しておくことで、ファイルやディレクトリの以前のバージョンに素早く戻れるのが利点です（例：ディレクトリを誤って削除しても、スナップショットからすぐに復元できる）。

でも、結局いっぱいになってしまいました。もっと柔軟性が欲しいなら、厚型ボリュームを薄型ボリュームに戻すことをおすすめします。

SteveKo · 2026 年 1 月 7 日午前 8:53

こんにちは、ご報告いただいた問題について、現在チームが再現を試みております。

その間に、現在のお客様のデータの状況についてご教示いただけますでしょうか？引き続きファイルへのアクセスやご利用は可能でしょうか、それともシステムが完全に停止し、利用できない状態でしょうか？

ご協力ありがとうございます。

rhardih · 2026 年 1 月 7 日午後 6:26

最も重要なデータはオフサイトに複製していますが、すべてではありません。そこでは10TB未満しか利用できないため、どのデータを優先するかが重要になります。

現在、スナップショットからファイルを1台の大容量外付けドライブにコピーしているところです。そのコピーが完了すれば、QTSでボリュームなどをいじることにも、より自信を持てると思います。

rhardih · 2026 年 1 月 7 日午後 6:31

あなたがリンクした記事には、次のように書かれていますね：

厚いボリューム（thick volume）を薄いボリューム（thin volume）に変換すると、厚いボリューム内の空き領域がストレージプールに戻されます。ただし、一度厚いボリュームを薄いボリュームに変換すると、元に戻して厚いボリュームにすることはできません。

つまり、私がQTSのUIだけでできたことは、本来…不可能なはずですよね？

現時点での私の計画は、スナップショット内のすべてのファイルをバックアップし終えたら、それを直接リバートしてみるつもりです。それが失敗した場合は、まず薄いボリュームに戻してみて、失われたファイルが復元されるか確認し、最終的には薄いボリューム上でスナップショットを復元してみます。それでもダメな場合は、システムフォルダなどを戻すためにファクトリーリセットを行い、その後手動で自分のデータをコピーし直すしかないと考えています。

SteveKo · 2026 年 1 月 9 日午前 9:41

「一度厚巻を薄巻に変換すると、再び厚巻に戻すことはできない」というご指摘について、技術的な補足をさせていただきます。

私の理解では、この記述は主にストレージプール内の空き容量が不足している場合に当てはまります。薄巻から厚巻へ再変換するには、システムがボリュームの全容量を事前に割り当てる必要があるため、ストレージプールに十分な空き容量があれば変換は可能です。しかし、プールが満杯の場合はこの操作を行うことができません。

rhardih · 2026 年 1 月 13 日午後 5:50

最新のアップデートは以下の通りです。

ほとんどのファイルを外部ドライブにrsyncでコピーし、スナップショットの「エクスポート」も実行しました。

rsyncでは、一部のファイルで以下のようなエラーが発生したため、エラーを無視する必要がありました。

2026/01/09 09:54:49 [6988] file has vanished: "/mnt/snapshot/1/10001.....

2026/01/09 09:54:50 [6988] rsync warning: some files vanished before they could be transferred (code 24) at main.c(2289) [sender=3.0.7]

ただ、件数はそれほど多くなかったので、ランダムなビットロットの犠牲になっただけかもしれないと考えています。

スナップショットのエクスポートは、エラーなく完了したようです。

次に試したのは、ボリュームをthinに戻すことでしたが、これは失敗し、UIからスナップショットが見えなくなりました。

その後、ボリュームが異常な状態であると表示されました。

まだthickボリュームのままだったので、ボリュームをスナップショットにリバートしようと試みました。これはしばらく実行されていましたが、仕事から帰宅して確認したところ、以下のエラーで失敗していました。

Error	2026-01-13	12:33:46	admin	192.168.1.5	Web Desktop	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:146.0) Gecko/20100101 Firefox/146.0	Storage & Snapshots	Snapshot Replica	[Storage & Snapshots] Failed to import snapshot "GMT+01_2026-01-04_0841". Path: /ExtRaid/ts-673_DataVol1_GMT+01_2026-01-04_0841.img.0000000, Volume/LUN: DataVol1.

その後、ボリュームはエラー状態になりました。最終的に再起動を試みたところ、再起動後はボリュームがアンマウント状態になりました。

再度スナップショットで試してみますが、うまくいかなければ、次の手段としてrsyncコピーから手動でファイルを復元し、破損していないことを祈るしかないと思います。

NA9D · 2026 年 1 月 13 日午後 9:09

スナップショットを外部ドライブにエクスポートしましたか？

この時点で必要なのは、ドライブを消去してやり直すことだと思います。申し訳ありませんが、それが必要なようです。

rhardih · 2026 年 1 月 14 日午前 5:25

はい、やりました。そして、ボリュームを削除することがおそらく唯一の解決策だと判断しました。今はスナップショットから新しいボリュームを作成しようとしていますが、今のところエラーなく進んでいます。リバートに失敗したからといって、スナップショットから新しいボリュームを一から作成できないという意味ではないことを願っています。うまくいくことを祈っています。

NA9D · 2026 年 1 月 14 日午前 5:26

問題ないはずです。

今回は必要に応じて拡張できるシンボリューム（thin volume）として設定したことを願っています。