【完全解決】Synology DS923+でスナップショット削除後も容量が回復しない原因と対処法
私もDS923＋を20TBのHDD4本でSHR1で運用しており、合計52TBくらい使えるので、余裕で運用できるだろうと思っていたのですが、最近になって残り6TBしかないと警告が出るようになっていました。そこで、YouTube用に長回ししていたけど使わなかった素材などを少し消しましたが、全然回復しません。
ストレージの使用状況を調べると、なんとスナップショットで36TBも使っているではありませんか。そこでスナップショットを調べてみると128個も保持しており、そんなに要らないので、直近7日分まで削除してみました。
しかし、全然容量が復活しません。調べてみるとNASは消してもすぐに容量が復活しないので24時間くらい待つようにという記事を見たので、3日放置しましたが一向に復活しません。
ChatGTPに相談したところ、紆余曲折しながら解決したので、備忘録として記します。私はそこまで詳しくないですが、それでも役に立つ人もいるかと思いますので。解決することに一生懸命であまりスクリーンショットを取っていなかったで、文字ベースですみません。
DSMの管理画面上ではスナップショットが存在しないように見えるにもかかわらず、
使用済み容量だけが減らない──これは Btrfs特有の仕様 が原因です。
この記事では、Synology NAS（Btrfs）でスナップショット領域が再利用できない場合の解決方法を、実際のトラブルをもとに解説します。
発生する主な症状
- Snapshot Replicationでスナップショットを削除済み
- DSMのUI上にはスナップショットが表示されない
- 使用済み容量がほとんど減らない
- SSHで削除を試みると以下のようなエラーが出る
rm: cannot remove 'xxx': Read-only file system
ERROR: cannot delete 'xxx': Operation not permitted
原因：Btrfsのサブボリュームが残っている
Synologyのスナップショットは、内部的には Btrfsのサブボリューム として管理されています。
DSM上でスナップショットを削除しても、
@sharesnapディレクトリ配下に実体が残るhomes共有フォルダのスナップショットがロックされる
といった理由で、容量が解放されないことがあります。
そのため、単純な rm -rf では削除できず、
SSH + btrfsコマンド + 再起動 が必要になります。
対処手順（安全重視）
※ スナップショットのみを削除する手順です。
※ 通常の共有フォルダや実データには影響しません。
① SSHを有効化してログイン
DSMで以下を有効にします。
- コントロールパネル
- 端末とSNMP
- SSHサービスを有効化
管理者権限のユーザーでSSHログインします。
② 残っているスナップショットを確認
btrfs subvolume list /volume1 | grep sharesnap
ここで @sharesnap が表示される場合、
スナップショットの実体が残っています。
③ homes以外のスナップショットを削除
まずは homes 以外のサブボリュームを削除します。
btrfs subvolume list /volume1 | grep '@sharesnap' | grep -v homes | awk '{print $9}' | while read subvol; do
btrfs subvolume delete /volume1/$subvol
done
④ homes が削除できない場合は再起動
homes は内部サービスと強く結びついているため、
稼働中は削除できないことがあります。
reboot
再起動後、すぐに次の作業を行います。
⑤ homesスナップショットを削除
btrfs subvolume list /volume1 | grep '@sharesnap/homes/GMT' | awk '{print $9}' | while read subvol; do
btrfs subvolume delete /volume1/$subvol
done
⑥ 親サブボリュームを削除
btrfs subvolume delete /volume1/@sharesnap/homes
btrfs subvolume delete /volume1/@sharesnap
⑦ 削除完了を確認
btrfs subvolume list /volume1 | grep sharesnap
何も表示されなければ、スナップショットは完全に削除されています。
コマンドチートシート（まとめ）
# 残存スナップショット確認
btrfs subvolume list /volume1 | grep sharesnap
# homes以外を削除
btrfs subvolume list /volume1 | grep '@sharesnap' | grep -v homes | awk '{print $9}' | while read subvol; do
btrfs subvolume delete /volume1/$subvol
done
# 再起動
reboot
# homesスナップショット削除
btrfs subvolume list /volume1 | grep '@sharesnap/homes/GMT' | awk '{print $9}' | while read subvol; do
btrfs subvolume delete /volume1/$subvol
done
# 親サブボリューム削除
btrfs subvolume delete /volume1/@sharesnap/homes
btrfs subvolume delete /volume1/@sharesnap
注意点とよくある失敗例
rm -rf で消そうとする
Btrfsのスナップショットは rm では削除できません。
必ず btrfs subvolume delete を使用します。
homesを稼働中に削除しようとする
homes はSMBやユーザー管理と連動しているため、
稼働中は Operation not permitted になることがあります。
親サブボリュームを先に削除する
子サブボリュームが残っていると、
Directory not empty
というエラーになります。
正しい削除順序
- 子スナップショットを削除
- homesは再起動後に削除
- 最後に親サブボリュームを削除
まとめ
- DSM上で消えても、Btrfs上では残ることがある
@sharesnapはBtrfsサブボリューム- homesスナップショットは再起動が鍵
- 正しい手順で容量は確実に回復する
この現象はNASの故障ではなく、
SynologyとBtrfsの仕様によるものです。
落ち着いて対応すれば、
データを失うことなく解決できます。
コメント