Learning AtlasIT Support → Cybersecurity
คลังบทอ่าน11.2 / สำรองและกู้คืนบทถัดไป
สารบัญบทอ่าน / Backup and Recovery / 11.2
03 · แก้ปัญหาและดูแลระบบ · บท 11.2

Recovery Planning

วางแผนกู้คืน

สำเนาที่กู้ไม่ได้ยังไม่ตอบโจทย์ จึงต้องวางลำดับการกู้ ระบบที่พึ่งกัน และวิธีตรวจผล

4 หัวข้อคำอธิบายในหน้านี้ภาพอธิบายและกลไกทีละส่วน
ควรรู้ก่อน: 11.1 ออกแบบการสำรอง
หัวข้อในบทนี้
ศัพท์ในบทนี้ · กดคำที่ขีดเส้นใต้ในเนื้อหาเพื่อดูความหมายได้ด้วย
DNS
ระบบค้นข้อมูลของชื่อ เช่น IP ของชื่อโฮสต์
RPO
เป้าหมายช่วงข้อมูลที่ยอมสูญย้อนหลังตามเวลา
RTO
เป้าหมายเวลาในการฟื้นบริการ
จากหลักการไปถึงกลไก

คืนไฟล์ได้ กับคืนบริการได้ ยังต่างกัน

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

ลำดับงาน · อ่านตามลูกศรคืนไฟล์ได้ กับคืนบริการได้ ยังต่างกัน
  1. Identify

    รู้บริการสำคัญ เจ้าของ dependency และ RPO/RTO ที่ตกลง

  2. Recover base

    คืนเครื่อง network identity และ config ที่บริการต้องพึ่งตามลำดับ

  3. Restore data

    เลือกชุด backup ตรวจความครบ ถอดรหัสและคืนด้วยเครื่องมือที่รองรับ

  4. Validate

    ทดสอบข้อมูล แอป สิทธิ์ และงานผู้ใช้ ไม่จบที่ไฟล์ copy ได้

  5. Improve

    วัดเวลาจริง ข้อมูลที่หาย ปัญหาและปรับแผนจากผลทดสอบ

มี backup ทุกคืนอาจรองรับข้อมูลหายได้เกือบหนึ่งวัน แต่เวลาคืนขึ้นกับขนาด ระบบและ dependency การกู้ลงที่ทดสอบแยกจากระบบจริงช่วยตรวจโดยไม่เขียนทับงานปัจจุบัน Failure review ต้องหาช่องโหว่ของวิธีทำงานและการตรวจ ไม่ใช่เพียงหาคนที่กดผิด

01 / 04

ตรวจการกู้คืนRestore Verification · 11.2.1

Restore verification ทดสอบกู้แล้วเปิดใช้ข้อมูลหรือบริการได้จริง

Restore verification ต้องพิสูจน์ว่าข้อมูลคืนครบ ถูกต้อง และแอปใช้งานได้จริง รวมถึงเวลาในการกู้และ dependency งาน backup job สีเขียวพิสูจน์แค่ขั้นตอนที่ระบบนั้นตรวจ

อ่านภาพตามลำดับการทำงาน
01Recover data

นำข้อมูลออกจากสำเนา

02Validate

ตรวจความถูกต้องและสิทธิ์

03Use service

เปิดงานที่พึ่งข้อมูลได้

กู้ database ในที่แยกแล้วตรวจ consistency และ query สำคัญ กู้ไฟล์แล้วตรวจเปิด อ่าน และ permission หากต้องกู้ภายในสองชั่วโมงให้วัดเวลาทั้งเตรียมระบบและคืนข้อมูล ไม่เฉพาะเวลาคัดลอก

ที่มาของหัวข้อนี้ · 1 รายการ

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

  • System Administration and IT Infrastructure Services · Module 5: Data Recovery & BackupsVideo: Testing BackupsIT4.M5.V6
02 / 04

ฟื้นฟูหลังภัยพิบัติDisaster Recovery · 11.2.2

Disaster recovery กำหนดวิธีฟื้นระบบหลังเหตุใหญ่ รวมคน ทรัพยากร และลำดับ

Disaster recovery วางวิธีฟื้นระบบหลังเหตุใหญ่ คือช่วงข้อมูลที่ยอมสูญได้ตามเวลา คือระยะเวลาที่ตั้งเป้าฟื้นบริการ ต้องคิด identity network key และผู้มีสิทธิ์กู้ร่วมกับ backup

เทียบหน้าที่เพื่อไม่สับสน
•RPO

ยอมสูญข้อมูลย้อนหลังเท่าใด

•RTO

เป้าหมายเวลาฟื้นบริการ

•Dependencies

สิ่งที่ต้องพร้อมเพื่อกู้

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

ที่มาของหัวข้อนี้ · 2 รายการ

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

03 / 04

ความต่อเนื่องธุรกิจBusiness Continuity · 11.2.3

Business continuity วางวิธีให้งานสำคัญดำเนินต่อ แม้ระบบบางส่วนยังไม่กลับมา

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

เทียบหน้าที่เพื่อไม่สับสน
•Critical activity

งานที่ต้องดำเนินต่อ

•Fallback

วิธีชั่วคราวและเจ้าของ

•Recovery transition

กลับระบบและกระทบยอด

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

ที่มาของหัวข้อนี้ · 2 รายการ

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

04 / 04

ทบทวนความล้มเหลวFailure Review · 11.2.4

ทบทวนความล้มเหลวเพื่อปรับสิ่งที่ป้องกัน ตรวจจับ และกู้คืนได้

Review หลังความล้มเหลวสร้าง timeline ตรวจสาเหตุและเงื่อนไขที่ทำให้ผลกระทบรุนแรง แยก trigger จาก root cause และระบุการปรับปรุงที่มีเจ้าของ วันครบกำหนด และวิธีตรวจผล

เทียบหน้าที่เพื่อไม่สับสน
•Timeline

เหตุการณ์ตามหลักฐาน

•Contributing factors

เงื่อนไขร่วมที่ทำให้เสียหาย

•Action

การปรับปรุงที่ตรวจผลได้

ไฟดับเป็น trigger แต่ไม่มีสำเนาที่กู้ได้อาจเป็นสาเหตุที่หยุดงานนาน การบอกให้ระวังมากขึ้นไม่แก้ระบบ ควรเปลี่ยนการตรวจ backup หรือ dependency ที่ทำให้กู้ไม่ได้แล้วทดสอบซ้ำ

ที่มาของหัวข้อนี้ · 2 รายการ

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

เชื่อมความเข้าใจ

นำศัพท์มาเชื่อมกับงาน

ตัวอย่างให้เห็นภาพ

กู้แอปได้แต่ไม่มีฐานข้อมูลหรือ DNS ก็ยังให้บริการไม่ได้ ต้องวาง dependency

สิ่งที่บทนี้เชื่อมไว้

สำเนาที่กู้ไม่ได้ยังไม่ตอบโจทย์ จึงต้องวางลำดับการกู้ ระบบที่พึ่งกัน และวิธีตรวจผล

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

บันทึกในเบราว์เซอร์นี้
บทเรียนที่เกี่ยวข้องและที่มาของบทอ่าน

คำอธิบายหน้านี้เขียนใหม่ตามหัวข้อใน Atlas รายการด้านล่างเป็นชื่อ Video/Reading ที่เคยจับคู่ไว้ แสดงไว้ให้ตรวจที่มาของชื่อหัวข้อ และไม่รับรองว่าคอร์สสอนทุกส่วนของคำอธิบายนี้