Cái nào tốt hơn để sao lưu trang web - rsync hoặc git đẩy


16

Tôi chạy 2 máy chủ web LAMP tại các nhà cung cấp khác nhau cho mục đích khắc phục thảm họa - máy chủ trực tiếp có công suất cao và máy chủ sao lưu có công suất thấp.

Hiện tại tôi rsync tất cả dữ liệu từ máy chủ trực tiếp đến máy chủ dự phòng cứ sau 4 giờ.

Điều này hoạt động tốt, nhưng hệ thống tăng đột biến tải trong khi rsync chỉ ra những tập tin đã thay đổi.

Vì tất cả các trang web cũng sống trong kho git, tôi tự hỏi liệu git đẩy có phải là một kỹ thuật sao lưu tốt hơn không.

Tôi phải bao gồm thư mục tải lên trực tiếp trong repo git; và sau đó quá trình sao lưu sẽ là:

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

và sau đó có một hook hook bài trên máy chủ dự phòng để kiểm tra mỗi lần đẩy.

Mỗi trang web có kích thước từ 50M đến 2GB. Tôi sẽ kết thúc với khoảng 50 repos riêng biệt.

Đây có phải là một giải pháp "tốt hơn" so với rsync?

  • Là git tốt hơn trong việc tính toán những tập tin đã thay đổi?
  • Là git đẩy hiệu quả hơn mà rsync
  • Tôi đã quên cái gì?

Cảm ơn!

---- Dữ liệu từ một số bài kiểm tra so sánh ------

1) Thư mục 52MB sau đó thêm thư mục 500k mới (chủ yếu là tệp văn bản)

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) Thư mục 1.4G sau đó thêm thư mục 18M mới (chủ yếu là hình ảnh)

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) Thư mục 52M sau đó thêm thư mục 18M mới (chủ yếu là hình ảnh)

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) Thư mục 1.4G sau đó thêm thư mục 500k mới (chủ yếu là văn bản)

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) Thư mục 1.4G - không thay đổi

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) Thư mục 52M - không thay đổi

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

3
một "rsync đẹp" thì sao? Tốc độ tải hệ thống là chính xác những gì bạn muốn: Hoàn tất quy trình AFAP và điều này cũng được miễn là nó không can thiệp vào hoạt động của trang web.

1
Cảm ơn - Tôi đã thực hiện một "rsync tốt đẹp", điều này có ích
David Laing

Câu trả lời:


4

Trên thực tế tôi sẽ đề nghị sử dụng kết hợp cân bằng của cả hai. Sao lưu chính của bạn nên được cam kết (ít nhất) mỗi đêm để git. Đồng bộ hóa nó một hoặc hai lần một tuần với một máy khác cách xa hộp sản xuất bằng rsync.

Git sẽ giúp bạn phục hồi ngay lập tức và nó cũng giúp cho việc phân tích dữ liệu dễ dàng hơn do thực tế là bạn sao lưu là phiên bản và có một thay đổi. Sau bất kỳ thay đổi lớn nào đối với dữ liệu, bạn có thể thực hiện một cam kết và đẩy để git thủ công và đưa lý do vào thay đổi. Trong trường hợp git bị hỏng thì rsync sẽ đến cứu nhưng hãy nhớ rằng bạn vẫn sẽ mất dữ liệu tùy thuộc vào tần số của rsync.

Nguyên tắc nhỏ: khi nói đến sao lưu và khắc phục thảm họa, không có gì có thể đảm bảo cho bạn khả năng phục hồi 100%.


2

Rsync là một công cụ đồng bộ tuyệt vời, nhưng bạn sẽ linh hoạt hơn rất nhiều khi chạy Git trên (các) máy chủ và cập nhật pushhoặc pullcập nhật.

Tôi phải theo dõi và sao lưu nội dung do người dùng tạo trên máy chủ của chúng tôi. Máy productionchủ có một bản sao của git repo và mỗi đêm, nó sẽ tự động thêm và xác nhận tất cả các tệp mới thông qua cron. Chúng được pushchuyển đến máy chủ gitolite của chúng tôi, sau đó sử dụng các hook để đồng bộ hóa các máy chủ còn lại.

Vì các máy chủ có các bản sao của repo trên tàu, bạn không chỉ nhận được một ảnh chụp nhanh mà còn có thông tin lịch sử chi tiết có thể dễ dàng cứu bạn nếu có bất cứ điều gì xảy ra với máy chủ của bạn.

Tôi nghĩ rằng bạn có khá nhiều hiểu biết về những gì cả hai cung cấp, tôi chỉ thay đổi dòng suy nghĩ của bạn từ các máy chủ kiểm tra / xuất mã cơ sở sang chỉ có repos của riêng họ. Một suy nghĩ khác là bạn có thể đồng bộ hóa các tệp phương tiện của mình (bạn đã nói 2GB cho một số trang web này, điều này khiến tôi nghĩ rằng có rất nhiều loại tệp phương tiện?) Và không theo dõi chúng trong Git.


Tôi đã thêm một số dữ liệu hiệu suất; cho thấy rsync gần như luôn luôn nhanh hơn git. Tuy nhiên, tôi thích quan điểm của bạn về sức mạnh bổ sung của việc có git repos trên máy chủ trực tiếp - Tôi tự hỏi liệu phương pháp lai không tốt nhất, với các thay đổi được đẩy vào repo git, và sau đó git repos được sao lưu vào bản sao lưu máy chủ ...
David Laing
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.