コミュニティソリューション

ZimaOSのシステムドライブを、より大容量のSSDへ安全にアップグレードする

A user with a 32GB ZimaOS SSD wanted more capacity without losing app and VM paths; the community recommended an offline whole-disk clone and delayed expansion.

計画的にZimaOSのシステムドライブをアップグレードする場合は、古いディスク全体を大容量SSDにクローンし、古いシステムディスクを切り離した状態で起動して、すべてのアプリとVMのパスを確認してから、使用可能な容量を拡張してください。これにより、ファイルを手動でコピーするよりも多くの状態を保持でき、元のドライブに手を加えずに済むため、ロールバックも可能になります。

2026年の元スレッドはIceWhaleスタッフによる手順ではなく、コミュニティの助言です。そのため、ディスク全体のクローンは実用的な移行方法として扱い、正式にサポートされたワンクリックのZimaOS機能とは考えないでください。最もリスクが高いのはコピー自体ではありません。2台の重複したシステムディスクを同時に起動したり、クローンが動作することを確認する前にパーティションのサイズを変更したりすることが問題です。

再インストールよりクローンが適している場合

クローンが適しているケース:

  • アプリがすでに設定されている。
  • VMのパスとストレージマッピングが機能している。
  • 元のSSDが正常な状態である。
  • 現在のシステムをそのまま維持したい。

古いインストールにエラーが蓄積している場合や、永続的なアプリデータの大部分がすでに別のストレージに保存されている場合は、クリーンインストールのほうが適していることがあります。

まずVMとアプリデータをバックアップする

計画的なクローンでも、ディスクの選択ミス、停電、交換先SSDの不良によって失敗する可能性があります。システムドライブに触れる前に、重要なVMデータと永続的なDockerフォルダーをエクスポートまたはバックアップしてください。

バックアップ計画ガイドでは、より包括的なバックアップ方法を説明しています。

ステップ1:オフラインでディスク全体をクローンする

Rescuezilla、Clonezilla、または別のディスクイメージ作成ツールを、別のブートメディアから使用します。古いSSD全体を、より大容量の交換用SSDにコピーします。

表示されているストレージパーティションだけをコピーしないでください。ZimaOSは複数のブート/システムパーティションとデュアルスロットアーキテクチャを使用しています。

ステップ2:古いドライブには手を加えない

クローンが完了したら、シャットダウンします。元のSSDを取り外し、安全な場所に保管します。まだフォーマットしないでください。

クローンが起動に失敗したり、アプリのパスに問題が生じたりしても、手を付けていない古いSSDがあれば、確実にロールバックできます。

ステップ3:拡張前に起動と動作を確認する

確認項目:

  • ZimaOSが正常に起動する。
  • ダッシュボードのバージョンが正しい。
  • アプリが表示される。
  • Dockerワークロードが起動する。
  • ZVMゲストからディスクが認識できる。
  • 共有とマウントが想定どおりのパスを維持している。

この確認を終えてから、追加のSSD容量について検討してください。

ステップ4:クローンしたパーティションレイアウトを確認する

実行:

lsblk
lsblk -f
df -h

セクター単位のクローンでは、通常、元のパーティションサイズが維持されます。追加容量は、書き込み可能なデータパーティションがすぐに拡張されるのではなく、未割り当て領域として表示される場合があります。

ZimaOSのシステムパーティションを無闇にリサイズしないでください

ZimaOSは、ブートとA/Bシステムリカバリ用に複数の小さなパーティションを使用します。誤ったパーティションを拡張すると、今後のアップデートやリカバリに失敗する可能性があります。

実際の目的がシステムパーティションの拡張ではなく、アプリやデータの容量を増やすことであれば、別のSSDを追加し、ZimaOSのデータ移行またはアプリストレージパスを使用するほうがすっきりする場合があります。

現在のZimaOSストレージ設定ガイドでは、ワークロードに応じて高速なアプリデータと大容量ストレージを分離することを推奨しています。

代替策:システムディスクを拡張する代わりにアプリデータを移動する

32GB/64GBのシステムディスクが正常に動作していて、問題がAppDataの増加だけである場合は、OSをクローンせずに永続的なアプリデータをより大きなストレージ領域へ移動することで、容量の問題を解決できます。

これにより、将来システムを再インストールする際の影響範囲を抑え、ユーザーデータを最小容量のディスクから分離できます。

ZimaOS Plusのアクティベーションについて

IceWhaleのほかの議論では、ブートディスクを変更するとZimaOS Plusの認証に影響し、サポートを通じた再バインドが必要になる場合があると指摘されています。Plusを使用している場合は、移行前に現在のアクティベーション状態を記録してください。

よくある質問

ディスク全体のクローンで、DockerのパスとVMのパスは維持されますか?

それがディスク全体をクローンする主な利点です。2026年のコミュニティ推奨では、既存の動作中のパスを維持するため、ディスク全体のクローンが特に推奨されていました。

ZimaOSの実行中に直接クローンを作成できますか?

コピー中にファイルシステムの状態が変化しないよう、レスキューメディアからオフラインでクローンを作成することを推奨します。

容量の大きいSSDなら、自動的に全容量が表示されますか?

必ずしもそうとは限りません。生のクローンでは、適切な書き込み可能領域を安全に拡張するか、別途使用するまで、追加の容量が未割り当てのまま残ることがあります。

クリーンインストールを選択すべきなのはどのような場合ですか?

現在のシステムが不安定な場合、または永続データが別のストレージに安全に保存されていて、アプリの再構築が容易な場合は、再インストールを選択してください。