LVMブロックデバイスのオフサイトフルバックアップを作成する必要があります。以前のddSSH方法を検討してください。
一貫したバックアップを確保するには、まずLVMスナップショットを作成する必要がありますか？
その後、新しく変更されたブロックはスナップショット論理ボリュームに書き込まれますが、dd元の論理ボリュームに書き込まれませんか？その後、スナップショットのみを使用してプライマリ論理ボリュームに書き込みを続け
ます。lvremove
私はddこれが最も遅く最も効率が悪い方法であると誰もが言うのを見ます。代替は何ですか？
圧縮せずにブロックデバイスのフルバックアップをより速くする方法がわかりません。
編集：さて、私が覚えていたことの1つは、ddFSレベルのデータに関係なくブロックがもちろん転送されることです。したがって、単一の1Kテキストファイルを持つ300GB LVの場合、dd300GBブロック全体が転送されます。それはできません。私はLVを約80％に保つので、送信ごとに追加の20％をあまり心配する必要はありません。
ベストアンサー1
スナップショット：バックアップしたいパーティションが現在マウントされている場合は、まずスナップショットを撮ります。 しかし、、追加する必要がありますスナップ写真、いいえ元のボリューム。とにかくマウントすると、元のボリュームの内容が変更されます。
その後、元の論理ボリュームを追加すると、新しく変更されたブロックがスナップショット論理ボリュームに書き込まれますか？
習慣。ブロックが変更されると、前のコンテンツが最初にスナップショットにコピーされます。これにより、元のボリュームのブロックが新しいコンテンツで上書きされます。バラよりhttp://tldp.org/HOWTO/LVM-HOWTO/snapshotintro.htmlもう1つの説明（スナップショットの仕組みがそれほど直感的ではないことは認めます。この二重コピーは、スナップショットボリュームの書き込みパフォーマンスが低下する理由でもあります。）
また、誰もがddが最も遅く効率が悪い方法であると言うのを見ます。代替は何ですか？
おっしゃるように、主な問題は、ファイルシステムが実際にブロックを使用しているかどうかに関係なく、すべてのブロックをコピーすることです。代わりに
- ファイルベースのバックアップ（例：古いtarファイル）もちろん、これには独自の欠点があります。たとえば、単純なddを使用して破損したディスクを回復できない、またはブートローダを保存しないなどです。
- 混合ソリューション。http://www.partimage.org/ディスク "smart" dd と同様の操作を行います。実際にどのブロックが使用されているかがわかるほど、ext2/3/xfs について十分に知っており、他のすべてのブロックがゼロで埋められていると仮定し、そのブロックのみをコピーします。残念ながら、partimageはext4またはbtrfsをサポートしません。