ในโลกของระบบฐานข้อมูลที่ขับเคลื่อนด้วยข้อมูล (Data-Driven World) ความล้มเหลวของระบบไม่ใช่คำถามว่า ‘จะเกิดขึ้นหรือไม่’ แต่คือ ‘เมื่อไหร่ที่มันจะเกิดขึ้น’ การหยุดชะงักของฐานข้อมูล PostgreSQL ที่สำคัญเพียงชั่วขณะ อาจส่งผลกระทบทางการเงินและชื่อเสียงขององค์กรได้อย่างมหาศาล ดังนั้น กลไกของการสำรองข้อมูล (Backup) และการกู้คืนระบบ (Restoration) จึงเป็นรากฐานสำคัญที่ทุกสถาปนิกระบบต้องเข้าใจอย่างลึกซึ้ง
หลักการกู้คืนระบบ PostgreSQL: RPO และ RTO คืออะไร?
ก่อนที่เราจะลงมือปฏิบัติการกู้คืน เราต้องเข้าใจแนวคิดหลักทางสถาปัตยกรรมก่อน การกู้คืนระบบไม่ได้หมายถึงแค่การ ‘ย้อนเวลา’ แต่คือการบริหารจัดการความเสี่ยงที่ต้องตอบโจทย์สองตัวแปรสำคัญ:
- RPO (Recovery Point Objective): คือปริมาณข้อมูลสูงสุดที่องค์กรยอมรับได้ที่จะสูญเสียไป (เช่น ถ้า RPO คือ 1 ชั่วโมง หมายความว่าข้อมูลที่สูญเสียไปต้องไม่เกิน 1 ชั่วโมง)
- RTO (Recovery Time Objective): คือระยะเวลาสูงสุดที่ระบบต้องกลับมาทำงานได้ตามปกติ (เช่น ถ้า RTO คือ 4 ชั่วโมง หมายความว่าต้องกู้คืนและใช้งานได้ภายใน 4 ชั่วโมง)
สำหรับ PostgreSQL การบรรลุ RPO และ RTO ที่ต่ำที่สุดต้องใช้กลยุทธ์ที่ซับซ้อนกว่าการ Dump และ Restore ธรรมดา นั่นคือการใช้เทคนิค Point-in-Time Recovery (PITR)
ขั้นตอนการกู้คืนข้อมูลด้วย PostgreSQL (The Restoration Process)
การกู้คืนข้อมูลใน PostgreSQL สามารถทำได้หลายวิธี ขึ้นอยู่กับความรุนแรงของความเสียหายและ RPO ที่กำหนดไว้:
1. การกู้คืนแบบ Dump/Restore (กรณีระบบล่มไม่มาก)
เป็นวิธีพื้นฐานที่สุด ใช้เมื่อต้องการกู้คืนข้อมูล ณ จุดเวลาที่ทำการ Backup ได้สำเร็จ โดยใช้คำสั่ง pg_dump เพื่อสร้างไฟล์สำรอง และใช้ psql หรือ pg_restore เพื่อนำกลับเข้าสู่ระบบ
SQL
# 1. Dump ฐานข้อมูล (Backup)
pg_dump -U user -d original_db > backup_file.sql
# 2. Restore ฐานข้อมูล (Recovery)
psql -U user -d target_db < backup_file.sql
2. Point-in-Time Recovery (PITR) (กรณีต้องการย้อนเวลา)
นี่คือเทคนิคระดับ Senior Architect ที่ใช้เมื่อระบบล่มและต้องการกู้คืนข้อมูลให้กลับไป ณ เวลาที่เกิดเหตุการณ์ (เช่น ก่อนที่ผู้ใช้จะรันคำสั่ง DELETE ข้อมูลสำคัญ) PITR ต้องอาศัยการสำรองข้อมูลหลัก (Base Backup) และไฟล์ Write-Ahead Log (WAL) ที่ถูกเก็บไว้ต่อเนื่อง
- เตรียมสภาพแวดล้อม: ต้องให้ PostgreSQL ทำงานในโหมด Recovery
- สั่งกู้คืน: ใช้คำสั่ง
recovery_target_timeเพื่อระบุเวลาที่ต้องการกู้คืน
SQL
# ตัวอย่างการตั้งค่าไฟล์ postgresql.conf เพื่อเปิดใช้งาน PITR
restore_command = 'cp /path/to/wal/%f %p'
recovery_target_time = '2024-06-15 10:00:00 UTC'
บทสรุป: การทดสอบคือหัวใจสำคัญ
การมีแผน Disaster Recovery (DR Plan) ที่สมบูรณ์เป็นสิ่งจำเป็น แต่สิ่งที่สำคัญกว่าคือการ ทดสอบ แผนนั้นอย่างสม่ำเสมอ การจำลองสถานการณ์กู้คืนข้อมูลเป็นประจำ จะช่วยให้ทีมงานมั่นใจได้ว่า เมื่อเกิดวิกฤตจริง ระบบจะสามารถกลับมาทำงานได้ตาม RTO ที่กำหนดไว้ได้อย่างมีประสิทธิภาพและแม่นยำ