วิธีสำรองฐานข้อมูลแอปของคุณ (และกู้คืนได้จริง)

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

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

การสำรองข้อมูลต้องครอบคลุมอะไรบ้าง

แอปไม่ได้มีเพียงฐานข้อมูล ควรรู้ว่าการสำรองแต่ละส่วนปกป้องอะไร

ข้อมูลคือส่วนที่สร้างใหม่ไม่ได้ โค้ดเขียนใหม่ได้ และการตั้งค่าก็กรอกใหม่ได้ แต่คำสั่งซื้อของลูกค้าทำไม่ได้

ขั้นตอนที่ 1: ตัดสินใจว่าข้อมูลสูญหายได้มากแค่ไหน

มีสองคำถามที่กำหนดแผนการสำรองข้อมูลของคุณ:

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

สำหรับแอปขนาดเล็กส่วนใหญ่ การสำรองอัตโนมัติวันละครั้งบวกการสำรองด้วยตนเองก่อนการเปลี่ยนแปลงที่มีความเสี่ยงถือเป็นจุดเริ่มต้นที่เหมาะสม แอปที่เกี่ยวข้องกับเงินหรือข้อมูลสุขภาพควรสำรองบ่อยกว่า หรือใช้ฐานข้อมูลที่ผู้ให้บริการจัดการให้พร้อมการกู้คืนแบบระบุเวลา (point-in-time recovery) ซึ่งหมายถึงความสามารถในการกู้คืนไปยังช่วงเวลาใดก็ได้ ไม่ใช่เฉพาะจุดสำรองล่าสุด

ขั้นตอนที่ 2: ตรวจสอบว่าผู้ให้บริการของคุณทำอะไรให้อยู่แล้ว

ผู้ให้บริการฐานข้อมูลที่มีการจัดการหลายรายสำรองข้อมูลอัตโนมัติให้อยู่แล้ว ควรตรวจสอบว่า:

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

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

ขั้นตอนที่ 3: สร้างไฟล์ดัมพ์ด้วย pg_dump

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

ตัวอย่างคำสั่งทั่วไป โดยใช้สตริงการเชื่อมต่อที่แอปของคุณมีอยู่แล้วในตัวแปรสภาพแวดล้อม:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

ตัวเลือกแต่ละตัวทำหน้าที่ดังนี้:

• --format=custom เขียนไฟล์บีบอัดที่ pg_restore อ่านได้ และช่วยให้กู้คืนตารางเดียวในภายหลังได้ ใช้ --format=plain หากต้องการไฟล์ .sql ที่อ่านได้
• --no-owner ไม่รวมคำสั่งเกี่ยวกับความเป็นเจ้าของ ทำให้การกู้คืนไปยังฐานข้อมูลอื่นง่ายขึ้น
• วันที่ในชื่อไฟล์ช่วยแยกไฟล์สำรองแต่ละครั้งออกจากกัน

เวอร์ชันของ pg_dump ควรเท่ากับหรือใหม่กว่าเวอร์ชัน Postgres ของฐานข้อมูล pg_dump รุ่นเก่าอาจไม่ยอมทำงาน

หากคุณสร้างแอปด้วย AI และไม่อยากแตะบรรทัดคำสั่ง ลองขอแบบนี้:

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

ขั้นตอนที่ 4: ทำให้เป็นอัตโนมัติ

การสำรองด้วยตนเองมักถูกลืม จึงควรทำให้เป็นอัตโนมัติด้วยสิ่งที่การตั้งค่าของคุณรองรับ:

• การสำรองตามกำหนดเวลาของผู้ให้บริการฐานข้อมูล หากผู้ให้บริการมีให้
• งานที่ตั้งเวลาไว้ บนเซิร์ฟเวอร์หรือบริการ CI ที่รัน pg_dump และอัปโหลดไฟล์ไปยังที่เก็บข้อมูล
• บริการสำรองข้อมูลแบบโฮสต์ ที่เชื่อมต่อกับฐานข้อมูลของคุณ

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

ขั้นตอนที่ 5: เก็บสำเนาไว้ที่อื่น

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

• ฐานข้อมูลที่ใช้งานอยู่
• การสำรองอัตโนมัติของผู้ให้บริการ
• ไฟล์ดัมพ์ของคุณเองในที่เก็บแยกต่างหาก เช่น bucket ของ object storage ในบัญชีอื่น

นอกจากนี้:

• จำกัดการเข้าถึง การสำรองข้อมูลมีข้อมูลของผู้ใช้ทุกคน ให้ปฏิบัติกับมันเหมือนฐานข้อมูลที่ใช้งานอยู่
• มีนโยบายการเก็บรักษา เช่น สำรองรายวันไว้สองสัปดาห์ และรายเดือนไว้หนึ่งปี ลบไฟล์เก่าอย่างตั้งใจ และจำไว้ว่ากฎหมายคุ้มครองข้อมูลอาจกำหนดให้คุณต้องลบข้อมูลส่วนบุคคลเมื่อถูกร้องขอ
• อย่า commit ไฟล์สำรองลงใน Git ไฟล์ดัมพ์ในที่เก็บโค้ดคือการรั่วไหลของข้อมูลที่รอเกิดขึ้น

ขั้นตอนที่ 6: ทดสอบการกู้คืน

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

1. สร้างฐานข้อมูลใหม่ที่ว่างเปล่า อย่ากู้คืนทับฐานข้อมูลที่ใช้งานอยู่เพื่อทดสอบ
2. กู้คืนไฟล์สำรองล่าสุดเข้าไป:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

สำหรับไฟล์ .sql ธรรมดา ให้ใช้ psql "$TEST_DATABASE_URL" -f backup.sql แทน

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

ขั้นตอนที่ 7: สำรองข้อมูลก่อนการเปลี่ยนแปลงที่มีความเสี่ยง

ควรสำรองใหม่ทันทีก่อน:

• รันการย้ายข้อมูล (migration) ฐานข้อมูลที่ลบหรือเปลี่ยนชื่อคอลัมน์
• นำเข้าข้อมูลจำนวนมาก
• ปล่อยให้เอเจนต์ AI ทำการเปลี่ยนแปลงขนาดใหญ่กับโครงสร้างข้อมูล
• ลบระเบียนเก่า

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

ข้อผิดพลาดที่พบบ่อย

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

การสำรองข้อมูลกับ Mythex

โปรเจกต์ Mythex สามารถมีฐานข้อมูล Postgres เฉพาะของตัวเองได้ และรายละเอียดการเชื่อมต่อจะถูกฉีดเข้าไปในพื้นที่ทำงานและแอปที่เผยแพร่แล้ว เอกสารของ Mythex ไม่ได้อธิบายฟีเจอร์การสำรองหรือกู้คืนฐานข้อมูล จึงควรวางแผนการสำรองเอง ขอให้เอเจนต์สร้างไฟล์ดัมพ์ ดาวน์โหลด และเก็บไว้ในที่ปลอดภัย โดยเฉพาะก่อนการเปลี่ยนแปลงใหญ่ การส่งออกโปรเจกต์ (Pro) จะมีโค้ดของคุณ โดยไม่รวมความลับและ node_modules แต่ไม่มีแถวข้อมูลในฐานข้อมูล ดูเพิ่มเติมได้ที่ Database และ Data ownership ในเอกสาร และหากต้องการข้อมูลเกี่ยวกับฐานข้อมูลเอง อ่าน Postgres คืออะไร

รายการตรวจสอบการสำรองข้อมูล

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

คำถาม