Backup / Restore
บทนี้จะสอนการสำรองข้อมูล (Backup) และการกู้คืนข้อมูล (Restore) ในบริบท Docker Data แบบละเอียดสำหรับผู้เริ่มต้น โดยเริ่มจากเหตุผลเชิงธุรกิจและความเสี่ยงจริงก่อน แล้วค่อยไปสู่ขั้นตอนพื้นฐานที่ทำได้ทันที เช่น backup volume ด้วย container ชั่วคราวและ tar รวมถึงการ restore กลับเข้า volume อย่างเป็นลำดับ
ภาพ flow backup: อ่านข้อมูลจาก volume ผ่าน container ชั่วคราว แล้วสร้างไฟล์ archive เพื่อนำไปเก็บรักษา
ภาพ flow restore: นำไฟล์ archive มาแตกกลับเข้า volume เป้าหมาย แล้วทดสอบก่อนนำกลับไปใช้จริง
ภาพเตือนความเสี่ยง: การมี volume อย่างเดียวไม่เพียงพอเมื่อเกิดลบผิด ดิสก์เสีย หรือเครื่องพัง
ภาพจำสำคัญบทนี้
Volume ช่วยเรื่องความคงอยู่ข้าม lifecycle ของ container แต่ Backup คือหลักประกันว่าเราจะกู้ข้อมูลกลับมาได้เมื่อเกิดเหตุไม่คาดคิด
ส่วนที่ 1
1) Backup คืออะไร
Backup คือการคัดลอกข้อมูลสำคัญออกจากแหล่งหลักไปเก็บไว้อีกที่หนึ่ง เพื่อให้มีสำเนาสำรองเมื่อเกิดปัญหา เช่น ไฟล์เสียหาย volume ถูกลบ หรือเครื่องพัง อธิบายแบบง่าย: Backup คือการเตรียมแผนหนีไฟให้ข้อมูลของเรา ถ้าแหล่งข้อมูลหลักหาย เราจะยังมีไฟล์สำรองไว้กู้ระบบกลับมาได้
ประเด็นที่ 1
Backup ไม่ใช่แค่ copy ไฟล์ แต่คือการเตรียมพร้อมรับเหตุไม่คาดคิด
ประเด็นที่ 2
เป้าหมายคือให้ข้อมูลสำคัญกลับมาใช้งานได้
ประเด็นที่ 3
ต้องทำอย่างสม่ำเสมอ ไม่ใช่ทำครั้งเดียวแล้วจบ
ประเด็นที่ 4
ต้องเก็บสำเนาไว้คนละที่กับข้อมูลหลักอย่างน้อยหนึ่งชุด
ส่วนที่ 2
2) Restore คืออะไร
Restore คือกระบวนการนำข้อมูลจาก backup กลับมาใช้งานจริงเมื่อข้อมูลต้นฉบับสูญหายหรือใช้งานไม่ได้ มองเป็นภาพง่าย ๆ: Backup คือการเก็บร่มไว้ก่อนฝนตก ส่วน Restore คือการหยิบร่มมาใช้ตอนฝนตกจริง
- Restore ที่ดีต้องทำได้จริงภายใต้เวลาจำกัด
- ต้องรู้ชัดว่าจะกู้ข้อมูลชุดไหน (backup version ไหน)
- ต้องตรวจสอบหลัง restore ว่าข้อมูลใช้งานได้จริง
- ถ้าไม่เคยซ้อม restore เลย ถือว่ายังเสี่ยงสูง
ส่วนที่ 3
3) ทำไมระบบที่ใช้ Docker Volume ยังต้อง backup
Docker Volume ช่วยให้ข้อมูลอยู่รอดข้ามการลบหรือสร้าง container ใหม่ก็จริง แต่ไม่ได้ป้องกันทุกความเสี่ยง ถ้าคุณลบ volume ผิด, ดิสก์เสีย, เครื่องหาย, ไฟล์ใน volume ถูกเขียนทับผิด หรือข้อมูลเสียหายจากแอป Volume อย่างเดียวช่วยไม่ได้ จึงยังต้องมี backup เสมอ
- Volume ป้องกันการหายจาก lifecycle ของ container
- Backup ป้องกันการหายจากความผิดพลาด/ภัยพิบัติ
- มี Volume แต่ไม่มี Backup = ยังมี single point of failure
- ระบบจริงต้องมีทั้ง persistence และ backup คู่กัน
ส่วนที่ 4
4) ตัวอย่างสถานการณ์ที่ข้อมูลอาจสูญหาย
ปัญหาต่อไปนี้เกิดจริงบ่อยในทีมที่เริ่มใช้ Docker และมักเกิดตอนรีบ deploy หรือ cleanup เครื่อง
| สถานการณ์ | สิ่งที่เสียหายได้ | ผลกระทบ |
|---|---|---|
| container พังแล้วสร้างใหม่ | ข้อมูลที่เก็บใน writable layer | ข้อมูลหายหากไม่ได้แยกออกมาเป็น volume |
| ลบ volume ผิด (`docker volume rm`) | ข้อมูลถาวรใน volume | ระบบหยุดทำงานและข้อมูลอาจหายถาวร |
| เครื่อง host พังหรือดิสก์เสีย | ทั้ง container + volume บนเครื่องนั้น | กู้ไม่ได้ถ้าไม่มี backup ที่อยู่อีกที่ |
| แอปเขียนข้อมูลผิด/ลบข้อมูลผิด | ข้อมูลใน volume ถูกทำลาย | ต้องย้อนกลับด้วย backup รุ่นก่อนหน้า |
ส่วนที่ 5
5) แนวคิดการ backup volume
แนวคิดหลักคืออ่านข้อมูลจาก volume แล้วแพ็กเป็นไฟล์ archive (เช่น .tar.gz) เก็บไว้ในที่ปลอดภัย สำหรับผู้เริ่มต้น วิธีพื้นฐานที่นิยมคือใช้ container ชั่วคราว mount volume + mount โฟลเดอร์ปลายทาง แล้วใช้ `tar` สร้างไฟล์ backup
ประเด็นที่ 1
มี source volume (ต้นทาง)
ประเด็นที่ 2
มี backup destination (ปลายทางเก็บไฟล์)
ประเด็นที่ 3
ใช้เครื่องมือ archive เช่น tar
ประเด็นที่ 4
ตั้งชื่อไฟล์ backup ให้สื่อวันที่เวลา
ส่วนที่ 6
6) แนวคิดการ restore volume
Restore คือการแตกไฟล์ archive กลับลง volume เป้าหมาย เพื่อให้ service กลับมาใช้งานข้อมูลได้ ควร restore ไป volume ใหม่ก่อนทดสอบ แล้วค่อยสลับใช้งานจริง จะปลอดภัยกว่าการทับข้อมูลเดิมทันที
- เลือกไฟล์ backup ที่ถูกต้อง
- เลือก volume เป้าหมายให้ถูก
- แตกไฟล์ด้วย tar ให้ path ถูกต้อง
- ตรวจสอบผลหลัง restore ก่อนเปิดระบบเต็มรูปแบบ
ส่วนที่ 7
7) ตัวอย่างขั้นตอน backup แบบพื้นฐาน
ตัวอย่างนี้ใช้แนวทางพื้นฐานที่ผู้เริ่มต้นทำตามได้ทันที: ใช้ container ชั่วคราวอ่านข้อมูลจาก volume แล้วสร้างไฟล์ `tar.gz` สมมติว่ามี volume ชื่อ `app_data` และต้องการเก็บ backup ไว้ที่โฟลเดอร์ `./backups` บนเครื่อง host
ส่วนที่ 8
8) ตัวอย่างขั้นตอน restore แบบพื้นฐาน
ขั้นตอน restore คือเตรียม volume เป้าหมาย แล้วแตกไฟล์ backup ลงใน volume นั้น จากนั้นค่อย mount ให้ container ใช้งาน ตัวอย่างนี้จะ restore ไฟล์ `app_data_20260408_120000.tar.gz` กลับเข้า volume `app_data_restored`
ส่วนที่ 9
9) ตัวอย่างคำสั่งที่เกี่ยวข้อง
คำสั่งต่อไปนี้ใช้บ่อยในการทำงาน backup/restore กับ Docker Volume
ส่วนที่ 10
10) อธิบายว่าทำไมบางกรณีควรหยุด service ก่อน backup
ถ้าระหว่าง backup ยังมีการเขียนข้อมูลอยู่ ไฟล์ที่ได้อาจอยู่คนละช่วงเวลากัน ทำให้ข้อมูลไม่สอดคล้อง (inconsistent backup) ตัวอย่างเช่น database กำลังเขียน transaction ใหม่พอดี แต่ backup จับบางไฟล์ก่อนและบางไฟล์หลังเขียน จะทำให้ restore แล้วใช้งานไม่ได้หรือข้อมูลเพี้ยน
- หยุด service ชั่วคราวช่วยให้ข้อมูลนิ่ง
- ลดโอกาสได้ backup ที่เปิดใช้ไม่ได้
- สำคัญมากกับระบบที่เขียนข้อมูลต่อเนื่อง
- ถ้าหยุดไม่ได้ ควรใช้วิธี backup ที่ DB รองรับโดยตรง
ส่วนที่ 11
11) ความต่างระหว่าง backup ไฟล์ธรรมดา กับ backup data ของ database
การ backup ไฟล์ทั่วไปมักใช้ archive ทั้งโฟลเดอร์ได้เลย แต่ database มีโครงสร้างภายในและสถานะการเขียนที่ซับซ้อนกว่า ดังนั้นงาน database ควรใช้เครื่องมือของฐานข้อมูลร่วมด้วย เช่น logical dump (`pg_dump`, `mysqldump`) หรือ snapshot ที่ระบบรองรับ
| ประเภทข้อมูล | แนวทางพื้นฐาน | ข้อควรระวัง |
|---|---|---|
| ไฟล์ทั่วไป (เอกสาร/รูป) | ใช้ tar archive ได้ตรงไปตรงมา | ระวังไฟล์ที่กำลังถูกเขียน |
| Database data | ใช้ dump tool ของ DB หรือวิธีที่ DB แนะนำ | ห้ามคิดว่า copy ไฟล์ดิบจะปลอดภัยเสมอ |
ส่วนที่ 12
12) ข้อควรระวังเรื่องความสม่ำเสมอของข้อมูล
ความสม่ำเสมอของข้อมูล (consistency) คือ backup ที่ได้ต้องสะท้อนสถานะข้อมูลที่ถูกต้อง ณ ช่วงเวลาหนึ่ง ถ้า backup ไม่สม่ำเสมอ ต่อให้ restore สำเร็จเชิงเทคนิค ระบบก็อาจใช้งานจริงไม่ได้
ประเด็นที่ 1
หลีกเลี่ยง backup ตอนมี write หนักถ้าเป็นไปได้
ประเด็นที่ 2
ใช้โหมด read-only หรือหยุด service ชั่วคราวในบางระบบ
ประเด็นที่ 3
ทดสอบ restore เป็นประจำเพื่อพิสูจน์คุณภาพ backup
ประเด็นที่ 4
เก็บ metadata เช่น เวลา backup และเวอร์ชันแอป/DB
ส่วนที่ 13
13) แนวทางเบื้องต้นในการวางแผน backup
เริ่มจากคำถามง่าย ๆ: ข้อมูลไหนหายไม่ได้, ยอมเสียข้อมูลได้มากสุดกี่ชั่วโมง, และยอมให้ระบบหยุดได้นานแค่ไหน จากนั้นกำหนดรอบ backup, นโยบายเก็บย้อนหลัง (retention), และขั้นตอน restore ที่ทีมทุกคนทำตามได้
- กำหนดความถี่ backup (รายชั่วโมง/รายวัน)
- กำหนด retention เช่น เก็บรายวัน 7 วัน รายสัปดาห์ 4 สัปดาห์
- เก็บ backup แยกเครื่องหรือแยก storage จากระบบหลัก
- มี runbook restore และซ้อมกู้คืนเป็นรอบ
ส่วนที่ 14
14) ข้อผิดพลาดที่พบบ่อย
รายการนี้คือกับดักที่พบบ่อยมาก และเป็นเหตุให้การกู้คืนล้มเหลวตอนเกิดเหตุจริง
- คิดว่าใช้ volume อย่างเดียวพอแล้ว ไม่ต้อง backup
- ทำ backup แต่ไม่เคยทดสอบ restore
- เก็บไฟล์ backup ไว้เครื่องเดียวกับระบบหลัก
- ตั้งชื่อไฟล์ backup ไม่เป็นระบบ หาไฟล์เวอร์ชันที่ต้องการไม่เจอ
- restore ทับข้อมูลจริงทันทีโดยไม่ทดสอบใน volume แยก
ส่วนที่ 15
15) สรุปท้ายบทแบบจำง่าย
จำสั้น ๆ: Volume ช่วยให้ข้อมูลไม่หายตอน container เปลี่ยน Backup ช่วยให้ข้อมูลกลับมาได้ตอนเกิดเหตุร้าย Restore คือความสามารถที่ต้องซ้อม ไม่ใช่แค่หวังว่าใช้ได้ สูตรจำ: มี Volume + มี Backup + ทดสอบ Restore = ระบบข้อมูลที่ไว้ใจได้มากขึ้น
ประเด็นที่ 1
ไม่มี backup = volume เสียก็จบ
ประเด็นที่ 2
backup ที่ไม่เคย restore ทดสอบ = ยังไม่ปลอดภัย
ประเด็นที่ 3
ต้องคิดทั้งการสำรองและการกู้คืนควบคู่กัน
ประเด็นที่ 4
วางแผนง่าย ๆ แต่ทำสม่ำเสมอ สำคัญที่สุด
ส่วนที่ 16
16) แบบฝึกหัด 4 ข้อ พร้อมแนวเฉลย
ลองทำด้วยตัวเองก่อน แล้วค่อยกดดูแนวเฉลย