การสำรองข้อมูลฐานข้อมูลเป็นหนึ่งในงานสำคัญที่สุดของผู้ดูแลระบบ หากเกิดเหตุไม่คาดฝัน เช่น ฮาร์ดแวร์เสียหาย ข้อมูลถูกลบโดยไม่ตั้งใจ หรือถูกโจมตีด้วย ransomware ระบบสำรองข้อมูลที่ดีจะช่วยให้กู้คืนข้อมูลได้อย่างรวดเร็วและสูญเสียน้อยที่สุด

PostgreSQL มีเครื่องมือสำรองข้อมูลในตัวหลายตัว โดยเครื่องมือหลักที่ใช้กันมากที่สุดคือ pg_dump และ pg_dumpall สำหรับ Logical Backup ส่วน Physical Backup จะใช้ pg_basebackup บทความนี้จะอธิบายทุกวิธีอย่างละเอียด พร้อมตัวอย่างการใช้งานและแนวทางการตั้งค่า automated dump ที่เชื่อถือได้

ประเภทของการสำรองข้อมูลใน PostgreSQL

การสำรองข้อมูลแบ่งออกเป็น 3 ประเภทหลัก แต่ละประเภทมีข้อดีข้อเสียและเหมาะกับสถานการณ์ต่างกัน

ประเภท	เครื่องมือ	ข้อดี	ข้อเสีย	เหมาะกับ
Logical Dump	pg_dump, pg_dumpall	ยืดหยุ่น, restore เฉพาะตารางได้	ช้ากว่าเมื่อ DB ใหญ่	DB ขนาดเล็ก-กลาง, migration
Physical Dump	pg_basebackup	เร็ว, dump ทั้ง cluster	ต้อง restore ทั้ง cluster	DB ขนาดใหญ่, Replication setup
การ Archive อย่างต่อเนื่อง	WAL Archiving + pg_basebackup	Point-in-Time Recovery (PITR)	ใช้พื้นที่มาก, ซับซ้อน	Production ที่ต้องการ RPO ต่ำ

pg_dump — Logical Dump แบบรายฐานข้อมูล

pg_dump เป็นเครื่องมือหลักสำหรับ Logical Dump ที่ export ข้อมูลออกมาเป็นชุดคำสั่ง SQL หรือไฟล์ archive ที่สามารถนำไป restore ได้ทั้งบนเซิร์ฟเวอร์เดิมหรือเซิร์ฟเวอร์ใหม่

รูปแบบพื้นฐาน

# สำรองฐานข้อมูลทั้งหมดเป็นไฟล์ SQL
pg_dump -U postgres -d mydb > mydb_backup.sql

# สำรองพร้อมระบุ host และ port
pg_dump -h localhost -p 5432 -U postgres -d mydb > mydb_backup.sql

# สำรองเฉพาะ schema (โครงสร้าง) ไม่รวมข้อมูล
pg_dump -U postgres -d mydb --schema-only > mydb_schema.sql

# สำรองเฉพาะข้อมูล ไม่รวมโครงสร้าง
pg_dump -U postgres -d mydb --data-only > mydb_data.sql

Output Formats

pg_dump รองรับหลายรูปแบบการ export แต่ละรูปแบบมีข้อดีต่างกัน

Format	Flag	นามสกุล	คุณสมบัติ
Plain SQL	-Fp (default)	.sql	อ่านได้ง่าย แก้ไขได้ ใช้ psql restore
Custom	-Fc	.dump	บีบอัดในตัว เลือก restore เฉพาะบางส่วนได้
Directory	-Fd	directory	แยกไฟล์ รองรับ parallel dump/restore
Tar	-Ft	.tar	เหมือน Custom แต่เป็น tar archive

# Custom format — แนะนำสำหรับงานทั่วไป
pg_dump -U postgres -Fc -d mydb -f mydb_backup.dump

# Directory format — เร็วที่สุดเพราะรองรับ parallel
pg_dump -U postgres -Fd -d mydb -j 4 -f mydb_backup_dir/

# Tar format
pg_dump -U postgres -Ft -d mydb -f mydb_backup.tar

คำแนะนำ: ใช้ Custom format (-Fc) เป็นค่า default สำหรับงานสำรองข้อมูลทั่วไป เพราะบีบอัดอัตโนมัติ ประหยัดพื้นที่ และเลือก restore เฉพาะตารางหรือ schema ที่ต้องการได้ สำหรับฐานข้อมูลขนาดใหญ่ให้ใช้ Directory format พร้อม parallel jobs

สำรองเฉพาะบางส่วน

# สำรองเฉพาะตาราง
pg_dump -U postgres -d mydb -t users -t orders > selected_tables.sql

# สำรองเฉพาะ schema (namespace)
pg_dump -U postgres -d mydb -n public > public_schema.sql

# สำรองยกเว้นตารางบางตาราง
pg_dump -U postgres -d mydb -T logs -T sessions > without_logs.sql

# สำรองยกเว้น schema
pg_dump -U postgres -d mydb -N temp_schema > without_temp.sql

# รวมหลายเงื่อนไข
pg_dump -U postgres -Fc -d mydb -n public -T logs -f production_backup.dump

Options ที่ใช้บ่อย

# สำรองพร้อม CREATE DATABASE statement
pg_dump -U postgres -C -d mydb > mydb_with_create.sql

# สำรองแบบ clean (DROP ก่อน CREATE)
pg_dump -U postgres -c -d mydb > mydb_clean.sql

# สำรองแบบ IF EXISTS (ไม่ error ถ้าไม่มี object)
pg_dump -U postgres -c --if-exists -d mydb > mydb_safe_clean.sql

# สำรองพร้อมบีบอัดด้วย gzip
pg_dump -U postgres -d mydb | gzip > mydb_backup.sql.gz

# สำรองพร้อม verbose output
pg_dump -U postgres -v -Fc -d mydb -f mydb_backup.dump

pg_dumpall — สำรองทั้ง PostgreSQL Cluster

pg_dumpall ทำงานคล้าย pg_dump แต่สำรองข้อมูลทุกฐานข้อมูลในเซิร์ฟเวอร์เดียวกัน รวมถึง global objects เช่น roles, tablespaces ที่ pg_dump ไม่สามารถ backup ได้

# สำรองทุกฐานข้อมูล + roles + tablespaces
pg_dumpall -U postgres > all_databases.sql

# สำรองเฉพาะ global objects (roles, tablespaces)
pg_dumpall -U postgres --globals-only > globals.sql

# สำรองเฉพาะ roles
pg_dumpall -U postgres --roles-only > roles.sql

# สำรองพร้อมบีบอัด
pg_dumpall -U postgres | gzip > all_databases.sql.gz

ข้อควรรู้: pg_dumpall รองรับเฉพาะ Plain SQL format เท่านั้น ไม่รองรับ Custom หรือ Directory format ดังนั้นหากต้องการ dump ทุกฐานข้อมูลในรูปแบบ Custom ให้ใช้ pg_dumpall –globals-only สำหรับ roles แล้ว loop เรียก pg_dump -Fc สำหรับแต่ละฐานข้อมูลแยก

การ Restore ข้อมูล

วิธีการ restore ขึ้นอยู่กับรูปแบบไฟล์ backup ที่ใช้ Plain SQL ใช้ psql ส่วน Custom, Directory และ Tar ใช้ pg_restore

Restore จาก Plain SQL

# Restore จากไฟล์ SQL
psql -U postgres -d mydb < mydb_backup.sql

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

# Restore ไปฐานข้อมูลใหม่
createdb -U postgres mydb_new
psql -U postgres -d mydb_new < mydb_backup.sql

# Restore จาก pg_dumpall
psql -U postgres -f all_databases.sql

pg_restore — Restore จาก Custom/Directory/Tar

# Restore จาก Custom format
pg_restore -U postgres -d mydb mydb_backup.dump

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

# Restore แบบ clean (DROP ก่อน)
pg_restore -U postgres -c -d mydb mydb_backup.dump

# Restore เฉพาะตาราง
pg_restore -U postgres -d mydb -t users -t orders mydb_backup.dump

# Restore เฉพาะ schema
pg_restore -U postgres -d mydb -n public mydb_backup.dump

# Parallel restore — เร็วกว่ามาก
pg_restore -U postgres -d mydb -j 4 mydb_backup_dir/

# Restore แบบ data-only
pg_restore -U postgres -d mydb --data-only mydb_backup.dump

# ดูสิ่งที่อยู่ใน backup file (ไม่ restore)
pg_restore -l mydb_backup.dump

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

# ข้าม error แล้วทำต่อ (สำหรับ psql)
psql -U postgres -d mydb --set ON_ERROR_STOP=off < mydb_backup.sql

# หยุดทันทีเมื่อเจอ error (สำหรับ psql)
psql -U postgres -d mydb --set ON_ERROR_STOP=on < mydb_backup.sql

# Restore แบบ single transaction (ถ้า error จะ rollback ทั้งหมด)
pg_restore -U postgres -d mydb --single-transaction mydb_backup.dump

# Restore พร้อม verbose เพื่อดู error
pg_restore -U postgres -d mydb -v mydb_backup.dump 2>&1 | tee restore.log

pg_basebackup — Physical Dump

pg_basebackup สร้าง Physical Dump โดย copy ไฟล์ข้อมูลทั้งหมดของ PostgreSQL cluster ซึ่งรวดเร็วกว่า Logical Dump มาก เหมาะสำหรับฐานข้อมูลขนาดใหญ่และเป็นพื้นฐานของการทำ Replication และ Point-in-Time Recovery

# ตั้งค่า postgresql.conf สำหรับ pg_basebackup
# wal_level = replica            (ค่า default ตั้งแต่ PG 10)
# max_wal_senders = 3            (จำนวน connection ที่อนุญาต)
# max_replication_slots = 2      (ถ้าใช้ replication slot)

# ตั้งค่า pg_hba.conf อนุญาต replication connection
# host replication postgres 127.0.0.1/32 scram-sha-256

# Reload config
pg_ctl reload -D /var/lib/postgresql/16/main/

# Physical dump พื้นฐาน
pg_basebackup -U postgres -D /backup/pg_base -Fp -Xs -P

# สำรองเป็น tar พร้อมบีบอัด
pg_basebackup -U postgres -D /backup/pg_base -Ft -z -Xs -P

# สำรองจากเซิร์ฟเวอร์อื่น
pg_basebackup -h db-server -U replicator -D /backup/pg_base -Fp -Xs -P

# ตัวเลือกที่ใช้บ่อย
# -D   : directory ปลายทาง
# -Fp  : plain format (copy ไฟล์ตามปกติ)
# -Ft  : tar format
# -Xs  : stream WAL ระหว่าง backup (แนะนำ)
# -z   : บีบอัดด้วย gzip
# -P   : แสดง progress
# --checkpoint=fast : เริ่ม backup ทันที ไม่ต้องรอ checkpoint

WAL Archiving และ Point-in-Time Recovery (PITR)

WAL (Write-Ahead Log) คือ log ที่ PostgreSQL เขียนก่อนเปลี่ยนแปลงข้อมูลจริง การ archive WAL ร่วมกับ base dump ทำให้สามารถกู้คืนข้อมูลไปยังจุดใดจุดหนึ่งในอดีตได้ (Point-in-Time Recovery) ซึ่งมีประโยชน์อย่างมากเมื่อเกิดการลบข้อมูลโดยไม่ตั้งใจ

ตั้งค่า WAL Archiving

# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'cp %p /backup/wal_archive/%f'
# %p = path ของ WAL file
# %f = filename ของ WAL file

# ทางเลือกที่ดีกว่า cp (ป้องกัน partial write)
archive_command = 'test ! -f /backup/wal_archive/%f && cp %p /backup/wal_archive/%f'

# Restart PostgreSQL หลังเปลี่ยน archive_mode
sudo systemctl restart postgresql

สร้าง Base Dump สำหรับ PITR

# สร้าง base dump
pg_basebackup -U postgres -D /backup/base_dump -Fp -Xs -P

# บันทึกเวลาที่ dump เสร็จ (สำคัญสำหรับ PITR)
date '+%Y-%m-%d %H:%M:%S%z' > /backup/base_dump/dump_timestamp.txt

ทำ Point-in-Time Recovery

# ขั้นตอน PITR
# 1. หยุด PostgreSQL
sudo systemctl stop postgresql

# 2. ย้ายข้อมูลเก่าออก
mv /var/lib/postgresql/16/main /var/lib/postgresql/16/main_old

# 3. Copy base dump กลับมา
cp -r /backup/base_dump /var/lib/postgresql/16/main

# 4. สร้าง recovery signal file
touch /var/lib/postgresql/16/main/recovery.signal

# 5. ตั้งค่า restore command ใน postgresql.conf
# restore_command = 'cp /backup/wal_archive/%f %p'
# recovery_target_time = '2026-04-07 10:30:00+07'
# recovery_target_action = 'promote'

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

# 7. Start PostgreSQL
sudo systemctl start postgresql

# 8. ตรวจสอบว่า recovery เสร็จสมบูรณ์
psql -U postgres -c "SELECT pg_is_in_recovery();"
# ควรได้ false (หมายถึง promote เป็น primary แล้ว)

Recovery Target Options: นอกจาก recovery_target_time ยังสามารถกำหนดจุด recovery ได้หลายแบบ เช่น recovery_target_xid (ระบุ Transaction ID), recovery_target_lsn (ระบุ WAL position) และ recovery_target_name (ระบุชื่อ restore point ที่สร้างไว้ด้วย pg_create_restore_point())

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

การตั้งค่าสำรองข้อมูลอัตโนมัติเป็นสิ่งจำเป็นสำหรับ production ตัวอย่างต่อไปนี้เป็น script ที่ใช้งานได้จริง รองรับ rotation และการแจ้งเตือน

#!/bin/bash
# PostgreSQL Automated Dump Script
# ใช้กับ cron: 0 2 * * * /opt/scripts/pg_dump_auto.sh

set -euo pipefail

# ตั้งค่า
DUMP_DIR="/backup/postgresql"
RETENTION_DAYS=7
PG_USER="postgres"
DATABASES=$(psql -U "$PG_USER" -t -A -c "SELECT datname FROM pg_database WHERE datistemplate = false AND datname != 'postgres';")
DATE=$(date '+%Y-%m-%d_%H%M%S')
LOG_FILE="/var/log/pg_dump_${DATE}.log"

# สร้าง directory
mkdir -p "${DUMP_DIR}/${DATE}"

echo "[$(date)] Dump started" | tee -a "$LOG_FILE"

# Dump globals (roles, tablespaces)
echo "[$(date)] Dumping globals..." | tee -a "$LOG_FILE"
pg_dumpall -U "$PG_USER" --globals-only > "${DUMP_DIR}/${DATE}/globals.sql" 2>> "$LOG_FILE"

# Dump แต่ละฐานข้อมูล
for DB in $DATABASES; do
    echo "[$(date)] Dumping database: $DB" | tee -a "$LOG_FILE"
    pg_dump -U "$PG_USER" -Fc -v -d "$DB" \
        -f "${DUMP_DIR}/${DATE}/${DB}.dump" 2>> "$LOG_FILE"

    # ตรวจสอบไฟล์ dump
    if [ -s "${DUMP_DIR}/${DATE}/${DB}.dump" ]; then
        SIZE=$(du -sh "${DUMP_DIR}/${DATE}/${DB}.dump" | cut -f1)
        echo "[$(date)] $DB dump completed: $SIZE" | tee -a "$LOG_FILE"
    else
        echo "[$(date)] ERROR: $DB dump file is empty!" | tee -a "$LOG_FILE"
    fi
done

# ลบไฟล์ dump เก่า
echo "[$(date)] Removing dumps older than ${RETENTION_DAYS} days..." | tee -a "$LOG_FILE"
find "$DUMP_DIR" -maxdepth 1 -type d -mtime +${RETENTION_DAYS} -exec rm -rf {} + 2>> "$LOG_FILE"

echo "[$(date)] Dump completed" | tee -a "$LOG_FILE"

ตั้ง Cron Job

# เปิด crontab ของ user postgres
sudo -u postgres crontab -e

# เพิ่ม schedule
# สำรองข้อมูลทุกวัน ตี 2
0 2 * * * /opt/scripts/pg_dump_auto.sh

# Full dump ทุกวันอาทิตย์ + daily incremental
0 2 * * 0 /opt/scripts/pg_full_dump.sh
0 2 * * 1-6 /opt/scripts/pg_incr_dump.sh

การตรวจสอบไฟล์สำรอง — ตรวจสอบไฟล์สำรอง

ไฟล์สำรองที่ไม่เคยทดสอบ restore เท่ากับไม่มีระบบสำรองข้อมูล ควรตรวจสอบไฟล์ที่สำรองไว้เป็นประจำเพื่อให้มั่นใจว่าสามารถกู้คืนข้อมูลได้จริง

#!/bin/bash
# Dump Verification Script
# ทดสอบว่าไฟล์สำรองสามารถ restore ได้จริง

DUMP_FILE="$1"
TEST_DB="restore_test_$(date +%s)"

echo "Creating test database: $TEST_DB"
createdb -U postgres "$TEST_DB"

echo "Restoring dump to test database..."
pg_restore -U postgres -d "$TEST_DB" "$DUMP_FILE" 2>&1

if [ $? -eq 0 ]; then
    # ตรวจสอบจำนวนตาราง
    TABLE_COUNT=$(psql -U postgres -d "$TEST_DB" -t -A -c \
        "SELECT count(*) FROM information_schema.tables WHERE table_schema = 'public';")
    echo "Verify PASSED: $TABLE_COUNT tables restored"
else
    echo "Verify FAILED: restore encountered errors"
fi

# ลบ test database
dropdb -U postgres "$TEST_DB"
echo "Test database dropped"

# ตรวจสอบไฟล์ dump โดยไม่ต้อง restore
# ดู table of contents
pg_restore -l mydb_backup.dump

# ดู table of contents พร้อมขนาด
pg_restore -l mydb_backup.dump | head -20

# ตรวจสอบว่าไฟล์ dump ไม่เสียหาย (Custom format)
pg_restore -l mydb_backup.dump > /dev/null 2>&1 && echo "OK" || echo "CORRUPTED"

สำรองฐานข้อมูลขนาดใหญ่ — เทคนิคเพิ่มประสิทธิภาพ

เมื่อฐานข้อมูลมีขนาดหลายสิบ GB ขึ้นไป การ dump ธรรมดาอาจใช้เวลานานมาก เทคนิคต่อไปนี้ช่วยเพิ่มความเร็วได้

# 1. Parallel dump — ใช้หลาย CPU
pg_dump -U postgres -Fd -j 4 -d mydb -f mydb_parallel/
# -j 4 = ใช้ 4 workers พร้อมกัน (ต้องใช้ Directory format)

# 2. Parallel restore
pg_restore -U postgres -d mydb -j 4 mydb_parallel/

# 3. บีบอัดระดับสูง
pg_dump -U postgres -Fc -Z 9 -d mydb -f mydb_maxcompress.dump
# -Z 9 = compression level สูงสุด (ช้าขึ้นแต่ไฟล์เล็กกว่า)

# 4. Exclude ตารางขนาดใหญ่ที่ไม่ต้องการ
pg_dump -U postgres -Fc -d mydb \
    -T audit_logs -T temp_data -T cache_table \
    -f mydb_without_large_tables.dump

# 5. แบ่งไฟล์สำรองเป็นไฟล์ย่อย
pg_dump -U postgres -d mydb | split -b 1G - mydb_backup_part_

# 6. ส่งไฟล์สำรองไปเซิร์ฟเวอร์อื่นโดยตรง (ไม่ต้องเก็บ local)
pg_dump -U postgres -Fc -d mydb | ssh backup-server "cat > /backup/mydb.dump"

แผนสำรองข้อมูล — แนวทางสำหรับ Production

แผนสำรองข้อมูลที่ดีต้องคำนึงถึง RPO (Recovery Point Objective) คือยอมเสียข้อมูลได้มากสุดเท่าไร และ RTO (Recovery Time Objective) คือต้องกู้คืนให้ได้ภายในเวลาเท่าไร ตัวอย่างแผนสำรองข้อมูลสำหรับ production

# แผนสำรองข้อมูลสำหรับ Production
# -----------------------------------------------
# 1. WAL Archiving          — ทำตลอดเวลา (RPO ≈ 0)
# 2. pg_basebackup (Full)   — ทุกวันอาทิตย์ ตี 1
# 3. pg_dump (Logical)      — ทุกวัน ตี 2
# 4. ตรวจสอบไฟล์ dump          — ทุกวันจันทร์ ตี 4
# 5. สำเนาสำรองนอกสถานที่          — ทุกวัน ตี 5

# ตัวอย่าง crontab
0 1 * * 0 /opt/scripts/pg_basebackup_full.sh
0 2 * * * /opt/scripts/pg_dump_daily.sh
0 4 * * 1 /opt/scripts/pg_verify_dump.sh
0 5 * * * /opt/scripts/pg_offsite_sync.sh

หลัก 3-2-1 Rule: เก็บสำเนาสำรองอย่างน้อย 3 ชุด ในสื่อจัดเก็บ 2 ประเภทที่ต่างกัน โดย 1 สำเนาต้องอยู่นอกสถานที่ (off-site) เช่น ส่งไปจัดเก็บบน Object Storage หรืออีกดาต้าเซ็นเตอร์

การรักษาความปลอดภัยไฟล์สำรอง

ไฟล์ที่สำรองไว้มีข้อมูลทั้งหมดของฐานข้อมูล ดังนั้นต้องป้องกันไม่ให้ถูกเข้าถึงโดยไม่ได้รับอนุญาต

# เข้ารหัสไฟล์สำรองด้วย GPG
pg_dump -U postgres -Fc -d mydb | gpg --symmetric --cipher-algo AES256 -o mydb_backup.dump.gpg

# ถอดรหัสและ restore
gpg -d mydb_backup.dump.gpg | pg_restore -U postgres -d mydb

# ตั้งค่า permission ให้ไฟล์ที่สำรอง
chmod 600 /backup/postgresql/*.dump
chown postgres:postgres /backup/postgresql/*.dump

# ใช้ .pgpass เพื่อไม่ต้องใส่ password ใน script
# สร้างไฟล์ ~/.pgpass
echo "localhost:5432:*:postgres:your_password" > ~/.pgpass
chmod 600 ~/.pgpass

Troubleshooting ปัญหาที่พบบ่อย

ปัญหาที่มักเจอเมื่อทำการสำรอง/กู้คืนและวิธีแก้ไข

# ปัญหา: "connection refused" เมื่อ pg_dump
# แก้: ตรวจสอบว่า PostgreSQL กำลังรันอยู่
sudo systemctl status postgresql
# ตรวจสอบ port
pg_isready -h localhost -p 5432

# ปัญหา: "permission denied" เมื่อ pg_dump
# แก้: ใช้ user ที่มีสิทธิ์เข้าถึงทุกตาราง
pg_dump -U postgres -d mydb -f backup.sql
# หรือ grant permission
GRANT SELECT ON ALL TABLES IN SCHEMA public TO backup_user;

# ปัญหา: restore error "role does not exist"
# แก้: สร้าง role ก่อน restore หรือใช้ --no-owner
pg_restore -U postgres -d mydb --no-owner mydb_backup.dump

# ปัญหา: restore error "database already exists"
# แก้: ใช้ --clean หรือ drop database ก่อน
pg_restore -U postgres -c -d mydb mydb_backup.dump

# ปัญหา: การ dump ช้ามาก
# แก้: ใช้ parallel dump
pg_dump -U postgres -Fd -j $(nproc) -d mydb -f mydb_parallel/

# ปัญหา: ไฟล์ dump ใหญ่มาก
# แก้: ใช้ compression + exclude ตาราง log/temp
pg_dump -U postgres -Fc -Z 9 -d mydb -T huge_log_table -f mydb_compact.dump

สรุป

การสำรองข้อมูลเป็นพื้นฐานสำคัญของการดูแลฐานข้อมูล PostgreSQL เครื่องมือหลักที่ควรรู้จักได้แก่ pg_dump สำหรับ Logical Dump แบบรายฐานข้อมูล pg_dumpall สำหรับสำรองทุกฐานข้อมูลพร้อม roles และ pg_basebackup สำหรับ Physical Dump ที่รวดเร็ว เมื่อรวมกับ WAL Archiving จะสามารถทำ Point-in-Time Recovery ได้ ซึ่งเป็นระดับการป้องกันสูงสุดสำหรับ production

สิ่งสำคัญที่สุดคือต้องทดสอบ restore เป็นประจำ ตั้ง automated dump พร้อม monitoring และเก็บไฟล์สำรองไว้หลายที่ตามหลัก 3-2-1 Rule การลงทุนเวลาตั้งค่าระบบสำรองข้อมูลที่ดีตั้งแต่แรกจะคุ้มค่าอย่างมากเมื่อเกิดเหตุไม่คาดฝัน

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

การตั้งค่าระบบสำรองข้อมูลที่เชื่อถือได้ต้องการเซิร์ฟเวอร์ที่ควบคุมได้เต็มที่ ทั้ง cron job, shell script, WAL archiving และพื้นที่จัดเก็บไฟล์ dump Cloud VPS ของ DE ให้คุณติดตั้งและ configure PostgreSQL ได้อย่างอิสระ พร้อม storage ที่ขยายได้ตามความต้องการ เหมาะกับการเก็บข้อมูลสำรองทั้ง on-site และ off-site

สำหรับผู้ที่ต้องการโฮสต์เว็บแอปพลิเคชันที่ใช้ฐานข้อมูลโดยไม่ต้องดูแลเซิร์ฟเวอร์เอง Cloud Hosting ของ DE มีระบบสำรองข้อมูลอัตโนมัติในตัว ช่วยให้คุณมั่นใจว่าข้อมูลจะปลอดภัยโดยไม่ต้องตั้งค่าเอง