はじめに
私の所属している研究室で，VMware ESXiのバックアップスクリプトを運用していたところ，バックアップデータの一部が欠損していました．原因としては，マルチディスクを使った仮想マシンを考慮できていなかったことで，.vmdk拡張子のファイルが取れていませんでした．
ちゃんと構成やバックアップについて理解していれば問題はない初歩的な内容ですが，これからバックアップ初心者は引っかかるかもしれません．
環境
VMware ESXi 8.0.3 build-24414501
バックアップの構成としては以下の図のようになっています．esxi-backupというVMからjasmine-bk.shをcronを使って3時に起動します．jasmine-bk.shはJasmineというESXiにあるbackup.shを動かすスクリプトです．ESXiのStoreNAS-Jasmine2からStoreNAS-Backup-Jasmineにバックアップを行う．
起こったこと
研究室で卒業課題のために新たに運用するサービスを公開しようと，今年Doktorというマイクロサービスを公開しました．今まで研究室でやっていなかったことをやっているため，問題も多く発生しており，その問題の1つがバックアップデータの欠損です．
バックアップスクリプトである，backup.shでは，スナップショット作成→.vmdk拡張子のファイルをバックアップ→スナップショットの削除→.vmdk拡張子のファイルのバックアップという手順でバックアップを行っています．
作成された当初は恐らくこのバックアップスクリプトで問題は起きておらず，このまま運用されていました．
↓運用していたbackup.sh
date_dir="$(date +%Y-%m-%d-%H-%M)"
echo "date_dir=$date_dir"
mkdir /vmfs/volumes/StoreNAS-Backup-Jasmine/backup/$date_dir
vim-cmd vmsvc/getallvms | grep -v Name | grep StoreNAS-Jasmine2 | awk "{print \$4;}" | cut -f 1 -d "/" | while read vm_name
do
echo "vm_name=$vm_name"
# get virtual machine id
vm_id=$(vim-cmd vmsvc/getallvms | grep "$vm_name" | grep StoreNAS-Jasmine2 | awk "{print \$1;}")
echo "vm_id=$vm_id"
# create a snapshot
vim-cmd vmsvc/snapshot.create $vm_id $vm_name
# create dir
mkdir "/vmfs/volumes/StoreNAS-Backup-Jasmine/backup/$date_dir/$vm_name"
# copy backup vmdisc
vmkfstools -i "/vmfs/volumes/StoreNAS-Jasmine2/$vm_name/$vm_name.vmdk" -d thin "/vmfs/volumes/StoreNAS-Backup-Jasmine/backup/$date_dir/$vm_name/$vm_name.vmdk"
# delete snapshot
vim-cmd vmsvc/snapshot.removeall $vm_id
# copy backup file
find /vmfs/volumes/StoreNAS-Jasmine2/"$vm_name"/* -not -name "*.vmdk" -exec cp {} /vmfs/volumes/StoreNAS-Backup-Jasmine/backup/$date_dir/"$vm_name"/ \;
done
しかし，Doktorの開発環境をリストアするためにバックアップからリストアする際にバックアップデータが欠損していてバックアップが行えませんでした．
原因としてはマルチディスクを考慮してバックアップを取っていなかったからです．マルチディスクとは，1台の仮想マシンに複数の仮想ハードディスクを接続して使う構成のことで，Doktorでは仮想ハードディスクが2台で構成されていました．
わかっている人からしたら当然かもしれませんが，どうやらESXiでは，1つの仮想マシンに複数の仮想ディスクを割り当てるとディスクごとに.vmdk拡張子のファイルが作成されます．具体的には，$vm_name.vmdk（$vm_nameはVM名）と$vm_name_1.vmdkのファイルが作成されていました．現在のシェルスクリプトでは，$vm_name.vmdkしかバックアップが作成されず，$vm_name_1.vmdkのファイル欠損していました．
↓問題の箇所：$vm_name.vmdkを指定しているため，欠損する
vmkfstools -i "/vmfs/volumes/StoreNAS-Jasmine2/$vm_name/$vm_name.vmdk" -d thin "/vmfs/volumes/StoreNAS-Backup-Jasmine/backup/$date_dir/$vm_name/$vm_name.vmdk"
対処
対処方法としては$vm_name.vmdk以外の.vmdk拡張子のファイルも探してバックアップを行うことです．方法はなんでもいいですが，私はforループで.vmdk拡張子のファイルも探し，それらのファイルをバックアップしています．その際，エクステントファイルは直接コピーせずvmkfstoolsコマンド側が勝手に処理してくれるので，*-flat.vmdk，*-delta.vmdk，*-sesparse.vmdkは除外します．
そうすることで，仮想ハードディスクがいくら増えようとも対処ができるバックアップスクリプトにすることができました．
↓改善した問題の箇所
for vmdk in /vmfs/volumes/StoreNAS-Jasmine/"$vm_name"/*.vmdk; do
[ -e "$vmdk" ] || continue
case "$vmdk" in *-flat.vmdk|*-delta.vmdk|*-sesparse.vmdk) continue ;; esac
vmkfstools -i "$vmdk" -d thin "/vmfs/volumes/StoreNAS-Backup-Jasmine/backup/$date_dir/$vm_name/$(basename "$vmdk")"
done
確認
バックアップデータを確認したところ，$vm_name_1.vmdkもバックアップを正常に取れていました．プログラム改善前と改善後で比べると，G2124034-doktor-m-v2_1.vmdkとそれのバイナリファイルである，G2124034-doktor-m-v2_1-flat.vmdkが増えています．
↓プログラム改善前の欠損しているバックアップデータ．
[root@jasmine:/vmfs/volumes/4e27fa8d-6a04048a/backup/2025-10-29-18-00/G2124034-doktor-m-v2] ls
G2124034-doktor-m-v2-151.scoreboard
G2124034-doktor-m-v2-152.scoreboard
G2124034-doktor-m-v2-153.scoreboard
G2124034-doktor-m-v2-154.scoreboard
G2124034-doktor-m-v2-155.scoreboard
G2124034-doktor-m-v2-156.scoreboard
G2124034-doktor-m-v2-157.scoreboard
G2124034-doktor-m-v2-158.scoreboard
G2124034-doktor-m-v2-159.scoreboard
G2124034-doktor-m-v2-160.scoreboard
G2124034-doktor-m-v2-aux.xml
G2124034-doktor-m-v2-flat.vmdk
G2124034-doktor-m-v2.nvram
G2124034-doktor-m-v2.scoreboard
G2124034-doktor-m-v2.vmdk
G2124034-doktor-m-v2.vmsd
G2124034-doktor-m-v2.vmx
G2124034-doktor-m-v2.vmxf
G2124034-doktor-m-v2.vmx~
vmware-157.log
vmware-158.log
vmware-159.log
vmware-160.log
vmware-161.log
vmware-162.log
vmware-163.log
vmware-164.log
vmware-165.log
vmware-166.log
vmware.log
vmx-G2124034-doktor-m-v2-f1f8774a68637ff947552ade47616750672a4d76cc419d31af3561ce2faa5147-2.vswp
vmx-G2124034-doktor-m-v2-f1f8774a68637ff947552ade47616750672a4d76cc419d31af3561ce2faa5147-3.vswp
[root@jasmine:/vmfs/volumes/4e27fa8d-6a04048a/backup/2025-10-29-18-00/G2124034-doktor-m-v2]
↓プログラム改善後の正常に動作しているバックアップデータ
[root@jasmine:/vmfs/volumes/4e27fa8d-6a04048a/backup/2025-11-03-20-30/G2124034-doktor-m-v2] ls
G2124034-doktor-m-v2-151.scoreboard
G2124034-doktor-m-v2-152.scoreboard
G2124034-doktor-m-v2-153.scoreboard
G2124034-doktor-m-v2-154.scoreboard
G2124034-doktor-m-v2-155.scoreboard
G2124034-doktor-m-v2-156.scoreboard
G2124034-doktor-m-v2-157.scoreboard
G2124034-doktor-m-v2-158.scoreboard
G2124034-doktor-m-v2-159.scoreboard
G2124034-doktor-m-v2-160.scoreboard
G2124034-doktor-m-v2-aux.xml
G2124034-doktor-m-v2-flat.vmdk
G2124034-doktor-m-v2.nvram
G2124034-doktor-m-v2.scoreboard
G2124034-doktor-m-v2.vmdk
G2124034-doktor-m-v2.vmsd
G2124034-doktor-m-v2.vmx
G2124034-doktor-m-v2.vmxf
G2124034-doktor-m-v2.vmx~
G2124034-doktor-m-v2_1-flat.vmdk
G2124034-doktor-m-v2_1.vmdk
vmware-157.log
vmware-158.log
vmware-159.log
vmware-160.log
vmware-161.log
vmware-162.log
vmware-163.log
vmware-164.log
vmware-165.log
vmware-166.log
vmware.log
vmx-G2124034-doktor-m-v2-f1f8774a68637ff947552ade47616750672a4d76cc419d31af3561ce2faa5147-2.vswp
vmx-G2124034-doktor-m-v2-f1f8774a68637ff947552ade47616750672a4d76cc419d31af3561ce2faa5147-3.vswp
[root@jasmine:/vmfs/volumes/4e27fa8d-6a04048a/backup/2025-11-03-20-30/G2124034-doktor-m-v2]
まとめ
新しいサービスを作成するたび，そのサービスのバックアップ方法も既存の手法が適用できるのかしっかり考える必要があります．今回はマルチディスクを考慮したバックアップが行われていかったため，リストアする際にバックアップデータが欠損している問題が発覚しました．
再発を防ぐためには，毎回リストアしてバックアップが正しく取れているのか確認するのは大変なので，アラートルール作って監視するとかが現実的ですかね．一旦卒業研究が落ち着いたらバックアップを監視できるExporterを作成しようと考えています．