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

災害復旧のために、異なるプロバイダーで2台のLAMP Webサーバーを実行します-高出力のライブサーバーと低出力のバックアップサーバー。

現在、ライブサーバーからバックアップサーバーにすべてのデータを4時間ごとに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

ギット

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

ギット

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

ギット

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

ギット

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

ギット

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

ギット

nothing to commit (working directory clean)

real    0m0.156s    user    0m0.057s    sys     0m0.097s

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

Gitは、即時の復旧を支援します。また、バックアップはバージョン管理され、変更ログがあるため、データの分析も容易になります。データに大きな変更を加えたら、コミットしてgitに手動でプッシュし、変更ログに理由を入力できます。gitがうまくいかない場合、rsyncが助けになりますが、rsyncの頻度によってはデータが失われることに注意してください。

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

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

サーバー上のユーザー生成コンテンツを追跡およびバックアップする必要があります。productionサーバーは、Gitのレポのコピーを持っており、毎晩それが自動的に追加されますとcronを経由して、新しいファイルのすべてをコミットします。これらはpushgitoliteサーバーに送信され、フックを使用して残りのサーバーを同期します。

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

両方が提供するものをよく理解していると思います。コードベースをチェックアウト/エクスポートするサーバーから独自のリポジトリを持つように思考のラインを変更するだけです。別の考えは、メディアファイルをrsync（これらのサイトのいくつかについて2GBと言ったため、多くのメディアタイプのファイルがあると思われますか？）とGitでそれらを追跡できないことです。