为了实现灾难恢复，我在不同的提供商上运行了2个LAMP Web服务器 – 一个高性能的在线服务器和一个低功耗的备份服务器。
目前，我每隔4小时将所有数据从活动服务器rsync同步到备份服务器。
这工作正常，但确实加载系统负载，而rsync计算出哪些文件已经改变。
由于所有的网站也住在git仓库，我想知道是否git推是一个更好的备份技术。
我不得不在git仓库中包含实时上传文件夹; 然后备份过程将是：
live$ git add . live$ git commit -a -m "{data-time} snapshot" live$ git push backup live_branch 然后在备份服务器上build立一个提交钩子来检查每次推送。
每个网站的大小从50M到2GB不等。 我最终会得到大约50个独立的git回购。
这是比rsync更好的解决scheme吗？
谢谢！
—-一些比较testing的数据——
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
其实我会build议使用两者的平衡组合。 你的主备份应该（至less）每天晚上提交git。 使用rsync将它每周同步一次或两次到另一台远离生产箱的机器。
Git将帮助您立即恢复，并且由于您的备份是版本编辑并且具有更新日志，因此它还使数据分析更容易。 在对数据进行任何重大更改之后，可以执行提交并手动推送到git，并将原因放入更改日志中。 如果git坏了，那么rsync会来救援，但请记住，你仍然会根据rsync的频率而丢失数据。
经验法则：当谈到备份和灾难恢复时，没有什么能保证给你100％的恢复。
Rsync是一个了不起的同步工具，但是在服务器上运行Git时，你可以获得更多的多function性，并可以进行更新。
我必须在我们的服务器上跟踪和备份用户生成的内容。 production服务器有一个git repo的副本，每天晚上它会自动添加并通过cron提交所有新文件。 那些push送到我们的gitolite服务器，然后使用挂钩来同步其余的服务器。
由于服务器有机载回购副本，所以不仅可以获得快照，而且可以获得详细的历史logging信息，如果您的服务器发生任何问题，这些信息可以轻松保存。
我认为你对这两者都有很好的理解，我只是将你的思路从检查/导出代码库的服务器改成只有自己的回购。 另一个想法是，你可以rsync你的媒体文件（你说2GB这些网站，这让我觉得有很多媒体types的文件？），而不是跟踪他们在Git。