สแนปช็อตคือการแสดง ณ จุดเวลาใดจุดหนึ่งโดยมีการป้องกันที่กำหนดจากการนำไปใช้ การวางแผนสำรองข้อมูลเพิ่มการเก็บรักษาอย่างตั้งใจ การแยกการเข้าถึง และการกู้คืนที่ทดสอบแล้ว สแนปช็อตบางรายการเป็นการสำรองข้อมูล บางรายการพึ่งพาพื้นที่จัดเก็บต้นฉบับ ถามว่าอะไรจะอยู่รอดจากการลบ การถูกบุกรุก หรือการสูญเสียสภาพแวดล้อมหลัก
อธิบายสำเนาก่อนตั้งชื่อ
คำว่าสแนปช็อตบอกคุณว่าจุดเวลาใดจุดหนึ่งได้รับการแสดงไว้ แต่ไม่ได้บอกว่าข้อมูลที่กู้คืนได้ถูกเก็บไว้ที่ใดหรือใครสามารถลบได้ สแนปช็อตของระบบไฟล์บนพื้นที่จัดเก็บต้นฉบับและสแนปช็อตบล็อกที่ผู้ให้บริการจัดการอาจมีขอบเขตความล้มเหลวที่ต่างกัน เริ่มจากวิธีการนำไปใช้แทนที่จะมองป้ายชื่อเป็นคำสัญญาสากล
AWS ระบุว่า EBS snapshots เป็นการสำรองข้อมูลแบบเพิ่มทีละส่วน ณ จุดเวลา ของวอลุ่ม นั่นคือการนำไปใช้เฉพาะ ไม่ใช่หลักฐานว่าตัวเลือกสแนปช็อตทุกแบบทำงานเหมือนกัน สำหรับบริการใดๆ ให้ถามว่าการกู้คืนขึ้นอยู่กับวอลุ่มต้นฉบับหรือไม่ สำเนาออกจากโดเมนความล้มเหลวหลักหรือไม่ และเกิดอะไรขึ้นเมื่อแหล่งต้นทางถูกลบ
เปรียบเทียบความล้มเหลวที่คุณคาดว่าจะอยู่รอด
การย้อนกลับอย่างรวดเร็วหลังการอัปเดตและการกู้คืนหลังการสูญเสียบัญชีเป็นปัญหาที่ต่างกัน สแนปช็อตภายในเครื่องอาจสะดวกสำหรับปัญหาแรก แต่ให้การแยกเพียงเล็กน้อยสำหรับปัญหาที่สอง สำเนาอิสระสามารถเพิ่มการป้องกันได้ แต่เฉพาะเมื่อเส้นทางการจัดเก็บ การเข้าถึง และการลบแยกจากเหตุการณ์ที่คุณเตรียมรับมืออย่างเพียงพอ
เขียนความล้มเหลวและผลลัพธ์ที่ต้องการลงไป การเปรียบเทียบเชิงตัวอย่างนี้เป็นเครื่องช่วยตัดสินใจ ไม่ใช่รายการฟีเจอร์ของ SwissOctet มันกระตุ้นให้ถามเกี่ยวกับสำเนาและการควบคุม แทนที่จะอ้างว่าเทคโนโลยีหนึ่งดีกว่าเสมอ ผลลัพธ์จริงขึ้นอยู่กับการกำหนดค่าและกระบวนการกู้คืนที่ผู้ให้บริการจัดทำเอกสารไว้
| สถานการณ์ | คำถามสำหรับสแนปช็อต | คำถามสำหรับการสำรองข้อมูล |
|---|---|---|
| การอัปเดตแอปพลิเคชันที่ผิดพลาด | ฉันกลับไปยังจุดที่ต้องการได้หรือไม่ | การกู้คืนที่ใช้งานได้ใช้เวลานานเท่าใด |
| ดิสก์หลักสูญหาย | สำเนาขึ้นอยู่กับดิสก์นั้นหรือไม่ | ฉันกู้คืนลงพื้นที่จัดเก็บใหม่ได้หรือไม่ |
| บัญชีผู้ดูแลระบบถูกบุกรุก | บัญชีนี้ลบสำเนาทุกชุดได้หรือไม่ | สิทธิ์การลบถูกแยกออกจากกันหรือไม่ |
| พบข้อผิดพลาดหลายสัปดาห์ต่อมา | จุดนั้นยังถูกเก็บรักษาไว้หรือไม่ | การเก็บรักษาครอบคลุมความล่าช้าในการค้นพบหรือไม่ |
ตรวจสอบความสอดคล้องของแอปพลิเคชัน
ดิสก์สามารถบันทึกไฟล์ในขณะที่แอปพลิเคชันยังเปลี่ยนแปลงไฟล์เหล่านั้นอยู่ ขึ้นอยู่กับซอฟต์แวร์และกระบวนการสแนปช็อต ผลลัพธ์อาจแสดงสถานะที่สอดคล้องกับการหยุดทำงานกะทันหัน มากกว่าสถานะแอปพลิเคชันที่ประสานกัน อย่าสันนิษฐานว่าไฟล์ที่อ่านได้หมายความว่าฐานข้อมูลและไฟล์อัปโหลดที่เกี่ยวข้องสอดคล้องกัน ให้ใช้วิธีการสำรองข้อมูลที่แอปพลิเคชันหรือฐานข้อมูลจัดทำเอกสารไว้
การออกแบบการเก็บถาวรต่อเนื่องของ PostgreSQL แสดงให้เห็นความแตกต่าง: การกู้คืนต้องมี base backup ที่เหมาะสมและลำดับไฟล์ write-ahead log ที่จำเป็นอย่างต่อเนื่อง การคัดลอกไดเรกทอรีอย่างไม่ระมัดระวังขณะฐานข้อมูลทำงานไม่ใช่ขั้นตอนที่เทียบเท่ากัน หากแอปพลิเคชันยังเก็บไฟล์ไว้นอกฐานข้อมูล ให้วางแผนว่าชุดข้อมูลทั้งสองจะถูกกู้คืนร่วมกันอย่างไร
มองการเก็บรักษาเป็นหน้าต่างการกู้คืน
การเก็บรักษาควรคำนึงถึงว่าข้อผิดพลาดอาจไม่ถูกสังเกตนานเท่าใด หน้าต่างสิบวันไม่ช่วยกับการลบโดยไม่ตั้งใจที่พบหลังจากหนึ่งเดือน การเก็บสำเนาทุกชุดไว้ตลอดไปสร้างปัญหาอีกแบบ: ต้นทุน การเปิดเผยข้อมูลอ่อนไหวที่เพิ่มขึ้น และนโยบายการลบที่ไม่ชัดเจน ให้เลือกการเก็บรักษาจากข้อกำหนดด้านการดำเนินงานและการจัดการข้อมูลที่เป็นรูปธรรม
ติดป้ายจุดกู้คืนด้วยบริบทที่มีประโยชน์ เช่น เวอร์ชันแอปพลิเคชันและเวลางานที่เสร็จสิ้น โดยไม่ฝังความลับไว้ เก็บประวัติให้เพียงพอที่จะแยกสถานะที่ดีออกจากสถานะที่เสียหาย ก่อนตัดข้อมูล ให้ยืนยันว่าระบบที่เลือกจัดการข้อมูลที่ใช้ร่วมกันหรือข้อมูลแบบเพิ่มทีละส่วนอย่างไร การลบจุดที่ติดป้ายอาจไม่เทียบเท่ากับการลบไฟล์เดี่ยวธรรมดา
แยกงานที่สำเร็จออกจากข้อมูลที่ตรวจสอบแล้ว
เครื่องมือสำรองข้อมูลที่รายงานความสำเร็จยืนยันว่ากระบวนการเสร็จสิ้นภายใต้กฎของมัน ไม่ได้พิสูจน์โดยอัตโนมัติว่าข้อมูลแอปพลิเคชันสำคัญทั้งหมดถูกเลือก ทุกไบต์ที่จัดเก็บยังคงสมบูรณ์ หรือเซิร์ฟเวอร์ใหม่สามารถใช้ผลลัพธ์ได้ สิ่งเหล่านั้นเป็นการตรวจสอบที่ต่างกัน ให้รวมสุขภาพของที่เก็บ การทบทวนการเลือก และการกู้คืนที่เป็นตัวแทนไว้ในแผนการดำเนินงาน
Restic ระบุความแตกต่างระหว่างการตรวจสอบที่เก็บเริ่มต้นกับการยืนยันที่อ่านข้อมูล pack ที่จัดเก็บไว้ การตรวจสอบที่อ่านข้อมูลเต็มรูปแบบอาจใช้เวลาและแบนด์วิดท์มากขึ้น ตัวอย่างนั้นทำให้ประเด็นการวางแผนเป็นรูปธรรม: ตัดสินใจว่าการยืนยันอ่านอะไรจริงและจัดงบงานไว้ ใช้เอกสารของเครื่องมือแทนการสันนิษฐานว่าทุกคำสั่งที่ชื่อว่า check มีความครอบคลุมเท่ากัน
ทดสอบการกู้คืนขนาดเล็กที่สมบูรณ์
ลองจินตนาการถึงสิ่งพิมพ์ที่มีฐานข้อมูล รูปภาพที่อัปโหลด และการกำหนดค่า กู้คืนทั้งสามอย่างเข้าสู่สภาพแวดล้อมทดสอบส่วนตัว จากนั้นเปิดบทความและตรวจสอบไฟล์แนบ ปิดการเชื่อมต่ออีเมล การชำระเงิน และการเผยแพร่ตามกำหนดระหว่างการฝึกซ้อม การทดสอบเฉพาะไฟล์ข้อความสุ่มจะพลาดความสัมพันธ์ที่ทำให้แอปพลิเคชันมีประโยชน์
วัดเวลาที่ต้องใช้และบันทึกว่าข้อมูลรับรอง เวอร์ชันแพ็กเกจ หรือ dependency ภายนอกใดขาดหายไป ตรวจสอบสิทธิ์บนไฟล์ที่กู้คืน ไม่ใช่แค่เนื้อหา การฝึกซ้อมกู้คืนมักค้นพบว่าข้อมูลมีอยู่ แต่คำแนะนำหรือการเข้าถึงที่จำเป็นในการใช้งานไม่เคยถูกเก็บไว้พร้อมกับแผนการดำเนินงาน
อ่านการสำรองข้อมูลเสริมเป็นบริการเฉพาะ
เมื่อกำหนดค่า SwissOctet ให้ดูตัวเลือกการสำรองข้อมูลและระยะเวลาการเก็บรักษาที่แน่นอนสำหรับตระกูลนั้น ถามว่าครอบคลุมวอลุ่มและข้อมูลแอปพลิเคชันใด การกู้คืนเป็นแบบบริการตนเองหรือไม่ และเกิดอะไรขึ้นเมื่อการกำหนดค่าหลักเปลี่ยนไป ป้ายชื่อตัวเลือกเพียงอย่างเดียวไม่ได้ยืนยันว่าเป็นสำเนาอิสระ ที่เก็บแบบเปลี่ยนแปลงไม่ได้ หรือจุดกู้คืนที่สอดคล้องกับฐานข้อมูล
ใช้สแนปช็อตในจุดที่เหมาะกับปริมาณงาน และเก็บกลยุทธ์การสำรองข้อมูลที่กว้างขึ้นสำหรับความล้มเหลวที่สแนปช็อตไม่ครอบคลุม บันทึกเส้นทางการกู้คืนอิสระสำหรับข้อมูลสำคัญ ปกป้องข้อมูลรับรองที่สามารถลบสำเนาได้ และทดสอบขั้นตอน ทางเลือกที่แข็งแกร่งที่สุดคือทางเลือกที่อยู่รอดในสถานการณ์ที่คุณกำหนดไว้ ไม่ใช่ทางเลือกที่มีชื่อให้ความมั่นใจมากที่สุด
รายการตรวจสอบปฏิบัติของคุณ
- ระบุว่าข้อมูลที่กู้คืนได้อยู่ที่ใด
- ระบุความล้มเหลวที่สำเนาต้องอยู่รอด
- ใช้วิธีการรักษาความสอดคล้องที่แอปพลิเคชันรองรับ
- เลือกการเก็บรักษาสำหรับช่วงการค้นพบ
- ปกป้องสิทธิ์การลบแยกต่างหาก
- กู้คืนแอปพลิเคชันที่สมบูรณ์ในสภาพแยก
รายละเอียดที่สำคัญ
สแนปช็อตไม่เคยเป็นการสำรองข้อมูลหรือไม่+
การนำสแนปช็อตไปใช้บางแบบเป็นการสำรองข้อมูล ความแตกต่างที่มีประโยชน์คือการพึ่งพาพื้นที่จัดเก็บ การเก็บรักษา รูปแบบการเข้าถึง และการกู้คืนที่ทดสอบแล้ว ไม่ใช่ป้ายชื่อเพียงอย่างเดียว
การตรวจสอบความสมบูรณ์ที่สำเร็จพิสูจน์ว่าแอปพลิเคชันจะทำงานได้หรือไม่+
มันพิสูจน์เฉพาะสิ่งที่การตรวจสอบนั้นครอบคลุม ให้ทดสอบการกู้คืนแอปพลิเคชัน การกำหนดค่า สิทธิ์ และความสัมพันธ์ของข้อมูลแยกต่างหาก
ควรเก็บการสำรองข้อมูลไว้บนเซิร์ฟเวอร์เดียวกันหรือไม่+
สำเนาบนเซิร์ฟเวอร์เดียวกันอาจช่วยกับความผิดพลาดเล็กน้อย แต่ใช้ความล้มเหลวสำคัญร่วมกัน ข้อมูลสำคัญต้องมีเส้นทางการกู้คืนนอกขอบเขตความล้มเหลวที่คุณตั้งใจจะอยู่รอด
ไปที่ต้นทาง
แหล่งอ้างอิงเหล่านี้สนับสนุนแนวคิดทางเทคนิคในคู่มือนี้ ปฏิบัติตามเอกสารปัจจุบันก่อนเปลี่ยนระบบโปรดักชัน
- Amazon EBS: สแนปช็อต docs.aws.amazon.com
- PostgreSQL: การเก็บถาวรต่อเนื่องและการกู้คืน ณ จุดเวลา www.postgresql.org
- Restic: การทำงานกับที่เก็บและการตรวจสอบความสมบูรณ์ restic.readthedocs.io
คำแนะนำด้านบรรณาธิการโดย SwissOctet ตัวอย่างมีไว้เพื่อประกอบ ข้อมูลจำเพาะของบริการ ตัวเลือกที่มี และเงื่อนไขตามสัญญาต้องได้รับการตรวจสอบแยกต่างหาก