การสำรองข้อมูลส่วนที่ 3: การตรวจสอบและทดสอบการซ้ำซ้อน การซ้ำซ้อน

หมายเหตุนี้กล่าวถึงเครื่องมือสำรองข้อมูลที่ทำการสำรองข้อมูลโดยการสร้างไฟล์เก็บถาวรบนเซิร์ฟเวอร์สำรอง

ในบรรดาสิ่งที่ตรงตามข้อกำหนดนั้นมีความซ้ำซ้อน (ซึ่งมีอินเทอร์เฟซที่ดีในรูปแบบของ deja dup) และการซ้ำซ้อน

เครื่องมือสำรองข้อมูลที่น่าทึ่งอีกอย่างหนึ่งคือ dar แต่เนื่องจากมีตัวเลือกมากมาย วิธีทดสอบจึงครอบคลุมเกือบ 10% ของความสามารถ - เราไม่ได้ทดสอบโดยเป็นส่วนหนึ่งของวงจรปัจจุบัน

ผลลัพธ์ที่คาดหวัง

เนื่องจากผู้สมัครทั้งสองสร้างไฟล์เก็บถาวรไม่ทางใดก็ทางหนึ่ง tar ปกติจึงสามารถใช้เป็นแนวทางได้

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

ลักษณะการทำงานเมื่อสร้างการสำรองข้อมูล:

1. ไฟล์จำนวนค่อนข้างน้อยบนเซิร์ฟเวอร์จัดเก็บข้อมูลสำรอง (เทียบได้กับจำนวนสำเนาสำรองหรือขนาดข้อมูลเป็น GB) แต่มีขนาดค่อนข้างใหญ่ (สิบถึงหลายร้อยเมกะไบต์)
2. ขนาดพื้นที่เก็บข้อมูลจะรวมการเปลี่ยนแปลงเท่านั้น โดยจะไม่เก็บข้อมูลซ้ำ ดังนั้นขนาดพื้นที่เก็บข้อมูลจะเล็กกว่าซอฟต์แวร์ที่ใช้ rsync
3. คาดว่าจะมีการโหลด CPU จำนวนมากเมื่อใช้การบีบอัดและ/หรือการเข้ารหัส และมีแนวโน้มว่าเครือข่ายและดิสก์จะโหลดค่อนข้างสูง หากกระบวนการเก็บถาวรและ/หรือการเข้ารหัสกำลังทำงานบนเซิร์ฟเวอร์จัดเก็บข้อมูลสำรอง

ลองใช้คำสั่งต่อไปนี้เป็นค่าอ้างอิง:

cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"

ผลการดำเนินการมีดังนี้:

เวลาดำเนินการ 3m12s จะเห็นได้ว่าความเร็วถูกจำกัดโดยระบบย่อยของดิสก์ของเซิร์ฟเวอร์จัดเก็บข้อมูลสำรองดังตัวอย่างด้วย rsync. เร็วขึ้นอีกหน่อยเท่านั้น เพราะ... การบันทึกไปที่ไฟล์เดียว

นอกจากนี้ เพื่อประเมินการบีบอัด ให้ใช้ตัวเลือกเดียวกัน แต่เปิดใช้งานการบีบอัดบนฝั่งเซิร์ฟเวอร์สำรอง:

cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"

ผลลัพธ์คือ:

เวลาดำเนินการ 10m11s เป็นไปได้มากว่าปัญหาคอขวดคือคอมเพรสเซอร์แบบไหลเดี่ยวที่ส่วนรับสัญญาณ

คำสั่งเดียวกันแต่มีการบีบอัดข้อมูลไปยังเซิร์ฟเวอร์ด้วยข้อมูลต้นฉบับเพื่อทดสอบสมมติฐานที่ว่าคอขวดเป็นคอมเพรสเซอร์แบบเธรดเดียว

cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"

มันกลับกลายเป็นเช่นนี้:

เวลาดำเนินการคือ 9 นาที 37 วินาที โหลดบนแกนเดียวโดยคอมเพรสเซอร์จะมองเห็นได้ชัดเจนเพราะว่า ความเร็วการถ่ายโอนเครือข่ายและโหลดบนระบบย่อยของดิสก์ต้นทางจะใกล้เคียงกัน

ในการประเมินการเข้ารหัส คุณสามารถใช้ openssl หรือ gpg ได้โดยเชื่อมต่อคำสั่งเพิ่มเติม openssl หรือ gpg ในท่อ สำหรับการอ้างอิงจะมีคำสั่งดังนี้:

cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"

ผลลัพธ์ออกมาดังนี้:

เวลาดำเนินการกลายเป็น 10 นาที 30 วินาที เนื่องจาก 2 กระบวนการทำงานบนฝั่งรับ - คอขวดเป็นคอมเพรสเซอร์แบบเธรดเดียวอีกครั้ง รวมถึงค่าใช้จ่ายในการเข้ารหัสเล็กน้อย

ยูพีเอส: ตามคำร้องขอของ bliznezz ฉันกำลังเพิ่มการทดสอบกับ pigz หากคุณใช้เฉพาะคอมเพรสเซอร์ก็จะใช้เวลาประมาณ 6 นาที 30 วินาที หากคุณเพิ่มการเข้ารหัสด้วยก็จะใช้เวลาประมาณ 7 นาที การจุ่มในกราฟด้านล่างคือดิสก์แคชที่ไม่ถูกล้าง:

การทดสอบซ้ำ

Duplicity เป็นซอฟต์แวร์ Python สำหรับการสำรองข้อมูลโดยการสร้างไฟล์เก็บถาวรที่เข้ารหัสในรูปแบบ tar

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

ข้อมูลสำรองสามารถเข้ารหัสและเซ็นชื่อได้โดยใช้ gnupg ซึ่งเป็นสิ่งสำคัญเมื่อใช้ผู้ให้บริการหลายรายในการจัดเก็บข้อมูลสำรอง (s3, backblaze, gdrive ฯลฯ)

มาดูกันว่าผลลัพธ์เป็นอย่างไร:

นี่คือผลลัพธ์ที่เราได้รับเมื่อทำงานโดยไม่มีการเข้ารหัส

สปอยเลอร์

เวลาทำงานของการทดสอบการทำงานแต่ละครั้ง:

เปิดตัว 1
เปิดตัว 2
เปิดตัว 3

16m33s
17m20s
16m30s

8m29s
9m3s
8m45s

5m21s
6m04s
5m53s

และนี่คือผลลัพธ์เมื่อเปิดใช้งานการเข้ารหัส gnupg โดยมีขนาดคีย์ 2048 บิต:

เวลาทำงานในข้อมูลเดียวกันพร้อมการเข้ารหัส:

เปิดตัว 1
เปิดตัว 2
เปิดตัว 3

17m22s
17m32s
17m28s

8m52s
9m13s
9m3s

5m48s
5m40s
5m30s

ระบุขนาดบล็อก - 512 เมกะไบต์ซึ่งมองเห็นได้ชัดเจนในกราฟ โหลดของโปรเซสเซอร์จริงยังคงอยู่ที่ 50% ซึ่งหมายความว่าโปรแกรมใช้คอร์โปรเซสเซอร์ไม่เกินหนึ่งคอร์

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

การเปิดใช้งานการเข้ารหัสไม่ได้เพิ่มเวลาการทำงานของโปรแกรมอย่างมีนัยสำคัญ แต่เพิ่มภาระของโปรเซสเซอร์ประมาณ 10% ซึ่งอาจเป็นโบนัสที่ดีทีเดียว

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

การทดสอบซ้ำ

ซอฟต์แวร์นี้เขียนด้วยภาษา C# และทำงานโดยใช้ชุดไลบรารีจาก Mono มี GUI และเวอร์ชัน CLI

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

ความแตกต่างเล็กน้อยอีกประการหนึ่ง - โปรแกรมเขียนฐานข้อมูล sqlite ในเครื่องในนามของผู้ใช้ที่เริ่มการสำรองข้อมูลดังนั้นคุณต้องตรวจสอบให้แน่ใจเพิ่มเติมว่าฐานข้อมูลที่ต้องการได้รับการระบุอย่างถูกต้องทุกครั้งที่เริ่มกระบวนการโดยใช้ cli เมื่อทำงานผ่าน GUI หรือ WEBGUI รายละเอียดจะถูกซ่อนไม่ให้ผู้ใช้เห็น

มาดูกันว่าโซลูชันนี้สามารถให้ตัวบ่งชี้อะไรได้บ้าง:

หากคุณปิดการเข้ารหัส (และ WEBGUI ไม่แนะนำให้ทำเช่นนี้) ผลลัพธ์จะเป็นดังนี้:

ใช้เวลา:

เปิดตัว 1
เปิดตัว 2
เปิดตัว 3

20m43s
20m13s
20m28s

5m21s
5m40s
5m35s

7m36s
7m54s
7m49s

เมื่อเปิดใช้งานการเข้ารหัสโดยใช้ aes จะมีลักษณะดังนี้:

ใช้เวลา:

เปิดตัว 1
เปิดตัว 2
เปิดตัว 3

29m9s
30m1s
29m54s

5m29s
6m2s
5m54s

8m44s
9m12s
9m1s

และถ้าคุณใช้โปรแกรมภายนอก gnupg ผลลัพธ์ต่อไปนี้จะออกมา:

เปิดตัว 1
เปิดตัว 2
เปิดตัว 3

26m6s
26m35s
26m17s

5m20s
5m48s
5m40s

8m12s
8m42s
8m15s

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

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

โดยรวมแล้วมีความประทับใจเชิงบวกต่อโปรแกรม รวมถึงการเป็นมิตรกับมือใหม่ด้วย

ผลการวิจัย

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

ผลการวิจัย

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

เมื่อเทียบกับโซลูชั่นที่ใช้ rsync - ประสิทธิภาพอาจแย่ลงหลายเท่าแม้ว่า tar ในรูปแบบบริสุทธิ์จะทำงานได้เร็วกว่า rsync ถึง 20-30%
มีการประหยัดขนาดของพื้นที่เก็บข้อมูล แต่มีเพียงการทำซ้ำเท่านั้น

การประกาศ

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

โพสโดย: พาเวล เดมโควิช

ที่มา: will.com