สำรอง PostgreSQL แบบไหน ถึงจะกู้กลับได้ตรงงาน

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

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

PostgreSQL มีทางเลือกสำรองหลายลักษณะครับ ลองแยกสิ่งที่แต่ละแบบเก็บกับเส้นทางกู้ก่อน แล้วค่อยเลือกความถี่ ที่เก็บ และการตรวจให้เหมาะกับงานที่เราดูแล

เริ่มจากข้อมูลที่ยอมเสียกับเวลาที่ยอมรอ

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

เช่น ข้อมูลบางกลุ่มอาจอ่านกลับมาจากต้นทางได้ ขณะที่ข้อมูลที่คนกรอกไว้เองอาจสร้างใหม่ไม่ได้ ทั้งสองกลุ่มอยู่ในฐานข้อมูลเดียวกันได้ จึงต้องรู้ว่าความเสียหายของการย้อนหนึ่งช่วงหมายถึงอะไรจริงๆ ก่อนเลือกว่ารอบคืนละครั้งเพียงพอหรือไม่

เวลาที่ใช้กู้ก็มีมากกว่าระยะนำไฟล์เข้าฐานข้อมูล ยังมีการเตรียมเครื่อง รุ่น PostgreSQL, extension, สิทธิ์ และการเปิดแอปตรวจ เมื่อประเมินเวลาต้องรวมเส้นทางเหล่านี้ ไม่เอาเวลาโหลดไฟล์อย่างเดียวไปใช้เป็นคำรับรองว่าบริการจะกลับมาได้ภายในนั้น

ควรมีรายการของที่ต้องใช้ร่วมกับฐานข้อมูลด้วย เช่น ไฟล์อัปโหลดหรือค่าตั้งบริการ หากข้อมูลในตารางอ้างไฟล์ที่ไม่มีในสำเนาเดียวกัน ต่อให้ฐานข้อมูล restore ผ่าน แอปก็ยังอาจทำงานไม่ครบตามที่คนใช้ต้องการ

logical dump เหมาะกับการเก็บโครงและข้อมูลตามฐาน

pg_dump ใช้ดึงข้อมูลฐานหนึ่งออกมาในรูปแบบที่เครื่องมือรองรับ โดยมีทั้ง plain SQL และ archive formats การเลือกรูปแบบมีผลกับวิธีกู้และความยืดหยุ่นในการเลือกส่วนที่นำกลับ จึงควรเลือกพร้อมขั้นตอน restore ไม่เลือกจากนามสกุลที่ดูคุ้นอย่างเดียว

จุดที่ต้องจำคือ dump ของฐานหนึ่งไม่ได้ครอบคลุม global objects ทุกอย่างของ cluster เช่น roles หรือตัวตั้งค่าบางส่วน เราจึงต้องมีรายการสิ่งที่ต้องเตรียมเพิ่มเติมตามขอบเขตของบริการ ไม่คิดว่าไฟล์เดียวชื่อฐานข้อมูลเป็นสำเนาของทั้งเครื่องแล้ว

logical dump ช่วยแยกข้อมูลออกจากรายละเอียดไฟล์ภายในได้ในหลายกรณี แต่การกู้ก็ยังมีเงื่อนไขเวอร์ชันและ dependency เช่น extension กับสิทธิ์ที่ต้องมี ควรตรวจรุ่นของ client ที่ใช้สำรองกับ server ต้นทางและปลายทางตามคู่มือ ไม่สมมติว่าสลับรุ่นใดก็ได้ทุกทิศทาง

ระหว่างรันต้องเก็บ exit status กับข้อความผิดพลาดไว้ด้วย การมีไฟล์ขนาดมากกว่าศูนย์ไม่ได้ยืนยันว่าการส่งออกจบครบ และถ้ามี pipeline บีบอัดหรือส่งต่อ ก็ต้องตรวจผลของทุกขั้น ไม่ให้คำสั่งท้ายผ่านแล้วกลบความล้มเหลวของขั้นสำรอง

สำเนาระดับไฟล์ต้องรักษาความสอดคล้องของฐาน

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

วิธีระดับกายภาพมีข้อกำหนดต่างจาก logical dump ทั้งขอบเขตของข้อมูลและความเข้ากันได้ตอนกู้ ถ้าเลือกวิธีนี้ก็ควรเก็บรายละเอียด cluster และขั้นตอนที่จำเป็นให้ครบ ไม่พึ่งว่าการเปิด container ด้วย tag เดิมจะทำให้ข้อมูลทุกอย่างเข้ากันเอง

snapshot ของ storage ก็ต้องประเมินตามความสามารถและเงื่อนไขของระบบจริง ไม่ใช่เห็นคำว่า snapshot แล้วถือว่าเท่ากับการสำรอง PostgreSQL แบบครบวงจร ต้องรู้ว่าครอบคลุมส่วนที่เกี่ยวข้องในจุดสอดคล้องเดียวกันหรือไม่และจะนำกลับอย่างไร

อยากย้อนใกล้จุดเกิดเหตุ ต้องดู base backup กับ WAL

continuous archiving และ point-in-time recovery ใช้ฐานสำรองร่วมกับ WAL ที่เก็บต่อเนื่องตามข้อกำหนด เพื่อกู้ไปยังจุดที่อยู่ในขอบเขตข้อมูลที่มีได้ จึงช่วยตอบโจทย์ต่างจากการมี dump เป็นช่วงๆ เพียงอย่างเดียว

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

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

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

สำเนาที่อยู่ที่เดิมยังมีความเสี่ยงร่วมกัน

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

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

ทดลองกู้แล้วค่อยอธิบายความพร้อม

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

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

สรุป

การเลือก backup PostgreSQL ควรเริ่มจากข้อมูลที่ยอมเสียและเวลาที่ต้องกลับมาใช้ได้ แล้วจับคู่กับ logical dump, วิธีระดับไฟล์ หรือ base backup กับ WAL ตามเงื่อนไข เมื่อเก็บสิ่งที่ต้องใช้ร่วมและทดลองกู้ในพื้นที่แยก เราจะมีคำตอบว่าระบบพร้อมฟื้นตัวอย่างไร มากกว่ารู้เพียงว่างานสำรองเมื่อคืนขึ้นว่าสำเร็จครับ