ลองนึกภาพ: คุณกำลังให้บริการโครงสร้างพื้นฐานด้านไอทีของศูนย์การค้าขนาดใหญ่ ฝนเริ่มตกในเมือง ฝนตกหนักทะลุหลังคา น้ำเต็มพื้นที่ค้าปลีกลึกถึงข้อเท้า เราหวังว่าห้องเซิร์ฟเวอร์ของคุณจะไม่อยู่ที่ชั้นใต้ดิน ไม่เช่นนั้นปัญหาจะไม่สามารถหลีกเลี่ยงได้
เรื่องราวที่อธิบายไม่ใช่แฟนตาซี แต่เป็นคำอธิบายโดยรวมของเหตุการณ์สองสามเหตุการณ์ในปี 2020 ในบริษัทขนาดใหญ่ แผนการกู้คืนความเสียหายหรือแผนการกู้คืนความเสียหาย (DRP) จะพร้อมเสมอสำหรับกรณีนี้ ในองค์กร นี่เป็นความรับผิดชอบของผู้เชี่ยวชาญด้านความต่อเนื่องทางธุรกิจ แต่ในบริษัทขนาดกลางและขนาดเล็ก การแก้ปัญหาดังกล่าวตกอยู่ที่บริการด้านไอที คุณต้องเข้าใจตรรกะทางธุรกิจด้วยตัวเอง เข้าใจว่าอะไรสามารถล้มเหลวได้ และจุดไหน สร้างการป้องกันและนำไปปฏิบัติ
จะดีมากหากผู้เชี่ยวชาญด้านไอทีสามารถเจรจากับธุรกิจและหารือเกี่ยวกับความจำเป็นในการป้องกันได้ แต่ฉันเคยเห็นมาแล้วหลายครั้งว่าบริษัทละเลยโซลูชันการกู้คืนระบบ (DR) เพราะถือว่ามันซ้ำซ้อน เมื่อเกิดอุบัติเหตุ การฟื้นตัวเป็นเวลานานอาจก่อให้เกิดความสูญเสีย และธุรกิจยังไม่พร้อม คุณสามารถทำซ้ำได้มากเท่าที่คุณต้องการ: "ฉันบอกคุณแล้ว" แต่บริการด้านไอทียังคงต้องกู้คืนบริการ
จากตำแหน่งสถาปนิก ฉันจะบอกวิธีหลีกเลี่ยงสถานการณ์นี้ ในส่วนแรกของบทความ ฉันจะแสดงงานเตรียมการ: วิธีหารือสามคำถามกับลูกค้าในการเลือกเครื่องมือรักษาความปลอดภัย:
- เรากำลังปกป้องอะไร?
- เรากำลังปกป้องจากอะไร?
- เราปกป้องได้แค่ไหน?
ในส่วนที่สอง เราจะพูดถึงทางเลือกในการตอบคำถาม: วิธีป้องกันตัวเอง ฉันจะยกตัวอย่างกรณีที่ลูกค้าแต่ละรายสร้างความคุ้มครองอย่างไร
สิ่งที่เราปกป้อง: การระบุหน้าที่ทางธุรกิจที่สำคัญ
ควรเริ่มเตรียมการโดยปรึกษาแผนปฏิบัติการหลังเหตุฉุกเฉินกับลูกค้าธุรกิจจะดีกว่า ปัญหาหลักที่นี่คือการค้นหาภาษากลาง โดยปกติแล้วลูกค้าจะไม่สนใจว่าโซลูชันด้านไอทีทำงานอย่างไร เขาสนใจว่าบริการนี้สามารถดำเนินธุรกิจและสร้างรายได้หรือไม่ ตัวอย่างเช่น หากไซต์ใช้งานได้ แต่ระบบการชำระเงินล่ม ก็ไม่มีรายได้จากลูกค้า และ "กลุ่มหัวรุนแรง" ยังคงเป็นผู้เชี่ยวชาญด้านไอที
ผู้เชี่ยวชาญด้านไอทีอาจประสบปัญหาในการเจรจาดังกล่าวด้วยเหตุผลหลายประการ:
- ฝ่ายบริการไอทียังไม่เข้าใจบทบาทของระบบสารสนเทศในธุรกิจอย่างถ่องแท้ ตัวอย่างเช่น หากไม่มีคำอธิบายกระบวนการทางธุรกิจหรือรูปแบบธุรกิจที่โปร่งใส
- กระบวนการทั้งหมดไม่ได้ขึ้นอยู่กับบริการด้านไอที ตัวอย่างเช่น เมื่อผู้รับเหมาดำเนินการส่วนหนึ่งของงาน และผู้เชี่ยวชาญด้านไอทีไม่ได้มีอิทธิพลโดยตรงต่อพวกเขา
ฉันจะจัดโครงสร้างการสนทนาดังนี้:
- เราอธิบายให้ธุรกิจต่างๆ ฟังว่าอุบัติเหตุเกิดขึ้นได้กับทุกคน และการฟื้นตัวต้องใช้เวลา สิ่งที่ดีที่สุดคือการสาธิตสถานการณ์ ว่าสิ่งนี้เกิดขึ้นได้อย่างไร และผลที่ตามมาที่เป็นไปได้คืออะไร
- เราแสดงให้เห็นว่าไม่ใช่ทุกอย่างขึ้นอยู่กับบริการไอที แต่คุณพร้อมที่จะช่วยเหลือในแผนปฏิบัติการในพื้นที่รับผิดชอบของคุณ
- เราขอให้ลูกค้าธุรกิจตอบว่า: หากวันสิ้นโลกเกิดขึ้น กระบวนการใดควรได้รับการฟื้นฟูก่อน? ใครมีส่วนร่วมในมันและอย่างไร?
ธุรกิจต้องการคำตอบง่ายๆ เช่น ศูนย์บริการทางโทรศัพท์จำเป็นต้องลงทะเบียนใบสมัครต่อไปทุกวันตลอด 24 ชั่วโมง
- เราขอให้ผู้ใช้ระบบหนึ่งหรือสองคนอธิบายกระบวนการนี้โดยละเอียด
จะดีกว่าถ้าให้นักวิเคราะห์ช่วยหากบริษัทของคุณมีขั้นแรกคำอธิบายอาจมีลักษณะดังนี้: ศูนย์บริการรับคำขอทางโทรศัพท์ ทางไปรษณีย์ และทางข้อความจากเว็บไซต์ จากนั้นเขาก็ป้อนพวกมันลงใน 1C ผ่านทางเว็บอินเตอร์เฟส และการผลิตก็นำพวกมันจากที่นั่นด้วยวิธีนี้
- จากนั้นเราจะดูว่าโซลูชันฮาร์ดแวร์และซอฟต์แวร์ใดบ้างที่สนับสนุนกระบวนการนี้ เพื่อการปกป้องที่ครอบคลุม เราคำนึงถึงสามระดับ:
- แอปพลิเคชันและระบบภายในไซต์ (ระดับซอฟต์แวร์)
- ไซต์ที่ระบบทำงาน (ระดับโครงสร้างพื้นฐาน)
- เครือข่าย (พวกเขามักจะลืมมัน)
- เราค้นหาจุดที่อาจเกิดความล้มเหลว: โหนดระบบที่ประสิทธิภาพของบริการขึ้นอยู่กับ เราแยกบันทึกโหนดที่ได้รับการสนับสนุนจากบริษัทอื่น: ผู้ให้บริการโทรคมนาคม ผู้ให้บริการโฮสติ้ง ศูนย์ข้อมูล และอื่นๆ ด้วยวิธีนี้ คุณสามารถกลับไปยังลูกค้าธุรกิจสำหรับขั้นตอนต่อไปได้
สิ่งที่เราปกป้องจาก: ความเสี่ยง
ต่อไป เราจะค้นหาจากลูกค้าธุรกิจว่าเราป้องกันความเสี่ยงอะไรบ้างเป็นอันดับแรก ความเสี่ยงทั้งหมดสามารถแบ่งออกเป็นสองกลุ่ม:
- การสูญเสียเวลาเนื่องจากการหยุดให้บริการ
- การสูญเสียข้อมูลอันเนื่องมาจากผลกระทบทางกายภาพ ปัจจัยมนุษย์ ฯลฯ
ธุรกิจต่างๆ กลัวที่จะสูญเสียทั้งข้อมูลและเวลา ทั้งหมดนี้นำไปสู่การสูญเสียเงิน ดังนั้นเราจึงถามคำถามอีกครั้งสำหรับแต่ละกลุ่มความเสี่ยง:
- สำหรับกระบวนการนี้ เราสามารถประมาณค่าใช้จ่ายที่สูญเสียข้อมูลและการสูญเสียเวลาเป็นเงินได้เท่าใด
- ข้อมูลอะไรบ้างที่เราไม่สามารถสูญเสียได้?
- เราจะไม่อนุญาตให้หยุดทำงานที่ไหน?
- เหตุการณ์ใดที่มีแนวโน้มและคุกคามเรามากที่สุด?
หลังจากการสนทนา เราจะเข้าใจวิธีจัดลำดับความสำคัญของจุดล้มเหลว
เราปกป้องได้มากเพียงใด: RPO และ RTO
เมื่อจุดวิกฤติของความล้มเหลวชัดเจน เราจะคำนวณตัวบ่งชี้ RTO และ RPO
ผมขอเตือนคุณว่า RTO (วัตถุประสงค์เวลาการกู้คืน) — นี่คือเวลาที่อนุญาตนับจากช่วงเวลาที่เกิดอุบัติเหตุจนกว่าบริการจะกลับคืนสู่สภาพเดิมอย่างสมบูรณ์ ในภาษาธุรกิจ นี่ถือเป็นการหยุดทำงานที่ยอมรับได้ หากเรารู้ว่ากระบวนการนำเข้าเงินเป็นจำนวนเท่าใด เราก็สามารถคำนวณความสูญเสียจากการหยุดทำงานแต่ละนาทีและคำนวณความสูญเสียที่ยอมรับได้
RPO (วัตถุประสงค์จุดกู้คืน) — จุดกู้คืนข้อมูลที่ถูกต้อง จะกำหนดเวลาที่เราอาจสูญเสียข้อมูล จากมุมมองทางธุรกิจ ข้อมูลสูญหายอาจส่งผลให้ต้องเสียค่าปรับ เป็นต้น ความสูญเสียดังกล่าวสามารถแปลงเป็นเงินได้
ผู้ใช้จะต้องคำนวณเวลาในการกู้คืน: ผู้ใช้จะสามารถเข้าสู่ระบบได้นานแค่ไหน ขั้นแรกเราเพิ่มเวลาการกู้คืนของลิงก์ทั้งหมดในห่วงโซ่ มักเกิดข้อผิดพลาดที่นี่: พวกเขารับ RTO ของผู้ให้บริการจาก SLA และลืมข้อกำหนดที่เหลือไป
ลองดูตัวอย่างที่เฉพาะเจาะจง ผู้ใช้เข้าสู่ระบบ 1C ระบบเปิดขึ้นพร้อมกับข้อผิดพลาดของฐานข้อมูล เขาติดต่อผู้ดูแลระบบ ฐานข้อมูลอยู่ในระบบคลาวด์ ผู้ดูแลระบบ รายงานปัญหาไปยังผู้ให้บริการ สมมติว่าการสื่อสารทั้งหมดใช้เวลา 15 นาที ในระบบคลาวด์ ฐานข้อมูลขนาดนี้จะถูกกู้คืนจากข้อมูลสำรองภายในหนึ่งชั่วโมง ดังนั้น RTO ทางฝั่งผู้ให้บริการคือหนึ่งชั่วโมง แต่นี่ไม่ใช่กำหนดเวลาสุดท้าย สำหรับผู้ใช้ ได้มีการเพิ่มเวลาเข้าไปอีก 15 นาทีในการตรวจจับปัญหา
จากนั้นผู้ดูแลระบบต้องตรวจสอบว่าฐานข้อมูลถูกต้อง เชื่อมต่อกับ 1C และเริ่มบริการ ซึ่งต้องใช้เวลาอีกหนึ่งชั่วโมง ซึ่งหมายความว่า RTO ทางฝั่งผู้ดูแลระบบจะใช้เวลา 2 ชั่วโมง 15 นาทีแล้ว ผู้ใช้ต้องใช้เวลาอีก 15 นาที: เข้าสู่ระบบ ตรวจสอบว่าธุรกรรมที่จำเป็นปรากฏขึ้น 2 ชั่วโมง 30 นาทีคือเวลาการกู้คืนบริการทั้งหมดในตัวอย่างนี้
การคำนวณเหล่านี้จะแสดงให้ธุรกิจเห็นว่าปัจจัยภายนอกใดบ้างที่ระยะเวลาการกู้คืนขึ้นอยู่กับ เช่น ถ้าออฟฟิศน้ำท่วม ต้องหาจุดรั่วและแก้ไขเสียก่อน จะใช้เวลาซึ่งไม่ขึ้นอยู่กับไอที
วิธีที่เราปกป้อง: การเลือกเครื่องมือสำหรับความเสี่ยงที่แตกต่างกัน
หลังจากหารือทุกประเด็นแล้ว ลูกค้าก็เข้าใจถึงต้นทุนการเกิดอุบัติเหตุของธุรกิจแล้ว ตอนนี้คุณสามารถเลือกเครื่องมือและหารือเกี่ยวกับงบประมาณได้ ฉันจะแสดงให้คุณเห็นว่าเรามีเครื่องมืออะไรบ้างสำหรับงานต่างๆ โดยใช้ตัวอย่างกรณีลูกค้า
เรามาเริ่มกันที่ความเสี่ยงกลุ่มแรก: ความสูญเสียเนื่องจากการหยุดให้บริการ แนวทางแก้ไขปัญหานี้ควรมี RTO ที่ดี
- โฮสต์แอปพลิเคชันในระบบคลาวด์
ขั้นแรกคุณสามารถย้ายไปยังระบบคลาวด์ได้ - ผู้ให้บริการได้คิดถึงปัญหาความพร้อมใช้งานสูงแล้ว โฮสต์การจำลองเสมือนถูกประกอบเข้าด้วยกันเป็นคลัสเตอร์ พลังงานและเครือข่ายได้รับการสงวนไว้ ข้อมูลจะถูกจัดเก็บไว้ในระบบจัดเก็บข้อมูลที่ทนทานต่อข้อผิดพลาด และผู้ให้บริการจะรับผิดชอบทางการเงินสำหรับการหยุดทำงาน
ตัวอย่างเช่น คุณสามารถโฮสต์เครื่องเสมือนกับฐานข้อมูลในระบบคลาวด์ได้ แอปพลิเคชันจะเชื่อมต่อกับฐานข้อมูลภายนอกผ่านช่องทางที่จัดตั้งขึ้นหรือจากคลาวด์เดียวกัน หากเกิดปัญหากับเซิร์ฟเวอร์ตัวใดตัวหนึ่งในคลัสเตอร์ VM จะรีสตาร์ทบนเซิร์ฟเวอร์ข้างเคียงภายในเวลาไม่ถึง 2 นาที หลังจากนั้น DBMS จะเริ่มทำงานและภายในไม่กี่นาทีฐานข้อมูลก็จะพร้อมใช้งาน
RTO: วัดเป็นนาที ข้อกำหนดเหล่านี้สามารถระบุได้ในข้อตกลงกับผู้ให้บริการ
ค่าใช้จ่ายของ: เราคำนวณต้นทุนทรัพยากรคลาวด์สำหรับแอปพลิเคชันของคุณ
สิ่งที่มันจะไม่ปกป้องคุณจาก: จากความล้มเหลวครั้งใหญ่ที่ไซต์ของผู้ให้บริการ เช่น จากอุบัติเหตุในระดับเมือง - คลัสเตอร์แอปพลิเคชัน
หากคุณต้องการปรับปรุง RTO คุณสามารถเสริมความแข็งแกร่งให้กับตัวเลือกก่อนหน้า และวางแอปพลิเคชันแบบคลัสเตอร์ในระบบคลาวด์ได้ทันที
คุณสามารถใช้คลัสเตอร์ในโหมดแอคทีฟ-พาสซีฟหรือแอคทีฟ-แอคทีฟ เราสร้าง VM หลายรายการตามความต้องการของผู้จำหน่าย เพื่อความน่าเชื่อถือที่มากขึ้น เราจึงแจกจ่ายข้อมูลเหล่านี้ไปยังเซิร์ฟเวอร์และระบบจัดเก็บข้อมูลต่างๆ หากเซิร์ฟเวอร์ที่มีฐานข้อมูลใดฐานข้อมูลหนึ่งล้มเหลว โหนดสำรองจะเข้าควบคุมการโหลดภายในไม่กี่วินาที
RTO: วัดเป็นวินาที
ค่าใช้จ่ายของ: มีราคาแพงกว่าคลาวด์ทั่วไปเล็กน้อย จึงจำเป็นต้องมีทรัพยากรเพิ่มเติมสำหรับการทำคลัสเตอร์
สิ่งที่มันจะไม่ปกป้องคุณจาก: ยังคงไม่สามารถป้องกันความล้มเหลวครั้งใหญ่ในสถานที่ได้ แต่การหยุดชะงักในท้องถิ่นจะไม่คงอยู่นานนักจากการปฏิบัติ: บริษัทค้าปลีกมีระบบข้อมูลและเว็บไซต์หลายแห่ง ฐานข้อมูลทั้งหมดตั้งอยู่ในสำนักงานของบริษัท ไม่มีการพิจารณา DR จนกระทั่งสำนักงานถูกปล่อยให้ไม่มีไฟฟ้าใช้หลายครั้งติดต่อกัน ลูกค้าไม่พอใจกับข้อขัดข้องของเว็บไซต์
ปัญหาเกี่ยวกับความพร้อมในการให้บริการได้รับการแก้ไขแล้วหลังจากย้ายไปยังระบบคลาวด์ นอกจากนี้เรายังจัดการเพื่อเพิ่มประสิทธิภาพการโหลดบนฐานข้อมูลโดยปรับสมดุลการรับส่งข้อมูลระหว่างโหนด - ย้ายไปยังระบบคลาวด์ที่ป้องกันภัยพิบัติ
หากคุณต้องการให้แน่ใจว่าแม้แต่ภัยพิบัติทางธรรมชาติบนไซต์หลักจะไม่รบกวนงานของคุณ คุณสามารถเลือกระบบคลาวด์ที่ทนต่อภัยพิบัติ ในตัวเลือกนี้ ผู้ให้บริการจะกระจายคลัสเตอร์การจำลองเสมือนไปยังศูนย์ข้อมูล 2 แห่ง การจำลองแบบซิงโครนัสอย่างต่อเนื่องเกิดขึ้นระหว่างศูนย์ข้อมูลแบบหนึ่งต่อหนึ่ง ช่องทางระหว่างศูนย์ข้อมูลถูกสงวนไว้และไปตามเส้นทางที่แตกต่างกัน ดังนั้นคลัสเตอร์ดังกล่าวจึงไม่กลัวปัญหาเครือข่าย
RTO: มีแนวโน้มเป็น 0
ค่าใช้จ่ายของ: ตัวเลือกคลาวด์ที่แพงที่สุด
สิ่งที่มันจะไม่ปกป้องคุณจาก: จะไม่ช่วยป้องกันข้อมูลเสียหายรวมทั้งจากปัจจัยมนุษย์ด้วย ดังนั้น แนะนำให้ทำการสำรองข้อมูลไปพร้อมๆ กันจากการปฏิบัติ: ลูกค้ารายหนึ่งของเราได้พัฒนาแผนการกู้คืนระบบที่ครอบคลุม นี่คือกลยุทธ์ที่เขาเลือก:
- ระบบคลาวด์ที่ทนทานต่อภัยพิบัติช่วยปกป้องแอปพลิเคชันจากความล้มเหลวในระดับโครงสร้างพื้นฐาน
- การสำรองข้อมูลสองระดับให้การป้องกันในกรณีที่เกิดข้อผิดพลาดจากมนุษย์ การสำรองข้อมูลมีสองประเภท: "เย็น" และ "ร้อน" การสำรองข้อมูลแบบ "เย็น" อยู่ในสถานะปิดใช้งานและต้องใช้เวลาในการปรับใช้ การสำรองข้อมูลแบบ "ร้อน" พร้อมใช้งานแล้วและได้รับการกู้คืนเร็วขึ้น มันถูกจัดเก็บไว้ในระบบจัดเก็บข้อมูลโดยเฉพาะ สำเนาชุดที่สามจะถูกบันทึกลงในเทปและจัดเก็บไว้ในห้องอื่น
สัปดาห์ละครั้ง ไคลเอนต์จะทดสอบการป้องกันและตรวจสอบการทำงานของการสำรองข้อมูลทั้งหมด รวมถึงการสำรองข้อมูลจากเทปด้วย ทุกปีบริษัทจะทดสอบระบบคลาวด์ที่ทนต่อภัยพิบัติทั้งหมด
- จัดระเบียบการจำลองแบบไปยังไซต์อื่น
อีกทางเลือกหนึ่งในการหลีกเลี่ยงปัญหาระดับโลกบนเว็บไซต์หลัก: ให้การจองทางภูมิศาสตร์ กล่าวอีกนัยหนึ่ง ให้สร้างเครื่องเสมือนสำรองที่ไซต์ในเมืองอื่น โซลูชันพิเศษสำหรับ DR เหมาะสำหรับสิ่งนี้: ในบริษัทของเรา เราใช้ VMware vCloud Availability (vCAV) ด้วยความช่วยเหลือนี้ คุณสามารถกำหนดค่าการป้องกันระหว่างไซต์ผู้ให้บริการคลาวด์หลายแห่งหรือกู้คืนไปยังคลาวด์จากไซต์ภายในองค์กรได้ ฉันได้พูดคุยรายละเอียดเพิ่มเติมเกี่ยวกับรูปแบบการทำงานกับ vCAV แล้ว .
อาร์พีโอ และ อาร์ทีโอ: จาก 5 นาที
ค่าใช้จ่ายของ: มีราคาแพงกว่าตัวเลือกแรก แต่ราคาถูกกว่าการจำลองแบบฮาร์ดแวร์ในระบบคลาวด์ที่ป้องกันภัยพิบัติ ราคาประกอบด้วยต้นทุนใบอนุญาต vCAV ค่าธรรมเนียมการจัดการ ต้นทุนทรัพยากรคลาวด์ และทรัพยากรสำรองตามโมเดล PAYG (10% ของต้นทุนทรัพยากรการทำงานสำหรับ VM ที่ปิดอยู่)
จากการปฏิบัติ: ลูกค้าเก็บเครื่องเสมือน 6 เครื่องพร้อมฐานข้อมูลที่แตกต่างกันไว้ในคลาวด์ของเราในมอสโก ในตอนแรก การป้องกันได้มาจากการสำรองข้อมูล: สำเนาสำรองบางส่วนถูกจัดเก็บไว้ในระบบคลาวด์ในมอสโกว และบางส่วนถูกจัดเก็บไว้ในไซต์เซนต์ปีเตอร์สเบิร์กของเรา เมื่อเวลาผ่านไป ฐานข้อมูลมีขนาดใหญ่ขึ้น และการกู้คืนจากข้อมูลสำรองก็เริ่มใช้เวลานานขึ้น
เพิ่มการจำลองแบบตาม VMware vCloud Availability ลงในการสำรองข้อมูลแล้ว แบบจำลองของเครื่องเสมือนจะถูกจัดเก็บไว้ในไซต์สำรองในเซนต์ปีเตอร์สเบิร์กและอัปเดตทุกๆ 5 นาที หากเกิดความล้มเหลวที่ไซต์หลัก พนักงานจะเปลี่ยนไปใช้แบบจำลองของเครื่องเสมือนในเซนต์ปีเตอร์สเบิร์กอย่างอิสระและทำงานกับเครื่องนั้นต่อไป
โซลูชันทั้งหมดที่ได้รับการพิจารณามีความพร้อมใช้งานสูง แต่ไม่ได้ป้องกันการสูญหายของข้อมูลเนื่องจากไวรัสแรนซัมแวร์หรือข้อผิดพลาดโดยไม่ได้ตั้งใจของพนักงาน ในกรณีนี้ เราจะต้องมีการสำรองข้อมูลที่จะจัดเตรียม RPO ที่จำเป็น
5. อย่าลืมสำรองข้อมูล
ทุกคนรู้ดีว่าคุณต้องสำรองข้อมูล แม้ว่าคุณจะมีโซลูชันป้องกันภัยพิบัติที่ยอดเยี่ยมที่สุดก็ตาม ดังนั้นฉันจะเตือนคุณถึงประเด็นสองสามประเด็นสั้นๆ
พูดอย่างเคร่งครัด การสำรองข้อมูลไม่ใช่ DR และนั่นคือเหตุผล:
- มันเป็นเวลานาน หากข้อมูลวัดเป็นเทราไบต์ การกู้คืนจะใช้เวลามากกว่าหนึ่งชั่วโมง คุณต้องกู้คืน กำหนดเครือข่าย ตรวจสอบว่าเปิดอยู่หรือไม่ ดูว่าข้อมูลเป็นไปตามลำดับหรือไม่ ดังนั้นคุณจึงสามารถจัดเตรียม RTO ที่ดีได้ก็ต่อเมื่อมีข้อมูลเพียงเล็กน้อยเท่านั้น
- ข้อมูลอาจไม่สามารถกู้คืนได้ในครั้งแรก และคุณต้องเผื่อเวลาในการดำเนินการซ้ำ ตัวอย่างเช่น มีหลายครั้งที่เราไม่ทราบแน่ชัดว่าข้อมูลสูญหายเมื่อใด สมมติว่ามีการขาดทุนเวลา 15.00 น. และจะมีการคัดลอกทุกชั่วโมง ตั้งแต่เวลา 15.00 น. เราจะดูจุดฟื้นตัวทั้งหมด: 14:00 น. 13:00 น. เป็นต้น หากระบบมีความสำคัญ เราจะพยายามลดอายุของจุดฟื้นตัวให้เหลือน้อยที่สุด แต่หากการสำรองข้อมูลใหม่ไม่มีข้อมูลที่จำเป็น เราจะดำเนินการในประเด็นถัดไป - นี่เป็นเวลาเพิ่มเติม
ในกรณีนี้ กำหนดเวลาการสำรองข้อมูลสามารถจัดเตรียมสิ่งที่จำเป็นได้ RPO. สำหรับการสำรองข้อมูล สิ่งสำคัญคือต้องมีการจองทางภูมิศาสตร์ในกรณีที่เกิดปัญหากับไซต์หลัก ขอแนะนำให้เก็บสำเนาสำรองบางชุดแยกกัน
แผนการกู้คืนความเสียหายขั้นสุดท้ายควรมีเครื่องมืออย่างน้อย 2 อย่าง:
- หนึ่งในตัวเลือกที่ 1-4 ซึ่งจะปกป้องระบบจากความล้มเหลวและการล่มสลาย
- สำรองข้อมูลเพื่อป้องกันข้อมูลสูญหาย
นอกจากนี้ยังควรดูแลช่องทางการสื่อสารสำรองในกรณีที่ผู้ให้บริการอินเทอร์เน็ตหลักล่ม และ - ว้าว! — DR ที่ค่าแรงขั้นต่ำพร้อมแล้ว
ที่มา: will.com