ファイルシステムイメージを任意のサイズのパーティションにデプロイする
ルートFSイメージに基づいてUbuntuマシンの展開プロセスを確立したい。イメージを単純にフォーマットされたハードドライブに復元したい（展開中にディスクを完全に消去できる） 。
構成を単純に保ち、別々の/と/homeに分割しないほうがいいです。
これまでClonezillaを使ってみて、復元できるルートパーティションのイメージを作成することに成功しました。ただし、そのプロセスを使用すると、復元先のルートパーティションが小さく、圧縮されていないときのベースイメージと同じくらい小さくなります（約20ギガ）。代わりに、実際のハードドライブのパーティションを最大容量まで拡張してから、すべてのシンボリックリンクやその他のベルやホイッスルを含むファイルシステムをそのパーティションに復元したいと思います。
また、パーティションがドライブに復元されたときに、ドライブにブートローダーとブートパーティションを確実にインストールして構成するプロセスを探しています。どこを見ればいいですか？ ddベースのプロセスはブロックごとにあるようで、宛先パーティションをイメージと同じサイズにする必要があります。同時に、この方法で展開するマシンのすべてのディスクが同じ容量であることを保証することはできません...どのようなアプローチを取るのでしょうか。たぶん私はより高いレベルのイメージングソリューションが必要ですか？パーティションの代わりにファイルシステムをバックアップするものですか？
PDATE：可能な構成にいくつかのプロディングを行った後、私の質問はこれに行き着きます。 1つのステップで次のことを実行できるパイプラインを確立するにはどうすればよいですか。
- dVD/CDからマシンを起動します
- 空のスペースなしで、ハードドライブをMBR/root/swapとしてフォーマットします
- 起動可能であることを確認してください
- ネットワークイメージからルートパーティションのクローンを作成する
これまでのところ、次のワークフローに落ち着きました。
- 小さなディスク（70ギグ）のイメージを作成します
- 全体として復元する
- 手動でgpartedに移動し、パーティションのサイズを変更して、ルートパーティションがイメージバージョンよりも大きくなるようにします
しかし、2つのディスクを続けて起動する必要があるため、非常に面倒です。
ファイルシステムの復元-Bootzillaがどのように機能するかはわかりませんが、基本的に3つのオプションがあります。
基盤となるブロックデバイスレベル（つまり、ファイルシステムの下）で操作します-元のイメージの正確なコピーを作成するクローン作成（例：
dd）を使用します。どんなに大きなパーティションを持っていても、元のサイズのファイルシステムになってしまいます（パーティションまたは物理デバイスが元のファイルシステムよりも小さい場合、厄介な問題が発生する可能性が非常に高くなります）。これは、使用している最速のオプションです（基本的に、ソースデバイスとターゲットデバイスの速度、およびそれらの相互接続によってのみ制限されます）。一方、柔軟性が最も低いものです。最終的に異なるサイズのパーティションを作成する場合は、手動で拡張する（またはスクリプト化する）必要があります。さらに、ブロックデバイス全体の画像を保持することにより、スペースを無駄にしています（画像には未使用のスペースが含まれていますが、ゼロにされてから画像が圧縮される場合があります）。
多数の（ほとんど）同一のシステムを維持している場合は、最も複雑でないため、これが最適な方法です。
操作inファイルシステムレベル-使用しているファイルシステムに付属のツールを使用して、コンテンツをアーカイブし、新しくフォーマットされたファイルシステムに復元します。たとえば、 [〜＃〜] xfs [〜＃〜] の場合、
xfsdump+ _mkfs.xfs_ +xfsrestoreコンボを使用します（詳細については、manページを参照してください）。少し遅くなりますが、保持する画像には必要なデータのみが含まれます（無駄なスペースはありません）。問題のファイルシステムがほとんど空の場合、これは追加のオーバーヘッド（復元時にファイルシステム構造を更新する）を簡単に補うことができます。また、増分スナップショットを作成して展開する機会も提供します。新しいファイルシステムを作成する追加の手順では、必要なパーティションサイズ（十分な大きさ）を使用し、特定のニーズ（ブロックサイズ、メタデータスペースなどの変更）に合わせて各ターゲットファイルシステムを調整できます。欠点は、ファイルシステム固有であるということです。
ファイルシステムレベルで操作します-
tarまたはcpio（またはrsyncまたはcp）などの標準ツールとオプションで圧縮（以前の場合のように）を使用します）。基盤となるファイルシステムは簡単に変更でき、プロセスは非常に簡単です。ツールの動作は非常に異なるため、特別なファイル（スパースファイル、デバイス/名前付きパイプ）の処理には細心の注意を払う必要があります。また、ファイルシステムの境界を越えないようにする必要があります。
ブートローダー-個別の_/boot_パーティションを気にしないでください-代わりに、個別の_/home_を検討することを強くお勧めします。データ用に個別のパーティションを作成する必要がない場合や、悪い考えでさえある場合は多くありません。
使用するブートローダーによっては、フルディスククローンの後でさえ機能する場合があります-同じサイズのディスク（パーティションだけでなく！）間の最初のオプションですが、一般的には「再インストール」が優先されます（そして非常に簡単です）-必要なすべての構成ファイルをコピーしていますしたがって、ブートローダーインストーラーを実行するだけで十分です。
注意しなければならないのは、from whereブートローダーがデータを読み取り、where書き込みますか-新しいファイルシステムにchrootして、そこからブートローダーを実行することをお勧めします。現在アクティブなルートファイルシステムからchroot（つまり、新しく複製されたファイルシステム）に_/dev_、_/proc_、場合によっては_/sys_をバインドマウントしてください。
注：20GBのパーティションは非常に大きいです-例：一般的なデスクトップLinuxのインストールは通常10GBをはるかに下回り、すでにかなりの数のソフトウェアが含まれています。
ユーザーが追加のソフトウェアをインストールしている場合、および/または（管理者として）ユーザーが（マシンごとに）インストールしている場合は、おそらく_/usr_以外の場所に移動する必要があります。ユーザーのソフトウェアは通常、自宅に直接配置されており（特にネットワークにマウントされたホームディレクトリの場合に非常に便利です）、システム固有のプログラムは_/usr/local_に配置する必要があります。これは、簡単に別のパーティションにすることができます。キャッシュ/ログも個別に保持する方が適切です。他のものとは別に、クリーンな分離により、アクセス権を正常に保つことができます-すべてのユーザーが自分のマシンへの管理者アクセス権を持っている必要はありません（はい、それには多くの例外がありますが、最初は常に非標準と見なされるべきです）。マシンを再イメージングしても、必ずしもすべてが破壊されるわけではありません。言い換えると、一部のパーツだけを再イメージングできます。また、MKFS DEVICE_OF(/var/chaches)は_rm -Rf /var/caches_よりも高速です。キャッシュデータのスナップショットを（必要に応じて）ファイルシステムから取得することも簡単です。
欠点-HDDの平均サイズのため、最近ではディスクスペースの断片化（複数のパーティションへの）はそれほど問題にならないはずです。