Bạn backup và recovery PostgreSQL như thế nào?

Question

Accepted Answer

PostgreSQL cung cấp nhiều phương pháp **backup** — logical backup (`pg_dump`) và physical backup (base backup + WAL cho **point-in-time recovery**). Một chiến lược backup-and-recovery vững chắc là thiết yếu để bảo vệ chống mất dữ liệu, và quan trọng nhất là **backup phải được kiểm thử (test)**.

## Logical backup — pg_dump

```bash
# pg_dump — dump một database thành SQL (hoặc archive tùy chỉnh) — portable, linh hoạt
pg_dump -U user -d mydb -F c -f backup.dump      # custom format (nén, restore linh hoạt)
pg_dump -U user -d mydb > backup.sql              # SQL thuần
pg_dumpall > all.sql                              # TẤT CẢ database + roles

# restore
pg_restore -U user -d mydb backup.dump            # từ custom format
psql -U user -d mydb -f backup.sql                # từ SQL thuần
```

`pg_dump` tạo một logical backup (SQL hoặc archive) của một database — portable (có thể restore sang phiên bản/server khác), phù hợp cho database nhỏ, migration và backup chọn lọc. Nhưng đó là một snapshot tại một thời điểm (không có recovery liên tục).

## Physical backup + Point-in-Time Recovery (PITR)

```text
Với database lớn hơn/quan trọng: một BASE BACKUP (bản sao các data file) + archiving
liên tục WAL (write-ahead log) → cho phép POINT-IN-TIME RECOVERY:
  ✓ Restore base backup, sau đó REPLAY WAL đến BẤT KỲ thời điểm nào
  ✓ Recovery về NGAY TRƯỚC khi xảy ra sự cố (ví dụ một DROP TABLE vô tình lúc 2:47 chiều)
→ Công cụ: pg_basebackup, WAL archiving, và các tool như pgBackRest / Barman tự động hóa việc này.
```

**PITR** rất mạnh: bằng cách archiving WAL liên tục, bạn có thể recovery về bất kỳ khoảnh khắc nào — không chỉ về backup gần nhất — điều này thiết yếu để giảm thiểu mất dữ liệu do sự cố.

## Những điều cốt lõi của chiến lược backup

```text
✓ Backup ĐỊNH KỲ, TỰ ĐỘNG (lên lịch, không thủ công/dễ quên)
✓ Lưu backup TÁCH KHỎI database server (và off-site / cloud) — sống sót qua hỏng phần cứng
✓ Chính sách lưu trữ - retention (giữ daily/weekly/monthly tùy nhu cầu)
✓ Kết hợp: base backup định kỳ + WAL liên tục cho PITR (dữ liệu quan trọng)
✓ Backup từ một REPLICA để tránh tạo tải lên primary
```

## Quy tắc quan trọng nhất: TEST backup của bạn

```text
⚠️ Một backup bạn chưa bao giờ restore thì KHÔNG phải là backup đáng tin cậy.
Backup CHƯA ĐƯỢC TEST sẽ thất bại đúng lúc bạn cần nó nhất (lỗi, không đầy đủ, sai quy trình).
→ Thường xuyên TEST việc restore để xác minh chúng thực sự hoạt động và bạn nắm rõ quy trình.
```

## Tại sao điều này quan trọng

Backup và recovery là kiến thức **then chốt** để vận hành PostgreSQL một cách có trách nhiệm — bảo vệ chống mất dữ liệu (do hỏng phần cứng, lỗi corruption, xóa nhầm, sự cố) là một trong những trách nhiệm quan trọng nhất với bất kỳ database production nào, nên hiểu các chiến lược backup là thiết yếu ở cấp độ senior.

Hiểu các phương pháp là cần thiết: **`pg_dump`** (logical backup — dump SQL/archive portable, phù hợp cho database nhỏ, migration và backup chọn lọc/cross-version, nhưng chỉ là snapshot tại một thời điểm) và **physical backup với Point-in-Time Recovery (PITR)** (base backup + WAL archiving liên tục, cho phép recovery về *bất kỳ* khoảnh khắc nào — điều này rất mạnh để giảm thiểu mất dữ liệu, như recovery về ngay trước một lệnh `DROP TABLE` vô tình, thiết yếu với dữ liệu quan trọng).

Nắm các **điều cốt lõi của chiến lược** (backup tự động định kỳ, lưu off-server và off-site, chính sách retention, kết hợp base backup với WAL cho PITR trên dữ liệu quan trọng, backup từ replica) là kiến thức vận hành quan trọng.

Quan trọng nhất, hiểu rằng **backup phải được test** — một backup chưa được test thì không đáng tin và thường thất bại đúng lúc cần (corruption, dữ liệu không đầy đủ, quy trình restore xa lạ) — là một nguyên tắc thiết yếu nhưng thường bị bỏ qua: thường xuyên test việc restore mới là điều khiến chiến lược backup thực sự đáng tin cậy.

Vì mất dữ liệu có thể là thảm họa (và recovery chỉ khả thi khi có backup hoạt động được), và vì một chiến lược đúng đắn (phương pháp backup phù hợp, PITR cho mất mát tối thiểu, lưu trữ off-site, và quan trọng nhất là restore *đã được test*) là thứ bảo vệ dữ liệu của một tổ chức, hiểu backup và recovery của PostgreSQL là kiến thức then chốt ở cấp độ senior cho việc vận hành database có trách nhiệm — một trách nhiệm cao rủi ro, nơi sự khác biệt giữa một chiến lược đã được test và một chiến lược chưa test có thể là khác biệt giữa việc recovery khỏi thảm họa và mất dữ liệu vĩnh viễn, khiến nó trở thành một chủ đề thiết yếu, thường xuyên liên quan với bất kỳ ai vận hành database production.