บทความนี้จะพิจารณาซอฟต์แวร์สำรองข้อมูลซึ่งโดยการแบ่งกระแสข้อมูลออกเป็นส่วนประกอบที่แยกจากกัน (ชิ้น) จะสร้างพื้นที่เก็บข้อมูล
ส่วนประกอบพื้นที่เก็บข้อมูลสามารถบีบอัดและเข้ารหัสเพิ่มเติมได้ และที่สำคัญที่สุด - ในระหว่างกระบวนการสำรองข้อมูลซ้ำ - นำกลับมาใช้ใหม่ได้
สำเนาสำรองในพื้นที่เก็บข้อมูลดังกล่าวเป็นสายโซ่ที่มีชื่อของส่วนประกอบที่เชื่อมต่อถึงกัน ตัวอย่างเช่น ตามฟังก์ชันแฮชต่างๆ
มีวิธีแก้ไขปัญหาที่คล้ายกันหลายประการ ฉันจะเน้นที่ 3: zbackup, borgbackup และ retic
ผลลัพธ์ที่คาดหวัง
เนื่องจากผู้สมัครทุกคนต้องการการสร้างพื้นที่เก็บข้อมูลไม่ทางใดก็ทางหนึ่ง ปัจจัยที่สำคัญที่สุดประการหนึ่งคือการประมาณขนาดของพื้นที่เก็บข้อมูล ตามหลักการแล้ว ขนาดของมันไม่ควรเกิน 13 GB ตามวิธีการที่ยอมรับ หรือน้อยกว่านั้น ขึ้นอยู่กับการปรับให้เหมาะสมที่ดี
เป็นที่พึงปรารถนาอย่างยิ่งที่สามารถสร้างสำเนาสำรองของไฟล์ได้โดยตรงโดยไม่ต้องใช้ตัวเก็บถาวรเช่น tar รวมถึงทำงานกับ ssh/sftp โดยไม่ต้องใช้เครื่องมือเพิ่มเติม เช่น rsync และ sshfs
ลักษณะการทำงานเมื่อสร้างการสำรองข้อมูล:
- ขนาดของที่เก็บจะเท่ากับขนาดของการเปลี่ยนแปลงหรือน้อยกว่า
- คาดว่าจะมีการโหลด CPU จำนวนมากเมื่อใช้การบีบอัดและ/หรือการเข้ารหัส และเครือข่ายและดิสก์ที่มีโหลดค่อนข้างสูงมีแนวโน้มว่าจะเกิดขึ้นหากกระบวนการเก็บถาวรและ/หรือการเข้ารหัสกำลังทำงานบนเซิร์ฟเวอร์จัดเก็บข้อมูลสำรอง
- หากพื้นที่เก็บข้อมูลเสียหาย ข้อผิดพลาดที่ล่าช้าอาจเกิดขึ้นได้ทั้งเมื่อสร้างการสำรองข้อมูลใหม่และเมื่อพยายามกู้คืน มีความจำเป็นต้องวางแผนมาตรการเพิ่มเติมเพื่อให้แน่ใจว่าพื้นที่เก็บข้อมูลมีความสมบูรณ์หรือใช้เครื่องมือในตัวเพื่อตรวจสอบความสมบูรณ์
การทำงานกับ tar ถือเป็นค่าอ้างอิง ดังที่แสดงในบทความก่อนหน้านี้
กำลังทดสอบ zbackup
กลไกทั่วไปของ zbackup คือโปรแกรมจะค้นหาในพื้นที่สตรีมข้อมูลอินพุตที่มีข้อมูลเดียวกัน จากนั้นเลือกบีบอัดและเข้ารหัสข้อมูลเหล่านั้น โดยบันทึกแต่ละพื้นที่เพียงครั้งเดียว
การขจัดข้อมูลซ้ำซ้อนใช้ฟังก์ชันแฮชริง 64 บิตพร้อมหน้าต่างเลื่อนเพื่อตรวจสอบการจับคู่แบบไบต์ต่อไบต์กับบล็อกข้อมูลที่มีอยู่ (คล้ายกับวิธีที่ rsync ใช้งาน)
lzma และ lzo แบบมัลติเธรดใช้สำหรับการบีบอัด และ aes สำหรับการเข้ารหัส เวอร์ชันล่าสุดสามารถลบข้อมูลเก่าออกจากพื้นที่เก็บข้อมูลได้ในอนาคต
โปรแกรมเขียนด้วยภาษา C++ โดยมีการพึ่งพาน้อยที่สุด เห็นได้ชัดว่าผู้เขียนได้รับแรงบันดาลใจจาก Unix-way ดังนั้นโปรแกรมจึงยอมรับข้อมูลบน stdin เมื่อสร้างการสำรองข้อมูล และสร้างสตรีมข้อมูลที่คล้ายกันบน stdout เมื่อทำการกู้คืน ดังนั้น zbackup จึงสามารถใช้เป็น "แบบเอกสารสำเร็จรูป" ที่ดีมากเมื่อเขียนโซลูชันการสำรองข้อมูลของคุณเอง ตัวอย่างเช่นผู้เขียนบทความนี้ใช้โปรแกรมนี้เป็นเครื่องมือสำรองข้อมูลหลักสำหรับเครื่องที่บ้านตั้งแต่ประมาณปี 2014
สตรีมข้อมูลจะเป็น tar ปกติ เว้นแต่จะระบุไว้เป็นอย่างอื่น
มาดูกันว่าผลลัพธ์เป็นอย่างไร:
มีการตรวจสอบงานใน 2 ตัวเลือก:
- พื้นที่เก็บข้อมูลจะถูกสร้างขึ้นและเปิดใช้งาน zbackup บนเซิร์ฟเวอร์พร้อมกับข้อมูลต้นทาง จากนั้นเนื้อหาของพื้นที่เก็บข้อมูลจะถูกถ่ายโอนไปยังเซิร์ฟเวอร์ที่จัดเก็บข้อมูลสำรอง
- พื้นที่เก็บข้อมูลจะถูกสร้างขึ้นบนเซิร์ฟเวอร์ที่จัดเก็บข้อมูลสำรอง zbackup จะถูกเปิดใช้งานผ่าน ssh บนเซิร์ฟเวอร์ที่จัดเก็บข้อมูลสำรอง และข้อมูลจะถูกส่งไปยังที่เก็บข้อมูลผ่านทางไปป์
ผลลัพธ์ของตัวเลือกแรกมีดังนี้: 43m11s - เมื่อใช้พื้นที่เก็บข้อมูลที่ไม่ได้เข้ารหัสและคอมเพรสเซอร์ lzma, 19m13s - เมื่อเปลี่ยนคอมเพรสเซอร์ด้วย lzo
โหลดบนเซิร์ฟเวอร์ที่มีข้อมูลต้นฉบับมีดังนี้ (แสดงตัวอย่างด้วย lzma โดยที่ lzo มีรูปภาพเดียวกันโดยประมาณ แต่ส่วนแบ่งของ rsync อยู่ที่ประมาณหนึ่งในสี่ของเวลา):
เป็นที่ชัดเจนว่ากระบวนการสำรองข้อมูลดังกล่าวเหมาะสำหรับการเปลี่ยนแปลงที่ค่อนข้างน้อยและเกิดขึ้นน้อยเท่านั้น ขอแนะนำอย่างยิ่งให้จำกัด zbackup ไว้ที่ 1 เธรด มิฉะนั้นจะมีโหลด CPU ที่สูงมากเพราะ โปรแกรมนี้ทำงานได้ดีมากในการทำงานหลายเธรด โหลดบนดิสก์มีขนาดเล็กซึ่งโดยทั่วไปแล้วระบบย่อยดิสก์ที่ใช้ ssd สมัยใหม่จะไม่สามารถสังเกตเห็นได้ชัดเจน คุณยังสามารถเห็นจุดเริ่มต้นของกระบวนการซิงโครไนซ์ข้อมูลพื้นที่เก็บข้อมูลกับเซิร์ฟเวอร์ระยะไกลได้อย่างชัดเจน ความเร็วของการดำเนินการเทียบได้กับ rsync ปกติและขึ้นอยู่กับประสิทธิภาพของระบบย่อยของดิสก์ของเซิร์ฟเวอร์จัดเก็บข้อมูลสำรอง ข้อเสียของแนวทางนี้คือการจัดเก็บพื้นที่เก็บข้อมูลในเครื่องและเป็นผลให้เกิดความซ้ำซ้อนของข้อมูล
ตัวเลือกที่สองที่น่าสนใจและใช้งานได้ในทางปฏิบัติมากขึ้นคือการเรียกใช้ zbackup บนเซิร์ฟเวอร์จัดเก็บข้อมูลสำรองโดยตรง
ขั้นแรก เราจะทดสอบการทำงานโดยไม่ใช้การเข้ารหัสด้วยคอมเพรสเซอร์ lzma:
เวลาทำงานของการทดสอบการทำงานแต่ละครั้ง:
เปิดตัว 1
เปิดตัว 2
เปิดตัว 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
หากคุณเปิดใช้งานการเข้ารหัสโดยใช้ aes ผลลัพธ์ที่ได้จะค่อนข้างใกล้เคียงกัน:
เวลาทำงานในข้อมูลเดียวกันพร้อมการเข้ารหัส:
เปิดตัว 1
เปิดตัว 2
เปิดตัว 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
หากการเข้ารหัสถูกรวมเข้ากับการบีบอัดโดยใช้ lzo จะมีลักษณะดังนี้:
ใช้เวลา:
เปิดตัว 1
เปิดตัว 2
เปิดตัว 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
ขนาดของพื้นที่เก็บข้อมูลผลลัพธ์ค่อนข้างเท่ากันที่ 13GB ซึ่งหมายความว่าการขจัดข้อมูลซ้ำซ้อนทำงานได้อย่างถูกต้อง นอกจากนี้ สำหรับข้อมูลที่บีบอัดแล้ว การใช้ lzo ให้ผลที่เห็นได้ชัดเจน ในแง่ของเวลาการทำงานทั้งหมด zbackup ใกล้เคียงกับความซ้ำซ้อน/ซ้ำซ้อน แต่จะช้ากว่าเวลาที่ใช้ librsync 2-5 เท่า
ข้อดีนั้นชัดเจน - ประหยัดพื้นที่ดิสก์บนเซิร์ฟเวอร์จัดเก็บข้อมูลสำรอง สำหรับเครื่องมือตรวจสอบพื้นที่เก็บข้อมูล ผู้เขียน zbackup ไม่ได้จัดเตรียมไว้ ขอแนะนำให้ใช้ดิสก์อาร์เรย์หรือผู้ให้บริการคลาวด์ที่ทนทานต่อข้อผิดพลาด
โดยรวมแล้วถือเป็นความประทับใจที่ดีมากแม้ว่าโปรเจ็กต์จะยืนนิ่งมาประมาณ 3 ปีแล้ว (คำขอฟีเจอร์ล่าสุดคือประมาณหนึ่งปีที่แล้วแต่ไม่มีการตอบกลับ)
การทดสอบการสำรองข้อมูล
Borgbackup เป็นทางแยกของห้องใต้หลังคา ซึ่งเป็นอีกระบบหนึ่งที่คล้ายกับ zbackup เขียนด้วยภาษาไพธอน มีรายการความสามารถคล้ายกับ zbackup แต่ยังสามารถ:
- ติดตั้งการสำรองข้อมูลผ่านฟิวส์
- ตรวจสอบเนื้อหาที่เก็บข้อมูล
- ทำงานในโหมดไคลเอนต์เซิร์ฟเวอร์
- ใช้คอมเพรสเซอร์ต่างๆ สำหรับข้อมูล รวมถึงการกำหนดประเภทไฟล์เมื่อทำการบีบอัด
- 2 ตัวเลือกการเข้ารหัส aes และเบลค
- เครื่องมือในตัวสำหรับ
การตรวจสอบประสิทธิภาพ
เกณฑ์มาตรฐาน borgbackup crud ssh://backup_server/repo/path local_dir
ผลลัพธ์มีดังนี้:
CZ-BIG 96.51 MB/s (10 ไฟล์ศูนย์ทั้งหมด 100.00 MB: 10.36 วินาที)
RZ-BIG 57.22 เมกะไบต์/วินาที (10 ไฟล์ศูนย์ทั้งหมด 100.00 MB: 17.48 วินาที)
UZ-BIG 253.63 MB/s (10 ไฟล์ศูนย์ทั้งหมด 100.00 MB: 3.94 วินาที)
DZ-BIG 351.06 เมกะไบต์/วินาที (10 ไฟล์ศูนย์ทั้งหมด 100.00 MB: 2.85 วินาที)
CR-BIG 34.30 เมกะไบต์/วินาที (10 ไฟล์สุ่ม 100.00 MB: 29.15 วินาที)
RR-ใหญ่ 60.69 MB/วินาที (10 ไฟล์สุ่ม 100.00 MB: 16.48 วินาที)
UR-BIG 311.06 เมกะไบต์/วินาที (10 ไฟล์สุ่ม 100.00 MB: 3.21 วินาที)
DR-BIG 72.63 เมกะไบต์/วินาที (10 ไฟล์สุ่ม 100.00 MB: 13.77 วินาที)
CZ-ปานกลาง 108.59 MB/s (1000 ไฟล์ศูนย์ทั้งหมด 1.00 MB: 9.21 วินาที)
RZ-ปานกลาง 76.16 MB/s (1000 ไฟล์ศูนย์ทั้งหมด 1.00 MB: 13.13 วินาที)
UZ-MEDIUM 331.27 MB/s (1000 ไฟล์ศูนย์ทั้งหมด 1.00 MB: 3.02 วินาที)
DZ-MEDIUM 387.36 เมกะไบต์/วินาที (1000 ไฟล์ศูนย์ทั้งหมด 1.00 MB: 2.58 วินาที)
CR-MEDIUM 37.80 MB/วินาที (1000 ไฟล์สุ่ม 1.00 MB: 26.45 วินาที)
RR-ปานกลาง 68.90 MB/s (1000 ไฟล์สุ่ม 1.00 MB: 14.51 วินาที)
UR-ปานกลาง 347.24 MB/s (1000 ไฟล์สุ่ม 1.00 MB: 2.88 วินาที)
DR-สื่อ 48.80 MB/s (1000 ไฟล์สุ่ม 1.00 MB: 20.49 วินาที)
CZ-SMALL 11.72 MB/s (10000 10.00 kB ไฟล์ศูนย์ทั้งหมด: 8.53 วินาที)
RZ-SMALL 32.57 MB/s (10000 10.00 kB ไฟล์ศูนย์ทั้งหมด: 3.07 วินาที)
UZ-SMALL 19.37 MB/s (10000 10.00 kB ไฟล์ศูนย์ทั้งหมด: 5.16 วินาที)
DZ-SMALL 33.71 MB/s (10000 10.00 kB ไฟล์ศูนย์ทั้งหมด: 2.97 วินาที)
CR-SMALL 6.85 MB/s (10000 ไฟล์สุ่ม 10.00 kB: 14.60 วินาที)
RR-เล็ก 31.27 MB/วินาที (10000 ไฟล์สุ่ม 10.00 kB: 3.20 วินาที)
UR-SMALL 12.28 MB/s (10000 ไฟล์สุ่ม 10.00 kB: 8.14 วินาที)
DR-SMALL 18.78 MB/s (10000 ไฟล์สุ่ม 10.00 kB: 5.32 วินาที)
เมื่อทำการทดสอบ การวิเคราะห์พฤติกรรมการบีบอัดจะถูกนำมาใช้เพื่อกำหนดประเภทไฟล์ (การบีบอัดอัตโนมัติ) และผลลัพธ์จะเป็นดังนี้:
ขั้นแรก เรามาตรวจสอบวิธีการทำงานโดยไม่มีการเข้ารหัสกันก่อน:
ใช้เวลา:
เปิดตัว 1
เปิดตัว 2
เปิดตัว 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
หากคุณเปิดใช้งานการให้สิทธิ์พื้นที่เก็บข้อมูล (โหมดพิสูจน์ตัวตน) ผลลัพธ์จะถูกปิด:
ใช้เวลา:
เปิดตัว 1
เปิดตัว 2
เปิดตัว 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
เมื่อเปิดใช้งานการเข้ารหัส aes ผลลัพธ์ก็ไม่ได้ลดลงมากนัก:
เปิดตัว 1
เปิดตัว 2
เปิดตัว 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
และถ้าคุณเปลี่ยน aes เป็น blake สถานการณ์จะดีขึ้นอย่างสมบูรณ์:
ใช้เวลา:
เปิดตัว 1
เปิดตัว 2
เปิดตัว 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
เช่นเดียวกับในกรณีของ zbackup ขนาดพื้นที่เก็บข้อมูลคือ 13GB และน้อยกว่านั้นอีกเล็กน้อย ซึ่งโดยทั่วไปแล้วคาดว่า ฉันพอใจมากกับเวลาทำงาน ซึ่งเทียบได้กับโซลูชันที่ใช้ librsync ซึ่งให้ความสามารถที่กว้างกว่ามาก ฉันยังพอใจกับความสามารถในการตั้งค่าพารามิเตอร์ต่างๆ ผ่านตัวแปรสภาพแวดล้อม ซึ่งให้ข้อได้เปรียบที่ร้ายแรงมากเมื่อใช้ borgbackup ในโหมดอัตโนมัติ ฉันพอใจกับการโหลดระหว่างการสำรองข้อมูลด้วย: เมื่อพิจารณาจากโหลดของโปรเซสเซอร์ borgbackup ทำงานใน 1 เธรด
ไม่มีข้อเสียเป็นพิเศษเมื่อใช้งาน
การทดสอบเรสติก
แม้ว่าที่จริงแล้ว restic จะเป็นวิธีแก้ปัญหาที่ค่อนข้างใหม่ (ผู้สมัคร 2 คนแรกเป็นที่รู้จักในปี 2013 และเก่ากว่า) แต่ก็มีลักษณะที่ค่อนข้างดี เขียนใน Go.
เมื่อเปรียบเทียบกับ zbackup จะให้เพิ่มเติม:
- การตรวจสอบความสมบูรณ์ของพื้นที่เก็บข้อมูล (รวมถึงการตรวจสอบในส่วนต่างๆ)
- รายการโปรโตคอลและผู้ให้บริการที่รองรับจำนวนมากสำหรับการจัดเก็บข้อมูลสำรอง รวมถึงการสนับสนุน rclone - rsync สำหรับโซลูชันคลาวด์
- เปรียบเทียบการสำรองข้อมูล 2 รายการด้วยกัน
- การติดตั้งที่เก็บผ่านฟิวส์
โดยทั่วไปรายการคุณสมบัติค่อนข้างใกล้เคียงกับ borgbackup ในบางแห่งมากกว่านั้นในที่อื่นน้อยกว่า คุณสมบัติอย่างหนึ่งคือไม่มีวิธีปิดการใช้งานการเข้ารหัส ดังนั้นสำเนาสำรองจะถูกเข้ารหัสเสมอ มาดูในทางปฏิบัติว่าซอฟต์แวร์นี้สามารถบีบอะไรได้บ้าง:
ผลลัพธ์มีดังนี้:
ใช้เวลา:
เปิดตัว 1
เปิดตัว 2
เปิดตัว 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
ผลลัพธ์ด้านประสิทธิภาพยังเทียบได้กับโซลูชันที่ใช้ rsync และโดยทั่วไปแล้ว ใกล้เคียงกับ borgbackup มาก แต่โหลดของ CPU จะสูงกว่า (ทำงานหลายเธรด) และฟันเลื่อย
เป็นไปได้มากที่โปรแกรมจะถูกจำกัดด้วยประสิทธิภาพของระบบย่อยของดิสก์บนเซิร์ฟเวอร์จัดเก็บข้อมูล ดังเช่นในกรณีของ rsync อยู่แล้ว ขนาดพื้นที่เก็บข้อมูลคือ 13GB เช่นเดียวกับ zbackup หรือ borgbackup ไม่มีข้อเสียที่ชัดเจนเมื่อใช้โซลูชันนี้
ผลการวิจัย
อันที่จริงแล้ว ผู้สมัครทุกคนได้รับผลลัพธ์ที่คล้ายคลึงกัน แต่มีราคาต่างกัน Borgbackup ทำงานได้ดีที่สุด, restic ช้ากว่าเล็กน้อย, zbackup อาจไม่คุ้มกับการเริ่มใช้งาน
และหากมีการใช้งานอยู่แล้ว ให้ลองเปลี่ยนเป็น borgbackup หรือ retic
ผลการวิจัย
วิธีแก้ปัญหาที่มีแนวโน้มมากที่สุดดูเหมือนจะไม่ชัดเจน เพราะ... เขาเป็นคนที่มีอัตราส่วนความสามารถต่อความเร็วในการทำงานที่ดีที่สุด แต่ตอนนี้อย่าเพิ่งด่วนสรุปทั่วไป
โดยพื้นฐานแล้ว Borgbackup ก็ไม่ได้แย่ไปกว่านี้ แต่ zbackup น่าจะถูกแทนที่ได้ดีกว่า จริงอยู่ที่ zbackup ยังสามารถใช้เพื่อให้แน่ใจว่ากฎ 3-2-1 ใช้งานได้ ตัวอย่างเช่น นอกเหนือจากสิ่งอำนวยความสะดวกการสำรองข้อมูลที่ใช้ (lib) rsync
การประกาศ
การสำรองข้อมูลส่วนที่ 5: การทดสอบการสำรองข้อมูล bacula และ veeam สำหรับ linux
การสำรองข้อมูลส่วนที่ 6: การเปรียบเทียบเครื่องมือสำรองข้อมูล
การสำรองข้อมูลส่วนที่ 7: บทสรุป
โพสโดย: พาเวล เดมโควิช
ที่มา: will.com