PostgreSQL Bài 38: Cơ chế sao lưu và khôi phục (Backup & Restore): pg_dump, WAL archiving và PITR.

Cơ chế sao lưu và khôi phục (Backup & Restore) trong PostgreSQL là chốt chặn cuối cùng bảo vệ hệ thống khỏi các thảm họa như lỗi thao tác con người (vô tình chạy lệnh DROP TABLE), mã độc tống tiền (Ransomware), hoặc hỏng hóc phần cứng diện rộng. PostgreSQL cung cấp hai trường phái sao lưu hoàn toàn khác biệt: sao lưu logic ở cấp độ dữ liệu và sao lưu vật lý ở cấp độ khối đĩa kết hợp nhật ký WAL.

1. Sao lưu Logic: pg_dump và pg_restore

Sao lưu logic trích xuất cấu trúc bảng và dòng dữ liệu thành các câu lệnh SQL (CREATE TABLE, INSERT) hoặc định dạng nhị phân tùy chỉnh. Cơ chế này chỉ đọc dữ liệu ở mốc thời gian hiện tại thông qua một Snapshot, không lưu lại lịch sử biến động.

• Lệnh pg_dump: Dùng để sao lưu một cơ sở dữ liệu cụ thể. Khuyến nghị luôn sử dụng định dạng Custom (-F c) vì nó nén dung lượng, cho phép khôi phục đa luồng và chọn lọc từng bảng.

  Bash

  # Sao lưu database 'sales_db' ra file nén custom
  pg_dump -U postgres -F c -d sales_db -f /backups/sales_db_20261009.dump
  
  

• Lệnh pg_dumpall: Trích xuất toàn bộ cụm PostgreSQL, bao gồm cả các thông tin hệ thống dùng chung (Global Objects) như danh sách Roles/Users và Tablespaces mà pg_dump không thể chạm tới.

• Lệnh pg_restore: Đọc file custom nén và đẩy ngược vào database. Bạn có thể tận dụng tham số -j để khôi phục song song bằng nhiều nhân CPU, giúp giảm thời gian downtime.

  Bash

  # Khôi phục song song với 4 workers (nhân CPU)
  pg_restore -U postgres -d sales_db -j 4 /backups/sales_db_20261009.dump
  
  

Nhược điểm chí mạng: Việc khôi phục (Restore) từ file dump rất chậm. Engine phải thực hiện chèn từng dòng (INSERT), xây dựng lại toàn bộ cấu trúc B-Tree Index từ đầu, không phù hợp cho các database quy mô hàng trăm GB trở lên với yêu cầu thời gian phục hồi (RTO) tính bằng phút.

2. Sao lưu Vật lý và WAL Archiving

Thay vì xuất dữ liệu thành SQL, sao lưu vật lý copy trực tiếp toàn bộ thư mục PGDATA (chứa các khối 8KB, file index, thư mục cấu hình). Tốc độ khôi phục bằng đúng tốc độ copy file của ổ cứng, không cần build lại Index.

Để đảm bảo sao lưu vật lý an toàn và không bị đứt gãy dữ liệu, bạn bắt buộc phải bật tính năng WAL Archiving. Như đã học ở Bài 33, WAL lưu trữ mọi thao tác thay đổi. Khi một file WAL (thường 16MB) đầy, PostgreSQL sẽ đóng gói nó và gọi một lệnh hệ điều hành để copy file đó ra kho lưu trữ an toàn (như NAS hoặc Amazon S3) trước khi tái sử dụng.

Cấu hình trong postgresql.conf:

Ini, TOML

wal_level = replica             # Bắt buộc từ mức replica trở lên
archive_mode = on               # Bật chế độ lưu trữ WAL
archive_command = 'cp %p /mnt/nfs_backup/wal_archive/%f'  # Lệnh shell copy file

Sau khi WAL Archiving hoạt động, bạn sử dụng công cụ pg_basebackup để tạo ra một bản sao lưu vật lý hoàn chỉnh ngay cả khi hệ thống đang phục vụ hàng ngàn truy vấn:

Bash

pg_basebackup -h localhost -U replicator_user -D /backups/base_backup/ -Ft -z -P

3. Khôi phục xuyên không gian: Point-in-Time Recovery (PITR)

PITR là đỉnh cao của kỹ thuật sao lưu. Nếu một nhân viên vô tình chạy lệnh DELETE FROM orders; lúc 10:05 sáng, bản backup pg_dump lúc 00:00 đêm qua sẽ khiến bạn mất toàn bộ đơn hàng từ nửa đêm đến sáng. Với PITR, bạn có thể "tua ngược thời gian" database về chính xác mốc 10:04:59 sáng, cứu trọn vẹn dữ liệu ngay trước thảm họa.

PITR là sự kết hợp giữa Base Backup (Bản sao lưu vật lý nền) và WAL Archives (Các file log liên tục).

Quy trình kích hoạt PITR:

1. Dừng hệ thống: Tắt tiến trình PostgreSQL hiện tại.

2. Dọn dẹp: Xóa hoặc đổi tên thư mục PGDATA bị hỏng. Giải nén bản pg_basebackup gần nhất vào thư mục này.

3. Tạo tín hiệu phục hồi: Tạo một file rỗng mang tên recovery.signal bên trong thư mục PGDATA để báo cho PostgreSQL biết nó cần chuyển sang chế độ khôi phục thảm họa thay vì khởi động bình thường.

4. Cấu hình mốc thời gian mục tiêu: Thêm các chỉ thị vào postgresql.conf:

   Ini, TOML

   # Chỉ định cách PostgreSQL lấy lại các file WAL từ kho lưu trữ
   restore_command = 'cp /mnt/nfs_backup/wal_archive/%f %p'
   
   # Mốc thời gian dừng phát lại WAL (ngay trước lúc xảy ra thảm họa)
   recovery_target_time = '2026-10-09 10:04:59+07'
   
   # Hành động sau khi khôi phục xong (promote: thăng cấp thành Master bình thường)
   recovery_target_action = 'promote'
   
   

5. Khởi động lại: PostgreSQL sẽ tự động nạp Base Backup, kéo các file WAL từ kho lưu trữ về, và dùng tiến trình REDO để phát lại tuần tự từng lệnh thay đổi cho đến khi đồng hồ hệ thống chạm đúng 10:04:59 thì dừng lập tức và mở kết nối cho ứng dụng.

Việc thiết lập WAL Archiving kết hợp Base Backup định kỳ giúp RPO (Recovery Point Objective - Khối lượng dữ liệu mất mát) gần như bằng 0, là tiêu chuẩn bắt buộc cho mọi hệ thống PostgreSQL cấp độ doanh nghiệp.