前提条件
拙宅の仮想化基盤はWindows ServerのHyper-Vで動いています。
色々な検証用VMを2TBのNVMe SSDに突っ込んで動かしていたのですが、空き容量が500GBを切り手狭になりましたので、CPU交換のついでにSSDも4TBに交換することにしました。
AcronisTrueImage WD Editionでクローン出来ない！何故だ！
丁度我が家のメインWindows PCはWD社のSSDで動作していますので、AcronisTrueImage WD Editionが使えます。このAcronisTrueImage WD Edition、 Western Digital社の製品が接続されてさえいればクローン元とクローン先がWD社の製品でなくても動作する というかなり縛りの緩い製品です（※2024年2月時点では）。
という訳で早速クローンします。
……クローン元にセクタエラーがあるのでVSSが上手く動かず、必ず特定のセクタでエラーを吐きます。
（ ´_ゝ`）ﾌｰﾝ……
取り敢えずWindows上で実行するとVSSがエラーを吐く。
ならAcronisTrueImage WD EditionのブータブルUSB作ってLinuxからクローンすれば良くね？（名推理
一般のご家庭ならその辺に1本はあるであろう適当なUSBメモリを挿してブータブルUSBを作成して、徐にUSBから起動します。
そしてクローンします。
クローン元にセクタエラーがあるので上手く動かず、必ず特定のセクタでエラーを吐きます。
（ ´_ゝ`）ﾌｰﾝ……
以後NVMe-USBアダプタを換えたり（今回の作業のために購入したアダプタ2種だけでなく、元々持っていたNVMe-USBケースも動員した）、PCを換えてみたりしましたが、兎に角AcronisTrueImage WD Editionではクローン時に特定のセクタでエラーを吐いてしまいます。
CrystalDiskInfo上ではディスクに特段のエラー記録は無く、寿命は100%なのですが。
兎に角1日目はAcronisTrueImage WD Editionでは上手くクローン出来ないという知見を得ました。しょんぼり。
やはりDD……！ DDは（概ね）全てを解決する……！
ディスク交換作業2日目。5G回線のiPadをお供にあーでもないこーでもないと色々調べた結果、次の２手段しかないという結論に至りました。
1.元のSSDからOSを起動してWindows Serverバックアップでディスクイメージを作成して新しいSSDに復元する
多分出来るとは思うのですが、既にAcronisTrueImage WD EditionでVSS関連のエラーを吐いており、実際にWindows上でもエラーが記録されているという事実がありますので、実際に可能かどうかはやや疑問が残ります。
2.ddで小ブロックずつ生データを読み出してエラーはスキップして0で埋めて新しいSSDに書き込む
今までに何度もこの手でセクタエラーを吐いたHDD/SSDから新しいストレージにOSをクローン出来た実績がありますので、これが一番無難な気がします。
両者を5分ぐらい机上で比較検討した結果、やはりddで小ブロックずつ生データを読み出して新SSDに書き込むしかない、という結論に至りました。
Ubuntu Desktop 22.04 LTSのブータブルUSBを作成し、CPUを交換した仮想化基盤サーバーに初期化した新しいSSDを装着。クローン元SSDとブータブルUSBも接続し、ブータブルUSBからUbuntu Desktop 22.04 LTSを起動します。
クローン元SSDとクローン先SSDのデバイス名を控えたら、次のコマンドを実行します。
sudo dd if=/dev/sdb of=/dev/nvme01p0 bs=4096 conv=noerror,sync status=progress
「if」はクローン元、「of」はクローン先のデバイス名です（環境によって変化しますのでご注意ください）。
ちなみにifとofを間違えると取り返しのつかないことになりますので、クローン元とクローン先のデバイス名はくれぐれもお間違えないようにご注意ください。
「bs」はブロックサイズ、「conv」は読み取りエラーが発生した場合は0で埋める処理、「status」は状況表示を行う指示です。
一抹の不安はありますが、兎に角やってみましょう。
実行した結果、最初の5GB付近から20GBあたりまではエラーを吐きまくりました。
20GB付近から先は平均して17MB/sでクローンが行われました（こいつ本当にNVMe-USB（USB3.1/UASP）接続なんか？？？？）。
完了までに約33時間かかりましたが、（ddはなんとか）完了しました。
だが本当の地獄はここからだったのです……。
クローンした新しいSSDが何故かMBR（しかもそれでWindowsが起動する）なのでGPTに変換する
もう見出し記事そのままなのですが、普通のWindows PCは特殊なSSD（Legacy BIOSまたはLegacy Modeでの動作がオンになっているUEFIで動作するPCでもブートドライブとして使用可能なBootROMを持つPlextor M8シリーズのようなものです）でもなければ、通常はNVMe SSDはドライバロードの関係上、UEFIにNVMeドライバが組み込まれたシステム上でGPTで初期化されたドライブでなければWindows OSを起動出来ない筈です（と少なくとも私の知識上では記憶しています）。
で、クローン元SSDはと言いますと……
お前、今までMBRで動いてたんか？？？？？
これが為に新SSDから起動したWindowsのパーティションサイズが2TB（正確には2.2TB）までしか拡張できないことが発覚。
ていうかホンマ何で君MBRで初期化されとるのにNVMe SSDからブート出来とるん？？？？？BootROM（OptionROM）付いてない筈やろ？？？？
しかしこういう時Windowsには心強いMicrosoft純正ツールがあります。
その名もMBR2GPT.exe。
使い方は簡単です。
該当するディスクから起動したWindows上で、管理者権限でPowershellを立ち上げ、次のコマンドを実行します。
C:¥Windows¥System32¥MBR2GPT.exe /validate /disk:0 /allowFULLOS
実行結果に「Successfull」の記述があれば変換可能です。
変換可能な場合は、
C:¥Windows¥System32¥MBR2GPT.ece /convert /disk:0 /allowFULLOS
を実行します。これでGPTパーティションへの変換からEFIブートローダー領域の作成までやってくれます。
但し、Windows回復環境のパーティションの作成に失敗したり、パーティションがCドライブの直後に出来たりするけどな！
実際、拙宅の環境では未使用領域の先頭にパーティションが出来ており、このパーティションを最後方に移動しなければパーティションの拡張が出来ませんでした。
という訳で折角変換が終わった後再起動を掛けて無事GPTになった新SSDからWindowsが起動したのに、ブータブルUSBのUbuntu Desktopに逆戻りして、GPartedでパーティションを移動します（※写真撮り忘れました）。
このパーティションが最後方に移動されたら、再び新SSDからWindowsを起動して、ディスクの管理から素直に（素直に？？？？）ボリュームを拡張しました（※スクリーンショット撮り忘れました）。
これで無事、4TBの領域をフルに使えるようになりました。
だが本当の地獄は（ry
CPUを交換したためかデバイスIDが変わってしまい、Hyper-Vの仮想スイッチとネットワークアダプタの紐付けが解除されてグチャグチャになってしまった
多分この紐付けを直す作業が一番堪えたと思います。
一度仮想スイッチに紐付いていたNICから1本（LAN用）を除いてネットワークケーブルを抜きます。
従来LAN側になっていた仮想スイッチを削除して、新しい仮想スイッチを作成してオンラインになっている該当NICを探して紐付けます。
仮想スイッチが作成出来たら、仮想マシンのネットワーク設定で、仮想NICがあるにも関わらず接続先スイッチが未設定に戻ってしまっているインターフェイスの接続先スイッチを、新しく作成したスイッチに設定します。
これを拙宅では12ある仮想マシン全てに1台1台手動でやりました。
全仮想マシンの設定が終わったら、再び仮想スイッチの設定に戻り、紐付けが狂ってしまっている仮想スイッチを削除して新しい仮想スイッチを作成し直して紐付け、再び仮想マシンのネットワーク設定をチェックして……という作業を仮想マシンと仮想スイッチの数だけ繰り返しました。もう嫌でござるよ……
この作業を終えた頃には、作業開始から72時間を回っていました。辛い。
結論
AcronisTrueImage WD Editionでも失敗するようなシチュエーションのディスククローンでも、Ubuntu（というか、Linux全般）からddコマンドを使ってクローンすることで無事クローンすることが出来た。
ddは神。
MBRなシステムディスクも、MBR2GPT.exeを使うことでGPTに変換出来、パーティションの移動さえ安全に出来るのであれば未使用領域を有効活用出来るようにパーティションの拡張が出来た。