web-dev-qa-db-ja.com

ウェブサイトのバックアップに適しています-rsyncまたはgit push

災害復旧の目的で、異なるプロバイダーで2つのLAMP Webサーバーを実行しています。高出力のライブサーバーと低出力のバックアップサーバーです。

現在、私は4時間ごとに1回、ライブサーバーからバックアップサーバーにすべてのデータをrsyncしています。

これは問題なく動作しますが、rsyncが変更されたファイルを特定している間、システムの負荷が急上昇します。

すべてのWebサイトはgitリポジトリにも存在するので、git Pushがより優れたバックアップ手法になるかどうか疑問に思っています。

ライブアップロードフォルダーをgitリポジトリに含める必要があります。次に、バックアッププロセスは次のようになります。

live$ git add .
live$ git commit -a -m "{data-time} snapshot"
live$ git Push backup live_branch

その後、バックアップサーバーにコミット後フックを設定して、すべてのプッシュでチェックアウトします。

各Webサイトのサイズは、50Mから2GBです。私は約50の個別のgitリポジトリになってしまいます。

これはrsyncより「良い」ソリューションですか?

  • Gitは変更されたファイルの計算に優れていますか?
  • Git pushはrsyncよりも効率的ですか
  • 何を忘れましたか?

ありがとう!

----いくつかの比較テストのデータ------

1)52MBフォルダー、次に新しい500kフォルダー(主にテキストファイル)を追加

rsync

sent 1.47K bytes  received 285.91K bytes  
total size is 44.03M  speedup is 153.22

real    0m0.718s    user    0m0.044s    sys     0m0.084s

git

Counting objects: 38, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (37/37), done.
Writing objects: 100% (37/37), 118.47 KiB, done.
Total 37 (delta 3), reused 0 (delta 0)

real    0m0.074s     user   0m0.029s    sys     0m0.045s

2)1.4Gフォルダー、次に新しい18Mフォルダー(主に画像)を追加

rsync

sent 3.65K bytes  received 18.90M bytes
total size is 1.42G  speedup is 75.17

real    0m5.311s    user    0m0.784s    sys     0m0.328s

git

Counting objects: 108, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (106/106), done.
Writing objects: 100% (107/107), 17.34 MiB | 5.21 MiB/s, done.
Total 107 (delta 0), reused 0 (delta 0)

real    0m15.334s    user   0m5.202s    sys     0m1.040s

3)52Mフォルダーに新しい18Mフォルダーを追加(主に画像)

rsync

sent 2.46K bytes  received 18.27M bytes  4.06M bytes/sec
total size is 62.38M  speedup is 3.41

real    0m4.124s    user    0m0.640s    sys     0m0.188s

git

Counting objects: 108, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (106/106), done.
Writing objects: 100% (107/107), 17.34 MiB | 5.43 MiB/s, done.
Total 107 (delta 1), reused 0 (delta 0)

real    0m6.990s    user    0m4.868s    sys     0m0.573s

4)1.4Gフォルダー、次に新しい500kフォルダーを追加(主にテキスト)

rsync

sent 2.66K bytes  received 916.04K bytes  612.47K bytes/sec
total size is 1.42G  speedup is 1547.14

real    0m1.191s    user    0m0.180s    sys     0m0.268s

git

Counting objects: 49, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (48/48), done.
Writing objects: 100% (48/48), 177.90 KiB, done.
Total 48 (delta 3), reused 0 (delta 0)

real    0m1.776s    user    0m0.390s    sys     0m0.497s

5)1.4Gフォルダー-変更なし

rsync

sent 1.72K bytes  received 716.44K bytes  287.26K bytes/sec
total size is 1.42G  speedup is 1979.18

real    0m1.092s    user    0m0.168s    sys     0m0.272s

git

nothing to commit (working directory clean)

real    0m0.636s    user    0m0.268s    sys     0m0.348s

5)52Mフォルダー-変更なし

rsync

sent 528 bytes  received 88.40K bytes  59.29K bytes/sec
total size is 62.38M  speedup is 701.41

real    0m0.779s    user    0m0.044s    sys     0m0.144s

git

nothing to commit (working directory clean)

real    0m0.156s    user    0m0.057s    sys     0m0.097s
16
David Laing

実際、両方をバランスよく組み合わせて使用​​することをお勧めします。メインのバックアップは(少なくとも)毎晩gitにコミットする必要があります。週に1〜2回、rsyncを使用して本番ボックスから遠く離れた別のマシンに同期します。

Gitは即時の復旧を支援します。また、バックアップがバージョン管理されており、変更ログがあるため、データの分析が容易になります。データに大きな変更を加えた後、手動でcommitおよびPush to gitを実行し、その理由を変更ログに記録できます。 gitがうまくいかない場合、rsyncが助けになりますが、rsyncの頻度によってはデータが失われることに注意してください。

経験則:バックアップと災害復旧に関しては、100%の復旧を保証するものはありません。

4
Aditya Patawari

Rsyncは素晴らしい同期ツールですが、サーバーでGitを実行すると、Pushingまたはpullingの更新により、より多くの汎用性が得られます。

サーバーでユーザーが作成したコンテンツを追跡してバックアップする必要があります。 productionサーバーにはgitリポジトリのコピーがあり、毎晩、cron経由ですべての新しいファイルを自動的に追加してコミットします。これらは、私たちのgitoliteサーバーにPushedされ、フックを使用して残りのサーバーを同期します。

サーバーにはオンボードのリポジトリのコピーがあるため、スナップショットだけでなく、サーバーで何かが発生した場合に簡単に保存できる詳細な履歴情報も取得できます。

私はあなたが両方が何を提供するかについて十分に理解していると思います、私はあなたの考え方を、サーバーがコードベースをチェックアウト/エクスポートすることから、独自のレポジトリを持つことだけに変えます。もう1つの考えは、メディアファイルをrsync(これらのサイトのいくつかでは2 GBと言ったため、メディアタイプのファイルがたくさんあると思いますか?)で、Gitでそれらを追跡できないということです。

2
Nic