วิธี Backup VPS อย่างถูกต้อง ป้องกันข้อมูลสูญหาย

ทำไม VPS ถึงต้อง Backup เอง?

ข้อแตกต่างสำคัญระหว่าง VPS กับ Shared Hosting คือเรื่อง Backup ใน Shared Hosting ส่วนใหญ่ผู้ให้บริการจะ Backup ให้อัตโนมัติ แต่บน VPS คุณรับผิดชอบ Backup เองทั้งหมด เพราะคุณมี Full Root Access และควบคุม Environment ทั้งหมด

AsiaGB Hosting ทำ Backup 2 ครั้งต่อเดือน แต่ VPS นั้นคุณต้องจัดการเอง ข้อมูลสูญหายจากฮาร์ดแวร์เสีย การโดน hack หรือแม้แต่ความผิดพลาดของตัวเองล้วนเกิดขึ้นได้ การ Backup ที่ดีคือสิ่งที่ทำให้คุณนอนหลับสบายได้

วิธีที่ 1: Manual Backup ด้วย tar/gzip

วิธีพื้นฐานที่สุดคือการบีบอัดไฟล์เว็บและ Database ด้วยตนเอง:

Backup ไฟล์เว็บ

Backup MySQL Database

ควรสร้าง Directory /backup ไว้ก่อน และตรวจสอบว่ามีพื้นที่เพียงพอ

วิธีที่ 2: rsync ไปยัง Remote Server

rsync ช่วย Sync ไฟล์ไปยังเซิร์ฟเวอร์ปลายทางได้อย่างมีประสิทธิภาพ โดยส่งเฉพาะไฟล์ที่เปลี่ยนแปลง:

ใช้ SSH Key สำหรับ Authentication เพื่อให้ rsync ทำงานได้อัตโนมัติใน Cron Job โดยไม่ต้องกรอกรหัสผ่าน

เครื่องมือ Backup ยอดนิยมบน Linux VPS

นอกจาก tar และ rsync ยังมีเครื่องมือระดับสูงที่ช่วยให้การ Backup สะดวกและน่าเชื่อถือมากขึ้น:

Duplicati

Duplicati เป็น Open-Source Backup Tool ที่มี GUI Web-based ใช้งานง่าย รองรับ Destination หลายรูปแบบเช่น SFTP, S3, Google Drive, Backblaze B2 และเข้ารหัสข้อมูลก่อน Upload ทำให้แม้ข้อมูลหลุดออกไปก็ไม่มีใครอ่านได้

# ติดตั้ง Duplicati บน Ubuntu/Debian
apt-get install mono-runtime libmono-2.0-dev
wget https://github.com/duplicati/duplicati/releases/download/v2.0.8.1/duplicati_2.0.8.1-1_all.deb
dpkg -i duplicati_2.0.8.1-1_all.deb
systemctl enable duplicati && systemctl start duplicati

BorgBackup (borg)

BorgBackup เน้น Deduplication — เก็บเฉพาะข้อมูลที่เปลี่ยนแปลงระดับ Block ทำให้ประหยัดพื้นที่อย่างมาก เหมาะกับ Database ขนาดใหญ่ที่เปลี่ยนบางส่วนทุกวัน

# ติดตั้งและสร้าง Repo
apt-get install borgbackup
borg init --encryption=repokey /backup/borg-repo

# สร้าง Archive รายวัน
borg create /backup/borg-repo::backup-{now:%Y-%m-%d} /var/www/html /etc

# แสดงรายการ Archives ทั้งหมด
borg list /backup/borg-repo

Rclone — Sync ไปยัง Cloud Storage

Rclone ช่วย Sync ไฟล์จาก VPS ไปยัง Cloud Storage มากกว่า 40 Provider เช่น AWS S3, Google Cloud Storage, Wasabi, Cloudflare R2 เหมาะสำหรับ Offsite Backup ตามกฎ 3-2-1

# ติดตั้ง Rclone
curl https://rclone.org/install.sh | sudo bash

# ตั้งค่า Remote (เช่น S3-compatible)
rclone config

# Sync ไปยัง Bucket
rclone sync /backup s3:your-bucket-name/vps-backup/ --progress

วิธีที่ 3: Snapshot (ถ้า Provider รองรับ)

Snapshot คือการบันทึกสถานะของ VPS ทั้งระบบ ณ จุดเวลาหนึ่ง ทำให้สามารถ Restore ทั้ง OS พร้อม Application และข้อมูลได้ในคราวเดียว

• เหมาะสำหรับ Restore ทั้งระบบหลังจากปัญหาใหญ่
• ใช้พื้นที่มากกว่า File Backup
• ต้องตรวจสอบว่า Provider ของคุณรองรับหรือไม่

วิธีที่ 4: Automated Cron Job

การ Backup มือคือสิ่งที่คุณทำแล้วลืม Cron Job ช่วยให้ Backup เกิดขึ้นอัตโนมัติตามเวลาที่กำหนด:

การ Backup MySQL Database อย่างถูกต้อง

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

Backup MySQL แบบ Full Dump

# Dump ทุก Database พร้อมกัน
mysqldump -u root -p --all-databases --single-transaction \
  --routines --triggers --events \
  > /backup/full-db-$(date +%Y%m%d_%H%M).sql

# บีบอัดทันทีเพื่อประหยัดพื้นที่
gzip /backup/full-db-$(date +%Y%m%d_%H%M).sql

Backup แบบ Per-Database

# Backup เฉพาะ Database ที่ต้องการ
mysqldump -u root -p --single-transaction \
  my_wordpress_db | gzip > /backup/wp-db-$(date +%Y%m%d).sql.gz

# Restore คืน
gunzip < /backup/wp-db-20260608.sql.gz | mysql -u root -p my_wordpress_db

กำหนดสิทธิ์ MySQL สำหรับ Backup User

แนะนำให้สร้าง MySQL User เฉพาะสำหรับ Backup ที่มี Permission เพียง SELECT และ LOCK TABLES เท่านั้น ลด Risk ถ้า Script หลุดออกไป:

CREATE USER 'backup_user'@'localhost' IDENTIFIED BY 'StrongPassHere';
GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER ON *.* TO 'backup_user'@'localhost';
FLUSH PRIVILEGES;

ลบ Backup เก่าอัตโนมัติ

อย่าลืมลบไฟล์ Backup เก่าด้วย มิฉะนั้น Disk จะเต็ม เพิ่ม Cron Job สำหรับลบไฟล์ที่เก่ากว่า 30 วัน:

กลยุทธ์ Offsite Backup: เก็บข้อมูลไว้นอก VPS

กฎ 3-2-1 กำหนดว่าต้องมีสำเนา 1 ชุดเก็บไว้ "Offsite" นั่นคือที่ที่แยกออกจากสถานที่ของ VPS หลัก เพื่อป้องกันเหตุการณ์ที่กระทบ Datacenter ทั้งหมดพร้อมกัน เช่น ไฟไหม้ น้ำท่วม หรือปัญหาของ Provider

ตัวเลือก Offsite Storage ที่นิยมใช้

• Object Storage (S3-compatible): Backblaze B2, Wasabi, Cloudflare R2 ราคาถูก ทนทาน ใช้กับ rclone ได้ทันที เหมาะสำหรับ VPS ขนาดกลาง-ใหญ่
• VPS ลำดับที่สอง: ถ้ามี VPS หลายตัว ให้ rsync ข้ามไปเก็บอีกตัวหนึ่ง ดีกว่าเก็บไว้ใน VPS เดียวกัน เพราะถ้า VPS หลักพังทั้งตัว ยังมีที่อื่นให้ Restore
• Google Drive / Dropbox (ผ่าน rclone): เหมาะกับข้อมูลขนาดเล็กถึงกลาง ฟรีในระดับหนึ่ง แต่ต้องพิจารณา Privacy ถ้าข้อมูลมีความอ่อนไหว

ตัวอย่าง Script Backup + Offsite Upload อัตโนมัติ

#!/bin/bash
# full-backup.sh - Backup + Upload ไป Wasabi S3
DATE=$(date +%Y%m%d_%H%M)
LOCAL_DIR="/backup"
REMOTE="wasabi:my-vps-backup/$HOSTNAME"

# 1. Backup ไฟล์เว็บ
tar -czf "$LOCAL_DIR/web-$DATE.tar.gz" /var/www/html

# 2. Backup Database
mysqldump -u backup_user -pPASSWORD --all-databases \
  --single-transaction | gzip > "$LOCAL_DIR/db-$DATE.sql.gz"

# 3. Upload ไปยัง Wasabi S3
rclone copy "$LOCAL_DIR" "$REMOTE" --min-age 1m

# 4. ลบไฟล์ใน VPS ที่เก่ากว่า 7 วัน
find "$LOCAL_DIR" -name "*.gz" -mtime +7 -delete

echo "Backup เสร็จแล้ว: $DATE"

การตั้งค่า Backup Alert และ Monitoring

Backup ที่ล้มเหลวโดยไม่มีใครรู้ไม่ต่างจากการไม่มี Backup เลย การเพิ่ม Alert ช่วยให้คุณรู้ทันทีหาก Backup Script มีปัญหา

ส่ง Email แจ้งเตือนเมื่อ Backup เสร็จ

#!/bin/bash
# backup-with-alert.sh
BACKUP_FILE="/backup/web-$(date +%Y%m%d).tar.gz"
ADMIN_EMAIL="[email protected]"

tar -czf "$BACKUP_FILE" /var/www/html 2>&1

if [ $? -eq 0 ]; then
    SIZE=$(du -sh "$BACKUP_FILE" | cut -f1)
    echo "Backup สำเร็จ: $BACKUP_FILE ($SIZE)" | mail -s "[VPS] Backup OK $(date +%Y-%m-%d)" "$ADMIN_EMAIL"
else
    echo "Backup ล้มเหลว! กรุณาตรวจสอบทันที" | mail -s "[VPS] BACKUP FAILED $(date +%Y-%m-%d)" "$ADMIN_EMAIL"
fi

ตรวจสอบขนาด Backup ว่าผิดปกติหรือไม่

ไฟล์ Backup ที่ใหญ่ผิดปกติหรือเล็กผิดปกติอาจบ่งบอกปัญหา เพิ่ม Check ขนาดไฟล์:

#!/bin/bash
# ตรวจสอบว่า Backup ไม่เล็กเกินไป (ต้อง > 1MB)
BACKUP_FILE="/backup/web-$(date +%Y%m%d).tar.gz"
MIN_SIZE=1048576  # 1MB in bytes

if [ -f "$BACKUP_FILE" ]; then
    ACTUAL_SIZE=$(stat -c%s "$BACKUP_FILE")
    if [ "$ACTUAL_SIZE" -lt "$MIN_SIZE" ]; then
        echo "คำเตือน: Backup ขนาดเล็กผิดปกติ ($ACTUAL_SIZE bytes)" | \
          mail -s "[VPS] Backup size warning" [email protected]
    fi
fi

การจัดการสิทธิ์และความปลอดภัยของ Backup Files

ไฟล์ Backup มักมีข้อมูลสำคัญรวมกันไว้ทั้งหมด ไม่ว่าจะเป็นไฟล์ Config, Database Dump หรือ SSL Certificate หากไฟล์ Backup หลุดออกไปเท่ากับข้อมูลทั้งหมดของคุณหลุดออกไปด้วย ดังนั้นต้องจัดการสิทธิ์ให้ถูกต้อง:

กำหนดสิทธิ์ Directory Backup

# สร้าง backup user แยกต่างหาก
useradd -r -s /bin/false backupuser

# กำหนด owner ของ directory
chown -R backupuser:backupuser /backup

# เจ้าของอ่าน-เขียนได้ คนอื่นเข้าไม่ได้
chmod 700 /backup

# ไฟล์ใหม่ใน /backup ให้ permission 600 อัตโนมัติ
echo "umask 077" >> /etc/profile.d/backup-umask.sh

เข้ารหัสไฟล์ Backup ก่อน Upload

ถ้าต้องการ Upload ไปยัง Cloud ที่ไม่แน่ใจความปลอดภัย แนะนำให้เข้ารหัสก่อนด้วย GPG:

# เข้ารหัสด้วย GPG (Symmetric)
gpg --cipher-algo AES256 --symmetric \
  --output /backup/web-20260608.tar.gz.gpg \
  /backup/web-20260608.tar.gz

# ถอดรหัส (Restore)
gpg --decrypt /backup/web-20260608.tar.gz.gpg \
  > /backup/web-20260608.tar.gz

ตรวจสอบ Integrity ด้วย Checksum

บันทึก MD5 หรือ SHA256 ของไฟล์ Backup ไว้เสมอ เพื่อใช้ยืนยันว่าไฟล์ไม่ถูกแก้ไขหรือเสียหายก่อน Restore:

# สร้าง Checksum
sha256sum /backup/web-20260608.tar.gz > /backup/web-20260608.tar.gz.sha256

# ตรวจสอบก่อน Restore
sha256sum --check /backup/web-20260608.tar.gz.sha256

ทดสอบ Restore สม่ำเสมอ

Backup ที่ดีที่สุดคือ Backup ที่ Restore ได้จริง ทดสอบ Restore บน Test Environment อย่างน้อยเดือนละครั้ง เพื่อให้แน่ใจว่าไฟล์ Backup ไม่เสียหายและ Process Restore ทำงานได้ถูกต้อง