วิธีการสำรองข้อมูลขนาดใหญ่ Gitlab?

เมื่อถามถึงการสนับสนุน Gitlab เกี่ยวกับวิธีการสำรองข้อมูล 3TB บน Gitlab ในสถานที่พวกเขาตอบกลับใช้เครื่องมือของเราที่สร้าง tarball

นี่แค่ตะเข็บฉันผิดไปทุกระดับ tarball นี้มีการถ่ายโอนข้อมูล postgres, ภาพ docker, ข้อมูล repo, GIT LFS, etc config และอื่น ๆ การสำรอง TB ของข้อมูลสแตติกพร้อมกับข้อมูล KB ที่มีไดนามิกมาก ๆ นั้นจะไม่ถูกต้อง จากนั้นปัญหาของเราต้องการสำรองข้อมูลทุกชั่วโมง

คำถาม

ฉันอยากรู้จากคนอื่น ๆ ว่าพวกเขาทำได้อย่างไรเพื่อรับการสำรองข้อมูลที่สอดคล้องกัน

ZFS บน Linux น่าจะดีกับฉันถ้านั่นเป็นส่วนหนึ่งของการแก้ปัญหา

— แซนดร้า
แหล่งที่มา

ทำไมมันผิด คุณสำรอง Gitlab ของคุณอย่างสมบูรณ์เพื่อคืนค่าอย่างสมบูรณ์ ฉันไม่คิดว่ามันผิด แน่นอนมันใช้พื้นที่มากกว่าการสำรองข้อมูลส่วนเพิ่ม แต่ ... ฉันไม่สนใจขนาดการสำรองข้อมูล

— Lenniey

การมีการสำรองข้อมูลทุก ๆ ชั่วโมงนั้นไม่ใช่เรื่องแปลก แต่ก็เป็นไปไม่ได้ที่จะสร้าง 3TB ภายในเวลาไม่ถึงชั่วโมงด้วยวิธีการของพวกเขา และการสำรองข้อมูลเพียงหนึ่งวันจะเป็น ~ 100TB ซึ่งอาจมีการเปลี่ยนแปลงข้อมูลเพียง 10MB

— Sandra

ตกลงนี่เป็นคำถามที่แตกต่างไม่เกี่ยวกับการสำรองข้อมูลโดยทั่วไป แต่เกี่ยวกับการสำรองข้อมูลบ่อยครั้ง

— Lenniey

ในเอกสารอย่างเป็นทางการของพวกเขาพวกเขายังกล่าวถึงวิธีการของพวกเขาว่าช้าและแนะนำทางเลือก:

If your GitLab server contains a lot of Git repository data you may find the GitLab backup script to be too slow. In this case you can consider using filesystem snapshots as part of your backup strategy.

ฉันไม่สามารถพูดจากประสบการณ์ได้ แต่ฉันอาจต้องรวมสิ่งนี้ในไม่ช้า ...

— Lenniey

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

— 54219

คำตอบ:

ในช่วงเวลาสั้น ๆ ระหว่างการสำรองข้อมูล (1 ชม.) ทางออกที่ดีที่สุดของคุณคือการพึ่งพาภาพรวมระดับระบบไฟล์และ send/recvการสนับสนุน

หากการใช้ZoLไม่ใช่ปัญหาในสภาพแวดล้อมของคุณฉันขอแนะนำให้ใช้อย่างจริงจัง ZFS เป็นระบบไฟล์ที่แข็งแกร่งมากและคุณจะชอบความพิเศษทั้งหมด (เช่นการบีบอัด) ที่มีให้ เมื่อรวมกับsanoid/syncoidมันสามารถให้กลยุทธ์การสำรองที่แข็งแกร่งมาก ข้อเสียเปรียบหลักคือมันไม่ได้รวมอยู่ในเคอร์เนล mainline ดังนั้นคุณต้องติดตั้ง / อัปเดตแยกต่างหาก

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

สุดท้ายเป็นโซลูชั่นทางเลือกคือการใช้lvmthinที่จะใช้สำรองข้อมูลปกติ (เช่นมีsnapper) อาศัยเครื่องมือของบุคคลที่สาม (เช่นbdsync, blocksyncฯลฯ ) เพื่อคัดลอก / เรือสันดอนเท่านั้น

วิธีการที่แตกต่างกันจะมีสองเครื่องจำลอง (ผ่านDRBD) ที่คุณนำภาพรวม indipendent lvmthinผ่าน

— shodanshok
แหล่งที่มา

แล้ว postgres ล่ะ จะหยุด gitlab และ postgres เป็นเวลาหนึ่งนาทีดังนั้นจึงสามารถสร้าง shapshot ที่สอดคล้องกันได้หรือไม่ เป็นการดีที่จะดีถ้า postgres สามารถวางในโหมดอ่านอย่างเดียวในขณะที่ทำสแนปชอต

— Sandra

@Sandra การกู้คืนจากสแน็ปช็อตระบบไฟล์ควรปรากฏขึ้นเพื่อ postgresql (และฐานข้อมูลอื่น ๆ ที่เขียนอย่างถูกต้อง) เป็นสถานการณ์ "โฮสต์ผิดพลาด" ทั่วไปเรียกขั้นตอนการกู้คืนของตัวเอง (เช่น: กระทำกับฐานข้อมูลหลัก คุณไม่จำเป็นต้องวาง postgres ในโหมดอ่านอย่างเดียวเมื่อทำการถ่ายภาพ

— shodanshok

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

และใช้กระบวนการสำรองข้อมูล "ในตัว" เพื่อสำรองข้อมูลปัญหา ฯลฯ ฉันสงสัยว่า 3TB มาจากส่วนนี้ดังนั้นคุณจะสามารถสำรองข้อมูลได้บ่อยครั้งที่ค่าใช้จ่ายน้อยมาก นอกจากนี้คุณยังสามารถตั้งค่าฐานข้อมูล PostgreSQL ด้วยโหมดสแตนด์บายพร้อมการจำลองแบบ

อาจเป็นไปได้ว่า 3TB ของคุณมาจากอิมเมจคอนเทนเนอร์ในรีจิสตรี Docker คุณต้องการสำรองข้อมูลเหล่านั้นหรือไม่ ถ้าเป็นเช่นนั้นอาจมีแนวทางที่ดีกว่าสำหรับเรื่องนั้น

โดยทั่วไปฉันขอแนะนำให้ดูที่การสำรองข้อมูลของคุณและสำรองข้อมูลในส่วนต่างๆ

แม้แต่เครื่องมือสำรองข้อมูลจาก GitLab ก็มีตัวเลือกให้รวม / ยกเว้นบางส่วนของระบบเช่น Docker Registry

— ETL
แหล่งที่มา

git pulls ไม่ใช่การสำรองข้อมูลส่วนเพิ่มที่สมบูรณ์แบบ git push --forceจะแบ่งการสำรองข้อมูลหรือลบประวัติจากการสำรองข้อมูลทั้งนี้ขึ้นอยู่กับวิธีการนำไปใช้

— 371366

@ dn3s นั่นเป็นเหตุผลที่คุณปิดการใช้งาน git push --force บนที่เก็บหลักเสมอ หากใครต้องการเปลี่ยนประวัติศาสตร์พวกเขาสามารถสร้างทางแยกของตนเองและยอมรับความเสี่ยงทั้งหมดที่เกิดขึ้น

— charlie_pl

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

— 371366