Database Restore จาก Backup Files

Categories

การสำรองข้อมูล (Backup) จะไม่มีประโยชน์เลยถ้าไม่สามารถกู้คืน (Restore) ได้จริง หลายองค์กรลงทุนกับระบบ Backup อย่างดี แต่ไม่เคยทดสอบกระบวนการ Restore จนกระทั่งเกิดเหตุฉุกเฉิน แล้วพบว่าข้อมูลกู้คืนไม่ได้หรือไม่ครบถ้วน

บทความนี้อธิบายวิธีการ Restore ฐานข้อมูลจาก Backup Files สำหรับระบบจัดการฐานข้อมูลที่นิยม ได้แก่ MySQL/MariaDB, PostgreSQL และ MongoDB ครอบคลุมทั้งการกู้คืนทั้งหมด (Full Restore) การกู้คืนบางส่วน (Partial Restore) การกู้คืนแบบ Point-in-Time และข้อควรระวังสำคัญที่ต้องรู้ก่อนเริ่มกระบวนการ

หลักการสำคัญก่อน Restore

ก่อนเริ่ม Restore ข้อมูลจาก Backup ทุกครั้ง ควรตรวจสอบและเตรียมความพร้อมเพื่อป้องกันปัญหาที่อาจเกิดขึ้น ไม่ว่าจะเป็นข้อมูลเสียหาย เวอร์ชันไม่ตรงกัน หรือ Restore ทับข้อมูลที่ยังใช้งานอยู่

  • ตรวจสอบความสมบูรณ์ของไฟล์ Backup ก่อนเริ่ม — ตรวจขนาดไฟล์ checksum และวันที่สร้าง
  • ทดสอบ Restore บนเซิร์ฟเวอร์ทดสอบก่อนเสมอ — อย่า Restore ลงบน Production โดยตรงถ้ายังไม่เคยทดสอบ
  • สำรองข้อมูลปัจจุบันก่อน Restore — ถ้าข้อมูลใน Production ยังมีค่า ให้ Backup ก่อนทับ
  • ตรวจสอบเวอร์ชันของฐานข้อมูลให้ตรงกัน — Backup จากเวอร์ชันเก่าอาจไม่เข้ากับเวอร์ชันใหม่
  • เตรียม Disk Space ให้เพียงพอ — การ Restore อาจต้องใช้พื้นที่มากกว่าขนาดไฟล์ Backup
  • แจ้งทีมที่เกี่ยวข้องก่อนเริ่ม — การ Restore อาจทำให้บริการหยุดชะงักชั่วคราว

Restore MySQL/MariaDB จาก Backup

MySQL และ MariaDB รองรับการ Restore จาก Backup หลายรูปแบบ ตั้งแต่ SQL Dump ที่เป็นไฟล์ข้อความธรรมดา ไปจนถึง Physical Backup ที่ copy ไฟล์ข้อมูลโดยตรง แต่ละวิธีมีข้อดีข้อเสียและขั้นตอนที่แตกต่างกัน

Restore จาก mysqldump (SQL Dump)

mysqldump เป็นเครื่องมือ Backup ที่ใช้กันมากที่สุดสำหรับ MySQL โดยสร้างไฟล์ SQL ที่มีคำสั่ง CREATE TABLE และ INSERT DATA สำหรับกู้คืนข้อมูล วิธี Restore ขึ้นอยู่กับว่าต้องการกู้คืนทั้งหมดหรือเฉพาะบางส่วน

# Restore ฐานข้อมูลทั้งหมด (Full Restore)
mysql -u root -p < full_backup.sql

# Restore เฉพาะฐานข้อมูลเดียว
mysql -u root -p mydb < mydb_backup.sql

# Restore จากไฟล์ที่บีบอัด (gzip)
gunzip < mydb_backup.sql.gz | mysql -u root -p mydb

# Restore จากไฟล์ที่บีบอัด (zstd — เร็วกว่า gzip)
zstd -d --stdout mydb_backup.sql.zst | mysql -u root -p mydb

# Restore เฉพาะตารางเดียวจากไฟล์ Backup ใหญ่
# ใช้ sed ดึงเฉพาะส่วนที่ต้องการ
sed -n '/^-- Table structure for table `orders`/,/^-- Table structure for table `/p' full_backup.sql | mysql -u root -p mydb

ตัวเลือกที่ช่วยให้ Restore เร็วขึ้น

การ Restore ฐานข้อมูลขนาดใหญ่อาจใช้เวลานาน มีตัวเลือกหลายอย่างที่ช่วยเพิ่มความเร็วในการ Restore ได้อย่างมาก

# ปิด Foreign Key Check ระหว่าง Restore (เร็วขึ้นมาก)
mysql -u root -p -e "SET GLOBAL foreign_key_checks=0;"
mysql -u root -p mydb < mydb_backup.sql
mysql -u root -p -e "SET GLOBAL foreign_key_checks=1;"

# ปิด Binary Log ชั่วคราว (ลด I/O ถ้าไม่ต้องการ Replication)
mysql -u root -p -e "SET sql_log_bin=0; SOURCE /path/to/backup.sql; SET sql_log_bin=1;"

# เพิ่ม Buffer Size สำหรับ InnoDB
mysql -u root -p --init-command="SET SESSION innodb_buffer_pool_size=2G" < backup.sql

# ใช้ mysqlimport สำหรับ CSV/TSV (เร็วกว่า INSERT)
mysqlimport --local -u root -p mydb /path/to/orders.txt

Restore จาก Physical Backup (Percona XtraBackup)

Physical Backup จะ copy ไฟล์ข้อมูลโดยตรง ทำให้ Restore เร็วกว่า SQL Dump มากสำหรับฐานข้อมูลขนาดใหญ่ เครื่องมือที่นิยมคือ Percona XtraBackup สำหรับ MySQL และ MariaBackup สำหรับ MariaDB

# 1. เตรียม Backup (Prepare) — จำเป็นก่อน Restore
xtrabackup --prepare --target-dir=/backup/full

# 2. หยุด MySQL Service
sudo systemctl stop mysql

# 3. ย้ายข้อมูลเดิมออก (สำรองไว้ก่อน)
sudo mv /var/lib/mysql /var/lib/mysql.old

# 4. Restore ข้อมูลจาก Backup
xtrabackup --copy-back --target-dir=/backup/full

# 5. ตั้ง Permission ให้ถูกต้อง
sudo chown -R mysql:mysql /var/lib/mysql

# 6. เริ่ม MySQL Service
sudo systemctl start mysql

# 7. ตรวจสอบว่าฐานข้อมูลทำงานปกติ
mysql -u root -p -e "SHOW DATABASES; SELECT COUNT(*) FROM mydb.orders;"

Point-in-Time Recovery (PITR) ด้วย Binary Log

Point-in-Time Recovery ช่วยกู้คืนข้อมูลไปยังเวลาที่ต้องการ เช่น ก่อนเกิดคำสั่ง DELETE ผิดพลาด โดยใช้ Binary Log ร่วมกับ Full Backup เป็นวิธีที่มีประโยชน์มากเมื่อต้องการกู้คืนแบบละเอียดถึงระดับวินาที

# ขั้นตอน PITR สำหรับ MySQL

# 1. Restore จาก Full Backup ก่อน
mysql -u root -p < full_backup_2026040100.sql

# 2. ดูรายการ Binary Log
mysql -u root -p -e "SHOW BINARY LOGS;"

# 3. หาตำแหน่ง (Position) ของเหตุการณ์ที่ต้องการ
mysqlbinlog --start-datetime="2026-04-05 00:00:00" --stop-datetime="2026-04-05 14:30:00" \
  /var/lib/mysql/mysql-bin.000042 | head -50

# 4. Apply Binary Log ตั้งแต่หลัง Backup จนถึงเวลาที่ต้องการ
mysqlbinlog --start-datetime="2026-04-01 00:00:00" --stop-datetime="2026-04-05 14:30:00" \
  /var/lib/mysql/mysql-bin.000040 \
  /var/lib/mysql/mysql-bin.000041 \
  /var/lib/mysql/mysql-bin.000042 | mysql -u root -p

# 5. ตรวจสอบข้อมูลหลัง PITR
mysql -u root -p -e "SELECT * FROM mydb.orders ORDER BY created_at DESC LIMIT 10;"

Restore PostgreSQL จาก Backup

PostgreSQL มีเครื่องมือ Restore ที่ทรงพลังหลายตัว ตั้งแต่ psql สำหรับ SQL Dump ไปจนถึง pg_restore สำหรับ Custom Format ที่รองรับการ Restore แบบเลือกเฉพาะบางส่วน

Restore จาก pg_dump (SQL Format)

# Restore ฐานข้อมูลเดียว (SQL plain text)
psql -U postgres -d mydb -f mydb_backup.sql

# สร้างฐานข้อมูลใหม่แล้ว Restore
createdb -U postgres mydb_restored
psql -U postgres -d mydb_restored -f mydb_backup.sql

# Restore จากไฟล์บีบอัด
gunzip -c mydb_backup.sql.gz | psql -U postgres -d mydb

# Restore ทั้ง Cluster (จาก pg_dumpall)
psql -U postgres -f full_cluster_backup.sql

Restore จาก Custom Format (pg_restore)

Custom Format (.dump) เป็นรูปแบบที่แนะนำสำหรับ Production เพราะรองรับการ Restore แบบเลือกเฉพาะบางส่วน สามารถ Restore แบบ Parallel ได้ และบีบอัดอัตโนมัติ

# Restore ทั้งหมดจาก Custom Format
pg_restore -U postgres -d mydb mydb_backup.dump

# Restore พร้อมสร้างฐานข้อมูลใหม่
pg_restore -U postgres -C -d postgres mydb_backup.dump

# Restore เฉพาะตารางที่ต้องการ
pg_restore -U postgres -d mydb -t orders -t customers mydb_backup.dump

# Restore เฉพาะ Schema (โครงสร้าง ไม่รวมข้อมูล)
pg_restore -U postgres -d mydb --schema-only mydb_backup.dump

# Restore เฉพาะข้อมูล (ไม่รวมโครงสร้าง)
pg_restore -U postgres -d mydb --data-only mydb_backup.dump

# Restore แบบ Parallel (เร็วขึ้นหลายเท่า)
pg_restore -U postgres -d mydb -j 4 mydb_backup.dump

# ดูรายการ Object ใน Backup ก่อน Restore
pg_restore -l mydb_backup.dump | head -30

จัดการ Error ระหว่าง Restore

การ Restore อาจพบ Error เช่น ตารางมีอยู่แล้ว หรือ Object ที่อ้างอิงไม่ตรงกัน PostgreSQL มีตัวเลือกช่วยจัดการปัญหาเหล่านี้

# ข้ามข้อผิดพลาดแล้วทำต่อ (ใช้เมื่อ Restore บางส่วนเท่านั้น)
pg_restore -U postgres -d mydb --if-exists --clean mydb_backup.dump

# ลบ Object เก่าก่อนสร้างใหม่ (Clean Restore)
pg_restore -U postgres -d mydb --clean --if-exists mydb_backup.dump

# ใช้ Single Transaction — ถ้ามี Error จะ Rollback ทั้งหมด
pg_restore -U postgres -d mydb --single-transaction mydb_backup.dump

# Restore เฉพาะ Schema ที่ต้องการ
pg_restore -U postgres -d mydb -n public mydb_backup.dump

Point-in-Time Recovery ด้วย WAL

PostgreSQL ใช้ WAL (Write-Ahead Log) สำหรับ Point-in-Time Recovery ซึ่งทำงานคล้ายกับ Binary Log ของ MySQL ต้องเปิด Continuous Archiving ไว้ก่อนจึงจะใช้ได้

# ขั้นตอน PITR สำหรับ PostgreSQL

# 1. หยุด PostgreSQL
sudo systemctl stop postgresql

# 2. สำรองข้อมูลปัจจุบัน (ถ้ามี)
sudo mv /var/lib/postgresql/16/main /var/lib/postgresql/16/main.old

# 3. Restore จาก Base Backup
sudo tar -xzf /backup/base_backup.tar.gz -C /var/lib/postgresql/16/main

# 4. สร้างไฟล์ recovery.signal (PostgreSQL 12+)
sudo touch /var/lib/postgresql/16/main/recovery.signal

# 5. แก้ไข postgresql.conf กำหนดเวลาที่ต้องการ
# restore_command = 'cp /backup/wal_archive/%f %p'
# recovery_target_time = '2026-04-05 14:30:00'
# recovery_target_action = 'promote'

# 6. ตั้ง Permission
sudo chown -R postgres:postgres /var/lib/postgresql/16/main

# 7. เริ่ม PostgreSQL (จะ Replay WAL จนถึงเวลาที่กำหนด)
sudo systemctl start postgresql

# 8. ตรวจสอบ Recovery สำเร็จ
sudo -u postgres psql -c "SELECT pg_is_in_recovery();"
# ถ้าได้ 'f' (false) แปลว่า Recovery เสร็จแล้ว

Restore MongoDB จาก Backup

MongoDB ใช้ mongorestore เป็นเครื่องมือหลักในการกู้คืนข้อมูลจาก Backup ที่สร้างด้วย mongodump รองรับทั้งการ Restore แบบ Directory และ Archive Format

Restore จาก mongodump

# Restore ทั้งหมดจาก Directory Backup
mongorestore --uri="mongodb://adminUser:password@localhost:27017" \
  /backup/mongodb/20260407

# Restore เฉพาะฐานข้อมูลเดียว
mongorestore --uri="mongodb://adminUser:password@localhost:27017" \
  --db myapp /backup/mongodb/20260407/myapp

# Restore เฉพาะ Collection เดียว
mongorestore --uri="mongodb://adminUser:password@localhost:27017" \
  --db myapp --collection orders /backup/mongodb/20260407/myapp/orders.bson

# Restore จาก Archive Format (ไฟล์เดียว)
mongorestore --uri="mongodb://adminUser:password@localhost:27017" \
  --gzip --archive=/backup/mongodb/full_20260407.gz

# Restore โดยลบข้อมูลเก่าก่อน (Drop ก่อน Insert)
mongorestore --uri="mongodb://adminUser:password@localhost:27017" \
  --drop /backup/mongodb/20260407

# Restore แบบ Parallel (เร็วขึ้น)
mongorestore --uri="mongodb://adminUser:password@localhost:27017" \
  --numParallelCollections=4 /backup/mongodb/20260407

Point-in-Time Recovery ด้วย Oplog

MongoDB ที่ทำงานเป็น Replica Set จะมี Oplog สำหรับบันทึกทุก Operation สามารถใช้ร่วมกับ mongodump เพื่อทำ PITR ได้

# Backup พร้อม Oplog
mongodump --uri="mongodb://adminUser:password@localhost:27017" \
  --oplog --out=/backup/mongodb/20260407

# Restore พร้อม Replay Oplog (PITR)
mongorestore --uri="mongodb://adminUser:password@localhost:27017" \
  --oplogReplay /backup/mongodb/20260407

# Restore พร้อมกำหนดเวลา (Oplog Limit)
mongorestore --uri="mongodb://adminUser:password@localhost:27017" \
  --oplogReplay --oplogLimit="1712345678:1" /backup/mongodb/20260407

ตรวจสอบความสำเร็จหลัง Restore

หลัง Restore เสร็จ ต้องตรวจสอบว่าข้อมูลกู้คืนมาถูกต้องและครบถ้วน ไม่ควรถือว่าสำเร็จจนกว่าจะผ่านการตรวจสอบทุกข้อ

ตรวจสอบ MySQL/MariaDB

# ตรวจจำนวน Record ในตารางสำคัญ
mysql -u root -p -e "
  SELECT 'orders' AS tbl, COUNT(*) AS cnt FROM mydb.orders
  UNION ALL
  SELECT 'customers', COUNT(*) FROM mydb.customers
  UNION ALL
  SELECT 'products', COUNT(*) FROM mydb.products;"

# ตรวจ Checksum ของตาราง (เทียบกับค่าก่อน Backup)
mysql -u root -p -e "CHECKSUM TABLE mydb.orders, mydb.customers;"

# ตรวจโครงสร้างตาราง
mysql -u root -p -e "SHOW CREATE TABLE mydb.orders\G"

# ตรวจ Integrity ของตาราง
mysqlcheck -u root -p --check --all-databases

ตรวจสอบ PostgreSQL

# ตรวจจำนวน Record
psql -U postgres -d mydb -c "
  SELECT 'orders' AS tbl, COUNT(*) FROM orders
  UNION ALL
  SELECT 'customers', COUNT(*) FROM customers
  UNION ALL
  SELECT 'products', COUNT(*) FROM products;"

# ตรวจ Sequence ว่าต่อเนื่องถูกต้อง
psql -U postgres -d mydb -c "SELECT sequencename, last_value FROM pg_sequences;"

# ตรวจ Index ว่ายังใช้ได้
psql -U postgres -d mydb -c "REINDEX DATABASE mydb;"

# ตรวจ Foreign Key Constraints
psql -U postgres -d mydb -c "
  SELECT conname, conrelid::regclass, confrelid::regclass
  FROM pg_constraint WHERE contype = 'f';"

ตรวจสอบ MongoDB

# ตรวจจำนวน Document
mongosh -u adminUser -p 'password' --authenticationDatabase admin --eval "
  use myapp;
  print('orders:', db.orders.countDocuments());
  print('customers:', db.customers.countDocuments());
  print('products:', db.products.countDocuments());"

# ตรวจ Index ว่ายังอยู่ครบ
mongosh -u adminUser -p 'password' --authenticationDatabase admin --eval "
  use myapp;
  db.orders.getIndexes().forEach(idx => print(JSON.stringify(idx)));"

# Validate Collection
mongosh -u adminUser -p 'password' --authenticationDatabase admin --eval "
  use myapp;
  print(JSON.stringify(db.orders.validate()));"

Restore Automation Script

การเขียน Script สำหรับ Restore อัตโนมัติช่วยลดความผิดพลาดจากการทำด้วยมือ และทำให้ทีมทุกคนทำตามขั้นตอนเดียวกัน ตัวอย่างด้านล่างเป็น Script สำหรับ MySQL ที่ครอบคลุมการตรวจสอบก่อน-หลัง Restore

#!/bin/bash
# restore_mysql.sh — MySQL Restore Script with Validation
set -euo pipefail

BACKUP_FILE="${1:?Usage: $0 <backup_file> [database_name]}"
DB_NAME="${2:-}"
MYSQL_USER="root"
LOG_FILE="/var/log/mysql_restore_$(date +%Y%m%d_%H%M%S).log"

log() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"; }

# 1. ตรวจสอบไฟล์ Backup
if [ ! -f "$BACKUP_FILE" ]; then
    log "ERROR: Backup file not found: $BACKUP_FILE"
    exit 1
fi

FILE_SIZE=$(stat -c%s "$BACKUP_FILE")
log "Backup file: $BACKUP_FILE ($(numfmt --to=iec $FILE_SIZE))"

if [ "$FILE_SIZE" -lt 100 ]; then
    log "ERROR: Backup file is too small — possibly corrupted"
    exit 1
fi

# 2. ตรวจสอบ Disk Space
REQUIRED_SPACE=$((FILE_SIZE * 3))
AVAILABLE_SPACE=$(df --output=avail /var/lib/mysql | tail -1)
AVAILABLE_BYTES=$((AVAILABLE_SPACE * 1024))

if [ "$AVAILABLE_BYTES" -lt "$REQUIRED_SPACE" ]; then
    log "ERROR: Not enough disk space. Need $(numfmt --to=iec $REQUIRED_SPACE), have $(numfmt --to=iec $AVAILABLE_BYTES)"
    exit 1
fi
log "Disk space OK"

# 3. สำรองข้อมูลปัจจุบันก่อน Restore
log "Creating safety backup before restore..."
SAFETY_BACKUP="/backup/safety_$(date +%Y%m%d_%H%M%S).sql.gz"
if [ -n "$DB_NAME" ]; then
    mysqldump -u "$MYSQL_USER" "$DB_NAME" 2>/dev/null | gzip > "$SAFETY_BACKUP" || true
else
    mysqldump -u "$MYSQL_USER" --all-databases 2>/dev/null | gzip > "$SAFETY_BACKUP" || true
fi
log "Safety backup: $SAFETY_BACKUP"

# 4. เริ่ม Restore
log "Starting restore..."
START_TIME=$(date +%s)

if [[ "$BACKUP_FILE" == *.gz ]]; then
    gunzip -c "$BACKUP_FILE" | mysql -u "$MYSQL_USER" ${DB_NAME:+$DB_NAME}
elif [[ "$BACKUP_FILE" == *.zst ]]; then
    zstd -d --stdout "$BACKUP_FILE" | mysql -u "$MYSQL_USER" ${DB_NAME:+$DB_NAME}
else
    mysql -u "$MYSQL_USER" ${DB_NAME:+$DB_NAME} < "$BACKUP_FILE"
fi

END_TIME=$(date +%s)
DURATION=$((END_TIME - START_TIME))
log "Restore completed in ${DURATION}s"

# 5. ตรวจสอบหลัง Restore
log "Running post-restore checks..."

if [ -n "$DB_NAME" ]; then
    TABLE_COUNT=$(mysql -u "$MYSQL_USER" -N -e "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='$DB_NAME';")
    log "Tables in $DB_NAME: $TABLE_COUNT"
    
    mysql -u "$MYSQL_USER" -e "SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema='$DB_NAME' ORDER BY table_rows DESC LIMIT 10;"
fi

mysqlcheck -u "$MYSQL_USER" --check ${DB_NAME:---all-databases} 2>&1 | tail -5 | tee -a "$LOG_FILE"

log "Restore process finished. Log: $LOG_FILE"

ข้อผิดพลาดที่พบบ่อยและวิธีแก้ไข

การ Restore ฐานข้อมูลมักพบปัญหาต่าง ๆ ที่ต้องรู้วิธีจัดการ ด้านล่างรวบรวมปัญหาที่พบบ่อยที่สุดพร้อมวิธีแก้ไข

MySQL: ERROR 1227 — Access denied

เกิดเมื่อ SQL Dump มีคำสั่ง DEFINER ของ User ที่ไม่มีอยู่ในเซิร์ฟเวอร์ปลายทาง แก้ไขโดยลบ DEFINER ออกก่อน Restore

# ลบ DEFINER ออกจากไฟล์ Backup ก่อน Restore
sed -i 's/DEFINER=[^ ]* //g' backup.sql

# หรือถ้าเป็นไฟล์บีบอัด
gunzip -c backup.sql.gz | sed 's/DEFINER=[^ ]* //g' | mysql -u root -p mydb

MySQL: ERROR 1118 — Row size too large

พบเมื่อ Restore ตารางที่มี Column จำนวนมากหรือ TEXT/BLOB หลายตัว แก้โดยปรับค่า innodb_strict_mode

# ปิด strict mode ชั่วคราว
mysql -u root -p -e "SET GLOBAL innodb_strict_mode=OFF;"
mysql -u root -p mydb < backup.sql
mysql -u root -p -e "SET GLOBAL innodb_strict_mode=ON;"

PostgreSQL: ERROR — relation already exists

เกิดเมื่อฐานข้อมูลมีตารางอยู่แล้ว ใช้ –clean เพื่อลบก่อนสร้างใหม่ หรือ Drop ฐานข้อมูลทั้งหมดแล้วสร้างใหม่

# วิธีที่ 1: ใช้ --clean (Drop แล้ว Create ใหม่)
pg_restore -U postgres -d mydb --clean --if-exists mydb_backup.dump

# วิธีที่ 2: Drop แล้วสร้างฐานข้อมูลใหม่
dropdb -U postgres mydb
createdb -U postgres mydb
pg_restore -U postgres -d mydb mydb_backup.dump

MongoDB: Failed to parse — version mismatch

เกิดเมื่อ Backup มาจาก MongoDB เวอร์ชันที่แตกต่างมาก เช่น Backup จาก 4.x แล้ว Restore ลง 7.x ซึ่งอาจมีปัญหากับ BSON Format

# ตรวจเวอร์ชันของ Backup
cat /backup/mongodb/20260407/admin/system.version.bson | bsondump

# ใช้ mongorestore เวอร์ชันเดียวกับ Backup
# ติดตั้ง MongoDB Database Tools เวอร์ชันที่ต้องการ
# แล้ว Restore ด้วยเวอร์ชันนั้น

# หรือ Export เป็น JSON แล้ว Import ใหม่
mongoexport --uri="mongodb://old-server:27017" --db myapp --collection orders --out orders.json
mongoimport --uri="mongodb://new-server:27017" --db myapp --collection orders --file orders.json

สรุป

การ Restore ฐานข้อมูลเป็นทักษะสำคัญที่ Database Administrator ทุกคนต้องเชี่ยวชาญ แต่ละระบบมีเครื่องมือและขั้นตอนเฉพาะ MySQL ใช้ mysql client สำหรับ SQL Dump และ xtrabackup สำหรับ Physical Backup ส่วน PostgreSQL ใช้ psql และ pg_restore ที่รองรับ Partial Restore ได้ยืดหยุ่นมาก และ MongoDB ใช้ mongorestore ที่ทำงานกับ BSON Format โดยตรง สิ่งสำคัญที่สุดคือต้องทดสอบกระบวนการ Restore เป็นประจำ ไม่ใช่รอจนเกิดเหตุฉุกเฉินแล้วค่อยลองเป็นครั้งแรก

แนะนำบริการ DE

การรันฐานข้อมูลในระบบ Production ต้องการเซิร์ฟเวอร์ที่มี Disk I/O เร็วสำหรับ Restore ข้อมูลขนาดใหญ่ และมี Storage เพียงพอสำหรับเก็บ Backup หลายชุด Cloud VPS ของ DE รองรับ SSD NVMe ที่มีความเร็วสูง พร้อม Root Access เต็มรูปแบบสำหรับติดตั้งและตั้งค่าเครื่องมือ Backup/Restore ได้อิสระ

สำหรับโปรเจกต์ที่ไม่ต้องการจัดการเซิร์ฟเวอร์เอง Cloud Hosting ของ DE เป็นทางเลือกที่สะดวกพร้อม Managed Infrastructure และระบบ Backup อัตโนมัติให้ใช้งานได้ทันที