Skip to content

สำรองข้อมูลอัตโนมัติ ​

สิ่งที่จะได้

สำรองฐานข้อมูลและไฟล์อัปโหลดทุกวัน ลบไฟล์เก่าทิ้ง และซ้อมกู้คืนเพื่อให้รู้ว่าใช้ได้จริง ใช้: backup, CLI

SQLite บน server ​

สคริปต์ที่คัดลอกฐานข้อมูลขณะเว็บยังทำงาน พร้อมไฟล์อัปโหลด:

bash
#!/bin/sh
set -e
cd /srv/my-site                          # root ของโปรเจกต์
day=$(date +%F)
mkdir -p backups
npx easy-cms backup "backups/cms-$day.db"            # สำเนาที่ข้อมูลตรงกัน CMS ยังทำงานต่อ
tar -czf "backups/uploads-$day.tar.gz" uploads       # ไฟล์อัปโหลด
find backups -type f -mtime +14 -delete              # เก็บไว้สองสัปดาห์

ตั้งให้รันทุกคืนด้วย cron (crontab -e):

30 2 * * * /srv/my-site/scripts/backup.sh >> /var/log/cms-backup.log 2>&1

แล้วคัดลอก backups/ ออกจาก server ไฟล์สำรองที่อยู่ดิสก์เดียวกันจะหายไปพร้อมดิสก์ เช่น ส่งไป bucket ของ S3 ด้วย aws s3 sync backups s3://my-backups/cms หรือใช้ rclone

Postgres ​

Postgres แบบจัดการให้ (Neon, Supabase, RDS…) มักมีการสำรองแบบย้อนเวลาได้ ให้เปิดใช้ก่อน ส่วนสำเนาของคุณเอง:

bash
pg_dump --format=custom --file="backups/cms-$(date +%F).dump" "$DATABASE_URL"

ไฟล์อัปโหลดใน bucket ​

เปิด versioning ของ bucket (S3, R2 และ MinIO รองรับ) เพื่อกู้ไฟล์ที่ถูกลบหรือแทนที่ได้ และตั้ง lifecycle rule ให้ลบเวอร์ชันเก่าเมื่อผ่านไประยะหนึ่ง

ซ้อมกู้คืน ​

เดือนละครั้ง พิสูจน์ว่าไฟล์สำรองใช้ได้:

  1. คัดลอกไฟล์สำรองของเมื่อคืนไปที่ที่แยกไว้ (ห้ามทับ production)
  2. เปิดเว็บกับไฟล์นั้น เช่น DATABASE_URL=file:./restore-test.db npm run dev (เมื่อ config อ่าน DATABASE_URL แบบในตัวอย่าง)
  3. เปิดหน้า admin เอกสารล่าสุดสักสองสามรายการและรูปของมัน

ขั้นตอนกู้คืนจริง และสิ่งที่ต้องทำกับ migration หลังจากนั้น อยู่ที่ Backup และการอัปเกรด

เผยแพร่ภายใต้สัญญาอนุญาต MIT