การสำรองข้อมูลส่วนที่ 6: การเปรียบเทียบเครื่องมือสำรองข้อมูล

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

การกู้คืนข้อมูล

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

rsync รับมือกับข้อมูลการทดสอบที่ตั้งไว้ในเวลา 4 นาที 28 วินาที แสดงให้เห็น

ภาระเช่นนี้

กระบวนการกู้คืนถึงขีดจำกัดของระบบย่อยของดิสก์ของเซิร์ฟเวอร์จัดเก็บข้อมูลสำรอง (กราฟฟันเลื่อย) คุณยังสามารถเห็นการโหลดเคอร์เนลหนึ่งได้อย่างชัดเจนโดยไม่มีปัญหาใด ๆ (iowait และ softirq ต่ำ - ไม่มีปัญหากับดิสก์และเครือข่ายตามลำดับ) เนื่องจากอีกสองโปรแกรม ได้แก่ rdiff-backup และ rsnapshot นั้นใช้ rsync และยังมี rsync ปกติเป็นเครื่องมือในการกู้คืน ดังนั้นทั้งสองโปรแกรมจึงมีโปรไฟล์โหลดและเวลาการกู้คืนข้อมูลสำรองเท่ากันโดยประมาณ

น้ำมันดิน ทำให้เสร็จเร็วขึ้นนิดหน่อย

2 นาที 43 วินาที:

โหลดของระบบทั้งหมดสูงขึ้นโดยเฉลี่ย 20% เนื่องจากค่า softirq ที่เพิ่มขึ้น - ต้นทุนค่าโสหุ้ยในระหว่างการทำงานของระบบย่อยเครือข่ายเพิ่มขึ้น

หากไฟล์เก็บถาวรถูกบีบอัดเพิ่มเติม เวลาในการกู้คืนจะเพิ่มขึ้นเป็น 3 นาที 19 วินาที
ด้วยภาระดังกล่าวบนเซิร์ฟเวอร์หลัก (แกะที่ด้านข้างของเซิร์ฟเวอร์หลัก):

กระบวนการคลายการบีบอัดจะใช้แกนประมวลผลทั้งสองคอร์เนื่องจากมีกระบวนการทำงานอยู่สองกระบวนการ โดยทั่วไปนี่คือผลลัพธ์ที่คาดหวัง นอกจากนี้ ยังได้รับผลลัพธ์ที่เปรียบเทียบได้ (3 นาที 20 วินาที) เมื่อเรียกใช้ gzip บนฝั่งเซิร์ฟเวอร์พร้อมการสำรองข้อมูล โปรไฟล์โหลดบนเซิร์ฟเวอร์หลักนั้นคล้ายกับการรัน tar โดยไม่ต้องใช้คอมเพรสเซอร์ gzip มาก (ดูกราฟก่อนหน้า)

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

โหลดนี้:

บางทีนี่อาจมีจุดประสงค์ อย่างน้อยก็เพื่อจำกัดความเร็วของผู้เขียน เสนอวิธีแก้ปัญหาดังกล่าว. กระบวนการกู้คืนสำเนาสำรองนั้นใช้เวลาน้อยกว่าครึ่งหนึ่งของหนึ่งคอร์เล็กน้อย โดยมีประสิทธิภาพที่เทียบเคียงได้เป็นสัดส่วน (เช่น ช้ากว่า 2-5 เท่า) บนดิสก์และเครือข่ายที่มี rsync

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

เรอ ฉันเสร็จสิ้นงานกู้คืนข้อมูลสำรองใน 7 นาที 2 วินาทีด้วย
ด้วยภาระนี้:

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

โปรแกรมแสดงความเร็วและโหลดเท่ากันโดยประมาณ สำรองพีซี เมื่อเปิดใช้งานโหมดการถ่ายโอน rsync ปรับใช้การสำรองข้อมูลสำหรับ

7 นาที 42 วินาที:

แต่ในโหมดการถ่ายโอนข้อมูล BackupPC จะจัดการกับ tar ได้ช้ากว่า: ภายใน 12 นาที 15 วินาที โดยทั่วไปโหลดของโปรเซสเซอร์จะต่ำกว่า

หนึ่งครั้งครึ่ง:

การตีสองหน้า หากไม่มีการเข้ารหัสก็แสดงผลลัพธ์ที่ดีขึ้นเล็กน้อย โดยกู้คืนข้อมูลสำรองใน 10 นาที 58 วินาที หากคุณเปิดใช้งานการเข้ารหัสโดยใช้ gpg เวลาในการกู้คืนจะเพิ่มขึ้นเป็น 15 นาที 3 วินาที นอกจากนี้ เมื่อสร้างพื้นที่เก็บข้อมูลสำหรับจัดเก็บสำเนา คุณสามารถระบุขนาดไฟล์เก็บถาวรที่จะใช้เมื่อแยกสตรีมข้อมูลขาเข้าได้ โดยทั่วไปแล้ว สำหรับฮาร์ดไดรฟ์ทั่วไป เนื่องจากโหมดการทำงานแบบเธรดเดียว จึงไม่มีความแตกต่างกันมากนัก อาจปรากฏในขนาดบล็อกที่แตกต่างกันเมื่อใช้ที่เก็บข้อมูลแบบไฮบริด โหลดบนเซิร์ฟเวอร์หลักระหว่างการกู้คืนมีดังนี้:

ไม่มีการเข้ารหัส

ด้วยการเข้ารหัส

ทำซ้ำ มีอัตราการฟื้นตัวที่เทียบเคียงได้ โดยเสร็จสิ้นภายใน 13 นาที 45 วินาที ใช้เวลาประมาณ 5 นาทีในการตรวจสอบความถูกต้องของข้อมูลที่กู้คืน (รวมประมาณ 19 นาที) ภาระก็คือ

ค่อนข้างสูง:

เมื่อเปิดใช้งานการเข้ารหัส aes ภายใน เวลาในการกู้คืนคือ 21 นาที 40 วินาที โดยมีการใช้งาน CPU สูงสุด (ทั้งสองคอร์!) ในระหว่างการกู้คืน เมื่อตรวจสอบข้อมูล มีเพียงเธรดเดียวที่ทำงานอยู่ โดยครอบครองแกนประมวลผลเดียว การตรวจสอบข้อมูลหลังการกู้คืนใช้เวลา 5 นาทีเท่าเดิม (รวมแล้วเกือบ 27 นาที)

ผล

การทำซ้ำทำได้เร็วกว่าเล็กน้อยในการกู้คืนเมื่อใช้โปรแกรม gpg ภายนอกสำหรับการเข้ารหัส แต่โดยทั่วไปความแตกต่างจากโหมดก่อนหน้านั้นมีน้อยมาก ระยะเวลาดำเนินการ 16 นาที 30 วินาที พร้อมการตรวจสอบข้อมูลภายใน 6 นาที ภาระก็คือ

จะเป็นดังนี้:

AMANDAโดยใช้ tar เสร็จภายใน 2 นาที 49 วินาที ซึ่งโดยหลักการแล้วมันใกล้เคียงกับ tar ทั่วไปมาก โหลดบนระบบโดยหลักการ

เหมือน:

เมื่อกู้คืนข้อมูลสำรองโดยใช้ สำรองข้อมูล ได้รับผลลัพธ์ดังต่อไปนี้:

การเข้ารหัส, การบีบอัด lzma

ความยาว 11 นาที 8 วินาที

การเข้ารหัส AES, การบีบอัด lzma

ระยะเวลาใช้งาน 14 นาที

การเข้ารหัส AES, การบีบอัด lzo

ความยาว 6 นาที 19 วินาที

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

BorgBackup ในโหมดที่ไม่ได้เข้ารหัสจะช้ากว่า tar เล็กน้อยใน 2 นาที 45 วินาที อย่างไรก็ตาม ไม่เหมือน tar ตรงที่สามารถขจัดข้อมูลซ้ำซ้อนของที่เก็บได้ โหลดกลายเป็น

ต่อไปนี้:

หากคุณเปิดใช้งานการเข้ารหัสแบบเบลค ความเร็วการกู้คืนข้อมูลสำรองจะช้าลงเล็กน้อย เวลาพักฟื้นในโหมดนี้คือ 3 นาที 19 วินาที และโหลดก็หมดไป

แบบนี้:

การเข้ารหัส AES ช้ากว่าเล็กน้อย ระยะเวลาการกู้คืนคือ 3 นาที 23 วินาที โดยเฉพาะการโหลด

ไม่มีการเปลี่ยนแปลง:

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

พักผ่อน รับมือกับการฟื้นตัวได้ช้าลงเล็กน้อย ระยะเวลาใช้งาน 4 นาที 28 วินาที โหลดดูเหมือน

เช่นนี้

เห็นได้ชัดว่ากระบวนการกู้คืนทำงานได้ในหลายเธรด แต่ประสิทธิภาพไม่สูงเท่ากับ BorgBackup แต่เทียบได้กับเวลากับ rsync ปกติ

ด้วย สำรองข้อมูล สามารถกู้คืนข้อมูลได้ภายใน 8 นาที 19 วินาที โหลดได้

จะเป็นดังนี้:

ภาระก็ยังไม่สูงมากถึงแม้จะต่ำกว่าน้ำมันดินด้วยซ้ำ ในบางสถานที่มีการระเบิด แต่ไม่เกินภาระของคอร์เดียว

การเลือกและเหตุผลของเกณฑ์การเปรียบเทียบ

ตามที่ระบุไว้ในบทความก่อนหน้านี้ ระบบสำรองข้อมูลจะต้องเป็นไปตามเกณฑ์ต่อไปนี้:

• สะดวกในการใช้
• ความเก่งกาจ
• ความมั่นคง
• รวดเร็ว

ควรพิจารณาแต่ละจุดแยกกันโดยละเอียด

ใช้งานง่าย

จะดีที่สุดเมื่อมีปุ่มเดียว “ทำทุกอย่างให้ดี” แต่หากคุณกลับมาที่โปรแกรมจริง สิ่งที่สะดวกที่สุดก็คือหลักการทำงานที่คุ้นเคยและเป็นมาตรฐาน
ผู้ใช้ส่วนใหญ่มีแนวโน้มที่จะดีกว่าหากพวกเขาไม่จำเป็นต้องจำคีย์จำนวนมากสำหรับ cli กำหนดค่าตัวเลือกต่างๆ ที่มักจะคลุมเครือผ่านทางเว็บหรือ Tui หรือตั้งค่าการแจ้งเตือนเกี่ยวกับการดำเนินการที่ไม่สำเร็จ นอกจากนี้ยังรวมถึงความสามารถในการ "ปรับ" โซลูชันการสำรองข้อมูลให้เข้ากับโครงสร้างพื้นฐานที่มีอยู่ได้อย่างง่ายดาย เช่นเดียวกับกระบวนการสำรองข้อมูลอัตโนมัติ นอกจากนี้ยังมีความเป็นไปได้ในการติดตั้งโดยใช้ตัวจัดการแพ็คเกจหรือในหนึ่งหรือสองคำสั่งเช่น "ดาวน์โหลดและแตกไฟล์" curl ссылка | sudo bash - วิธีการที่ซับซ้อน เนื่องจากคุณต้องตรวจสอบสิ่งที่มาถึงผ่านลิงก์

ตัวอย่างเช่น ในบรรดาผู้สมัครที่พิจารณา วิธีแก้ปัญหาง่ายๆ คือ burp, rdiff-backup และ restic ซึ่งมีคีย์ช่วยจำสำหรับโหมดการทำงานที่แตกต่างกัน ซับซ้อนกว่าเล็กน้อยคือบอร์กและความซ้ำซ้อน ที่ยากที่สุดคืออแมนดา ส่วนที่เหลืออยู่ตรงกลางในแง่ของความสะดวกในการใช้งาน ไม่ว่าในกรณีใด หากคุณต้องการเวลามากกว่า 30 วินาทีในการอ่านคู่มือผู้ใช้ หรือคุณต้องไปที่ Google หรือเครื่องมือค้นหาอื่น และเลื่อนดูความช่วยเหลือที่มีขนาดยาว การตัดสินใจก็ทำได้ยากไม่ทางใดก็ทางหนึ่ง

ผู้สมัครบางรายที่ได้รับการพิจารณาสามารถส่งข้อความผ่าน e-mailjabber ได้โดยอัตโนมัติ ในขณะที่คนอื่นๆ อาศัยการแจ้งเตือนที่กำหนดค่าไว้ในระบบ นอกจากนี้ โซลูชันที่ซับซ้อนส่วนใหญ่มักไม่มีการตั้งค่าการแจ้งเตือนที่ชัดเจนทั้งหมด ไม่ว่าในกรณีใดหากโปรแกรมสำรองข้อมูลสร้างรหัสส่งคืนที่ไม่ใช่ศูนย์ซึ่งบริการระบบจะเข้าใจอย่างถูกต้องสำหรับงานเป็นระยะ (ข้อความจะถูกส่งไปยังผู้ดูแลระบบหรือโดยตรงไปยังการตรวจสอบ) - สถานการณ์นั้นง่าย แต่หากไม่สามารถกำหนดค่าระบบสำรองข้อมูลซึ่งไม่ได้ทำงานบนเซิร์ฟเวอร์สำรองข้อมูลได้ วิธีที่ชัดเจนในการพูดถึงปัญหาก็คือความซับซ้อนนั้นมากเกินไปแล้ว ไม่ว่าในกรณีใด การออกคำเตือนและข้อความอื่น ๆ ไปยังเว็บอินเทอร์เฟซหรือบันทึกเท่านั้นถือเป็นแนวปฏิบัติที่ไม่ดี เนื่องจากส่วนใหญ่มักจะถูกละเลย

สำหรับระบบอัตโนมัติ โปรแกรมง่ายๆ สามารถอ่านตัวแปรสภาพแวดล้อมที่กำหนดโหมดการทำงานได้ หรือมี cli ที่พัฒนาแล้วซึ่งสามารถทำซ้ำลักษณะการทำงานได้อย่างสมบูรณ์เมื่อทำงานผ่านเว็บอินเตอร์เฟส เป็นต้น รวมถึงความเป็นไปได้ในการดำเนินงานอย่างต่อเนื่อง ความพร้อมของโอกาสในการขยาย ฯลฯ

ความเก่งกาจ

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

เป็นสัญญาณ - ความสามารถในการทำงานโดยใช้ ssh ปกติ

ความเร็วในการทำงาน

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

ความมั่นคง

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

เปรียบเทียบเครื่องมือสำรองข้อมูล

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

rsync
4m15s
4m28s
ใช่
ไม่
ไม่
ไม่
ใช่
ไม่
ไม่
ใช่
ไม่
ใช่
ใช่
ไม่
ไม่
ไม่
ไม่
ไม่
ใช่
6

น้ำมันดิน
บริสุทธิ์
3m12s
2m43s
ใช่
ไม่
ไม่
ไม่
ไม่
ไม่
ใช่
ใช่
ไม่
ใช่
ไม่
ไม่
ไม่
ไม่
ไม่
ไม่
ใช่
8,5

gzip
9m37s
3m19s
ใช่

Riff สำรอง
16m26s
17m17s
ใช่
ใช่
ใช่
ใช่
ใช่
ไม่
ใช่
ไม่
ใช่
ไม่
ใช่
ไม่
ใช่
ใช่
ใช่
ไม่
ใช่
11

สแนปชอต
4m19s
4m28s
ใช่
ใช่
ใช่
ใช่
ไม่
ไม่
ใช่
ไม่
ใช่
ไม่
ใช่
ไม่
ไม่
ใช่
ใช่
ไม่
ใช่
12,5

เรอ
11m9s
7m2s
ใช่
ไม่
ใช่
ใช่
ใช่
ใช่
ใช่
ไม่
ใช่
ใช่
ไม่
ไม่
ใช่
ไม่
ใช่
ไม่
ใช่
10,5

การตีสองหน้า
ไม่มีการเข้ารหัส
16m48s
10m58s
ใช่
ใช่
ไม่
ใช่
ไม่
ใช่
ใช่
ไม่
ไม่
ใช่
ไม่
ใช่
ใช่
ไม่
ใช่
ไม่
ใช่
11

gpg
17m27s
15m3s

ทำซ้ำ
ไม่มีการเข้ารหัส
20m28s
13m45s
ไม่
ใช่
ไม่
ไม่
ไม่
ใช่
ใช่
ไม่
ไม่
ใช่
ไม่
ใช่
ใช่
ใช่
ใช่
ใช่
ใช่
11

AES
29m41s
21m40s

gpg
26m19s
16m30s

zbackup
ไม่มีการเข้ารหัส
40m3s
11m8s
ใช่
ใช่
ไม่
ไม่
ไม่
ใช่
ใช่
ใช่
ไม่
ใช่
ไม่
ใช่
ใช่
ใช่
ไม่
ไม่
ไม่
10

AES
42m0s
14m1s

aes+lzo
18m9s
6m19s

BorgBackup
ไม่มีการเข้ารหัส
4m7s
2m45s
ใช่
ใช่
ใช่
ใช่
ใช่
ใช่
ใช่
ใช่
ใช่
ใช่
ไม่
ใช่
ใช่
ใช่
ใช่
ไม่
ใช่
16

AES
4m58s
3m23s

blake2
4m39s
3m19s

พักผ่อน
5m38s
4m28s
ใช่
ใช่
ใช่
ใช่
ไม่
ใช่
ใช่
ใช่
ใช่
ใช่
ไม่
ใช่
ไม่
ใช่
ไม่
ใช่
ใช่
15,5

สำรองข้อมูล
8m21s
8m19s
ใช่
ใช่
ใช่
ไม่
ใช่
ไม่
ใช่
ไม่
ใช่
ใช่
ไม่
ใช่
ใช่
ใช่
ใช่
ไม่
ใช่
12

อแมนดา
9m3s
2m49s
ใช่
ไม่
ไม่
ใช่
ใช่
ใช่
ใช่
ไม่
ใช่
ใช่
ใช่
ใช่
ใช่
ไม่
ใช่
ใช่
ใช่
13

สำรองพีซี
rsync
12m22s
7m42s
ใช่
ไม่
ใช่
ใช่
ใช่
ใช่
ใช่
ไม่
ใช่
ไม่
ไม่
ใช่
ใช่
ไม่
ใช่
ไม่
ใช่
10,5

น้ำมันดิน
12m34s
12m15s

ตำนานตาราง:

• สีเขียว เวลาใช้งานไม่เกิน 1 นาที หรือตอบว่า “ใช่” (ยกเว้นคอลัมน์ “Need a client server?”) XNUMX คะแนน
• สีเหลือง ระยะเวลาใช้งาน 0.5-XNUMX นาที XNUMX คะแนน
• สีแดง เวลาทำงานเกินสิบนาที หรือคำตอบคือ “ไม่” (ยกเว้นคอลัมน์ “Do you need a client server?”) 0 คะแนน

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

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

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

การประกาศ

การสำรองข้อมูล ตอนที่ 1: เหตุใดจึงต้องสำรองข้อมูล ภาพรวมของวิธีการ เทคโนโลยี
การสำรองข้อมูลส่วนที่ 2: การตรวจสอบและทดสอบเครื่องมือสำรองข้อมูลที่ใช้ rsync
การสำรองข้อมูลส่วนที่ 3: การตรวจสอบและทดสอบการซ้ำซ้อน การซ้ำซ้อน
การสำรองข้อมูลส่วนที่ 4: การตรวจสอบและทดสอบ zbackup, restic, borgbackup
การสำรองข้อมูลส่วนที่ 5: การทดสอบการสำรองข้อมูล bacula และ veeam สำหรับ linux
การสำรองข้อมูลส่วนที่ 6: การเปรียบเทียบเครื่องมือสำรองข้อมูล
การสำรองข้อมูลส่วนที่ 7: บทสรุป

ที่มา: will.com