Backup สำเร็จ แต่ ERP กู้ได้จริงไหม? เช็กลิสต์ซ้อมกู้คืนระบบ

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

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

1. Backup สำเร็จ ไม่ได้แปลว่ากู้ได้

การตรวจมี 3 ระดับ แต่ละระดับตอบคนละคำถาม องค์กรส่วนใหญ่หยุดอยู่ที่ระดับแรก

แม้แต่เครื่องมือของ PostgreSQL เองก็เตือนไว้ว่า pg_verifybackup ตรวจไฟล์สำรองได้ แต่ตรวจแทนการเปิดฐานข้อมูลขึ้นมาใช้จริงไม่ได้ จึงยังต้องทดลองกู้และตรวจข้อมูลอยู่ดี [1]

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

2. RPO (Recovery Point Objective) และ RTO (Recovery Time Objective) คุยกันด้วยภาษางาน

RPO (Recovery Point Objective) คือยอมให้ข้อมูลหายย้อนหลังได้นานที่สุดกี่นาทีหรือกี่ชั่วโมง RTO (Recovery Time Objective) คือยอมให้ระบบหยุดได้นานที่สุดเท่าไรก่อนกลับมาใช้งาน สองค่านี้ต้องตกลงกันระหว่างฝ่ายงานกับ IT และต้องระบุให้ชัดว่าเริ่มจับเวลาเมื่อไร และ "กลับมาใช้งานได้" หมายถึงทำอะไรได้บ้าง

ตัวอย่าง: ระบบล่มเวลา 14:00 น. ถ้าตั้ง RPO ไว้ 15 นาที ข้อมูลที่กู้กลับมาต้องครบถึงอย่างน้อย 13:45 น. ถ้าตั้ง RTO ไว้ 4 ชั่วโมง ฝ่ายงานต้องกลับมาทำงานสำคัญได้ภายใน 18:00 น. กู้ฐานข้อมูลเสร็จ 15:00 น. ยังไม่นับว่าจบ ถ้าไฟล์แนบยังเปิดไม่ได้ หรือผู้ใช้ยังล็อกอินไม่ได้

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

3. Saeree ERP มีอะไรบ้าง และต้องสำรองอะไร

ก่อนวางแผนต้องรู้ว่าระบบประกอบด้วยชิ้นส่วนอะไร Saeree ERP มีโครงสร้างไม่ซับซ้อน ข้อมูลทั้งหมดอยู่ที่เดียว

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

4. เลือกวิธีสำรองให้ตรงกับ RPO ที่ตั้งไว้

ระบบที่อยู่บน VM มีทางเลือกสำรอง 3 แบบ ใช้ร่วมกันได้ และส่วนใหญ่ควรมีอย่างน้อย 2 แบบ

ข้อควรระวังกับสคริปต์กู้ฐานข้อมูลที่มากับระบบ: ขั้นตอนกู้จะลบฐานข้อมูลเดิมแล้วสร้างใหม่ก่อนนำเข้า ให้รันบนเครื่องทดสอบเท่านั้น และตรวจชื่อฐานข้อมูลปลายทางทุกครั้งก่อนกด Enter ถ้าจะอัปเกรดรุ่น PostgreSQL ด้วย ให้แยกเป็นการทดสอบอีกรอบ จะได้รู้ว่าปัญหามาจากการกู้หรือจากการอัปเกรด อ่านเพิ่มได้ที่ ทำไม Saeree ERP เลือก PostgreSQL

5. ซ้อมบนเครื่องแยก และปิดทางออกก่อนเปิดระบบ

สร้าง VM ใหม่ในเครือข่ายที่แยกจากระบบจริง ก่อนเปิด WildFly ให้ปิดการส่งอีเมล การเชื่อมระบบภายนอก และงานตามตารางเวลา เพราะฐานข้อมูลที่กู้มาจะมีค่าตั้งค่าของระบบจริงติดมาด้วย ทั้งอีเมลผู้ใช้และปลายทางที่เชื่อมอยู่

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

# ทำบนเครื่องทดสอบเท่านั้น
createdb -U erp_user erp_test
psql -U erp_user -d erp_test -f ExpDat.dmp

# จุดข้อมูลที่กู้ได้ = เวลาของรายการล่าสุดในฐาน
psql -U erp_user -d erp_test -c "select max(created) from c_invoice;"

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

เลือกงานสำคัญไม่กี่อย่างมาทดสอบก่อน เช่น เปิดยอดงบประมาณคงเหลือ ค้นใบสั่งซื้อ เปิดไฟล์แนบของใบนั้น และลองบันทึกใบรับสินค้าหนึ่งใบ ให้คนที่ทำงานนั้นจริงเป็นคนทดสอบ ไม่ใช่ให้ IT ทดสอบแทน

6. ให้ฝ่ายงานตรวจรับ ไม่ใช่ IT บอกว่าเสร็จ

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

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

7. รายงานให้ผู้บริหารตัดสินใจได้ในหน้าเดียว

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

8. สิ่งที่เราแนะนำลูกค้า Saeree ERP

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

• สำรอง 2 ชั้น: backup ระดับ VM สำหรับกู้ทั้งเครื่องให้เร็ว และ dump ฐานข้อมูลทุกวันเก็บไว้นอกเครื่อง สำหรับจุดเวลาที่ชัดและใช้ย้ายเครื่องได้
• ต้องการ RPO ระดับนาที ค่อยเพิ่ม PITR และวางแผนพื้นที่เก็บ WAL
• เก็บ WAR รุ่นที่ใช้จริง ไฟล์ตั้งค่า WildFly และรายงานที่ปรับแต่งไว้คู่กับไฟล์สำรอง ไม่ต้องไปหาตอนเกิดเหตุ
• ซ้อมกู้ลง VM ใหม่ บน Proxmox หรือ VMware ที่ใช้อยู่ อย่างน้อยปีละครั้ง และทุกครั้งที่อัปเกรดรุ่นใหญ่
• ใช้รายการโมดูลที่องค์กรใช้จริง เป็นตัวตั้งว่าฝ่ายไหนต้องมาตรวจรับ

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

สรุป

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

ความมั่นใจว่ากู้ระบบได้ ต้องมาจากวันที่เคยกู้สำเร็จจริง ไม่ใช่จากข้อความว่า backup สำเร็จ

— ไพฑูรย์ บุตรี

แหล่งอ้างอิง

ตรวจข้อมูล 22 กันยายน 2569 — ใช้เอกสาร PostgreSQL 18 เป็นตัวอย่าง ให้เลือกคู่มือให้ตรงรุ่นที่ติดตั้ง เช็กลิสต์และตัวเลขตัวอย่างเป็นข้อเสนอของผู้เขียน

1. PostgreSQL: pg_verifybackup
2. PostgreSQL: Continuous Archiving and Point-in-Time Recovery
3. CISA, FBI, NSA และ MS-ISAC: StopRansomware Guide (2023)