Disaster Recovery: วางแผน DR Site สำหรับ IT Infrastructure
Disaster Recovery (DR) คือแผนและกระบวนการในการกู้คืน IT systems หลังจากเกิดเหตุการณ์ที่ทำให้ระบบล่ม ไม่ว่าจะเป็นภัยธรรมชาติ (น้ำท่วม แผ่นดินไหว ไฟไหม้) hardware failure (server ล่ม storage พัง) cyber attack (ransomware, DDoS) หรือ human error (ลบข้อมูลผิด misconfiguration)
จากสถิติ 40% ของธุรกิจ ที่ประสบ major disaster และไม่มี DR plan จะปิดกิจการภายใน 1 ปี การมี DR plan ที่ดีไม่ได้ป้องกัน disaster แต่ทำให้กู้คืนได้เร็วและสูญเสียน้อยที่สุด บทความนี้จะอธิบายวิธีวางแผน DR site ตั้งแต่กำหนด RTO/RPO จนถึง implementation
คำศัพท์สำคัญ
| คำศัพท์ | ความหมาย | ตัวอย่าง |
|---|---|---|
| RTO (Recovery Time Objective) | เวลาสูงสุดที่ระบบ down ได้ | RTO 4 ชั่วโมง = ต้องกู้คืนภายใน 4 ชั่วโมง |
| RPO (Recovery Point Objective) | ข้อมูลสูงสุดที่ยอมเสียได้ | RPO 1 ชั่วโมง = ข้อมูลหายได้ไม่เกิน 1 ชั่วโมง |
| MTTR (Mean Time To Recovery) | เวลาเฉลี่ยในการกู้คืน | MTTR 2 ชั่วโมง |
| MTBF (Mean Time Between Failures) | เวลาเฉลี่ยระหว่าง failures | MTBF 10,000 ชั่วโมง |
| BIA (Business Impact Analysis) | วิเคราะห์ผลกระทบต่อธุรกิจ | ระบบ ERP down 1 วัน = สูญเสีย 1 ล้านบาท |
ประเภทของ DR Site
Cold Site
Cold Site มีแค่ physical space, power, cooling, network connectivity ไม่มี servers หรือ data pre-installed ต้องขน hardware มาติดตั้ง + restore data จาก backup RTO: 24-72+ ชั่วโมง ค่าใช้จ่าย: ต่ำสุด เหมาะกับ: ระบบที่ down ได้หลายวัน
Warm Site
Warm Site มี hardware ติดตั้งพร้อม แต่ data ไม่ real-time (sync ทุก 1-24 ชั่วโมง) ต้อง restore data ล่าสุดจาก backup แล้ว start services RTO: 4-24 ชั่วโมง ค่าใช้จ่าย: ปานกลาง เหมาะกับ: ระบบส่วนใหญ่ขององค์กร
Hot Site
Hot Site มี hardware ติดตั้งพร้อม + data replicate แบบ real-time (synchronous/asynchronous) สามารถ failover ได้ทันทีหรือภายในนาที RTO: นาที ถึง 1-2 ชั่วโมง ค่าใช้จ่าย: สูงมาก (เกือบเท่า primary site) เหมาะกับ: ระบบ critical ที่ down ไม่ได้ (banking, e-commerce)
ตาราง DR Site เปรียบเทียบ
| คุณสมบัติ | Cold Site | Warm Site | Hot Site |
|---|---|---|---|
| RTO | 24-72+ ชั่วโมง | 4-24 ชั่วโมง | นาที – 2 ชั่วโมง |
| RPO | 24+ ชั่วโมง | 1-24 ชั่วโมง | 0 – 1 ชั่วโมง |
| Hardware พร้อม | ไม่ | ใช่ | ใช่ |
| Data พร้อม | ไม่ (restore จาก backup) | ไม่ real-time | Real-time replication |
| ค่าใช้จ่าย/เดือน | ต่ำ | ปานกลาง | สูง |
| ความซับซ้อน | ต่ำ | ปานกลาง | สูง |
วางแผน DR: 6 ขั้นตอน
1. Business Impact Analysis (BIA)
วิเคราะห์ ว่าระบบไหนสำคัญที่สุด ถ้า down จะสูญเสียเท่าไหร่ จัดลำดับ criticality: Tier 1 (mission critical ต้องกู้ก่อน), Tier 2 (important), Tier 3 (nice to have) กำหนด RTO/RPO สำหรับแต่ละระบบตาม business impact
2. เลือก DR Strategy
เลือก DR site type ตาม RTO/RPO ที่กำหนด Tier 1 systems → Hot Site Tier 2 systems → Warm Site Tier 3 systems → Cold Site หรือ backup restore พิจารณา cloud DR (AWS, Azure) เป็นทางเลือกที่ cost-effective กว่า physical DR site
3. เลือก DR Site Location
DR site ต้องอยู่ห่างจาก primary site พอที่จะไม่ถูกผลกระทบจาก disaster เดียวกัน แนะนำ 50+ กิโลเมตร (สำหรับภัยธรรมชาติ) ต้องมี network connectivity ที่ดี (dedicated link หรือ VPN) พิจารณา latency สำหรับ synchronous replication (ยิ่งไกล latency ยิ่งสูง)
4. Data Replication
เลือก replication method ตาม RPO: Synchronous replication: RPO = 0 (ไม่เสียข้อมูลเลย) ต้อง latency ต่ำ (< 5ms) Asynchronous replication: RPO = seconds-minutes ทนได้กับ latency สูง Scheduled backup: RPO = ชั่วโมง-วัน ถูกที่สุดแต่เสียข้อมูลมากที่สุด
5. สร้าง DR Runbook
DR Runbook คือ step-by-step procedures สำหรับ failover ต้องละเอียดพอที่คนที่ไม่เคยทำก็ทำได้ ระบุ: ใครทำ, ทำอะไร, ลำดับ, เงื่อนไข, contact list รวม network failover procedures (DNS change, BGP route, VPN), server startup sequence, application startup sequence, data verification
6. ทดสอบ DR Plan
DR plan ที่ไม่ได้ทดสอบ = ไม่มี DR plan ทดสอบอย่างน้อยปีละ 1-2 ครั้ง ประเภทการทดสอบ: Tabletop exercise (walkthrough ขั้นตอน), Partial failover (ทดสอบบางระบบ), Full failover (ทดสอบทั้งหมด) record ปัญหาที่พบ แก้ไข update runbook
Cloud DR: ทางเลือกที่ Cost-effective
AWS / Azure DR
Cloud DR ไม่ต้องลงทุน hardware สำหรับ DR site จ่ายตาม usage (เมื่อ failover ถึงจ่ายเต็ม) AWS: CloudEndure, AWS Backup, Site Recovery Azure: Azure Site Recovery, Azure Backup replicate VMs, databases, storage ไป cloud DR เมื่อ primary site ล่ม spin up VMs บน cloud ภายในนาที ค่าใช้จ่าย standby ต่ำมาก (จ่ายแค่ storage + replication)
ทิ้งท้าย: DR Plan คือ Insurance ของ IT
Disaster Recovery เหมือนประกันภัย หวังว่าจะไม่ต้องใช้ แต่ถ้าเกิดเหตุขึ้นจะดีใจที่มี ทำ BIA กำหนด RTO/RPO เลือก DR strategy ที่เหมาะสม สร้าง runbook ที่ละเอียด ทดสอบเป็นประจำ และ update plan เมื่อ infrastructure เปลี่ยนแปลง
อ่านเพิ่มเติมเกี่ยวกับ Backup Strategy 3-2-1 และ Network Design ที่ siamlancard.com หรือจาก icafeforex.com และ siam2r.com
