Backup & Restore

รูปแบบการสำรองข้อมูล

Docker volumes อาศัยอยู่ภายในพื้นที่จัดเก็บที่ Docker จัดการ คุณไม่สามารถ cp ไฟล์เหล่านั้นจาก host ได้โดยตรง วิธีมาตรฐานในการสำรองข้อมูล volume คือการสร้าง throwaway container ที่ mount ทั้ง source volume และไดเรกทอรี backup ที่ bind-mounted แล้วใช้ tar เพื่อ archive เนื้อหาของ volume

docker run --rm \
  -v mydata:/data \
  -v $(pwd):/backup \
  alpine \
  tar czf /backup/mydata-backup.tgz -C /data .

อธิบายแต่ละส่วน:

ส่วน	ความหมาย
`--rm`	ลบ container ทันทีหลังจาก exit
`-v mydata:/data`	Mount volume ที่จะสำรองที่ `/data`
`-v $(pwd):/backup`	Mount ไดเรกทอรี host ปัจจุบันที่ `/backup` (archive จะอยู่ที่นี่)
`alpine`	Image ขนาดเล็ก — ไม่ต้องการ dependency เพิ่มเติม
`tar czf /backup/mydata-backup.tgz -C /data .`	สร้าง compressed archive ของทุกอย่างใน `/data`

หลังจากคำสั่ง mydata-backup.tgz จะอยู่บน host ของคุณในไดเรกทอรีปัจจุบัน

การกู้คืน volume

เพื่อกู้คืนจาก archive เข้าสู่ volume (สร้าง volume ถ้ายังไม่มี):

# สร้าง volume ใหม่ (หรืออันที่มีอยู่) เพื่อกู้คืนเข้าไป
docker volume create mydata-restored

# แตก archive เข้าสู่ volume
docker run --rm \
  -v mydata-restored:/data \
  -v $(pwd):/backup \
  alpine \
  tar xzf /backup/mydata-backup.tgz -C /data

tar xzf แตก archive ออก -C /data เปลี่ยนไปที่ /data ก่อนแตก ทำให้ไฟล์ลงที่ volume root โดยตรง

การย้าย volume ไปยัง host อื่น

การย้าย volume คือ สำรอง + คัดลอก + กู้คืน:

สำรอง บน source host (คำสั่งข้างต้น — ผลิต mydata-backup.tgz)
คัดลอก archive ไปยัง target host: scp mydata-backup.tgz user@target:/home/user/
กู้คืน บน target host ด้วยคำสั่งกู้คืนข้างต้น

target ไม่จำเป็นต้องรู้อะไรเกี่ยวกับการตั้งค่า Docker ของ source host ระหว่างการถ่ายโอน volume คือแค่ tar archive ธรรมดา

การสำรองข้อมูล volume ของ container ที่กำลังรันอย่างปลอดภัย

ถ้าเป็นไปได้ ให้หยุด container ก่อนสำรองเพื่อหลีกเลี่ยงความไม่สอดคล้องในกรณีที่กำลังเขียนข้อมูลอยู่:

docker stop myapp
docker run --rm -v myapp-data:/data -v $(pwd):/backup alpine tar czf /backup/myapp-data.tgz -C /data .
docker start myapp

สำหรับฐานข้อมูลที่มี backup tools ของตัวเอง (เช่น pg_dump, mysqldump) ให้เลือกใช้ database-native dump แทนการ tar volume โดยตรง — ผลิต snapshot ที่สอดคล้องกันโดยไม่คำนึงถึงการเขียนที่ค้างอยู่ใน buffer

ฝึกปฏิบัติ

snippet ด้านล่างสร้าง volume เขียนข้อมูลลงไป สำรองข้อมูลไปยัง tar archive สร้าง volume ใหม่ที่ว่างเปล่า กู้คืน archive เข้าไป และตรวจสอบว่าข้อมูลครบถ้วน

# 1. Create a source volume and populate it
docker volume create source-vol
docker run --rm -v source-vol:/data alpine sh -c "echo 'important data' > /data/record.txt && echo 'more data' > /data/extra.txt"

# 2. Back up the volume to the current directory
docker run --rm -v source-vol:/data -v $(pwd):/backup alpine tar czf /backup/source-vol.tgz -C /data .

# 3. Verify the archive exists on the host
ls -lh source-vol.tgz

# 4. Create a new volume and restore into it
docker volume create restored-vol
docker run --rm -v restored-vol:/data -v $(pwd):/backup alpine tar xzf /backup/source-vol.tgz -C /data

# 5. Verify restored data
docker run --rm -v restored-vol:/data alpine ls /data
docker run --rm -v restored-vol:/data alpine cat /data/record.txt

# 6. Clean up
docker volume rm source-vol restored-vol
rm source-vol.tgz

ข้อแลกเปลี่ยน

ตัวเลือก	Benefit	Cost
Backup ด้วย throwaway container (tar)	ใช้ได้กับทุก volume ไม่ต้องพึ่ง tool เฉพาะฐานข้อมูล	ไม่รับประกันความสอดคล้องถ้า container ต้นทางยังเขียนข้อมูลอยู่ระหว่าง backup
Database-native dump (`pg_dump`, `mysqldump`)	ได้ snapshot ที่สอดคล้องกันแม้ container ยังรันอยู่	ใช้ได้เฉพาะกับฐานข้อมูลที่มี tool รองรับ ต้อง restore ผ่าน tool เดียวกัน

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

ไม่มีแผนสำรองข้อมูลสำหรับ volume เลย จนกว่าจะเกิดปัญหาแล้วค่อยนึกได้ว่าไม่เคย backup
รัน docker rm -v หรือ docker compose down -v โดยไม่ตั้งใจ ลบทั้ง container และ volume พร้อมกันโดยไม่มี backup สำรองไว้ก่อน
สำรองข้อมูลไว้แต่ไม่เคยทดสอบ restore จริง พอถึงเวลาต้องใช้จริงกลับพบว่า archive เสียหายหรือ restore ไม่สำเร็จ

💡 ตัวอย่างจากของจริง

ทีม production ที่ใช้ official Postgres image มักตั้ง cron job รัน pg_dump เป็นประจำ ควบคู่กับการสำรอง volume ด้วย tar container เพื่อให้มีทั้ง consistent snapshot และ raw backup สำรองซ้อนกัน ลดความเสี่ยงจากทั้งสองวิธี