チャブーンさん、ご回答ありがとうございます。
＞「ファイルストレージのディスク」と「VSSのディスク」は別にする、がベストプラクティスだと思っていて、それで試してどうですか？
はい、 ＞ちなみに、こちらの情報ある回避策の一つ、VSSのボリュームを別に割り当てする構成はとっておりました。
この方法がそれに該当するものと思っておりました。具体的にはブロックストレージ側で通常のファイル共有（重複除去のチャンクストレージも含む）のLUNとは別にVSS用のLUNを作成して割当している構成で使っていました。
＞どうしても無償で何とかしたい、のなら英語版フォーラムに質問するしかないと思いますが、情報の少なさから難しいと思います。
早速、同じチームのメンバーが英語で探してくれたところ、今回のケースに該当するものが見つかりました。こちらに記載されているように、重複除去を設定する前にVSSを動かしていたので、古いVSSのバージョン履歴が残っていることが原因のようです。
https://serverfault.com/questions/472671/mixing-volume-shadow-copy-and-data-deduplication-in-windows-server
古いVSSのバージョン履歴を削除して、最適化（retrim）を実行してみようと思います。
追記：
古いVSSのバージョン履歴を削除して、最適化（retrim）を実行してみたところ、ストレージの容量が回復していました。
解決の目処が立ちました。
ありがとうございました。
