วางแผนสำรอง PostgreSQL ให้กู้คืนได้จริงด้วย pg_dump, WAL และ PITR

การสำรองฐานข้อมูลที่ดีไม่ได้วัดจากการมีไฟล์ backup อยู่ในพื้นที่จัดเก็บเท่านั้น แต่ต้องตอบให้ได้ว่าหากระบบเสียหายตอนนี้จะกู้กลับมาได้จริงหรือไม่ และธุรกิจยอมสูญเสียข้อมูลย้อนหลังได้มากที่สุดกี่นาที คำถามเหล่านี้ทำให้ backup เปลี่ยนจากงานประจำทางเทคนิคไปเป็นแผนรับมือเหตุขัดข้องของระบบ production

Backup ที่ดีต้องเริ่มจากการกู้คืน

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

ก่อนออกแบบระบบสำรองข้อมูล ทีมควรตอบคำถามสำคัญสองข้อให้ชัดเจน ได้แก่ ยอมให้ข้อมูลสูญหายย้อนหลังได้นานเพียงใด และยอมให้ระบบหยุดทำงานระหว่างการกู้คืนได้นานเท่าไร คำตอบจะเป็นตัวกำหนดว่าควรใช้ pg_dump เพียงอย่างเดียว หรือจำเป็นต้องมี physical backup, WAL archive และ PITR ร่วมด้วย

เริ่มต้นกับ Logical Backup ด้วย pg_dump

ผู้ที่เริ่มดูแล PostgreSQL บน production มักรู้จัก pg_dump เป็นเครื่องมือแรก เพราะใช้งานง่ายและเหมาะกับงานหลายประเภท pg_dump สร้าง logical backup โดยสำรองข้อมูลในระดับโครงสร้างและวัตถุของฐานข้อมูล เช่น schema, table, index, data, function และ permission บางส่วน

Logical backup มีความยืดหยุ่นสูง เพราะสามารถนำไปกู้บนอีกเซิร์ฟเวอร์หนึ่งหรือเลือกกู้เฉพาะวัตถุบางรายการได้ จึงเหมาะทั้งกับการย้ายฐานข้อมูล การสร้าง staging จาก production การส่งชุดข้อมูลให้ทีมพัฒนา และการกู้คืนเฉพาะ table ที่ได้รับความเสียหาย

ตัวอย่างการสร้าง backup แบบ custom format และกู้ไปยังฐานข้อมูลปลายทางมีดังนี้

pg_dump -Fc mydb > mydb.dump
pg_restore -d mydb_restore mydb.dump

ตัวเลือก -Fc สั่งให้ pg_dump ใช้ custom format ซึ่งเหมาะกับงานกู้คืนที่ต้องการความยืดหยุ่นมากกว่า plain SQL โดยมีประโยชน์สำคัญดังนี้

• เลือก restore เฉพาะ object ที่ต้องการได้
• รองรับการ restore แบบขนานเพื่อลดเวลาในบางสถานการณ์
• ตรวจสอบรายการ object และ metadata ภายในไฟล์ได้สะดวก

อย่างไรก็ตาม pg_dump เป็น snapshot ของฐานข้อมูล ณ เวลาที่เริ่มทำรายการสำรอง หากสร้างไฟล์ตอนตีหนึ่งแล้วฐานข้อมูลเสียหายตอนบ่ายสาม การกู้จากไฟล์ดังกล่าวอาจทำให้ข้อมูลตั้งแต่ตีหนึ่งถึงบ่ายสามสูญหายทั้งหมด เว้นแต่จะมีระบบสำรองหรือบันทึกการเปลี่ยนแปลงอีกชั้นหนึ่ง

Logical Backup และ Physical Backup ต่างกันอย่างไร

Logical backup มองฐานข้อมูลในระดับ SQL object เปรียบเสมือนการคัดลอกเนื้อหาและโครงสร้างออกจากฐานข้อมูล วิธีนี้เหมาะกับการย้ายระบบ การสร้างสำเนา การส่งออกข้อมูล หรือการกู้คืนเพียงบางส่วน

Physical backup มอง PostgreSQL ในระดับไฟล์จริงภายใน data directory โดยต้องสำรอง data files และจัดการ WAL ให้ถูกต้อง วิธีนี้เหมาะกับการกู้คืนทั้ง cluster ให้กลับมาอยู่ในสถานะเดิมมากกว่าการเลือกกู้เฉพาะ table

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

WAL และ Point-in-Time Recovery

WAL หรือ Write-Ahead Log คือบันทึกการเปลี่ยนแปลงของ PostgreSQL ก่อนที่การเปลี่ยนแปลงจะถูกเขียนลง data file ระบบจะเขียนข้อมูลลง WAL ก่อนเพื่อรองรับกลไกอย่าง crash recovery และ replication

หากเก็บ base backup ควบคู่กับ WAL อย่างต่อเนื่อง จะสามารถทำ Point-in-Time Recovery หรือ PITR ได้ แนวทางนี้ช่วยกู้ฐานข้อมูลกลับไปยังเวลาที่กำหนด เช่น ช่วงก่อนมีผู้รันคำสั่ง DELETE ผิด table ตอน 14:37 น.

กระบวนการ PITR สามารถอธิบายเป็นลำดับได้ดังนี้

1. ใช้ base backup เป็นจุดตั้งต้นของฐานข้อมูล
2. นำ WAL ที่จัดเก็บไว้มาประมวลผลต่อจากจุดนั้น
3. Replay การเปลี่ยนแปลงไปตามลำดับเวลา
4. หยุดเมื่อถึงเวลาหรือเหตุการณ์ก่อนเกิดความเสียหาย

กล่าวอย่างง่าย Base backup คือภาพตั้งต้น ส่วน WAL archive คือเส้นทางของการเปลี่ยนแปลงหลังจากนั้น เมื่อนำทั้งสองส่วนมารวมกัน ระบบจึงสามารถย้อนกลับไปยังจุดที่ต้องการได้ละเอียดกว่าการกู้จาก pg_dump เพียงไฟล์เดียว

กำหนด RPO และ RTO ให้ชัดเจน

RPO หรือ Recovery Point Objective ระบุว่าระบบยอมสูญเสียข้อมูลย้อนหลังได้มากที่สุดเท่าไร หากกำหนด RPO ไว้ที่ 5 นาที ระบบสำรองต้องจัดเก็บ WAL หรือใช้ความสามารถของผู้ให้บริการที่ทำให้ข้อมูลซึ่งอาจสูญหายไม่เกินประมาณ 5 นาที

RTO หรือ Recovery Time Objective ระบุว่าระบบยอมให้บริการหยุดทำงานได้นานเพียงใด หาก RTO เท่ากับ 30 นาที ขั้นตอนกู้ฐานข้อมูล เชื่อมต่อแอปพลิเคชัน และตรวจสอบความพร้อมต้องเสร็จภายใน 30 นาทีจริง ไม่ใช่เพียงการคาดเดาว่าน่าจะทำได้

การกำหนดค่าเหล่านี้ควรสัมพันธ์กับความสำคัญของระบบและวิธี backup ที่เลือกใช้ RPO ที่สั้นมากอาจต้องพึ่ง WAL archive หรือความสามารถ PITR ของ managed database ขณะที่ RTO ที่สั้นจำเป็นต้องมีขั้นตอน restore ที่ชัดเจนและผ่านการจับเวลามาแล้ว

Restore Drill พิสูจน์ว่า Backup ใช้งานได้จริง

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

ปัญหาที่มักพบระหว่างการกู้คืนประกอบด้วย

• ไม่มี password หรือข้อมูลรับรองที่จำเป็น
• PostgreSQL extension ติดตั้งไม่ครบ
• เวอร์ชันของเครื่องมือหรือฐานข้อมูลไม่ตรงกัน
• พื้นที่ disk ไม่เพียงพอ
• กระบวนการ restore ช้ากว่าที่ประเมิน
• ไฟล์ backup เสียหรือใช้งานไม่ได้ตั้งแต่แรก

Restore drill คือการซ้อมกู้คืนตามรอบเวลา เช่น เดือนละครั้ง โดยสร้างฐานข้อมูลใหม่จาก backup ล่าสุดและตรวจสอบผลลัพธ์เหมือนเป็นเหตุการณ์จริง การซ้อมควรทำตั้งแต่ต้นจนจบและจับเวลาไว้ เพื่อพิสูจน์ทั้งความสมบูรณ์ของข้อมูลและความเป็นไปได้ของ RTO

กิจกรรมพื้นฐานของ restore drill ควรประกอบด้วย

1. สร้างฐานข้อมูลหรือ environment ใหม่สำหรับการทดสอบ
2. Restore ข้อมูลจาก backup ล่าสุด
3. รัน smoke test กับเส้นทางสำคัญของระบบ
4. ตรวจสอบจำนวน row หรือข้อมูลธุรกิจที่สำคัญ
5. ตรวจสอบความเข้ากันได้กับ migration ปัจจุบัน
6. บันทึกเวลาที่ใช้และปัญหาที่พบระหว่างกระบวนการ

สำหรับระบบ Node.js การทดสอบไม่ควรหยุดเพียงแค่เห็นฐานข้อมูลทำงาน แต่ต้องตรวจสอบการเชื่อมต่อและพฤติกรรมของส่วนประกอบอื่นด้วย เพราะฐานข้อมูลที่ restore สำเร็จอาจยังไม่พร้อมให้แอปพลิเคชันกลับมาเปิดบริการ

Checklist หลัง restore สำหรับ Node.js backend อาจประกอบด้วย

• แอปพลิเคชันเชื่อมต่อฐานข้อมูลได้หรือไม่
• ค่าใน .env ใช้ host, database และ user ถูกต้องหรือไม่
• Prisma หรือ TypeORM มองเห็น schema และสถานะ migration ถูกต้องหรือไม่
• Job queue และ worker กลับมาทำงานในสถานะที่เหมาะสมหรือไม่
• งานที่ถูกเริ่มซ้ำหลังระบบกลับมาทำงานทำให้ข้อมูลผิดเพี้ยนหรือไม่

อย่าพึ่งพา Managed Snapshot เพียงชั้นเดียว

Managed database snapshot จากผู้ให้บริการ cloud ช่วยลดภาระในการดูแล backup และมักเปิด automated backup ได้สะดวก อย่างไรก็ตาม การเปิดความสามารถนี้ไม่ได้หมายความว่าระบบพร้อมรับทุกสถานการณ์โดยอัตโนมัติ ทีมยังต้องศึกษาขอบเขตและทดลองกู้คืนตามแผนที่ใช้จริง

ข้อจำกัดที่ควรตรวจสอบมีดังนี้

• Snapshot อาจอยู่ในระดับ instance และต้องกู้กลับมาทั้งชุด
• ไม่สามารถเลือกกู้เพียง table เดียวได้โดยตรง
• ระยะเวลา retention อาจสั้นกว่าความต้องการของธุรกิจ
• การสำรองข้าม region อาจไม่ได้เปิดไว้
• การ restore และการทดสอบอาจมีค่าใช้จ่ายเพิ่มเติม
• ช่วงเวลาที่รองรับ PITR อาจขึ้นอยู่กับ plan หรือ configuration

Snapshot อาจกู้ทั้ง instance ได้รวดเร็ว แต่ไม่สะดวกเมื่อต้องการนำ table เดียวที่ถูกลบกลับมา ในสถานการณ์เช่นนี้ การมี pg_dump แยกสำหรับข้อมูลสำคัญอาจช่วยให้กู้เฉพาะส่วนได้เร็วกว่า

ออกแบบ Backup แบบหลายชั้น

แนวทางที่ใช้งานได้จริงสำหรับ production PostgreSQL คือการใช้วิธีสำรองหลายชั้นร่วมกัน แต่ละชั้นควรมีหน้าที่ชัดเจนและลดข้อจำกัดของอีกชั้นหนึ่ง

1. ใช้ pg_dump สำหรับ logical backup การย้ายข้อมูล และการกู้คืนเฉพาะส่วน
2. ใช้ physical backup ร่วมกับ WAL และ PITR สำหรับ disaster recovery และการย้อนกลับตามเวลา
3. ใช้ managed snapshot เป็น baseline ที่สะดวกสำหรับการกู้คืนระดับ instance
4. ทำ restore drill เป็นประจำเพื่อพิสูจน์ว่าไฟล์ เครื่องมือ ขั้นตอน และบุคลากรพร้อมใช้งานจริง

การเลือกแต่ละชั้นต้องอ้างอิง RPO และ RTO ของระบบ หากวิธีที่ใช้อยู่ยังรักษาข้อมูลหรือกู้ระบบกลับมาไม่ทันตามค่าที่กำหนด แผน backup นั้นก็ยังไม่ตอบโจทย์ production แม้จะสร้างไฟล์สำรองได้ทุกวันก็ตาม

สรุป

Backup ที่ไม่เคยผ่านการ restore ยังคงเป็นเพียงความหวัง เพราะไม่มีหลักฐานว่าไฟล์และขั้นตอนจะทำงานในวันที่เกิดเหตุจริง แผนสำรอง PostgreSQL ที่น่าเชื่อถือควรรวม pg_dump, physical backup, WAL, PITR หรือ managed snapshot ตามความเหมาะสม พร้อมกำหนด RPO และ RTO อย่างชัดเจน

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