ไอเดีย #74: เครื่องมือ backup ฐานข้อมูลอัตโนมัติพร้อมทดสอบ restore

มีคำพูดในวงการว่า "backup ที่ไม่เคยลอง restore ก็คือยังไม่มี backup" หลายทีมตั้ง cron ให้ pg_dump ทุกคืนแล้วก็ลืมไป จนวันที่ดิสก์พังถึงเพิ่งพบว่าไฟล์ backup เป็นศูนย์ไบต์มาสามเดือน หรือเก็บไว้บนเซิร์ฟเวอร์เดียวกับที่พังนั่นแหละ ไอเดียนี้คือเครื่องมือ backup ฐานข้อมูลอัตโนมัติที่ส่งไปเก็บนอกเครื่อง และทดสอบ restore ให้เราจริง ๆ ทุกรอบ

ใครจะใช้

• DevOps/ผู้ดูแลระบบ — ตั้งค่าฐานข้อมูล ตารางเวลา ปลายทางเก็บไฟล์ นโยบายเก็บรักษา
• นักพัฒนา — ขอ restore ฐานข้อมูลช่วงเวลาหนึ่งไปใช้ตรวจสอบปัญหา
• หัวหน้าทีม/ผู้ตรวจสอบ — ดูรายงานว่า backup และ restore test ผ่านครบทุกวัน

ฟีเจอร์ขั้นต่ำ (MVP)

• ลงทะเบียนฐานข้อมูล PostgreSQL/MySQL หลายตัว พร้อม credential ที่เข้ารหัส
• ตารางเวลาแบบ cron ต่อฐานข้อมูล รัน dump แล้วบีบอัดและเข้ารหัสไฟล์
• ส่งไฟล์ไปเก็บ offsite เช่น object storage ที่รองรับ S3 API หรือเซิร์ฟเวอร์อีกที่ผ่าน SFTP
• นโยบาย retention เช่น เก็บรายวัน 7 ชุด รายสัปดาห์ 4 ชุด รายเดือน 6 ชุด
• Restore test อัตโนมัติ: สร้าง container ฐานข้อมูลชั่วคราว restore ไฟล์ล่าสุด แล้วรัน query ตรวจ เช่น นับแถวตารางสำคัญ
• บันทึกผลทุกครั้ง: ขนาดไฟล์ เวลา checksum ผ่าน/ไม่ผ่าน
• แจ้งเตือนเมื่อ backup ล้มเหลว ขนาดไฟล์ลดลงผิดปกติ หรือ restore test ไม่ผ่าน

ต่อยอดได้อีก

• รองรับ backup แบบต่อเนื่อง (WAL archiving) เพื่อ restore ถึงเวลาที่ต้องการ
• คำสั่ง restore แบบคลิกเดียวไปยัง staging พร้อม mask ข้อมูลส่วนบุคคล
• วัด RTO จริงจากเวลาที่ restore ใช้
• backup ไฟล์ uploads ของแอปควบคู่กัน

โครงข้อมูลตั้งต้น

• db_target — id, name, engine, host, port, db_name, credential_enc, schedule_cron
• storage_target — id, type (s3/sftp), config_enc
• backup_run — id, db_target_id, started_at, finished_at, status, file_key, size_bytes, checksum
• restore_test — id, backup_run_id, started_at, duration_sec, status, checks_json
• retention_policy — id, db_target_id, keep_daily, keep_weekly, keep_monthly

ระดับความยาก และสิ่งที่จะได้เรียนรู้

ปานกลาง

• ใช้ pg_dump/pg_restore และเข้าใจข้อดีข้อเสียของแต่ละ format
• ควบคุม Docker จากโค้ดเพื่อสร้างฐานข้อมูลชั่วคราว
• stream ไฟล์ขนาดใหญ่ขึ้น storage โดยไม่กินหน่วยความจำ
• เขียนอัลกอริทึม retention แบบ grandfather-father-son

ข้อควรระวัง

• ไฟล์ backup มีข้อมูลทั้งหมดของระบบ ต้องเข้ารหัสก่อนออกจากเครื่อง และเก็บ key แยกจากไฟล์
• credential ฝั่ง storage ควรมีสิทธิ์แค่เขียน ไม่ควรลบได้ เผื่อเครื่องโดนเจาะแล้วถูกลบ backup ทิ้ง
• ถ้านำ backup ไป restore บน staging ต้อง mask ข้อมูลส่วนบุคคลตามหลัก PDPA

ทีมคุณเคยลอง restore จริงครั้งล่าสุดเมื่อไรครับ บอกกันตรง ๆ ได้ 555? และสำหรับ restore test ควรตรวจอะไรบ้างถึงจะมั่นใจว่าข้อมูลใช้ได้จริง ไม่ใช่แค่ restore ไม่ error มาช่วยกันลิสต์ครับ ใครทำแล้วแชร์สคริปต์ในกระทู้ได้เลย