🥇วิธีที่ GitLab ช่วยคุณสำรองข้อมูลพื้นที่เก็บข้อมูล NextCloud ขนาดใหญ่

เฮ้ ฮับ!

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

ปัญหาที่เกิดจากฟีเจอร์การติดตั้งคือมีข้อมูลจำนวนมาก การกำหนดเวอร์ชันที่จัดทำโดย Nextcloud ความซ้ำซ้อน เหตุผลส่วนตัว และอื่นๆ ทำให้เกิดการซ้ำกันจำนวนมาก

ประวัติศาสตร์

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

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

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

ขั้นแรกเรามาดูข้อมูลอินพุตกันก่อน พวกเราต้องการ:

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

เพื่อแก้ปัญหาในการจัดการข้อมูลสำรอง เราได้ติดตั้ง GitLab รายละเอียดเพิ่มเติมโดยแท็กเกิล

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

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

เครื่องมือสำรองข้อมูล

เราเริ่มค้นหาวิธีการแก้ไขโดยเลือกเครื่องมือสร้างการสำรองข้อมูล

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

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

การจัดการการสำรองข้อมูล

Borg และ Restic นั้นดี แต่ไม่มีผลิตภัณฑ์ใดที่มีกลไกการควบคุมแบบรวมศูนย์ เพื่อวัตถุประสงค์ในการจัดการและการควบคุม เราเลือกเครื่องมือที่เราใช้งานอยู่แล้ว โดยที่เราไม่สามารถจินตนาการถึงงานของเราได้ รวมถึงระบบอัตโนมัติ - นี่คือ CI/CD - GitLab ที่รู้จักกันดี

แนวคิดมีดังนี้: มีการติดตั้ง gitlab-runner บนแต่ละโหนดที่จัดเก็บข้อมูล Nextcloud รันเนอร์รันสคริปต์ตามกำหนดเวลาที่ตรวจสอบกระบวนการสำรองข้อมูล และเปิดตัว Borg หรือ Retic

เราได้อะไร? ผลตอบรับจากการดำเนินการ ควบคุมการเปลี่ยนแปลงได้สะดวก รายละเอียดในกรณีที่เกิดข้อผิดพลาด

ที่นี่ ที่นี่บน GitHub เราโพสต์ตัวอย่างสคริปต์สำหรับงานต่างๆ และสุดท้ายเราก็แนบมันเข้ากับการสำรองข้อมูลไม่เพียงแต่ Nextcloud เท่านั้น แต่ยังรวมไปถึงบริการอื่นๆ อีกมากมาย นอกจากนี้ยังมีตัวกำหนดเวลาหากคุณไม่ต้องการกำหนดค่าด้วยตนเอง (และเราไม่ต้องการ) และ .gitlab-ci.yml

ยังไม่มีวิธีเปลี่ยนการหมดเวลา CI/CD ใน Gitlab API ได้ แต่มีขนาดเล็ก มันต้องเพิ่มขึ้นนะบอกเลย 1d.

โชคดีที่ GitLab สามารถเปิดตัวได้ไม่เพียงแต่ตามการคอมมิตเท่านั้น แต่ยังตามกำหนดเวลาเท่านั้น นี่คือสิ่งที่เราต้องการจริงๆ

ตอนนี้เกี่ยวกับสคริปต์ตัวตัดคำ

เรากำหนดเงื่อนไขต่อไปนี้สำหรับสคริปต์นี้:

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

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

เรายินดีที่จะพิจารณาข้อเสนอแนะและความคิดเห็นเกี่ยวกับโอเพ่นซอร์ส - ยินดีต้อนรับ

Какэтоработает

นักวิ่งที่มี Bash executor จะเปิดตัวบนโหนดสำรอง ตามกำหนดการ งาน CI/CD จะเปิดตัวในหัวผักกาดแบบพิเศษ Runner เปิดตัวสคริปต์ wrapper สากลสำหรับงานดังกล่าว โดยจะตรวจสอบความถูกต้องของที่เก็บข้อมูลสำรอง จุดเชื่อมต่อ และทุกสิ่งที่เราต้องการ จากนั้นสำรองข้อมูลและล้างข้อมูลเก่า ข้อมูลสำรองที่เสร็จแล้วจะถูกส่งไปยัง S3

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

เราไม่ได้ใช้คุณสมบัติในการส่งข้อมูลสำรองผ่าน ssh สิ่งนี้ไม่ได้เพิ่มความปลอดภัย และความสามารถด้านเครือข่ายของผู้ให้บริการ S3 นั้นสูงกว่าเครื่อง ssh เครื่องเดียวของเรามาก

เพื่อปกป้องเครื่องของคุณจากแฮกเกอร์ เนื่องจากแฮ็กเกอร์สามารถลบข้อมูลบน S3 ได้ คุณต้องเปิดใช้งานการกำหนดเวอร์ชัน
ข้อมูลสำรองจะเข้ารหัสข้อมูลสำรองเสมอ

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

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

อ่านเป็นภาษารัสเซีย

หน้าที่หลัก

prepare การอบรม
testcheck ตรวจสอบความพร้อม
maincommand ทีมงานหลัก
forcepostscript ฟังก์ชั่นที่ถูกดำเนินการในท้ายที่สุดหรือโดยข้อผิดพลาด เราใช้มันเพื่อยกเลิกการต่อเชื่อมพาร์ติชัน

ฟังก์ชั่นการบริการ

cleanup เราบันทึกข้อผิดพลาดหรือลบไฟล์บันทึก
checklog แยกวิเคราะห์บันทึกการเกิดขึ้นของบรรทัดที่มีข้อผิดพลาด
ret ตัวจัดการทางออก
checktimeout ตรวจสอบการหมดเวลา

สิ่งแวดล้อม

VERBOSE=1 เราแสดงข้อผิดพลาดบนหน้าจอทันที (stdout)
SAVELOGSONSUCCES=1 บันทึกบันทึกเมื่อสำเร็จ
INIT_REPO_IF_NOT_EXIST=1 สร้างพื้นที่เก็บข้อมูลหากไม่มีอยู่ ปิดใช้งานตามค่าเริ่มต้น
TIMEOUT เวลาสูงสุดสำหรับการดำเนินการหลัก คุณสามารถตั้งค่าเป็น 'm', 'h' หรือ 'd' ในตอนท้ายได้

โหมดการจัดเก็บข้อมูลสำหรับสำเนาเก่า ค่าเริ่มต้น:

KEEP_DAILY=7
KEEP_WEEKLY=4
KEEP_MONTHLY=6

ตัวแปรภายในสคริปต์

ERROR_STRING — สตริงสำหรับบันทึกการเช็คอินเพื่อดูข้อผิดพลาด
EXTRACT_ERROR_STRING — นิพจน์สำหรับแสดงสตริงหากเกิดข้อผิดพลาด
KILL_TIMEOUT_SIGNAL — สัญญาณสำหรับการฆ่าหากหมดเวลา
TAIL — จำนวนสายที่มีข้อผิดพลาดบนหน้าจอ
COLORMSG — สีของข้อความ (สีเหลืองเริ่มต้น)

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

เรสติค vs บอร์ก

นอกจากนี้ยังมีการเปรียบเทียบระหว่าง Borg และ Retic ที่นี่เกี่ยวกับHabréและเราไม่ได้มีหน้าที่สร้างอีกอันหนึ่ง แต่เป็นของเราเอง เป็นสิ่งสำคัญสำหรับเราว่าข้อมูลจะดูเป็นอย่างไรพร้อมข้อมูลเฉพาะของเรา เรานำพวกเขามา

เกณฑ์การคัดเลือกของเรา นอกเหนือจากที่กล่าวไปแล้ว (การขจัดข้อมูลซ้ำซ้อน การกู้คืนอย่างรวดเร็ว ฯลฯ):

ความต้านทานต่องานที่ยังไม่เสร็จ ตรวจสอบการฆ่า -9
ขนาดบนดิสก์
ข้อกำหนดสำหรับทรัพยากร (CPU, หน่วยความจำ)
ขนาดของหยดที่เก็บไว้
ทำงานกับ S3
การตรวจสอบความสมบูรณ์

สำหรับการทดสอบ เราใช้ไคลเอนต์หนึ่งรายที่มีข้อมูลจริงและมีขนาดรวม 1,6 TB
เงื่อนไข

บอร์กไม่ทราบวิธีทำงานโดยตรงกับ S3 และเราติดตั้งดิสก์เป็นฟิวส์ผ่าน พวกโง่. Retic ส่งมาที่ S3 เอง

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

เพื่อลดอิทธิพลของเครือข่าย เราใช้ผู้ให้บริการในพื้นที่ - Yandex Cloud

ผลการทดสอบเปรียบเทียบ

Kill -9 ด้วยการรีสตาร์ทอีกครั้งก็ประสบความสำเร็จทั้งคู่
ขนาดบนดิสก์ บอร์กอัดได้ผลลัพธ์ก็เป็นไปตามคาด

ตัวสำรอง
ขนาด

แอนเดอ
562Gb

พักผ่อน
628Gb

โดยซีพียู
ตัว Borg เองกินเพียงเล็กน้อยด้วยการบีบอัดเริ่มต้น แต่ต้องได้รับการประเมินร่วมกับกระบวนการที่โง่เขลา โดยรวมแล้วสามารถเปรียบเทียบได้และใช้ประมาณ 1,2 คอร์บนเครื่องเสมือนทดสอบเดียวกัน
หน่วยความจำ. Retic มีขนาดประมาณ 0,5GB Borg มีขนาดประมาณ 200MB แต่ทั้งหมดนี้ไม่มีนัยสำคัญเลยเมื่อเทียบกับแคชไฟล์ระบบ ดังนั้นจึงแนะนำให้จัดสรรหน่วยความจำเพิ่มเติม
ความแตกต่างของขนาดหยดนั้นน่าทึ่งมาก

ตัวสำรอง
ขนาด

แอนเดอ
ประมาณ 500MB

พักผ่อน
ประมาณ 5MB

ประสบการณ์ S3 ของ Retic นั้นยอดเยี่ยมมาก การทำงานกับ Borg ผ่าน goofys ไม่ได้ทำให้เกิดคำถามใด ๆ แต่มีข้อสังเกตว่าขอแนะนำให้ทำการติดตั้งหลังจากการสำรองข้อมูลเสร็จสิ้นเพื่อรีเซ็ตแคชโดยสมบูรณ์ ลักษณะเฉพาะของ S3 คือชิ้นส่วนที่มีการสูบน้อยจะไม่ถูกส่งไปยังบัคเก็ต ซึ่งหมายความว่าข้อมูลที่เติมไม่ครบถ้วนจะนำไปสู่ความเสียหายร้ายแรง
การตรวจสอบความสมบูรณ์ทำงานได้ดีในทั้งสองกรณี แต่ความเร็วแตกต่างกันอย่างมาก
เรสติค ชั่วโมง 3,5.
Borg พร้อมแคชไฟล์ SSD ขนาด 100GB – ชั่วโมง 5. ผลลัพธ์จะมีความเร็วเท่ากันโดยประมาณหากข้อมูลอยู่ในดิสก์ภายในเครื่อง
Borg อ่านโดยตรงจาก S3 โดยไม่มีแคช ชั่วโมง 33. ยาวอย่างน่ากลัว

สิ่งสำคัญที่สุดคือ Borg สามารถบีบอัดและมี blobs ที่ใหญ่ขึ้น ซึ่งทำให้การจัดเก็บและการดำเนินการ GET/PUT ใน S3 ถูกลง แต่สิ่งนี้ต้องแลกมาด้วยการตรวจสอบที่ซับซ้อนและช้าลง สำหรับความเร็วในการฟื้นตัว เราไม่ได้สังเกตเห็นความแตกต่างใดๆ Retic จะใช้เวลาในการสำรองข้อมูลครั้งต่อไป (หลังจากการสำรองข้อมูลครั้งแรก) นานขึ้นเล็กน้อย แต่ไม่มากนัก

สุดท้ายแต่ไม่ท้ายสุดในตัวเลือกคือขนาดของชุมชน

และเราเลือกบอร์ก

คำไม่กี่คำเกี่ยวกับการบีบอัด

Borg มีอัลกอริธึมการบีบอัดใหม่ที่ยอดเยี่ยมในคลังแสง - zstd คุณภาพการบีบอัดไม่ได้แย่ไปกว่า gzip แต่เร็วกว่ามาก และเทียบความเร็วได้กับ lz4 ที่เป็นค่าเริ่มต้น

ตัวอย่างเช่น ดัมพ์ฐานข้อมูล MySQL ถูกบีบอัดได้ดีกว่า lz4 สองเท่าที่ความเร็วเท่ากัน อย่างไรก็ตาม ประสบการณ์กับข้อมูลจริงแสดงให้เห็นว่าอัตราส่วนการบีบอัดของโหนด Nextcloud มีความแตกต่างกันน้อยมาก

บอร์กมีโหมดการบีบอัดโบนัสค่อนข้าง - หากไฟล์มีเอนโทรปีสูง การบีบอัดจะไม่ถูกนำไปใช้เลย ซึ่งจะเพิ่มความเร็ว เปิดใช้งานโดยตัวเลือกเมื่อสร้าง
-C auto,zstd
สำหรับอัลกอริทึม zstd
ด้วยตัวเลือกนี้ เมื่อเปรียบเทียบกับการบีบอัดเริ่มต้น เราก็ได้
560Gb และ 562Gb ตามลำดับ ข้อมูลจากตัวอย่างข้างต้น ผมขอเตือนคุณว่า หากไม่มีการบีบอัด ผลลัพธ์ที่ได้คือ 628Gb ผลลัพธ์ของความแตกต่าง 2GB ค่อนข้างทำให้เราประหลาดใจ แต่เราคิดว่าจะเลือกมันในที่สุด auto,zstd.

วิธีการตรวจสอบการสำรองข้อมูล

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

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

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

ความสามารถในการปรับขนาดทำได้โดยการรันรันเนอร์บนโหนดที่แตกต่างกันด้วยแท็กที่แตกต่างกัน
การตรวจสอบของเราจะรวบรวมสถานะการสำรองข้อมูลผ่าน GitLab API ในหน้าต่างเดียว หากจำเป็น ปัญหาจะสังเกตได้ง่ายและแปลเป็นภาษาท้องถิ่นได้ง่ายเช่นกัน

ข้อสรุป

เป็นผลให้เรารู้แน่ว่าเราทำการสำรองข้อมูลว่าการสำรองข้อมูลของเราถูกต้อง ปัญหาที่เกิดขึ้นใช้เวลาน้อยและได้รับการแก้ไขในระดับหน้าที่ผู้ดูแลระบบ การสำรองข้อมูลใช้พื้นที่น้อยมากเมื่อเทียบกับ tar.gz หรือ Bacula

ที่มา: will.com

GitLab ช่วยคุณสำรองข้อมูลพื้นที่เก็บข้อมูล NextCloud ขนาดใหญ่ได้อย่างไร