ClonezillaでCentOSをHyper-VへP2V｜Partcloneのバックアップ失敗をddで回避した実録

前任者が不要PCで作っていたCentOS 6.4を廃棄するために，イメージを取って復元することにしました。

事の発端は，倉庫から資産管理されていない太古のサーバーが発掘されたためです。
捨てるにしても，何者なのかわかりません。
そのため，まずは起動させてみました。

起動はしました。
したんですが，パスワードが分かりません。
前任の前任者くらいの世代で，誰もわかりません。

今回は太古のサーバーの話ではないので，出番はここで終了です。

そんなサーバーに太刀打ちするためには，冒頭に話した，CentOS マシンに縋ったわけです。
このCentOSマシンは前任者から一方的に渡されたもので，あまり大事に扱っていなかったからか，起動はするものの，HDDからカラカラと音がします。

そもそも，CentOS 6シリーズは，6.10が2020年11月30日にEOLとなっています。
その中でも，このマシンはCentOS 6.4と，2013年頃のOSになります。

OSがEOLしていることは分かっていますが，中に何が入っているか分からないので，移行しないで塩漬けにしていました。
とりあえず，まず物理サーバーをそのままイメージ化してHyper-Vへ退避し，その後，GLPIやPukiWikiを新しいLinux環境へ移すことにしました。

今回はその一連の流れをまとめます。

※2026年9月時点での検証内容です。

今回移行するCentOSサーバー

まず，CentOS上で構成を確認してみました。
使ったのは以下のコマンドです。

cat /etc/centos-release
uname -a
php -v
httpd -v
mysql --version

結果は次のとおりで，かなり歴史を感じる構成です。

ディスクの構成は以下でした。

/dev/sda
├─ /dev/sda1  500MB  /boot
└─ /dev/sda2  約232GB LVM
      ├─ lv_root  50GB
      ├─ lv_home  約178GB
      └─ lv_swap  約4GB

/homeは178GBも確保されていますが，実使用量はほとんどなく，WebアプリやMySQLのデータは主にroot側に置かれていることがわかりました。

最初はClonezillaの通常方式でバックアップ

Clonezilla Liveを起動し，物理ディスク全体をイメージ化しました。

Start Clonezilla
↓
device-image
↓
local_dev
↓
保存先USB HDD
↓
savedisk
↓
sda

この時点ではバックアップできたと思っていました。

ここで出来上がったイメージ容量が妙に小さかった違和感をスルーしたために，リストアに失敗することになりました。

Hyper-Vは第1世代VMを使用

元CentOSにてディスクを確認しMBR形式であることが分かりました。
Legacy BIOSで起動していることも分かりました。

fdisk -l /dev/sda
ls /sys/firmware/efi
No such file or directory

Hyper-Vでは第1世代VMがLegacy BIOSで，第2世代VMがUEFIを使用します。

今回は，以下の構成で仮想マシンを作成しました。

構成

• Hyper-V
• 第1世代
• 2 vCPU
• メモリ：4096GB
• 300GB VHDX（動的拡張）
  

元ディスクは約250GBだけど，復元先が元よりわずかに小さいと面倒なので300GBにしています。

もしも第2世代で作ってしまうと

こんな画面が出ます。こうなると仮想マシン作り直しです。

Hyper-Vの仮想マシンに復元

折角手順をキャプチャしたので，一応残しておこうと思います。

画像が多いので，1ステップ2枚で進めます。スマホでみると小さくなってしまいますが，タップして拡大してください。

STEP

言語の選択する

Chose Languageは，ClonezillaのUI上の表示です。
ここでは日本語を選択しましたが，後々出てくる表示に困惑しました。

STEP

「Start Clonezilla」で開始する

イメージから復元するため，開始を選択します。
コマンドラインもありますが，何につかうのかわかりません。

STEP

モードの選択は「device-image」，イメージのマウントは「Local_dev」を選択

今回はイメージファイルから，復元なので，device-imageを選択した。
デバイス，デバイスもできるらしいが，用途は思いつかなかった。

STEP

物理デバイスリストが表示されるので，保存先を確認する

USBを刺したり抜いたりできるのはここ。
次の画面へ遷移した後がよくわからなかった。

STEP

要注意：システムチェックは何もなければ「no-fsck」で進める

バックアップするときには，オリジナルを壊しかねない。

STEP

リストアを選択

STEP

リストアするイメージファイルを指定し，リストア先のディスクを指定する

STEP

パーティションの指定はイメージのもの，リストア可能かの確認は不要，ログの保管は任意で

パーティションの指定は，基本的にはイメージのものがトラブル少ないってのは経験則です。

STEP

完了後の動作は「シャットダウン」を選択，画面が切り替わったら「Y」を押してEnterで開始

完了後の動作は，こだわりなければシャットダウンがおすすめです。次の工程にスムーズに進めます。

Hyper-Vへ復元するとKernel Panic

作成したClonezillaイメージをHyper-VのVHDXへ復元してみました。

GRUBも起動し，CentOSのKernelまでは読み込んでいるようですが，途中でマウントにエラーが出て，Kernel panicになりました。

mount: you must specify the filesystem type
mount: you must specify the filesystem type
mount: you must specify the filesystem type
mount: you must specify the filesystem type
mount: you must specify the filesystem type
mount: you must specify the filesystem type
mount: you must specify the filesystem type
Kernel panic - not syncing: Attempted to kill init!

最初は，物理サーバーからHyper-Vへハードウェアが変わったために，initramfsにHyper-V用ドライバーが入っていないのか，ぐらいにしか考えていなかったのですが，調査を進めると，原因は別にありました。

インストール用ISOからRescueモードでLVMを確認する

CentOS 6.10のインストールDVDからRescue環境を起動してみました。

原因はClonezillaの保存ログに残っていた

ここで最初に作ったClonezillaイメージを確認しました。

フォルダ内には，あるはずのvg_cent2-lv_root.ext4-ptcl-img...がなく，saving-error-XXXXXXXXというファイルが残っており，バッチリと原因が書いてありました。

Saving /dev/vg_cent2/lv_root ...

extfsclone.c: bitmap free count err,
partclone get free:11701278 but extfs get 11701263.

Please run fsck to check and repair the file system

Failed to use partclone program to save or restore an image!

Failed to save partition /dev/vg_cent2/lv_root.

結局のところ，全イメージ化に失敗していました。

/bootは保存成功
/homeも保存成功
swapも保存
lv_rootだけ保存に失敗

その不完全なイメージをHyper-Vへ復元したので，rootファイルシステムをマウントできずKernel Panicになっていた状態です。

Partcloneがext4の不整合を検出して停止していた

最初のClonezillaでは，-q2で実行されていました。

Clonezilla公式ドキュメントによると、-q2はPartcloneを使用するモード。
一方，-q1 は「Force to use dd」で，ddを強制的に使用する方式とのこと。

Clonezilla公式によると-q1は，非効率で遅いものの，すべてのファイルシステムで動作すると記載がある。

Partcloneはファイルシステムを理解して使用中ブロックを中心に保存するため効率的ですが，今回はext4のbitmap情報に不整合があり，保存処理そのものを拒否したってことらしいです。

そこで方針を変更します。

Clonezillaを「-q1 Only dd」で取り直す

状況から見て，オリジナルにも問題はあるとは思います。
だけど，オリジナル側を壊すわけにはいかない局面なので，fsck -yの実行はできませんでした。

壊しそうで怖いからね。

そのため，まず壊れた状態も含めて，そのままバックアップする方針としました。

Clonezillaをもう一度起動し，次の順で選択しました。

STEP

Beginner/Expertは，Expertを選択

STEP

ファイルの修復は「no-fsck」

STEP

Savediskを選択し，名前を変更しておく

STEP

モード選択は「-q1」のDDモードを選択

STEP

拡張パラメータは選択せずに「了解」

そろそろ，了解に違和感がなくなってきた。

STEP

圧縮は「-z9」，分割は「4096」を選択

どちらもBeginnerだったときと同じ内容です。

STEP

ここからは特に，変更なく「了解」

STEP

ここも画面に従っていく

完了後はシャットダウンのみ選択しました。

dd方式で取得すると約20GBのイメージになった

2回目に作成したClonezillaイメージは，圧縮後で約20GBでした。

最初のバックアップと比較すると明らかに大きいです。

もちろん，「20GBだったから正常」 なわけでも 「小さかったから壊れていた」なわけでもないので，容量だけで判定することはできないです。

とはいえ，20MBと20GBじゃあ，気がつくべきですよね。

dd方式のイメージをHyper-Vへ再度復元

新しく取得した約20GBのイメージを，同じHyper-V第1世代VMのVHDXへ展開してみます。

すると今回は，CentOS 6.4が正常に起動しました
さらにHyper-V上でネットワークアダプターを設定し，クライアントPCからアクセスしてみるとGLPIのWeb画面も表示できました。

CentOS 6をHyper-Vへ移して終わりではない

今回Hyper-Vへ移した目的は，CentOS 6.4を今後も長期間使い続けるためではありません。そのため，前任者が構築した環境を失わないための保存用・移行元として扱い，サポートされている新しいOS・アプリケーション環境へ移すか，内容を確認して破棄しようと思います。

まとめ

今回は，古いCentOS物理マシンをClonezillaでイメージ化し，Hyper-Vへ移行してみました。
最初は通常のPartclone方式でバックアップしたが，ext4のbitmap不整合によりroot領域だけ保存されていませんでした。
その不完全なイメージをHyper-Vへ復元したために，Kernel panicが発生し起動しない状態となりました。
Clonezillaのエラーログを遡ることで原因を特定し，最終的にはExpertモードからddでディスクイメージを取り直し，新しいイメージをHyper-Vへ復元して，CentOSは正常に起動し，別PCからGLPIのWeb画面まで確認できました。

今回の作業を通じて

一番の学びは，バックアップファイルを取得しても，それだけで安心はせず，実際に復元まで確認する必要があると体験できたことだと思います。

分かっちゃいるけど，バックアップが走りきっても，正しくバックアップできているかは，リストアしないとわからないよね。

参考リンク

Clonezilla公式：Save disk image
Clonezilla Liveでdevice-image，local_dev，savediskを使用してディスクイメージを保存する基本手順が掲載されている。
Clonezilla公式「Save disk image」

Clonezilla公式：ocs-sr オプション
今回使用した-q1 --force-to-use-ddと，通常使用される-q2 --use-partcloneの違いを確認できる。
Clonezilla公式「ocs-sr」

Microsoft Learn：Hyper-Vの第1世代と第2世代
Legacy BIOSを使用する第1世代とUEFIを使用する第2世代の違い，既存環境を仮想化する際の選択基準が記載されている。
Microsoft Learn「Hyper-V 第1世代または第2世代」

CentOS Project：CentOS 6 EOL
CentOS Linux 6の更新が2020年11月30日に終了。
CentOS Project FAQ