# เปลี่ยน RPO และ RTO ให้เป็นงบประมาณการกู้คืนที่คุณทดสอบได้ | SwissOctet Insights

https://swissoctet.com/th/insights/rpo-rto-recovery-budget/

SwissOctet / ข้อมูลเชิงลึก / การดำเนินงานวันที่สอง การดำเนินงานวันที่สอง ประยุกต์ · อ่าน 4 นาที

เปลี่ยน RPO และ RTO เป็นงบประมาณการกู้คืนที่ทดสอบได้

แปลงการสูญเสียข้อมูลและการหยุดชะงักที่ยอมรับได้เป็นแผนการกู้คืนที่จับเวลาได้ พร้อมการพึ่งพา ความสามารถในการกู้คืน และการฝึกซ้อมที่วัดผลได้

โดย SwissOctet Editorial บันทึกคู่มือ คัดลอกลิงก์

ในหน้านี้ 01 เริ่มต้นด้วยบริการที่ผู้คนใช้งานได้ 02 แยกนาฬิกาสองเรือนออกจากกัน 03 จัดงบประมาณให้ทุกขั้นตอนของการกู้คืน 04 ตรวจสอบช่วงเวลาข้อมูลสูญหายจริง 05 เลือกกลยุทธ์ภายในงบประมาณ 06 ฝึกซ้อมโดยไม่เป็นอันตรายต่อระบบโปรดักชัน 07 ทำให้แผนใช้งานได้ระหว่างเกิดความล้มเหลว รายการตรวจสอบปฏิบัติของคุณ แหล่งอ้างอิงและอ่านเพิ่มเติม กลับไปยังคลัง คำตอบตรงประเด็น RPO อธิบายช่วงเวลาข้อมูลสูญหายที่คุณยอมรับได้ ส่วน RTO อธิบายระยะเวลาหยุดชะงักที่คุณตั้งเป้าให้อยู่ภายใน กำหนดทั้งสองสำหรับฟังก์ชันทางธุรกิจที่มีประโยชน์ แล้วพิสูจน์ลำดับการกู้คืนในการฝึกซ้อม ตารางการสำรองข้อมูลหรือข้อกำหนดเซิร์ฟเวอร์เพียงอย่างเดียวไม่ได้กำหนดวัตถุประสงค์ใด ๆ

01 เริ่มต้นด้วยบริการที่ผู้คนใช้งานได้

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

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

02 แยกนาฬิกาสองเรือนออกจากกัน

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

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

03 จัดงบประมาณให้ทุกขั้นตอนของการกู้คืน

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

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

ขั้นตอนการกู้คืน เวลาจัดสรรเชิงตัวอย่าง หลักฐานที่ต้องเก็บรวบรวม

ตรวจจับและประเมิน 15 นาที การมาถึงของการแจ้งเตือนและการตัดสินใจเหตุการณ์

เตรียมสภาพแวดล้อมการกู้คืน 20 นาที การเข้าถึงและการกำหนดค่าพร้อมใช้งาน

กู้คืนข้อมูลและบริการ 50 นาที การกู้คืนเสร็จสมบูรณ์พร้อมข้อมูลที่สอดคล้องกัน

ตรวจสอบและเปิดใช้งานใหม่ 25 นาที เส้นทางของผู้ใช้สำเร็จ

ส่วนเผื่อสำหรับเหตุฉุกเฉิน 10 นาที งานที่ไม่คาดคิดถูกบันทึกไว้

04 ตรวจสอบช่วงเวลาข้อมูลสูญหายจริง

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

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

05 เลือกกลยุทธ์ภายในงบประมาณ

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

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

06 ฝึกซ้อมโดยไม่เป็นอันตรายต่อระบบโปรดักชัน

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

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

07 ทำให้แผนใช้งานได้ระหว่างเกิดความล้มเหลว

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

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

เปลี่ยนเป็น行動 รายการตรวจสอบปฏิบัติของคุณ

✓ กำหนดฟังก์ชันทางธุรกิจที่กู้คืนแล้ว

✓ อนุมัติเป้าหมาย RPO และ RTO แยกจากกัน

✓ จัดงบประมาณการตรวจจับ การเข้าถึง การกู้คืน และการตรวจสอบ

✓ วัดจุดข้อมูลที่ใช้งานได้ล่าสุด

✓ ฝึกซ้อมในสภาพแวดล้อมที่แยกออก

✓ บันทึกช่องว่างและทำซ้ำหลังการเปลี่ยนแปลงที่เกี่ยวข้อง

ดาวน์โหลดรายการตรวจสอบ

คำถามที่พบบ่อย รายละเอียดที่สำคัญ

RTO เหมือนกับ uptime หรือไม่? +

ไม่ RTO เป็นเป้าหมายการกู้คืนสำหรับสถานการณ์การหยุดชะงัก uptime วัดความพร้อมใช้งานในช่วงเวลาหนึ่ง อย่างหนึ่งไม่ได้กำหนดอีกอย่างหนึ่ง

การสำรองข้อมูลรายชั่วโมงรับประกัน RPO หนึ่งชั่วโมงหรือไม่? +

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

ทุกโครงการต้องใช้เซิร์ฟเวอร์สแตนด์บายหรือไม่? +

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

แหล่งอ้างอิงหลัก ไปที่ต้นทาง

แหล่งอ้างอิงเหล่านี้สนับสนุนแนวคิดทางเทคนิคในคู่มือนี้ ปฏิบัติตามเอกสารปัจจุบันก่อนเปลี่ยนระบบโปรดักชัน

NIST SP 800-34 Rev. 1: คู่มือการวางแผนเหตุฉุกเฉิน nvlpubs.nist.gov

AWS Well-Architected: กำหนดวัตถุประสงค์การกู้คืน docs.aws.amazon.com

Microsoft Learn: ความต่อเนื่องทางธุรกิจ ความพร้อมใช้งานสูง และการกู้คืนจากภัยพิบัติ learn.microsoft.com

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

เชื่อมโยงความรู้ โครงสร้างพื้นฐานที่เกี่ยวข้อง

Vector VPS สวิตเซอร์แลนด์ Vault Storage สวิตเซอร์แลนด์ Metal Atlas สวิตเซอร์แลนด์

รักษาสายไว้ บันทึกภาคสนามถัดไปของคุณ

สำรวจทุกคู่มือ

บันทึกภาคสนาม / 01

+

การดำเนินงานวันที่สอง ประยุกต์

สร้างการสำรองข้อมูลที่คุณกู้คืนได้จริง

เลือกเป้าหมายการกู้คืน ปกป้องสำเนาอิสระ และฝึกการกู้คืนก่อนที่เหตุการณ์จะบังคับให้ต้องทำ

อ่าน 4 นาที อ่านคู่มือ

บันทึกภาคสนาม / 02

+

การดำเนินงานวันที่สอง ประยุกต์

แบบจำลองภัยคุกคามเชิงปฏิบัติสำหรับโครงการโฮสติ้งของคุณ

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

อ่าน 6 นาที อ่านคู่มือ

บันทึกภาคสนาม / 03

+

การดำเนินงานวันที่สอง ประยุกต์

การดูแลระบบ Windows RDP อย่างปลอดภัยโดยไม่สูญเสียการเข้าถึง

แยกการเข้าถึงเครือข่าย การพิสูจน์ตัวตน และสิทธิ์ออกจากกัน จากนั้นยืนยันเส้นทางกู้คืนก่อนจำกัดการเข้าถึงระยะไกล

อ่าน 6 นาที อ่านคู่มือ