☰

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

tag-icon • tag-icon git backup rsync
rsync 和 git push 哪个更适合网站备份

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

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

这可以正常工作，但是在 rsync 找出哪些文件已发生更改时会导致系统负载激增。

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

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

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

然后在备份服务器上有一个提交后挂钩，用于在每次推送时进行检查。

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

这是一个比 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

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

同步

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

同步

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

同步

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

同步

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

同步

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

答案1

实际上，我建议两者均衡使用。您的主要备份应（至少）每晚提交给 git。每周使用 rsync 将其同步一到两次到远离生产箱的另一台机器。Git

将帮助您立即恢复，并且由于您的备份是版本化的并且具有更改日志，因此它还使数据分析更容易。在对数据进行任何重大更改后，您可以手动提交并推送到 git，并将原因放入更改日志中。如果 git 出现问题，那么 rsync 会来救援，但请记住，您仍然会丢失数据，具体取决于 rsync 的频率。

经验法则：当涉及到备份和灾难恢复时，没有什么可以保证 100% 恢复。

答案2

pushRsync 是一个很棒的同步工具，但是在服务器上运行 Git 并进行更新时，你会获得更多的多功能性pull。

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

由于服务器上有 repo 的副本，您不仅可以获得快照，还可以获得详细的历史信息，如果您的服务器出现任何问题，这些信息可以轻松地拯救您。

我认为你对两者提供的功能都有了很好的理解，我只是希望改变你的思路，从服务器检查/导出代码库到拥有自己的存储库。另一个想法是，你可以 rsync 你的媒体文件（你说其中一些网站有 2GB，这让我认为有很多媒体类型的文件？）而不是在 Git 中跟踪它们。

相关内容