哪个更适合网站备份-rsync或git push

为了灾难恢复的目的，我在不同的提供商处运行2台LAMP Web服务器-高功率的实时服务器和低功率的备份服务器。

目前，我每隔4小时将所有数据从实时服务器同步到备份服务器一次。

这样做可以，但是会增加系统负载，而rsync会找出哪些文件已更改。

由于所有网站也都位于git存储库中，所以我想知道git push是否会是更好的备份技术。

我必须将实时上传文件夹包含在git repo中；然后备份过程将是：

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

然后在备份服务器上使用post commit钩子，以在每次推送时检出。

每个网站的大小从50M到2GB不等。我最终会得到大约50个单独的git repos。

这是比rsync更好的解决方案吗？

• git可以更好地计算哪些文件已更改吗？
• git push比rsync更高效
• 我忘记了什么？

谢谢！

----来自一些比较测试的数据------

1）52MB文件夹，然后添加一个新的500k文件夹（主要是文本文件）

同步

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文件夹（主要是图像）

同步

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文件夹（主要是图像）

同步

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文件夹（主要是文本）

同步

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文件夹-不变

同步

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文件夹-不变

同步

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远离生产机器的机器。

Git将帮助您立即恢复，并且由于您的备份是版本控制的并且具有变更日志，因此它还使数据分析更加容易。在对数据进行任何重大更改之后，您可以进行提交并手动推送到git并将原因放入changelog中。万一git变坏了，那么rsync就可以解决，但是请记住，根据rsync的频率，您仍然会丢失数据。

经验法则：在备份和灾难恢复方面，没有任何东西可以保证为您提供100％的恢复。

Rsync是一个奇妙的同步工具，但服务器（一个或多个）上运行时的Git，你得到更多的灵活性push荷兰国际集团和pull荷兰国际集团更新。

我必须在我们的服务器上跟踪和备份用户生成的内容。该production服务器具有git repo的副本，并且每天晚上它都会通过cron自动添加并提交所有新文件。那些被push编入我们的gitolite服务器，然后它使用钩子同步其余服务器。

由于服务器在机上具有仓库的副本，因此您不仅可以获得快照，还可以获得详细的历史记录信息，如果服务器发生任何事情，这些信息可以轻松地为您节省时间。

我认为您几乎对这两种产品都有很好的了解，我只是将您的思路从服务器签出/导出代码库更改为仅拥有自己的存储库。另一个想法是，您可以同步您的媒体文件（您为某些站点说2GB，这使我认为文件的媒体类型很多？），而不必在Git中跟踪它们。