Home » Disaster Recovery Plan คู่มือ DRP สำหรับองค์กร
Disaster Recovery Plan คู่มือ DRP สำหรับองค์กร
Disaster Recovery Plan คืออะไร? ทำไมทุกองค์กรต้องมี
Disaster Recovery Plan (DRP) คือ แผนการกู้คืนระบบ IT เมื่อเกิดภัยพิบัติหรือเหตุการณ์ร้ายแรง เช่น ไฟไหม้ น้ำท่วม Ransomware Server ล่ม หรือ Hardware เสียหายทั้งหมด DRP กำหนดว่าจะกู้คืนระบบอะไร เร็วแค่ไหน ยอมเสียข้อมูลได้เท่าไหร่ ใครรับผิดชอบอะไร องค์กรที่ไม่มี DRP เมื่อเกิดภัยพิบัติจะสูญเสียข้อมูล หยุดทำงาน และอาจปิดกิจการได้
RTO และ RPO
| ตัวชี้วัด |
คำอธิบาย |
ตัวอย่าง |
| RTO (Recovery Time Objective) |
ระบบต้องกลับมาใช้ได้ภายในกี่ชั่วโมง/วัน |
ERP: RTO 4 ชม., Email: RTO 1 ชม. |
| RPO (Recovery Point Objective) |
ยอมเสียข้อมูลได้กี่ชั่วโมง ย้อนหลัง |
Database: RPO 1 ชม. (Backup ทุก 1 ชม.) |
ตัวอย่าง: ถ้า ERP มี RTO 4 ชม. RPO 1 ชม. หมายความว่า เมื่อเกิดภัยพิบัติ ERP ต้องกลับมาใช้ได้ภายใน 4 ชม. และเสียข้อมูลได้ไม่เกิน 1 ชม. ย้อนหลัง
ประเภทภัยพิบัติ
| ประเภท |
ตัวอย่าง |
ความรุนแรง |
| ธรรมชาติ |
น้ำท่วม แผ่นดินไหว ไฟไหม้ พายุ |
สูงมาก สูญเสียทั้งหมด |
| Cyber Attack |
Ransomware, Data Breach, DDoS |
สูง ข้อมูลถูกเข้ารหัส/รั่วไหล |
| Hardware Failure |
Server ล่ม, Storage เสีย, Switch พัง |
ปานกลาง-สูง |
| Human Error |
ลบข้อมูลผิด, Config ผิด, อัปเดตพลาด |
ต่ำ-สูง |
| ไฟฟ้า/โครงสร้าง |
ไฟดับยาว, แอร์พัง ห้อง Server ร้อน |
ปานกลาง |
DR Strategy
| Strategy |
RTO |
ต้นทุน |
วิธีการ |
| Backup & Restore |
24-72 ชม. |
ต่ำ |
Restore จาก Backup ไป Hardware ใหม่ |
| Warm Standby |
4-24 ชม. |
ปานกลาง |
DR Site มี Server ไว้ แต่ไม่ Run ตลอด |
| Hot Standby |
นาที – 4 ชม. |
สูง |
DR Site Run ตลอด Data Replicate Real-time |
| Active-Active |
0 (Zero Downtime) |
สูงมาก |
2 Site ทำงานพร้อมกัน Load Balance |
DR Site Options
- On-Premise DR: สร้าง DR Site ที่สำนักงานอีกแห่ง หรือ Colocation Datacenter
- Cloud DR: ใช้ Cloud (AWS, Azure) เป็น DR Site จ่ายตามใช้จริง ไม่ต้องซื้อ Hardware
- DRaaS: Disaster Recovery as a Service ใช้บริการ DR สำเร็จรูป เช่น Zerto, Veeam Cloud Connect
- NAS Replication: Replicate ข้อมูลจาก NAS หลัก ไป NAS สำรอง ที่อีกที่หนึ่ง
ขั้นตอนสร้าง DRP
- สำรวจระบบ: ระบุระบบ IT ทั้งหมด Server, Application, Database, Network
- จัดลำดับ: จัดลำดับความสำคัญ ระบบไหน Critical ต้องกลับมาก่อน
- กำหนด RTO/RPO: กำหนด RTO RPO ของแต่ละระบบ ตามความสำคัญ
- เลือก Strategy: เลือก DR Strategy ที่เหมาะสม ตาม RTO/RPO และงบ
- เขียนแผน: เขียน Step-by-step ว่าเมื่อเกิดภัยพิบัติ ต้องทำอะไร ใครทำ
- ตั้ง Backup: ตั้ง Backup ตาม RPO ที่กำหนด ทดสอบ Restore
- ตั้ง Replication: ตั้ง Replication ไป DR Site (ถ้าเลือก Hot/Warm Standby)
- ทดสอบ: ทดสอบ DRP อย่างน้อยปีละ 2 ครั้ง
- อัปเดต: อัปเดต DRP เมื่อมีการเปลี่ยนแปลงระบบ
DR Testing
| ประเภท |
วิธี |
ความเสี่ยง |
ความถี่ |
| Tabletop |
ประชุมจำลองสถานการณ์ ไม่ทำจริง |
ไม่มี |
ทุก 6 เดือน |
| Walkthrough |
ทดสอบขั้นตอน ทีละ Step ไม่กระทบ Production |
ต่ำ |
ทุก 6 เดือน |
| Simulation |
จำลอง Failover ไป DR Site จริง |
ปานกลาง |
ปีละ 1 ครั้ง |
| Full Test |
Failover ไป DR Site จริง ปิด Primary |
สูง |
ปีละ 1 ครั้ง |
DRP Best Practices
- 3-2-1 Backup: 3 สำเนา 2 สื่อ 1 Offsite เป็นขั้นต่ำ
- ทดสอบ Restore: ทดสอบ Restore จาก Backup จริงๆ ทุกเดือน ไม่ใช่แค่ตรวจว่า Backup ทำงาน
- Document: เขียน DRP ละเอียด Step-by-step ใครก็ทำตามได้
- Contact List: รายชื่อคนที่ต้องติดต่อ โทรศัพท์ อีเมล บทบาท
- Offsite Copy: เก็บ DRP Document ที่ไม่ใช่ในออฟฟิศ (Cloud หรือบ้าน)
- ทดสอบทุก 6 เดือน: ทดสอบ DRP อย่างน้อย 2 ครั้ง/ปี อัปเดตหลังทดสอบ
- Cyber DR: รวม Ransomware Recovery ใน DRP เพราะเป็นภัยพิบัติที่พบบ่อยที่สุด
สรุป Disaster Recovery Plan — เตรียมพร้อมก่อนภัยพิบัติมาถึง
DRP เป็นสิ่งจำเป็นสำหรับทุกองค์กร กำหนด RTO/RPO สร้าง Backup ที่เชื่อถือได้ มี DR Strategy ที่เหมาะสม และทดสอบสม่ำเสมอ อย่ารอจนเกิดภัยพิบัติแล้วค่อยทำ หากต้องการข้อมูลเพิ่มเติม ติดตามได้ที่ SiamLanCard.com
