Backup & Disaster Recovery
Backup & Data Protection Architecture
โครงสร้างเครือข่ายที่ออกแบบเพื่อ “ระบบงานสำคัญ” ที่ต้องการความเสถียรและปลอดภัยสูง
ทุกองค์กรรู้ว่าต้องมีระบบสำรองข้อมูล แต่ไม่ใช่ทุกองค์กรที่มี “สถาปัตยกรรม”
ที่ทำให้การ กู้คืนเกิดขึ้นได้ทันเวลา ในช่วงที่ระบบล่ม ไฟดับ เซิร์ฟเวอร์พัง หรือโดน
Ransomware
บทพิสูจน์ ไม่ได้อยู่ที่ตัวซอฟต์แวร์ว่าทำงานได้หรือไม่ แต่อยู่ที่ระบบทั้งหมด
สามารถทำให้ธุรกิจกลับมาทำงานต่อได้เร็วแค่ไหนจึงจะถือว่าสำรองข้อมูลสำเร็จจริง
นี่คือเหตุผลที่ VIRYA SOLUTIONS ไม่ได้มองงาน Backup เป็นงานติดตั้งซอฟต์แวร์หรือ เชื่อมอุปกรณ์เก็บข้อมูล แต่เป็นการออกแบบ “ระบบนิเวศของข้อมูล” ที่ประกอบด้วยโครงสร้าง พื้นฐานหลากหลายชั้น ตั้งแต่ Hypervisor ที่รัน VM, ระบบ Storage ที่เก็บข้อมูลจริง, เส้น ทางการรับส่งข้อมูล, ไปจนถึงรูปแบบของ Repository และการจัดชั้นของสื่อสำรองให้ สอดคล้องกับระดับความสำคัญของงาน
ทำไมองค์กรในไทยเลือก
กลับพบว่าเมื่อถึงเวลาต้อง Restore จริง ระบบกลับช้าเกินไป ไม่ทันกำหนด RTO หรือข้อมูลล่าสุดไม่ตรงกับรอบการทำงานจริงจนเกิดความเสียหายซ้ำซ้อน
นั่นคือเหตุผลที่เราตรวจสอบขั้นตอนทั้งหมดตั้งแต่ต้นน้ำก่อนการออกแบบเสมอ
กระบวนการออกแบบสถาปัตยกรรม
1. ทำความเข้าใจสถาปัตยกรรมเดิม
เมื่อเริ่มต้น เราจะทำความเข้าใจสถาปัตยกรรมระบบที่ลูกค้ามีอยู่ ไม่ว่าจะเป็น VMware, Hyper-V, ระบบ HCI หรือสภาพแวดล้อมผสม พร้อมวิเคราะห์ความสามารถของ Storage เช่น Enterprise Storage ที่มีระบบ snapshot ในตัว หรือโครงสร้างระดับกลางที่รองรับเฉพาะ workload บางรูปแบบ เพราะสิ่งเหล่านี้ล้วนส่งผลโดยตรงต่อประสิทธิภาพในการสำรองและกู้ คืนข้อมูล
2. ออกแบบเส้นทางการสำรองข้อมูล
จากนั้นเราจึงออกแบบเส้นทางการสำรองข้อมูลให้เข้ากับลักษณะงานจริง เช่น การลดโหลด บน datastore ผลิต การเลือกวิธีอ่านข้อมูลจาก VM ให้เร็วที่สุด หรือการออกแบบ proxy / data mover ให้เหมาะกับ topology ของ network เพื่อหลีกเลี่ยงคอขวด และทำให้การสำรองข้อมูล ทำได้รวดเร็วโดยไม่รบกวนระบบหลัก
ที่ยังต้องให้บริการตลอดเวลา
3. การออกแบบ Repository ที่เหมาะสม
ส่วนที่หลายองค์กรมองข้ามคือ Repository ซึ่งไม่ใช่เพียงอุปกรณ์เก็บข้อมูลธรรมดา แต่ ต้องเลือกให้สอดคล้องกับความเร็วที่ต้องใช้ในวันที่กู้คืน เช่น ระบบงานที่ต้องกู้กลับในไม่กี่นาที ต้องใช้พื้นที่เก็บข้อมูลที่รองรับ I/O สูงมาก ในขณะที่ข้อมูลทั่วไปที่ต้องเก็บนานอาจเหมาะกับสื่อ อีกประเภทหนึ่ง
การวาง repository ในแบบที่เหมาะสมจึงเป็นทั้งศาสตร์และศิลป์ของงาน Backup Architecture ไม่ว่าจะเป็น NAS, block storage, appliance ระดับองค์กร หรือ object storage บน cloud ก็ต้องเลือกใช้ให้สอดคล้องกับระดับความสำคัญของข้อมูลจริง ๆ ไม่ใช่เพียงเพราะเป็นแบรนด์ใดแบรนด์หนึ่ง
4. สร้าง Multi-Tier Backup
เมื่อออกแบบสถาปัตยกรรม repository เสร็จ ระบบจะถูกขยายไปเป็น multi-tier backup เพื่อสร้างความปลอดภัยหลายชั้นสำรองกันเอง เช่น สำเนาแบบใกล้ระบบเพื่อกู้คืนเร็วที่สุด, สำเนาที่เก็บไว้นานเพื่อป้องกันความผิดพลาดหรือการลบโดยไม่ตั้งใจ และสำเนานอกสถานที่ที่ ใช้เมื่อเกิดเหตุการณ์ใหญ่ ซึ่งทั้งหมดต้องทำงานร่วมกันได้อย่างราบรื่นโดยไม่สร้างภาระเกิน ควรต่อทรัพยากรของลูกค้า
5. กำหนด RTO/RPO ที่แท้จริง
เราปรับทุกส่วนให้สัมพันธ์กับ RTO/RPO ที่ธุรกิจต้องการจริง ไม่ใช่ค่าที่ตั้งไว้ตามเอกสาร ค่าที่องค์กรรับได้คือสิ่งที่สำคัญที่สุด เช่น บางระบบยอมให้ข้อมูลสูญเสียได้เพียงไม่กี่นาที บาง ระบบยอมได้เป็นชั่วโมง และบางระบบจำเป็นต้องกู้กลับให้ได้ทันที สิ่งเหล่านี้ทำให้ สถาปัตยกรรมของแต่ละองค์กรมีความแตกต่างกันโดยสิ้นเชิง และเป็นเหตุผลว่าทำไม VIRYA ไม่เคยทำ Backup แบบ “สูตรสำเร็จ”
6. ทดสอบการกู้คืน (Restore Test)
เพื่อให้มั่นใจว่าระบบนี้พร้อมใช้งานจริง เราจะทำการทดสอบกู้คืนเต็มรูปแบบใน สถานการณ์จำลอง เพื่อพิสูจน์ว่าสถาปัตยกรรมที่วางไว้ทำงานได้ตามเวลาที่กำหนด ทั้งการกู้คืน ระดับไฟล์ ระบบทั้งเครื่อง หรือการย้าย workload ไปยังระบบสำรองชั่วคราว รวมถึงการตั้งค่า DR Workflow ที่รองรับสถานการณ์ไฟดับทั้งตึกหรือระบบหลักขัดข้องกะทันหัน
ประสบการณ์ในหลายโครงการทำให้เห็นชัดว่า เมื่อสถาปัตยกรรม Backup ถูกออกแบบ อย่างถูกต้อง
ธุรกิจสามารถสำรองข้อมูลเสร็จในเวลาที่สั้นลง กู้คืนได้จริง และลดภาระของทีม ไอทีลงอย่างมาก
ทั้งยังเพิ่มความมั่นใจให้ฝ่ายบริหารว่าสามารถรับมือกับเหตุการณ์ไม่คาดฝัน ได้มากขึ้น
ตัวอย่างจากงานจริง
Case Study 1: ปรับลด Backup Window
ในระบบหนึ่งที่มี VM จำนวนมากบน Storage ระดับองค์กร การสำรองข้อมูลเดิมใช้เวลา ยาวจนกินเวลาเข้าเช้าวันถัดไป บางวันสำรองไม่ทัน ก่อนที่ทีมเราจะเข้าไป โครงสร้างทางเทคนิค ไม่ได้ผิด แต่ออกแบบไม่เข้ากับรูปแบบการทำงานจริงของระบบและเวลาที่ธุรกิจต้องการ เมื่อเรา ปรับเส้นทางการรับข้อมูลและออกแบบการทำงานร่วมกับ snapshot ที่ Storage มีอยู่ ผลคือ backup window สั้นลงอย่างมาก และไม่กระทบระบบผลิตอีกต่อไป ขณะที่การกู้คืนทำได้เร็วขึ้น หลายเท่า
Case Study 2: สร้าง Repository หลายชั้น
ในอีกระบบหนึ่ง องค์กรเก็บสำรองข้อมูลไว้เพียงชุดเดียวใน NAS ลำพัง ไม่มีการแยก สำเนา ไม่มีสำเนาออกนอกสถานที่ และไม่มีกลไกป้องกันการลบหรือติด ransomware ทำให้ ความเสี่ยงสูงโดยที่ผู้บริหารไม่รู้ตัว เมื่อปรับเป็น repository หลายชั้นที่รองรับทั้งการกู้คืนทันที การเก็บสำเนานาน และการสร้างสำเนาที่ไม่สามารถลบแก้ไขได้ องค์กรก็มีระบบสำรองข้อมูลที่ มั่นคงขึ้นทันทีโดยไม่ต้องปรับโครงสร้างระบบผลิตเลย