เลือกขอบเขตของที่เก็บข้อมูล
ใช้ปลายทางและข้อมูลรับรองแยกจากเซิร์ฟเวอร์โปรดักชัน การเข้ารหัสฝั่งไคลเอนต์สามารถปกป้องสำเนาที่จัดเก็บไว้ได้ แต่รหัสผ่านหรือคีย์ของที่เก็บข้อมูลต้องสำรองไว้อย่างเป็นส่วนตัว การสูญหายอาจทำให้สแนปช็อตที่เข้ารหัสทุกชิ้นใช้งานไม่ได้
เก็บข้อมูลอย่างสม่ำเสมอ
ใช้การดัมป์แบบเนทีฟของฐานข้อมูลหรือขั้นตอนสแนปช็อตที่แอปพลิเคชันรองรับ สำรองข้อมูลการกำหนดค่า คำแนะนำในการติดตั้งใช้งาน และความลับที่ได้รับการป้องกันซึ่งจำเป็นสำหรับการกู้คืน ยกเว้นแคชชั่วคราวเฉพาะเมื่อคุณรู้ว่าสามารถสร้างใหม่ได้
ทำให้การลบยากขึ้น
พิจารณาปลายทางแบบเพิ่มต่อท้ายเท่านั้นหรือแบบไม่เปลี่ยนแปลง ซึ่งเครื่องต้นทางไม่สามารถลบสำเนาย้อนหลังทั้งหมดได้ แยกข้อมูลรับรองการเก็บรักษาและการตัดทอนออกจากกันเมื่อทำได้ การเข้ารหัสเพียงอย่างเดียวไม่หยุดเซิร์ฟเวอร์ที่ถูกบุกรุกจากการลบที่เก็บข้อมูลที่เขียนได้
กำหนดตารางการตรวจสอบและการซ้อมกู้คืน
ตรวจสอบสถานะการออกของงานและอายุของการสำรองข้อมูลที่ดีครั้งล่าสุด รันการตรวจสอบความสมบูรณ์ของที่เก็บข้อมูลที่เครื่องมือรองรับ กู้คืนตัวอย่างเป็นประจำ และซ้อมการกู้คืนแบบสมบูรณ์หลังการเปลี่ยนแปลงแอปพลิเคชันครั้งสำคัญ
แยกการเพิ่มสำเนาออกจากการลบประวัติ
ปลายทางแบบ append-only ช่วยให้เซิร์ฟเวอร์โปรดักชันเพิ่มสแนปช็อตได้ ขณะที่อำนาจการลบยังอยู่บนเครื่องที่เชื่อถือได้แยกต่างหาก การเก็บรักษายังต้องตรวจสอบอย่างรอบคอบ: สแนปช็อตใหม่ที่ปลอมแปลงอาจบั่นทอนนโยบายการเลือกตามปฏิทินบางประเภท ตรวจสอบคำแนะนำของเครื่องมือ ทดลองการเก็บรักษาแบบ dry run และติดตามความจุ การดำเนินการ forget ของ Restic จะเลือกสแนปช็อต ส่วน pruning จะลบข้อมูลที่จัดเก็บไว้ซึ่งไม่มีการอ้างอิง
- เก็บข้อมูลรับรองสำหรับดูแลรีโพซิทอรีออกจากเครื่องโปรดักชัน
- ทดลองการเก็บรักษาข้อมูลแบบจำลองก่อนอนุญาตให้ลบ
- ใช้ปลายทางใหม่ที่ว่างเปล่าสำหรับการทดสอบการกู้คืนแต่ละครั้ง
restic check
restic snapshots
restic restore latest --target /srv/restore-drillเอกสารอย่างเป็นทางการ: การเก็บรักษาและการตัดทอนของ Restic
การซ้อมกู้คืนพร้อมเงื่อนไขผ่าน
เลือกความล้มเหลวหนึ่งกรณีที่สมจริง: ไฟล์ที่ถูกลบ ฐานข้อมูลที่สูญหาย หรือการสร้างเครื่องใหม่ทั้งหมด กู้คืนไปยังไดเรกทอรีแยกหรือโฮสต์ที่แยกออกมา ตรวจสอบเนื้อหาไฟล์ สิทธิ์ และความสามารถของแอปพลิเคชันในการใช้งานไฟล์เหล่านั้น บันทึกเวลาที่ใช้และขั้นตอนด้วยมือใด ๆ ที่ขาดหายไปจาก runbook การตรวจสอบที่เก็บข้อมูลยืนยันคุณสมบัติที่แตกต่างจากการกู้คืนแอปพลิเคชันที่ใช้งานได้
- อย่าทดลองกู้คืนทับแอปพลิเคชันที่ใช้งานจริงเป็นครั้งแรก
- ยืนยันว่าข้อมูลรับรองการเข้ารหัสสามารถกู้คืนได้อย่างอิสระ
- แจ้งเตือนหากการสำรองข้อมูลสำเร็จครั้งล่าสุดเกินเป้าหมายการกู้คืนของคุณ
สร้างรายการกู้คืนก่อนเลือกการยกเว้น
ระบุรายการที่ไม่สามารถสร้างใหม่ได้ด้วยการติดตั้งแพ็กเกจซ้ำ เช่น เนื้อหาฐานข้อมูล ไฟล์อัปโหลด การกำหนดค่าแอปพลิเคชัน คีย์สำหรับลงนามหรือเข้ารหัส และเวอร์ชันที่ติดตั้งใช้งาน บันทึกวิธีการรักษาความสอดคล้องกำกับแต่ละรายการ การดัมป์ฐานข้อมูลผูกกับจุดเวลาที่กำหนดไว้ การคัดลอกไดเรกทอรีฐานข้อมูลที่กำลังใช้งานอยู่อาจให้ผลลัพธ์ที่ต่างออกไป เก็บการเข้าถึงรีโพซิทอรี พาสเฟรส และไฟล์ส่งออกคีย์ Borg ไว้ในตำแหน่งกู้คืนส่วนตัวที่แยกต่างหาก ทดสอบว่าเครื่องทดแทนสามารถเปิดรีโพซิทอรีได้ก่อนทำให้เป็นสำเนากู้คืนเพียงชุดเดียว
- ระบุจุดประสงค์การกู้คืน (recovery point objective) ว่าอาจสูญเสียงานล่าสุดได้มากเพียงใด กำหนดตารางเวลาตามข้อกำหนดนั้น
- ระบุวัตถุประสงค์เวลาการกู้คืน: การสร้างใหม่ (rebuild) อาจใช้เวลานานเท่าใด รวมถึงการนำเข้าฐานข้อมูลและการเปลี่ยนแปลง DNS ในการซ้อม
- ตรวจสอบว่าการยกเว้นที่ตั้งใจไว้สำหรับแคชไม่ได้ลบไฟล์อัปโหลด โวลุ่มของคอนเทนเนอร์ หรือการกำหนดค่าที่ได้รับการป้องกันไปด้วย
- ใช้เอกสารสำหรับเวอร์ชันหลักของ Borg ที่ติดตั้งไว้ รูปแบบ repository และคำสั่งไม่สามารถใช้แทนกันได้ในทุกเวอร์ชัน
เอกสารอย่างเป็นทางการ: Borg: การเข้ารหัส ความสอดคล้อง และการกู้คืน
ตรวจสอบข้อมูลที่จัดเก็บไว้รวมถึงเมทาดาทาของรีโพซิทอรี
การตรวจสอบที่เก็บข้อมูลเริ่มต้นของ Restic และการตรวจสอบแบบอ่านผ่านทำหน้าที่ต่างกัน กำหนดเวลาการตรวจสอบข้อมูลโดยคำนึงถึงแบนด์วิดท์และเวลาที่ใช้ ตัวอย่างตรวจสอบหนึ่งในห้าของไฟล์แพ็กที่กำหนดไว้ การตรวจสอบตามกำหนดเวลาครั้งต่อ ๆ ไปต้องใช้เศษส่วนที่เหลือเพื่อครอบคลุมที่เก็บข้อมูล ชุดย่อยที่เลือกแบบสุ่มไม่ได้ให้การรับประกันความครอบคลุมแบบเดียวกัน ทั้งสองการดำเนินการไม่ได้พิสูจน์ว่าแอปพลิเคชันสามารถเริ่มทำงานได้ด้วยข้อมูลที่กู้คืนมา
restic check --read-data-subset=1/5
restic snapshots --host example-host
restic restore latest --host example-host --target /srv/restore-drillเอกสารอย่างเป็นทางการ: restic: การตรวจสอบที่เก็บข้อมูลและการทวนสอบข้อมูล
แยกงานบำรุงรักษาให้พ้นจากความสามารถของไคลเอนต์ที่ถูกบุกรุก
ที่เก็บแบบ append-only ของ Borg รักษาข้อมูลเซกเมนต์ที่คอมมิตแล้ว แต่ไคลเอนต์ยังสามารถเปลี่ยนรายการอาร์ไคฟ์ที่มองเห็นได้ การกู้คืนและการบีบอัดต้องใช้ขั้นตอนการดูแลระบบที่ระบุไว้เป็นเอกสาร จำกัดข้อมูลรับรองการสำรองข้อมูลระยะไกลให้ใช้กับคำสั่งฝั่งเซิร์ฟเวอร์ของ Borg ไม่ใช่เชลล์หรือการเข้าสู่ระบบไฟล์ระบบแบบไม่จำกัดที่อาจข้ามการป้องกันเหล่านั้นได้ เมื่อใช้ restic ให้ตรวจสอบคำแนะนำ keep-within สำหรับการเก็บแบบ append-only ก่อนการบำรุงรักษาใด ๆ ที่อาจลบประวัติ ให้ตรวจสอบสุขภาพของที่เก็บและดูตัวอย่างการเลือกจากเครื่องที่เชื่อถือได้
- ตรวจสอบอายุของการสำรองข้อมูลสำเร็จครั้งล่าสุด การเติบโตของที่เก็บข้อมูล พื้นที่แคช และความจุว่างที่ปลายทางทั้งสอง
- หากการกู้คืนล้มเหลว ให้เก็บรักษารีโพซิทอรีต้นฉบับและบันทึกไว้ก่อนพยายามซ่อมแซมหรือล้างข้อมูล
- หากงานสำเร็จแต่ไฟล์ที่คาดไว้หายไป ให้ตรวจสอบเนื้อหาของไฟล์เก็บถาวรและรูปแบบการยกเว้นก่อนเปลี่ยนการเก็บรักษา
- จบการทดสอบด้วยการเปิดไฟล์และรันการตรวจสอบแอปพลิเคชันแบบแยกส่วน เก็บปลายทางการผลิตออกจากคำสั่งกู้คืน
เอกสารอย่างเป็นทางการ: Borg: การดำเนินการแบบเพิ่มอย่างเดียวและการบำรุงรักษา · restic: การเก็บรักษาและข้อพิจารณาแบบ append-only