วิธีไหนดีกว่าสำหรับการสำรองข้อมูลเว็บไซต์ - rsync หรือ git push


16

ฉันเรียกใช้เว็บเซิร์ฟเวอร์ 2 หลอดที่ผู้ให้บริการที่แตกต่างกันเพื่อการกู้คืนจากความเสียหาย - เซิร์ฟเวอร์ที่ใช้พลังงานสูงและเซิร์ฟเวอร์สำรองที่ใช้พลังงานต่ำ

ขณะนี้ฉันซิงค์ข้อมูลทั้งหมดจากเซิร์ฟเวอร์สดไปยังเซิร์ฟเวอร์สำรองทุก 4 ชั่วโมง

ใช้งานได้ดี แต่ขัดขวางระบบโหลดขณะที่ rsync คิดว่าไฟล์ใดมีการเปลี่ยนแปลง

เนื่องจากเว็บไซต์ทั้งหมดนั้นอาศัยอยู่ในที่เก็บคอมไพล์ฉันสงสัยว่าการพุชแบบ git นั้นจะเป็นเทคนิคการสำรองข้อมูลที่ดีกว่าหรือไม่

ฉันต้องรวมโฟลเดอร์การอัปโหลดสดใน repo คอมไพล์; แล้วกระบวนการสำรองข้อมูลจะเป็น:

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

แล้วมีการโพสต์กระทำเบ็ดบนเซิร์ฟเวอร์สำรองเพื่อเช็คเอาต์ทุกครั้ง

แต่ละเว็บไซต์มีขนาดตั้งแต่ 50M ถึง 2GB ฉันจะจบด้วย repos คอมไพล์ประมาณ 50 อัน

นี่เป็นทางออกที่ "ดีกว่า" กว่า rsync หรือไม่

  • git ดีกว่าในการคำนวณว่าไฟล์ใดมีการเปลี่ยนแปลงหรือไม่?
  • git นั้นมีประสิทธิภาพมากกว่า 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

3
สิ่งที่เกี่ยวกับ "rsync ที่ดี"? โหลด spiking ของระบบเป็นสิ่งที่คุณต้องการ: ดำเนินการตามกระบวนการ AFAP ให้เสร็จสิ้นและนี่ก็โอเคตราบใดที่มันไม่รบกวนการทำงานของเว็บไซต์

1
ขอบคุณ - ฉันกำลังทำ "nice rsync" ซึ่งช่วยคุณได้
David Laing

คำตอบ:


4

ที่จริงฉันขอแนะนำให้ใช้การผสมผสานที่สมดุลของทั้งสอง การสำรองข้อมูลหลักของคุณควรกระทำ (อย่างน้อย) ทุกคืนเพื่อคอมไพล์ ซิงค์สัปดาห์ละสองครั้งหรือสองครั้งกับเครื่องอื่นซึ่งอยู่ห่างจากกล่องผลิตโดยใช้ rsync

Git จะช่วยคุณในการกู้คืนทันทีและยังทำให้การวิเคราะห์ข้อมูลง่ายขึ้นเนื่องจากการสำรองข้อมูลของคุณนั้นเป็นรุ่นที่ปรับปรุงและมีการเปลี่ยนแปลง หลังจากการเปลี่ยนแปลงที่สำคัญใด ๆ กับข้อมูลคุณสามารถทำการคอมมิทและพุชด้วยตนเองและใส่เหตุผลในการเปลี่ยนแปลง ในกรณีที่คอมไพล์เสียแล้ว rsync จะเข้ามาช่วยเหลือ แต่โปรดจำไว้ว่าคุณยังคงหลวมข้อมูลขึ้นอยู่กับความถี่ของ rsync

Rule of thumb: เมื่อพูดถึงการสำรองข้อมูลและการกู้คืนความเสียหายไม่มีอะไรสามารถรับประกันได้ว่าจะให้การกู้คืนได้ 100%


2

Rsync เป็นเครื่องมือซิงค์ที่ยอดเยี่ยม แต่คุณจะได้รับความสามารถที่หลากหลายมากขึ้นเมื่อใช้งาน Git บนเซิร์ฟเวอร์และทำการอัพเดทpushหรือpullไอเอ็นจี

ฉันต้องติดตามและสำรองเนื้อหาที่สร้างโดยผู้ใช้บนเซิร์ฟเวอร์ของเรา productionเซิร์ฟเวอร์มีสำเนาของ repo คอมไพล์และทุกคืนโดยอัตโนมัติเพิ่มและกระทำทั้งหมดของไฟล์ใหม่ผ่าน cron สิ่งเหล่านี้ถูกpushแก้ไขไปยังเซิร์ฟเวอร์ gitolite ของเราซึ่งจะใช้ hooks เพื่อซิงค์ส่วนที่เหลือของเซิร์ฟเวอร์

เนื่องจากเซิร์ฟเวอร์มีสำเนาของ repo on-board คุณจึงไม่ได้รับเพียงแค่ภาพรวม แต่ข้อมูลประวัติโดยละเอียดที่สามารถช่วยคุณได้อย่างง่ายดายหากมีสิ่งใดเกิดขึ้นกับเซิร์ฟเวอร์ของคุณ

ฉันคิดว่าคุณมีความเข้าใจที่ดีเกี่ยวกับข้อเสนอทั้งสองฉันจะเปลี่ยนแนวความคิดของคุณจากเซิร์ฟเวอร์ที่ตรวจสอบ / ส่งออก codebase เป็นเพียงแค่มี repos ของตัวเอง ความคิดอีกอย่างหนึ่งคือคุณสามารถซิงค์ไฟล์สื่อของคุณ (คุณบอกว่า 2GB สำหรับไซต์เหล่านี้บางแห่งซึ่งทำให้ฉันคิดว่ามีไฟล์ประเภทสื่อจำนวนมากใช่ไหม) และไม่ติดตามใน Git


ฉันได้เพิ่มข้อมูลประสิทธิภาพบางอย่างแล้ว ซึ่งแสดงว่า rsync นั้นเร็วกว่า git เกือบทุกครั้ง อย่างไรก็ตามฉันชอบคะแนนของคุณเกี่ยวกับพลังพิเศษของการมี git repos บนเซิร์ฟเวอร์ที่ใช้งานอยู่ - ฉันสงสัยว่าวิธีไฮบริดไม่ดีที่สุดกับการเปลี่ยนแปลงที่ถูกผลักเข้าไปใน git repo และจากนั้น git repos ถูกเชื่อมต่อกับการสำรองข้อมูล เซิร์ฟเวอร์ ...
David Laing
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.