Capacity Tier (หรือที่เราเรียกกันภายใน Vim - captir) ปรากฏขึ้นในยุคของ Veeam Backup and Replication 9.5 Update 4 ภายใต้ชื่อ Archive Tier แนวคิดเบื้องหลังคือการทำให้สามารถย้ายข้อมูลสำรองที่หลุดออกจากหน้าต่างการกู้คืนการดำเนินการไปยังพื้นที่จัดเก็บอ็อบเจ็กต์ได้ สิ่งนี้ช่วยล้างพื้นที่ดิสก์สำหรับผู้ใช้ที่มีพื้นที่น้อย และตัวเลือกนี้เรียกว่า Move Mode
ในการดำเนินการง่ายๆ (ตามที่ดูเหมือน) นี้ ก็เพียงพอที่จะปฏิบัติตามเงื่อนไขสองประการ: จุดทั้งหมดจากข้อมูลสำรองที่ถูกย้ายจะต้องอยู่นอกขอบเขตของหน้าต่างการกู้คืนการดำเนินการที่กล่าวถึงข้างต้น ซึ่งตั้งค่าไว้อย่างชัดเจนใน UI และประการที่สอง: ห่วงโซ่จะต้องอยู่ในสิ่งที่เรียกว่า "รูปแบบปิดผนึก" (ห่วงโซ่การสำรองข้อมูลแบบปิดผนึกหรือห่วงโซ่การสำรองข้อมูลที่ไม่ใช้งาน) นั่นคือไม่มีการเปลี่ยนแปลงเกิดขึ้นในห่วงโซ่นี้เมื่อเวลาผ่านไป
แต่ใน VBR v10 แนวคิดนี้ได้รับการเสริมด้วยฟังก์ชันใหม่ - โหมดการคัดลอก โหมดปิดผนึก และสิ่งที่มีชื่อที่ออกเสียงยาก ความไม่เปลี่ยนรูป ปรากฏขึ้น
นี่คือสิ่งที่น่าสนใจที่เราจะพูดถึงในวันนี้ อันดับแรกเกี่ยวกับวิธีการทำงานใน VBR9.5u4 จากนั้นเกี่ยวกับการเปลี่ยนแปลงในเวอร์ชันที่สิบ
และขอให้ผู้ชนะเลิศแห่งภาษาบริสุทธิ์ยกโทษให้ฉัน แต่มีคำศัพท์มากมายที่ไม่สามารถแปลได้
ดังนั้นที่นี่จะมีนิกายแองกลิซึมมากมาย
และกิ๊ฟมากมาย
และรูปภาพ
- โดยไม่รู้สึกเสียใจแม้แต่น้อย ผู้เขียนบทความ.
อย่างที่เป็นอยู่
เรามาเริ่มต้นด้วยการวิเคราะห์หน้าต่างการกู้คืนการปฏิบัติงานและการสำรองข้อมูลที่ปิดผนึก (หรือตามที่เรียกในเอกสารประกอบของ Inactive Backup Chain) หากไม่มีความเข้าใจก็จะไม่สามารถอธิบายเพิ่มเติมได้
ดังที่เราเห็นในภาพ เรามีห่วงโซ่การสำรองข้อมูลประเภทหนึ่งพร้อมบล็อกข้อมูล ซึ่งอยู่ที่ระดับประสิทธิภาพ SOBR ของพื้นที่เก็บข้อมูลที่เชื่อมต่อระดับความจุไว้ ระยะเวลาการสำรองข้อมูลการปฏิบัติงานของเราคือสามวัน
ดังนั้น .vbk ที่สร้างขึ้นในวันจันทร์จะปิดผนึก chain ก่อนหน้า ซึ่งหน้าต่างถูกตั้งค่าเป็นสามวัน และนั่นหมายความว่าคุณสามารถเริ่มขนส่งทุกสิ่งที่เก่ากว่าสามวันนี้ไปยังสนามยิงปืนได้อย่างปลอดภัย
แต่โซ่ที่ปิดผนึกนั้นหมายถึงอะไรกันแน่ และอะไรที่สามารถส่งไปยังระยะการยิงความจุในการอัพเดต 4 ได้?
สำหรับ Forward Inscaleal สัญญาณของการปิดผนึกโซ่คือการสร้างการสำรองข้อมูลเต็มรูปแบบใหม่ และไม่สำคัญว่าจะได้รับการสำรองข้อมูลเต็มรูปแบบนี้มาอย่างไร: พิจารณาทั้งการสำรองข้อมูลแบบเต็มสังเคราะห์และการสำรองข้อมูลเต็มรูปแบบที่ใช้งานอยู่
ในกรณีของ Reverse ไฟล์เหล่านี้คือไฟล์ทั้งหมดที่ไม่อยู่ในหน้าต่างการทำงาน
ในกรณีของการเพิ่มการส่งต่อด้วยการย้อนกลับ สิ่งเหล่านี้ล้วนเป็นการย้อนกลับและ .vbk หากมี .vbk อื่นในขอบเขตประสิทธิภาพ
ตอนนี้เรามาดูตัวเลือกในการทำงานกับ Backup Copy chains เฉพาะสินค้าที่อยู่ภายใต้การเก็บรักษาของ GFS เท่านั้นที่ถูกขนส่งที่นี่ เนื่องจากทุกสิ่งที่เก็บไว้ในกลุ่มสำเนาสำรองล่าสุดสามารถเปลี่ยนแปลงได้ไม่ทางใดก็ทางหนึ่ง
ทีนี้มาดูใต้ฝากระโปรงกัน ที่นั่นกระบวนการที่เรียกว่าภาวะขาดน้ำเกิดขึ้น โดยปล่อยไฟล์สำรองว่างไว้และลากบล็อกจากไฟล์เหล่านี้ไปยังระยะการยิงที่สามารถรองรับได้ เพื่อเพิ่มประสิทธิภาพกระบวนการนี้ จะใช้สิ่งที่เรียกว่าดัชนีการคายน้ำ ซึ่งช่วยให้คุณหลีกเลี่ยงการคัดลอกบล็อกที่ถูกคัดลอกไปยังระยะการยิงที่มีความจุแล้ว
มาดูกันว่าสิ่งนี้จะเป็นอย่างไรด้วยตัวอย่าง: สมมติว่าเรามี .vbk ที่ออกมาจากหน้าต่างธุรกรรมและเป็นของเครือข่ายที่ปิดสนิท ซึ่งหมายความว่าเรามีสิทธิ์ทุกประการที่จะย้ายมันไปยังระยะการยิงที่มีความจุ ในขณะที่ย้าย ไฟล์ข้อมูลเมตาจะถูกสร้างขึ้นในขีดความจุและบล็อกของไฟล์ที่ถ่ายโอน ไฟล์ข้อมูลเมตาระดับลิงก์จะอธิบายว่าไฟล์ของเราประกอบด้วยบล็อกใดบ้าง ในกรณีในภาพ ไฟล์แรกของเราประกอบด้วยบล็อก a, b, c และข้อมูลเมตามีลิงก์ไปยังบล็อกเหล่านี้ เมื่อเรามีไฟล์ .vbk ไฟล์ที่สอง ซึ่งพร้อมที่จะย้ายและประกอบด้วยบล็อก a, b และ d เราจะวิเคราะห์ดัชนีการคายน้ำ และเข้าใจว่าต้องถ่ายโอนเฉพาะบล็อก d เท่านั้น และไฟล์ข้อมูลเมตาของมันจะมีลิงก์ไปยังบล็อกก่อนหน้าสองบล็อกและบล็อกใหม่หนึ่งบล็อก
ดังนั้น กระบวนการในการเติมข้อมูลลงในช่องว่างเหล่านี้กลับเรียกว่าการคืนสภาพ (rehydration) บริษัทใช้ดัชนีการคืนสภาพเป็นของตัวเองอยู่แล้ว โดยอิงตามไฟล์ .vbk ที่เก่าที่สุดตามขอบเขตประสิทธิภาพในเครื่อง นั่นคือ หากผู้ใช้ต้องการส่งคืนไฟล์จากระยะการยิงความจุ ขั้นแรกเราจะสร้างดัชนีของบล็อกของการสำรองข้อมูลเต็มรูปแบบที่เก่าที่สุด และถ่ายโอนเฉพาะบล็อกที่หายไปจากแกลเลอรีการยิงความจุ ในกรณีที่แสดงในภาพ เพื่อที่จะเติมน้ำให้กับ FullBackup1.vbk ตามดัชนีการเติมน้ำ เราต้องการเพียงบล็อก C เท่านั้น ซึ่งเราใช้จากระยะการยิงที่มีความจุ หากออบเจ็กต์คลาวด์จัดเก็บข้อมูลทำหน้าที่เป็นระยะการยิงความจุ สิ่งนี้จะช่วยให้คุณประหยัดเงินจำนวนมหาศาล
ที่นี่อาจดูเหมือนว่าเทคโนโลยีนี้เหมือนกับเทคโนโลยีที่ใช้ใน WAN Accelerators แต่ดูเหมือนว่าจะเป็นเช่นนั้นเท่านั้น ในตัวเร่งความเร็ว การขจัดข้อมูลซ้ำซ้อนเป็นแบบสากล ในที่นี้ การขจัดข้อมูลซ้ำซ้อนในเครื่องจะใช้ภายในแต่ละไฟล์ที่ออฟเซ็ตเฉพาะ สิ่งนี้เกิดขึ้นเนื่องจากความแตกต่างในงานที่ได้รับการแก้ไข: ที่นี่เราจำเป็นต้องคัดลอกไฟล์สำรองข้อมูลขนาดใหญ่เต็มรูปแบบ และจากการวิจัยของเรา แม้ว่าจะใช้เวลาระหว่างกันเป็นเวลานานก็ตาม อัลกอริธึมการขจัดข้อมูลซ้ำซ้อนนี้ให้ผลลัพธ์ที่ดีที่สุด
แต่ดัชนีเพิ่มเติมสำหรับเทพเจ้าแห่งดัชนี! นอกจากนี้ยังมีดัชนีสำหรับการกู้คืนข้อมูล! เมื่อเราเริ่มกู้คืนเครื่องที่อยู่ในขีดความจุ เราจะอ่านเฉพาะบล็อกข้อมูลเฉพาะที่ไม่อยู่ในเส้นประประสิทธิภาพเท่านั้น
มันเกิดขึ้นได้อย่างไร?
นั่นคือทั้งหมดสำหรับส่วนเบื้องต้น มีรายละเอียดค่อนข้างมาก แต่ตามที่กล่าวไว้ข้างต้น หากไม่มีรายละเอียดเหล่านี้ ก็จะไม่สามารถอธิบายวิธีการทำงานของฟังก์ชันใหม่ได้ ดังนั้นเพื่อไม่ให้เป็นการเสียเวลา เรามาต่อกันที่เรื่องแรกกันดีกว่า
โหมดคัดลอก
ขึ้นอยู่กับเทคโนโลยีที่มีอยู่เป็นส่วนใหญ่ แต่มีตรรกะการใช้งานที่แตกต่างไปจากเดิมอย่างสิ้นเชิง
วัตถุประสงค์ของโหมดนี้คือเพื่อให้แน่ใจว่าข้อมูลทั้งหมดที่อยู่ในขอบเขตท้องถิ่นมีสำเนาอยู่ในขีดความจุ
หากคุณเปรียบเทียบโหมดย้ายและคัดลอกโดยตรง จะมีลักษณะดังนี้:
- สามารถเคลื่อนย้ายได้เฉพาะโซ่ที่ปิดผนึกเท่านั้น ในกรณีของโหมดคัดลอก ทุกอย่างจะถูกถ่ายโอนอย่างแน่นอน ไม่ว่าจะเกิดอะไรขึ้นในงานสำรองข้อมูลก็ตาม
- การย้ายจะถูกทริกเกอร์เมื่อไฟล์เกินขอบเขตของหน้าต่างการสำรองข้อมูลที่ดำเนินการ และการคัดลอกจะถูกทริกเกอร์ทันทีที่ไฟล์สำรองข้อมูลปรากฏขึ้น
- การตรวจสอบข้อมูลใหม่สำหรับการคัดลอกเกิดขึ้นอย่างต่อเนื่อง และสำหรับการย้ายข้อมูลจะถูกทริกเกอร์ทุกๆ 4 ชั่วโมง
ในการพิจารณาโหมดใหม่ ฉันขอเสนอให้เปลี่ยนจากตัวอย่างง่ายๆ ไปเป็นตัวอย่างที่ซับซ้อน
ในกรณีที่พบบ่อยที่สุด เราเพียงแค่มีไฟล์ใหม่เพิ่มขึ้น และเราก็คัดลอกไฟล์เหล่านั้นไปยังระยะการยิงที่สามารถรองรับได้ ไม่ว่าจะใช้โหมดใดในงานสำรองข้อมูล ไม่ว่าจะเป็นของส่วนที่ปิดผนึกของห่วงโซ่หรือไม่ก็ตาม ไม่ว่าหน้าต่างการทำงานของเราจะหมดอายุหรือไม่ก็ตาม พวกเขาแค่หยิบมันมาและคัดลอกมัน
กระบวนการเบื้องหลังนี้ยังคงเป็นภาวะขาดน้ำตามที่อธิบายไว้ข้างต้น ในโหมดคัดลอก ยังช่วยให้แน่ใจว่าเราไม่ได้คัดลอกบล็อกที่มีอยู่ในที่เก็บข้อมูลของเราแล้ว ข้อแตกต่างเพียงอย่างเดียวคือหากในโหมดภาพยนตร์เราแทนที่ไฟล์จริงด้วยไฟล์จำลอง เราจะไม่แตะต้องมันแต่อย่างใด และปล่อยให้ทุกอย่างเหมือนเดิม ไม่เช่นนั้นก็จะเป็นดัชนีภาวะขาดน้ำเหมือนกันทุกประการ ซึ่งจะพยายามประหยัดเงินและเวลาของคุณอย่างระมัดระวัง
คำถามเกิดขึ้น - หากคุณดูที่ UI ก็มีโอกาสที่จะเลือกทั้งสองตัวเลือกพร้อมกัน โหมดรวมดังกล่าวจะทำงานอย่างไร
ลองคิดดู
จุดเริ่มต้นเป็นมาตรฐาน: ไฟล์สำรองจะถูกสร้างขึ้นและคัดลอกทันที ส่วนเพิ่มจะถูกสร้างขึ้นและคัดลอกไปด้วย สิ่งนี้จะเกิดขึ้นจนกระทั่งเมื่อเราตระหนักว่าไฟล์ได้ออกจากหน้าต่างการทำงานของเราไปแล้วและมีห่วงโซ่ที่ปิดสนิทปรากฏขึ้น ณ จุดนี้ เราทำการดำเนินการขจัดน้ำออกและแทนที่ไฟล์เหล่านี้ด้วยไฟล์จำลอง แน่นอนว่าเราจะไม่คัดลอกอะไรไปที่ระยะการยิงความจุอีกต่อไป
ตรรกะที่น่าสนใจทั้งหมดนี้มีหน้าที่รับผิดชอบเพียงช่องทำเครื่องหมายเดียวในอินเทอร์เฟซ: คัดลอกข้อมูลสำรองไปยังที่เก็บข้อมูลอ็อบเจ็กต์ทันทีที่สร้างขึ้น
เหตุใดเราจึงต้องมีโหมดถ่ายสำเนานี้
เป็นการดีกว่าถ้าเปลี่ยนคำถามใหม่ด้วยวิธีนี้: ความเสี่ยงอะไรบ้างที่ได้รับการปกป้องด้วยความช่วยเหลือ? มันช่วยเราแก้ปัญหาอะไรได้บ้าง?
คำตอบนั้นชัดเจน: แน่นอนว่านี่คือการกู้คืนข้อมูล หากเรามีสำเนาข้อมูลภายในเครื่องที่สมบูรณ์บนพื้นที่จัดเก็บอ็อบเจ็กต์ ไม่ว่าจะเกิดอะไรขึ้นกับผลิตภัณฑ์ของเรา เราก็สามารถกู้คืนข้อมูลจากไฟล์ที่อยู่ใน Amazon แบบมีเงื่อนไขได้เสมอ
มาดูสถานการณ์ที่เป็นไปได้ตั้งแต่แบบง่ายที่สุดไปจนถึงแบบที่ซับซ้อนกว่ากัน
ความโชคร้ายที่ง่ายที่สุดที่อาจเกิดขึ้นกับหัวของเราคือการไม่สามารถเข้าถึงไฟล์ใดไฟล์หนึ่งในห่วงโซ่การสำรองข้อมูล
เรื่องที่น่าเศร้ากว่านั้นคือขอบเขตหนึ่งของพื้นที่เก็บข้อมูล SOBR ของเราเสียหาย
จะยิ่งแย่ลงไปอีกเมื่อไม่สามารถเข้าถึงที่เก็บ SOBR ทั้งหมดได้ แต่ระยะการยิงยังใช้งานได้
และทุกอย่างแย่มาก - นี่คือตอนที่เซิร์ฟเวอร์สำรองเสียและความปรารถนาแรกของคุณคือพยายามวิ่งไปที่ชายแดนแคนาดาภายในสิบนาที
ตอนนี้เรามาดูแต่ละสถานการณ์แยกกัน
เมื่อเราสูญเสียไฟล์สำรองข้อมูลหนึ่งไฟล์ (และหลายไฟล์) สิ่งที่เราต้องทำคือเริ่มกระบวนการสแกนพื้นที่เก็บข้อมูลอีกครั้ง และไฟล์ที่สูญหายจะถูกแทนที่ด้วยไฟล์จำลอง และเมื่อใช้กระบวนการคืนสภาพ (ซึ่งมีการกล่าวถึงในตอนต้นของบทความ) ผู้ใช้จะสามารถดาวน์โหลดข้อมูลจากระยะการยิงความจุไปยังที่จัดเก็บในตัวเครื่องได้
ตอนนี้สถานการณ์มีความซับซ้อนมากขึ้น สมมติว่า SOBR ของเราประกอบด้วยส่วนขยายสองส่วนที่ทำงานในโหมดประสิทธิภาพ ซึ่งหมายความว่า .vbk และ .vib ของเราจะกระจายอยู่ในเลเยอร์ที่ค่อนข้างไม่สม่ำเสมอ และเมื่อถึงจุดหนึ่ง ขอบเขตหนึ่งจะไม่พร้อมใช้งาน และผู้ใช้จำเป็นต้องกู้คืนเครื่องอย่างเร่งด่วน ซึ่งส่วนหนึ่งของข้อมูลอยู่ในขอบเขตนี้อย่างแม่นยำ
ผู้ใช้เปิดตัววิซาร์ดการกู้คืน เลือกจุดที่เขาต้องการกู้คืน และในขณะที่ทำงาน ตัวช่วยสร้างก็ตระหนักว่าเขาไม่มีข้อมูลทั้งหมดที่จำเป็นสำหรับการกู้คืนในเครื่อง ดังนั้นจึงต้องดาวน์โหลดจากความจุที่ถ่าย แกลเลอรี่ ในเวลาเดียวกัน บล็อกที่ยังคงอยู่ในที่จัดเก็บในตัวเครื่องจะไม่ถูกดาวน์โหลดจากคลาวด์ ความรุ่งโรจน์ของดัชนีการคืนค่า (ใช่มีการกล่าวถึงในตอนต้นของบทความด้วย)
ชนิดย่อยของกรณีนี้คือ พื้นที่เก็บข้อมูล SOBR ทั้งหมดไม่สามารถเข้าถึงได้ ในกรณีนี้ เราไม่มีอะไรจะคัดลอกจากที่จัดเก็บในตัวเครื่อง และบล็อกทั้งหมดจะถูกดาวน์โหลดจากคลาวด์
และสถานการณ์ที่น่าสนใจที่สุดคือเซิร์ฟเวอร์สำรองเสียชีวิต มีสองตัวเลือกที่นี่: ผู้ดูแลระบบเก่งมากและได้ทำการสำรองข้อมูลการกำหนดค่า และผู้ดูแลระบบเองก็เป็นพินอคคิโอที่ชั่วร้ายและไม่ได้ทำการสำรองข้อมูลการกำหนดค่า
ในกรณีแรก เพียงแค่ปรับใช้การติดตั้ง VBR ใหม่ทั้งหมดที่ไหนสักแห่งและกู้คืนฐานข้อมูลจากการสำรองข้อมูลโดยใช้วิธีมาตรฐานก็เพียงพอแล้ว เมื่อสิ้นสุดกระบวนการนี้ ทุกอย่างจะกลับสู่สภาวะปกติ หรือจะถูกกู้คืนตามสถานการณ์ใดสถานการณ์หนึ่งข้างต้น
แต่ถ้าผู้ดูแลระบบเป็นศัตรูของเขาเองหรือการสำรองข้อมูลการกำหนดค่าประสบความล้มเหลวครั้งใหญ่แม้ที่นี่เราจะไม่ปล่อยให้เขาตกอยู่ภายใต้ความเมตตาแห่งโชคชะตา ในกรณีนี้ เราได้แนะนำขั้นตอนใหม่ที่เรียกว่า Import Object Storage ช่วยให้คุณสามารถข้ามกระบวนการสร้างพื้นที่เก็บข้อมูล SOBR ขึ้นใหม่ด้วยตนเอง และแนบระยะการยิงความจุเข้ากับพื้นที่นั้นด้วยการสแกนซ้ำในภายหลัง และเพียงเพิ่มออบเจ็กต์พื้นที่จัดเก็บข้อมูลลงในอินเทอร์เฟซ Vim และเรียกใช้ขั้นตอนการนำเข้าพื้นที่เก็บข้อมูลที่เก็บข้อมูล สิ่งเดียวที่สามารถขวางทางระหว่างคุณและข้อมูลสำรองของคุณได้คือการร้องขอให้ป้อนรหัสผ่านหากข้อมูลสำรองของคุณถูกเข้ารหัส
นี่อาจเป็นทั้งหมดที่เกี่ยวกับโหมดการคัดลอกและเราดำเนินการต่อไป
โหมดปิดผนึก
แนวคิดหลักคือการสำรองข้อมูลใหม่ไม่สามารถปรากฏบนขอบเขต SOBR ที่เลือกของที่เก็บ ก่อนเวอร์ชัน 10 เรามีเพียงโหมดการบำรุงรักษาเท่านั้น เมื่อการทำงานใดๆ กับพื้นที่เก็บข้อมูลถูกห้ามโดยสิ้นเชิง โหมดฮาร์ดคอร์ประเภทหนึ่งสำหรับการปิดพื้นที่จัดเก็บข้อมูล โดยมีเพียงปุ่ม Evacuate เท่านั้นที่ใช้งานได้ ซึ่งจะส่งการสำรองข้อมูลไปยังขอบเขตอื่นแบบครั้งเดียว
และโหมดปิดผนึกเป็นตัวเลือกแบบ "นุ่มนวล": เราห้ามการสร้างการสำรองข้อมูลใหม่และค่อยๆ ลบข้อมูลเก่าตามการเก็บรักษาที่เลือก แต่ในกระบวนการนี้ เราจะไม่สูญเสียความสามารถในการกู้คืนจากจุดที่เก็บไว้ สิ่งที่มีประโยชน์มากเมื่อเรามีฮาร์ดแวร์ชิ้นหนึ่งที่ใกล้หมดอายุการใช้งานและจำเป็นต้องเปลี่ยนใหม่ หรือเราแค่ต้องปล่อยมันไว้สำหรับสิ่งที่สำคัญกว่า แต่ไม่มีที่ไหนที่จะรับและย้ายทุกอย่างในคราวเดียว หรือลบไม่ได้
ดังนั้นหลักการดำเนินการจึงค่อนข้างง่าย: จำเป็นต้องห้ามการดำเนินการเขียนทั้งหมด (การปรากฏตัวของข้อมูลใหม่) ปล่อยให้อ่าน (การกู้คืน) และการลบ (การเก็บรักษา)
สามารถใช้ทั้งสองโหมดพร้อมกันได้ แต่โปรดจำไว้ว่าการบำรุงรักษาจะมีลำดับความสำคัญสูงกว่า
เป็นตัวอย่าง พิจารณา SOBR ที่ประกอบด้วยสองขอบเขต สมมติว่าในช่วงสี่วันแรกเราได้สร้างการสำรองข้อมูลในโหมด Forward Forever Increamental แล้วจึงปิดผนึกขอบเขต ซึ่งนำไปสู่ความจริงที่ว่าเราเริ่มต้นการสร้างข้อมูลใหม่ที่ใช้งานเต็มรูปแบบในขอบเขตที่สองที่มีอยู่ หากการเก็บรักษาของเราเป็นสี่ เมื่อห่วงโซ่ทั้งหมดที่อยู่ในขอบเขตที่ปิดผนึกนั้นเกินขอบเขต มันจะถูกลบออกด้วยมโนธรรมที่ชัดเจน
มีบางสถานการณ์ที่การลบเกิดขึ้นเร็วกว่านั้น ตัวอย่างเช่น นี่เป็นการส่งต่อแบบเพิ่มทีละงวด หากเราสร้างการสำรองข้อมูลเต็มรูปแบบในสองวันแรก และในวันพฤหัสบดี เราตัดสินใจที่จะปิดผนึกพื้นที่เก็บข้อมูล จากนั้นในวันศุกร์ เมื่อมีการสร้างการสำรองข้อมูลใหม่ ไฟล์สำหรับวันจันทร์จะถูกลบเนื่องจาก ไม่มีการพึ่งพาจนถึงจุดนี้ และประเด็นนั้นไม่ได้ขึ้นอยู่กับใครเลย จากนั้นเรารอจนกว่าจะมีการสร้างสี่จุดในขอบเขตที่มีอยู่ และลบสามจุดที่เหลือ ซึ่งไม่สามารถลบแยกจากกันได้
สิ่งต่างๆ จะง่ายขึ้นด้วยการ Reverse Increamental ในนั้นคะแนนที่เก่าแก่ที่สุดไม่ได้ขึ้นอยู่กับสิ่งใดและสามารถลบได้อย่างปลอดภัย ดังนั้น ทันทีที่มีการสร้าง .vbk ใหม่ในระดับใหม่ .vrbs เก่าจะถูกลบทีละรายการ
อย่างไรก็ตาม ทำไมเราถึงสร้าง .vbk ใหม่ทุกครั้ง: หากเราไม่ได้สร้างมันขึ้นมา แต่ยังคงเพิ่มจำนวนแบบเก่าต่อไป .vbk แบบเก่าก็จะค้างเป็นเวลานานอย่างไม่สิ้นสุดในโหมดใดๆ เพื่อป้องกันการถูกลบ ดังนั้นจึงตัดสินใจว่าทันทีที่ปิดผนึกขอบเขต เราจะสร้างการสำรองข้อมูลเต็มรูปแบบในขอบเขตฟรี
สิ่งต่าง ๆ มีความซับซ้อนมากขึ้นด้วยระยะการยิงที่มีความจุ
ก่อนอื่น มาดูโหมดการคัดลอกกันก่อน สมมติว่าเรากำลังสร้างการสำรองข้อมูลเป็นเวลาสี่วัน จากนั้นระยะการยิงก็ถูกปิดผนึก เราจะไม่ลบสิ่งใดๆ แต่อดทนต่อการเก็บรักษาอย่างถ่อมตัว หลังจากนั้นเราจะลบข้อมูลออกจากระยะการยิงที่สามารถรองรับได้
สิ่งเดียวกันนี้เกิดขึ้นโดยประมาณในโหมดการย้าย - เรารอการรีทัช ลบอันเก่าในที่จัดเก็บในเครื่อง และลบอันที่เก็บไว้ในที่จัดเก็บออบเจ็กต์
ตัวอย่างที่น่าสนใจกับการส่งต่อแบบเพิ่มหน่วยตลอดไป เราติดตั้งการเก็บรักษาไว้ที่สามจุด และเริ่มสำรองข้อมูลในวันจันทร์ ซึ่งจะถูกคัดลอกไปยังระบบคลาวด์เป็นประจำ หลังจากการปิดผนึกที่จัดเก็บข้อมูลแล้ว การสำรองข้อมูลจะถูกสร้างขึ้นต่อไปโดยคงไว้ XNUMX จุด แต่ข้อมูลที่จัดเก็บไว้ในขีดความจุยังคงขึ้นอยู่กับและไม่สามารถลบได้ ดังนั้นเราจึงรอจนถึงวันพฤหัสบดี เมื่อ .vbk ของเราไปไกลกว่าการเก็บรักษา และหลังจากนั้น เราก็จะลบเชนที่บันทึกไว้ทั้งหมดอย่างใจเย็น
และข้อจำกัดความรับผิดชอบเล็กน้อย: ตัวอย่างทั้งหมดแสดงไว้ในเครื่องเดียว หากคุณมีหลายรายการในการสำรองข้อมูล การรีทัชจะแตกต่างกันไปขึ้นอยู่กับว่า Active Full ถูกสร้างขึ้นหรือไม่
โดยพื้นฐานแล้วทั้งหมดที่มีให้ มาดูฟีเจอร์ที่ฮาร์ดคอร์ที่สุดกันดีกว่า -
ไม่เปลี่ยนรูป
เช่นเดียวกับประเด็นก่อนหน้า สิ่งแรกคือฟังก์ชันนี้จะแก้ปัญหาอะไร ทันทีที่เราอัปโหลดข้อมูลสำรองของเราไปที่ใดที่หนึ่งเพื่อจัดเก็บข้อมูล มีความปรารถนาอย่างแรงกล้าที่จะรับประกันความปลอดภัย กล่าวคือ ห้ามมิให้มีการลบข้อมูลและแก้ไขใด ๆ ในระหว่างการเก็บรักษาที่กำหนด รวมถึงผู้ดูแลระบบ รวมถึงภายใต้บัญชีรูทของพวกเขาด้วย สิ่งนี้จะช่วยให้คุณสามารถปกป้องพวกเขาจากความเสียหายโดยไม่ได้ตั้งใจหรือโดยเจตนา ใครก็ตามที่ทำงานกับ AWS อาจเคยเจอคุณสมบัติที่คล้ายกันที่เรียกว่า Object Lock
ทีนี้มาดูโหมดโดยทั่วไปแล้วเจาะลึกรายละเอียด ในตัวอย่างของเรา ความไม่เปลี่ยนรูปจะถูกเปิดใช้งานสำหรับระยะการยิงที่มีความจุของเราโดยมีการเก็บรักษาไว้สี่วัน และเปิดใช้งานโหมดคัดลอกในการสำรองข้อมูล
ความไม่เปลี่ยนรูปไม่โต้ตอบกับการเก็บรักษาทั่วไป แต่อย่างใด ตัวอย่างเช่น มันไม่ได้เพิ่มคะแนนพิเศษหรืออะไรทำนองนั้น เป็นเพียงว่าบุคคลไม่สามารถลบไฟล์สำรองได้ภายในสี่วัน หากคุณสำรองข้อมูลในวันจันทร์ คุณจะสามารถลบไฟล์ได้ในวันศุกร์เท่านั้น
แนวคิดเรื่องภาวะขาดน้ำ ดัชนี และข้อมูลเมตาที่อธิบายไว้ก่อนหน้านี้ทั้งหมดยังคงทำงานเหมือนเดิมทุกประการ แต่มีเงื่อนไขเดียว - บล็อกนี้ไม่เพียงถูกตั้งค่าสำหรับข้อมูลเท่านั้น แต่ยังรวมถึงข้อมูลเมตาด้วย สิ่งนี้จะเกิดขึ้นในกรณีที่ผู้โจมตีที่มีไหวพริบตัดสินใจลบฐานข้อมูลเมตาดาต้าของเรา และเพื่อป้องกันไม่ให้บล็อกข้อมูลกลายเป็นไบนารี่ที่ไร้ประโยชน์
ตอนนี้เป็นเวลาที่ดีที่จะอธิบายเทคโนโลยีการสร้างบล็อกของเรา หรือการสร้างบล็อก ในการทำเช่นนี้ให้พิจารณาสถานการณ์ที่นำไปสู่การปรากฏตัว
ลองใช้มาตราส่วนเวลาหกวัน และต่ำกว่านี้เราจะทำเครื่องหมายเวลาที่คาดว่าจะหมดอายุของการเปลี่ยนแปลงไม่ได้ ในวันแรกเราจะสร้างไฟล์ที่ประกอบด้วยบล็อกข้อมูล a และข้อมูลเมตาของมัน หากตั้งค่าความไม่เปลี่ยนรูปเป็นสามวัน ก็สมเหตุสมผลที่จะถือว่าในวันที่สี่ข้อมูลจะถูกปลดล็อคและลบ ในวันที่สองเราจะเพิ่มไฟล์ใหม่ 2 ซึ่งประกอบด้วยบล็อก b ด้วยการตั้งค่าเดียวกัน การบล็อกยังคงต้องถูกลบออกในวันที่สี่ แต่ในวันที่สามมีเรื่องเลวร้ายเกิดขึ้น - ไฟล์ File3 ถูกสร้างขึ้นซึ่งประกอบด้วยบล็อก d ใหม่และลิงก์ไปยังบล็อก a เก่า ซึ่งหมายความว่าสำหรับบล็อกและแฟล็กความไม่เปลี่ยนรูปจะต้องรีเซ็ตเป็นวันที่ใหม่ ซึ่งจะถูกเลื่อนไปเป็นวันที่หก และนี่คือปัญหาที่เกิดขึ้น - ในการสำรองข้อมูลจริงมีบล็อกดังกล่าวจำนวนมาก และเพื่อที่จะขยายระยะเวลาที่ไม่สามารถเปลี่ยนแปลงได้ คุณจะต้องส่งคำขอจำนวนมากในแต่ละครั้ง และในความเป็นจริง นี่จะเป็นกระบวนการรายวันที่แทบจะไม่มีที่สิ้นสุด เนื่องจากมีโอกาสสูงที่เราจะพบบล็อกที่กรองข้อมูลซ้ำซ้อนจำนวนมากในแต่ละสำเนา คำขอจำนวนมากจากผู้ให้บริการพื้นที่เก็บข้อมูลอ็อบเจ็กต์หมายถึงอะไร ขวา! บิลใหญ่ตอนสิ้นเดือน
และเพื่อไม่ให้ลูกค้าคนโปรดของคุณถูกเปิดเผยด้วยเงินจำนวนมาก กลไกการสร้างบล็อกจึงถูกคิดค้นขึ้น นี่เป็นช่วงเวลาเพิ่มเติมที่เราเพิ่มให้กับช่วงเวลาที่ไม่สามารถเปลี่ยนแปลงได้ที่ตั้งไว้ ในตัวอย่างด้านล่าง ช่วงเวลานี้คือสองวัน แต่นี่เป็นเพียงตัวอย่างเท่านั้น ในความเป็นจริง พวกเขาใช้สูตรของตัวเอง ซึ่งให้เวลาเพิ่มอีกประมาณสิบวันในช่วงล็อครายเดือน
เรามาพิจารณาสถานการณ์เดียวกันต่อไป แต่ด้วยการสร้างบล็อก ในวันแรกเราสร้าง file1 จากบล็อก a และข้อมูลเมตา เราเพิ่มระยะเวลาการสร้างและความไม่เปลี่ยนรูป - ซึ่งหมายความว่าโอกาสในการลบไฟล์จะเป็นวันที่หก หากในวันที่สองเราสร้าง File2 ซึ่งประกอบด้วยบล็อก b และลิงก์สำหรับบล็อก a จะไม่มีอะไรเกิดขึ้นกับวันที่คาดว่าจะลบ เธอยืนเหมือนที่เธอทำในวันที่หก ดังนั้นเราจึงพยายามประหยัดเงินตามจำนวนคำขอ สถานการณ์เดียวที่สามารถเลื่อนกำหนดเวลาได้คือหากระยะเวลาการสร้างหมดอายุแล้ว นั่นคือหากในวันที่สาม File3 ใหม่มีลิงก์สำหรับบล็อก a รุ่นที่ 2 จะถูกเพิ่มเนื่องจาก Gen1 หมดอายุแล้ว และวันที่คาดว่าจะลบบล็อก a จะเปลี่ยนเป็นวันที่แปด สิ่งนี้ช่วยให้เราสามารถลดจำนวนคำขอเพื่อขยายอายุการใช้งานของบล็อกที่กรองข้อมูลซ้ำออกได้อย่างมาก ซึ่งช่วยประหยัดเงินของลูกค้าได้มาก
เทคโนโลยีนี้มีให้สำหรับผู้ใช้ฮาร์ดแวร์ที่เข้ากันได้กับ S3 และ S3 ซึ่งผู้ผลิตรับประกันว่าการใช้งานของพวกเขาไม่แตกต่างจากของ Amazon ดังนั้นคำตอบสำหรับคำถามที่ถูกต้องว่าทำไม Azure จึงไม่รองรับ - พวกมันมีคุณสมบัติที่คล้ายกัน แต่ใช้งานได้ในระดับคอนเทนเนอร์ ไม่ใช่แต่ละวัตถุ อย่างไรก็ตาม Amazon เองก็มีการล็อกออบเจ็กต์ในสองโหมด: การปฏิบัติตามข้อกำหนดและการกำกับดูแล ในกรณีที่สอง ยังคงมีความเป็นไปได้ที่ผู้ดูแลระบบที่ยิ่งใหญ่ที่สุดที่อยู่เหนือผู้ดูแลระบบและรูทที่อยู่เหนือรูท แม้ว่าจะล็อกอ็อบเจ็กต์แล้ว จะยังคงลบข้อมูลอยู่ ในกรณีของการปฏิบัติตามกฎระเบียบ ทุกอย่างจะถูกตอกย้ำอย่างแน่นหนาและไม่มีใครสามารถลบข้อมูลสำรองได้ แม้แต่ผู้ดูแลระบบของ Amazon (ตามแถลงการณ์อย่างเป็นทางการ) นี่คือโหมดที่เราสนับสนุน
และตามปกติแล้วจะมีลิงก์ที่มีประโยชน์บางส่วน:
- เกี่ยวกับ ในทุกรายละเอียด
- ข้อมูลทั้งหมดเกี่ยวกับ อย่างดีที่สุด
- О ในรายละเอียด
ที่มา: will.com