ClonezillaでLinux環境の安全を確保する
システムの故障は、決まって不都合なタイミングで起こるものです。カーネルアップデートの失敗であれ、SSDの書き込み寿命による突然の死であれ、大惨事を「なかったこと」にできるかどうかは、コーヒーを一杯飲む程度の休憩で済むか、12時間に及ぶ復旧作業に追われるかの分かれ目となります。3年間で15以上の本番 Linuxノードを管理してきた経験から私が学んだのは、「テストしていないバックアップは、ただの無意味なデータの集まりに過ぎない」ということです。盲目的に信頼できる復旧プロセスが必要なのです。
Clonezillaは、ディスクイメージ作成における定番のオープンソースツールです。単にフォルダをコピーするのではなく、ブートローダー、パーティションテーブル、隠しセクタに至るまで、マシンの根幹部分を丸ごとキャプチャします。このガイドでは、個別のワークステーションやサーバーを蘇らせるための必須ツールであるClonezilla Liveに焦点を当てます。
クイックスタート：10分で終わるバックアップ
急いでいる方のために、システムイメージを取得するための効率的なワークフローを紹介します。ClonezillaのISOを書き込んだUSBメモリ（RufusやBalenaEtcherを使用）と、イメージを保存するための二次ドライブが必要です。標準的な40GBのUbuntuインストールであれば、通常12分以内に完了します。
- 起動: Clonezilla USBを差し込み、BIOS/UEFIブートメニューから選択します。
- 言語: デフォルトのまま「Enter」を押します。
- 初期化: 「Start_Clonezilla」を選択します。
- モード:
device-imageを選択します。これにより、直接のクローンではなく、ポータブルなイメージファイルが作成されます。 - ストレージ:
local_devを選択します。ここで外付けドライブを接続し、カーネルが認識するまで5秒待ってから「Enter」を押します。バックアップを保存する特定のパーティションを選択します。 - ウィザード:
Beginner mode（初心者モード）を選択し、次にsavediskを選択します。 - 識別: イメージに名前を付け（例：
2026-04-18_db-server-prod）、ソースディスク（通常、SATAならsda、NVMeならnvme0n1）を選択します。 - 圧縮:
-z1p(gzip)を使用します。速度とファイルサイズのバランスが最も優れています。 - 実行: 「y」で確定します。Clonezillaが外付けドライブへのデータ転送を開始します。
深掘り：なぜClonezillaは標準的なツールより優れているのか
rsyncのような単純なファイルバックアップでは、低レベルのメタデータを見落としてしまいます。一方で、古典的なddコマンドは「愚直」です。500GBのドライブであれば、たとえ450GBが空き容量であっても、すべてのビットをコピーしてしまいます。Clonezillaは、Partcloneを使用することで、より効率的な手法を採用しています。
Partcloneは、EXT4、XFS、Btrfsといった一般的なファイルシステムを理解します。実際に使用されているブロックを特定し、空のブロックは無視します。このインテリジェンスにより、100GBしかデータが入っていない1TBのドライブは、巨大な1TBのファイルではなく、約50GBの圧縮イメージとして保存されます。
イメージ vs ダイレクトクローン
最初に2つの主要な選択肢に直面します：
- device-image: 圧縮ファイルのフォルダを作成します。4TBの大容量バックアップドライブに数十個のイメージを保存できるため、アーカイブに最適です。
- device-device: 即時の移行用です。古い256GBのSSDから新しい1TBのNVMeにアップグレードし、すべてを一気に移したい場合に使用します。
ポータビリティの要素
クラウドのスナップショットは便利ですが、特定のプロバイダーに縛られてしまいます。Clonezillaのイメージはプラットフォームに依存しません。私は、物理ワークステーションをProxmoxやVMware環境に移行する際、ドライバを一つも再インストールすることなく、頻繁にこれらのイメージを活用してきました。OSをポータブルなコンテナに変えてくれるのです。
高度な設定：ネットワーク共有（SSH）へのバックアップ
サーバーラックでUSBケーブルを差し替えるのは面倒な作業です。私のお気に入りのワークフローは、SSHサーバーを中央リポジトリとして使用することです。これにより、NASや専用のバックアップサーバーにイメージを集約できます。
「Mount Storage」ステップでssh_serverを選択します。保存先サーバーのIPアドレス、ポート（通常は22）、および書き込み権限を持つユーザーが必要です。
# まずストレージサーバー側の準備を行う
sudo mkdir -p /mnt/backups/srv-01
sudo chown -R backup-user:backup-user /mnt/backups/srv-01
Clonezillaはsshfsを使用してリモートフォルダをマウントします。標準的なギガビットLANであれば、110MB/s程度の速度が期待できます。このレートなら、100GBのシステムイメージ全体が約15分で完了します。
エキスパートモード：イメージの縮小
標準的な復元では、ターゲットディスクがソースよりも1MBでも小さいと失敗します。Expert mode（エキスパートモード）がこれを解決します。-icds（ディスクサイズのチェックを無視）フラグと-k1オプションを使用することで、パーティションテーブルを比例的にリサイズさせることができます。これは、古い500GBのHDDから最新の480GBのSSDに移行する際の救世主となります。
鉄壁の復旧を実現するためのルール
イメージの作成は最初の一歩に過ぎません。ディスクが死んだときに途方に暮れないよう、以下のプロトコルに従ってください。
1. CRCの検証
バックアップ完了後、Clonezillaはイメージの整合性をチェックするかどうか尋ねてきます。必ず「Yes」と答えてください。チェックサムを実行し、転送中にビット反転が起きなかったことを確認します。この追加の3分間は、最高に価値のある保険となります。
2. 避難訓練（リストアテスト）の実施
設定が間違っていたことを知るのが、本当のクラッシュ時であってはいけません。取得したイメージをVirtualBoxなどの仮想マシンに復元してみてください。OSが起動し、Webサーバーやデータベースが立ち上がるなら、その戦略は有効です。仮想マシンで失敗するなら、実機でも失敗します。
3. わかりやすい名前を付ける
backup_v1のような汎用的な名前は混乱を招きます。私は厳格に YYYY-MM-DD_[ホスト名]_[ステータス] という形式を使用しています。例：
2026-04-18_web-prod-01_pre-php8.4-upgrade4. ブートモードに注意
UEFIとレガシーBIOSに互換性はありません。UEFIシステムからイメージを取得した場合、復元先のマシンもUEFIモードに設定されている必要があります。これらを混同するとシステムが起動せず、ライブディスクから手動でGRUBを修復する羽目になります。
Clonezillaをマスターすれば、重要なシステムアップデートに伴う不安が解消されます。それは、自信を持って実験や最適化を行えるようにするセーフティネットです。まずは今日、手元のUSBでバックアップを作成することから始めてみてください。一度復元の成功を体験すれば、もうこれなしでサーバーを管理することはできなくなるでしょう。
