กลยุทธ์ Backup เว็บไซต์ที่ได้ผลจริง

3-2-1 Rule Backup Database อัตโนมัติ Offsite Backup และสิ่งที่คนมักลืม นั่นคือการทดสอบ Restore

Backup Strategy เว็บไซต์ 3-2-1 Rule mysqldump Offsite Backup

3-2-1 Rule Backup คืออะไร

3-2-1 Rule คือกฎทองของการ Backup ข้อมูลที่ผู้เชี่ยวชาญด้าน IT แนะนำมาหลายทศวรรษ:

ตัวอย่าง 3-2-1 สำหรับเว็บไซต์: ข้อมูลบน Hosting (Live) + Backup บน Hosting ตัวเอง + Backup บน Google Drive หรือ S3

ประเภทของ Backup

Full Backup

สำเนาข้อมูลทุกอย่างทั้งหมด ใช้พื้นที่มากที่สุด แต่ Restore ง่ายที่สุด แนะนำทำสัปดาห์ละครั้งหรือก่อนอัพเดท Major

Incremental Backup

สำเนาเฉพาะไฟล์ที่เปลี่ยนแปลงนับจาก Backup ครั้งล่าสุด ใช้พื้นที่น้อย แต่ Restore ต้องใช้ Full Backup + Incremental ทุกชุดต่อเนื่อง

Differential Backup

สำเนาเฉพาะไฟล์ที่เปลี่ยนแปลงนับจาก Full Backup ครั้งล่าสุด (ไม่ใช่ Backup ล่าสุด) Restore ต้องใช้ Full Backup + Differential ล่าสุดเท่านั้น

เครื่องมือ Backup บน Hosting

cPanel Backup Wizard

Login cPanel → Backup Wizard → Back Up → Full Backup ดาวน์โหลดเป็นไฟล์ tar.gz รวมทั้ง Files, Databases, Emails, DNS Records เหมาะสำหรับ Backup ก่อนย้าย Hosting หรือ Major Update

JetBackup (ถ้า Hosting รองรับ)

JetBackup เป็น Backup System ระดับ Hosting Provider ที่บางเจ้าติดตั้งให้ในทุก Account รองรับ Incremental Backup, Restore ไฟล์เดี่ยว, Offsite Destination (S3/FTP/SFTP) ตรวจสอบใน cPanel ว่ามีเมนู "JetBackup" หรือไม่

Backup Database อัตโนมัติด้วย Cron + mysqldump

วิธีที่ยืดหยุ่นและเชื่อถือได้ที่สุดสำหรับ Database Backup คือ Script อัตโนมัติ:

#!/bin/bash
# /home/user/scripts/backup_db.sh
DATE=$(date +%Y%m%d_%H%M)
DB_USER="dbuser"
DB_PASS="dbpassword"
DB_NAME="dbname"
BACKUP_DIR="/home/user/backups/db"

# สร้าง Backup Directory ถ้ายังไม่มี
mkdir -p $BACKUP_DIR

# Dump Database
mysqldump -u $DB_USER -p$DB_PASS $DB_NAME | gzip > $BACKUP_DIR/db_${DATE}.sql.gz

# ลบ Backup เก่ากว่า 14 วัน
find $BACKUP_DIR -name "*.sql.gz" -mtime +14 -delete

echo "Backup completed: db_${DATE}.sql.gz"

ตั้ง Cron Job ใน cPanel ให้รัน Script นี้ทุกวัน:

0 2 * * * /bin/bash /home/user/scripts/backup_db.sh >> /home/user/logs/backup.log 2>&1

Offsite Backup ด้วย Rclone ไปยัง Cloud

Rclone คือเครื่องมือ Open Source ที่ Sync ไฟล์ไปยัง Cloud Storage ได้หลายเจ้า:

# ติดตั้ง Rclone (ถ้า Hosting อนุญาต SSH)
curl https://rclone.org/install.sh | sudo bash

# ตั้งค่า Remote (Google Drive ตัวอย่าง)
rclone config
# ทำตาม Wizard เลือก Google Drive

# Sync ไฟล์ Backup ไปยัง Google Drive
rclone copy /home/user/backups gdrive:website-backups/

# ดูไฟล์ที่ Upload แล้ว
rclone ls gdrive:website-backups/
Tip: ตั้ง Cron ให้รัน Rclone Sync หลังจาก Backup เสร็จ จะได้ Offsite Copy อัตโนมัติทุกวัน เป็นการทำ 3-2-1 Rule โดยอัตโนมัติ

ทดสอบ Restore — สิ่งที่คนมักลืม

Backup ที่ดีที่สุดคือ Backup ที่ Restore ได้จริง แนะนำทดสอบ Restore อย่างน้อยเดือนละครั้ง:

# ทดสอบ Restore Database ไปยัง DB ทดสอบ
mysql -u dbuser -p testdb < backup.sql

# ตรวจสอบจำนวน Records หลัง Restore
mysql -u dbuser -p testdb -e "SELECT COUNT(*) FROM wp_posts;"

# ทดสอบ Restore ไฟล์บน Staging
tar -xzf website_backup.tar.gz -C /staging/

ตรวจสอบ Backup ทำงานถูกต้อง

# ตรวจสอบว่า Backup ไฟล์ถูกสร้างทุกวัน
ls -lh ~/backups/db/ | tail -10

# ตรวจสอบขนาด Backup ไม่เล็กผิดปกติ (= Backup ว่าง)
du -sh ~/backups/db/*.sql.gz | tail -5

# ตรวจสอบ Backup Log
tail -20 ~/logs/backup.log

# ทดสอบ Integrity ของ SQL Backup
zcat backup.sql.gz | mysql --dry-run -u dbuser -p testdb

แก้ปัญหาที่พบบ่อย

Error: mysqldump ล้มเหลว "Access denied for user"

ตรวจสอบ Username และ Password ที่ใช้ใน Script ว่าถูกต้อง และ User มีสิทธิ์ SELECT บน Database นั้น ตรวจสอบด้วย: mysql -u dbuser -p -e "SHOW GRANTS;"

Cron Job รันแต่ไม่มี Backup ไฟล์

ตรวจสอบ Path ของ Script ว่าถูกต้อง และ Script มีสิทธิ์ Execute ด้วย chmod +x backup_db.sh ดู Log ใน ~/logs/backup.log เพื่อหา Error Message

Backup ไฟล์ขนาดใหญ่เกิน Disk Quota

ตรวจสอบว่า Script ลบ Backup เก่าทำงานหรือไม่ และย้าย Backup ไป Offsite Storage ทันทีหลัง Backup เสร็จ ไม่ควรเก็บ Backup มากกว่า 7-14 ชุดบน Hosting เดิม

คำถามที่พบบ่อย

Q: Backup ของ Hosting Provider เชื่อถือได้ไหม ต้องทำเองด้วยไหม?

A: Backup ของ Provider เชื่อถือได้ระดับหนึ่ง แต่ไม่ควรพึ่งพาอย่างเดียว เพราะถ้า Server หรือ Data Center มีปัญหา Backup ของ Provider อาจพัง Provider บางเจ้าคิดค่า Restore ด้วย แนะนำทำ Backup ของตัวเองเสมอ

Q: ควร Backup บ่อยแค่ไหน?

A: ขึ้นอยู่กับความถี่ที่ข้อมูลเปลี่ยน สำหรับ WordPress Blog ที่โพสต์วันละครั้ง ควร Backup ทุกวัน E-Commerce ที่มี Order ตลอดเวลาควร Backup ทุกชั่วโมงหรือใช้ Real-time Replication

Q: Google Drive หรือ Dropbox เหมาะสำหรับ Offsite Backup ไหม?

A: ได้สำหรับเว็บขนาดเล็กถึงกลาง แต่ถ้าเว็บมีข้อมูลมากควรใช้ Object Storage เช่น AWS S3 หรือ Wasabi ซึ่งถูกกว่าและมีความเชื่อถือสูงกว่าสำหรับ Production Backup

บทความที่เกี่ยวข้อง