web-dev-qa-db-ja.com

Xenドメインのバックアップ

現在Xenバックアップシステムを開発していますが、次の問題が発生しました。

バックアップには2つの方法があります。

  • lVMスナップショットからddを実行し、それをtarringし、リモートでrsyncします。
  • lVMスナップショットをマウントし、すべてをリモートの場所にrsyncします

2番目のオプションではrdiff-backupを使用できるので、最初のオプションは実際にストレージを大量に消費しますが、増分バックアップを節約して多くのスペースを節約できます。

今、私は2つの質問があります：

  • ddを使用するときに「空白」を持たない方法はありますか？たとえば、50 GBのLVMボリュームがあり、3 GBしか使用されていない場合、ddを使用すると、50 GBのイメージが作成されます（したがって、47 GBが無駄になります）。 tarはこれを修正できますが、多くの余分な時間がかかります（基本的にはありません）
  • imgによって作成されたこれらのddファイルは、何らかの方法で段階的に保存できますか？
backupxenlvm
6
Devator

空白スペースの圧縮

スナップショットから基本に戻しましょう。まず、1つのファイルをタールアップする理由を確認するようにお願いします。立ち止まって、tarが何をするのか、なぜそうしているのかを考えてください。

$ dd if=/dev/zero of=zero bs=$((1024*1024)) count=2048
2048+0 records in
2048+0 records out
2147483648 bytes transferred in 46.748718 secs (45936739 bytes/sec)
$ time gzip zero

real    1m0.333s
user    0m37.838s
sys     0m1.778s
$ ls -l zero.gz
-rw-r--r--  1 user  group  2084110 Mar 11 16:18 zero.gz

それを考えると、圧縮によって、それ以外の場合は空のスペースで約1000：1の利点が得られることがわかります。圧縮は、スパースファイルのシステムサポートに関係なく機能します。それをさらに強化する他のアルゴリズムがありますが、生の全体的なパフォーマンスについては、gzipが勝ちます。

Unixユーティリティとスパースファイル

スパースファイルをサポートするシステムを考えると、ddにはスペースを節約するオプションがある場合があります。不思議なことに、私のMacにはconv=sparseフラグを持つddのバージョンが含まれていますが、HFS +ファイルシステムはそれをサポートしていません。反対に、テストに使用した新しいDebianインストールでは、ext4のスパースファイルがサポートされていますが、ddのインストールにはフラグがありません。図に行きます。

したがって、別の演習：

上記と同じファイルに/ dev/zeroをコピーしました。 du、df、およびlsによって確認されるように、ファイルシステム上で2Gのスペースを占有しました。次に、cpを使用して、4GBのスペースを使用する2つのファイルがあることに気付きました。それで、別のフラグを試す時が来ました：

`cp --sparse=always sparse sparse2`

これを使用すると、cpは通常のファイルを取得し、ゼロの長い文字列を検出するたびにスパース割り当てを使用します。これで、lsによると4GBを占めると報告されているファイルが2つありますが、duとdfによると2GBしかありません。

スパースファイルを取得したので、cpは動作しますか？はい。 cp sparse2 sparseの結果、lsはファイルごとに2GBの消費スペースを表示しますが、duはファイルシステムでゼロブロックを使用していることを示します。結論：一部のユーティリティはすでにスパースファイルを尊重しますが、ほとんどのユーティリティはすべてを書き戻します。 cpでさえ、手を強制的に試行しない限り、書き込まれたファイルをスパースに戻すことを知りません。

次に、1MBのファイルを作成してスパースエントリにした後、vimで編集してみました。数文字しか入力していませんが、すべてを使用するようになりました。クイック検索で同様のデモが見つかりました： https://unix.stackexchange.com/questions/17572/what-is-the-interaction-of-the-rsync-size-only-and-sparse-options ==

まばらな結論

だから私の考えはこれをすべて与えました：

  • LVMを使用したスナップショット
  • スナップショットに対して zerofree を実行します
  • rsync -Sを使用して、結果がスパースファイルでコピーします
  • Rsyncを使用できない場合、ネットワークを介して転送している場合はスナップショットをgzipで圧縮してから、展開されていないイメージに対してcp --sparse=alwaysを実行して、スパースコピーを作成します。

差分バックアップ

ブロックデバイスでの差分バックアップの欠点は、物事が少し動き回り、扱いにくい大きな差分を生成する可能性があることです。 StackOverflowについていくつかの議論があります： https://stackoverflow.com/questions/4731035/binary-diff-and-patch-utility-for-a-virtual-machine-image これは最良の使用法を結論付けましたxdeltaでした。それを行う場合は、最初に空のスペースをゼロにしてください。

7
Jeff Ferland

あなたの2つの質問...

ddは、セクターをイメージとして取得します。空白部分をスキップするように指示する方法はありません。複製しているドライブの忠実なイメージが作成されます。ただし、Zipや7zなどの圧縮ユーティリティを使用して出力をリダイレクトする場合、空白はほぼ同じ効果を得るために出力を縮小する必要があります。 （ddユーティリティがまだ空白を複製しているため）それでも時間がかかりますが、ストレージのサイズ係数は大幅に削減されます。未使用のスペースのために約20ギガに圧縮されるVMWareからの100ギガ以上のディスクイメージがあります。

私の知る限りではなく、段階的に節約することに関して。 ddは、何が変更され、何が変更されていないかをどのように知るのでしょうか。それは本当にそのためのものではありませんでした。増分保存は、ほとんどの場合、rdiff-backupやrsyncなどのユーティリティを使用して実行し、それらを圧縮して、ファイルレベルで実行する必要があります。

1
Bart Silverstrim

tarは、ゼロでいっぱいにならない限り、無駄なスペースを修正できません（通常は修正されません）。ジェフが提案したようにツールを実行して空き領域をゼロにすると、スナップショットが大量のデータを処理し、多くの時間がかかり、スナップショットのバッキングストア領域を大量に消費します。スナップショットをマウントしたくない理由があり、それをrsyncまたはrdiff-backupしますか？また、スナップショットをマウントせずに（ext [234]の場合）迅速にバックアップし、マルチレベルの増分バックアップを実行できるdumpを確認することもできます。小さなファイルがたくさんあるファイルシステムでは、tarやrsyncよりもはるかに高速になる可能性があります。マルチスレッド圧縮も実行できます。

0
psusi