何百万ものハードリンクでファイルシステムをミラーリングする方法は?


11

現時点で1つの大きな問題があります。顧客の1人のファイルシステムをミラーリングする必要があります。それは通常、実際には問題ではありませんが、次のとおりです。

このファイルシステムには、数百万のハードリンクを持つフォルダーが1つあります(はい!数百万!)。rsyncファイルリストを作成するには4日以上かかります。

次のrsyncオプションを使用します。

rsync -Havz --progress serverA:/data/cms /data/

誰もこのrsyncを高速化する方法、または代替手段を使用する方法を考えていますか?ddターゲットディスクはソースより小さいため、使用できませんでした。

UPDATE: オリジナルのファイルシステムがあるのでext3、我々がしようとしますdumprestore。更新します


トリッキー。最初にソースファイルシステムを縮小してから、ddを縮小しますか?
-Bittrance

回答:


3

両側をrsync 3にアップグレードする必要があります。変更ログから:

- A new incremental-recursion algorithm is now used when rsync is talking
  to another 3.x version.  This starts the transfer going more quickly
  (before all the files have been found), and requires much less memory.
  See the --recursive option in the manpage for some restrictions.

rsync 3.0.0がリリースされてから2年以上が経過しましたが、残念ながら、ほとんどのエンタープライズディストリビューションはそれより古いコードに基づいているため、rsync 2.6を使用している可能性があります。

あなたがあれば、(誰がこの問題を持っている場合)、参考のためにしているあなたは、増分再帰と互換性のないオプションを使用している、すでにrsyncの3を実行しています。manページから:

    Some options require rsync to know the full file list, so  these
    options  disable the incremental recursion mode.  These include:
    --delete-before,   --delete-after,    --prune-empty-dirs,    and
    --delay-updates.

また、インクリメンタル再帰をサポートするには、両側で rsync 3を実行する必要があります。


プリッチャードはその後ろ盾に感謝しますが、インクリメンタルな部分は問題ありません。両方がrsync> 3.0を使用します。-Hなしでrsyncを使用すると、速度が大幅に向上しますが、それは必要なことではありません。
トーマスバーガー

痛い。ええ、その場合、ファイルシステムへのアクセスを高速化するオプション(ext3を使用している場合はext4への切り替えなど)、より高速なディスクまたはRAIDレベルへの切り替え(オプションの場合)などを検討することをお勧めします。ファイルシステムの速度が十分ではなく、ブロックレベルのバックアップが唯一の選択肢である可能性があります。あるサーバーから別のサーバーにBackupPCプールを再同期しようとすると、この問題が発生しました。
スティーブンプリチャード

3

ext *ダンプを使用しました。うまく機能し、復元側はext *である必要さえありません。

デバイスをアンマウントし、を使用してオフラインバックアップを行いましたdump vf - /dev/vg0/opt | gzip -c > /mnt/backup/ext3dump.gz

最後の行には、サイズ、時間、速度、最後のiノード番号が表示されます。

DUMP: dumping regular inode 47169535
DUMP: dumping regular inode 47169536
DUMP: Volume 1 completed at: Wed Jun 29 05:42:57 2011
DUMP: Volume 1 54393520 blocks (53118.67MB)
DUMP: Volume 1 took 4:16:43
DUMP: Volume 1 transfer rate: 3531 kB/s
DUMP: 54393520 blocks (53118.67MB)
DUMP: finished in 15403 seconds, throughput 3531 kBytes/sec
DUMP: Date of this level  dump: Wed Jun 29 01:24:29 2011
DUMP: Date this dump completed:  Wed Jun 29 05:42:57 2011
DUMP: Average transfer rate: 3531 kB/s
DUMP: DUMP IS DONE

これがまだ当てはまるかどうかはわかりませんが、ダンプ時にファイルシステムが使用中の場合、ダンプにはいくつかの問題がありました。あなたの目標はスピードですので、私は、あなたはすでにそれを他のすべてのアクセスを無効にし、ちょうどで-場合..私たちはあなたが行く方法を知ってみようとしている
SuperBOB

0

LVMを使用してボリュームのスナップショットを作成し、スナップショットをバックアップとしてrsyncできます。

または、これを他の回答と組み合わせdump てスナップショットボリュームで使用、元のボリュームをオフラインにする必要をなくすことができます。


ファイルシステムレベルではなく、ブロックレベルで動作するものであれば、おそらく大きな改善になるでしょう。
マーチン

私の質問でわかるように、ローカルではなくネットワーク全体にミラーリングする必要があります。また、LVMはミラーではなく、まさにあなたが言ったように、スナップショットです。
トーマスバーガー

1
@Thomas Berger:私は、(rsyncを使用して)ネットワーク経由でスナップショットをコピーすると思いました。また、LVMスナップショットが1つではない場合、どのようにmirrorを正確に定義しますか?
テディ

それでも同じ問題があります。数日かかります。この日は巨大なダルタがあります(必要ではありません)ので、十分なスペースを確保する必要があり、そのスペースはありません。また、ミラーはソースの独立したコピーです。お客様の生産から開発にデータをコピーする必要があります。
トーマスバーガー

@Thomas Berger:元々、スナップショット上のファイルシステムではなく、実際のスナップショットボリュームを再同期することを意味していました。ただし、スナップショット+ダンプソリューションの方が優れていると考えています。
テディ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.