# Tự chạy Postgres trên VM: ba mật khẩu, backup liên tục, restore thử

> 2server quản lý PostgreSQL 18 trên VM của bạn: ba mật khẩu tách biệt, backup pgBackRest kèm WAL archiving, và diễn tập restore tự động vào container tạm. Kèm giới hạn: không có HA hay failover tự động.

- URL: https://2found.dev/vi/blog/tu-chay-postgres-tren-vm-ba-role-restore-drill-vi/
- Published: 2026-11-04T09:03:05.777Z
- Updated: 2026-11-04T09:03:05.777Z
- Language: vi

---

Nhiều người nghe "tự chạy database trên một VM" là thấy rủi ro, và nỗi lo đó có lý: một bản backup chưa từng được restore thì chưa phải là backup, mới chỉ là một tệp bạn hy vọng dùng được.

Trang tài liệu [PostgreSQL trên 2server](https://2found.dev/docs/2server/postgres/index.md) mô tả cách 2server quản lý cluster PostgreSQL 18 trên VM của bạn. Bài này đọc lại ba thứ trong đó, và nói thẳng một thứ nó không làm.

## Một: ba mật khẩu độc lập

Theo trang tài liệu, cluster có ba mật khẩu độc lập, mỗi cái cho một việc:

| Vai trò | Dùng cho |
|---|---|
| app | DML: đọc và ghi dữ liệu của ứng dụng |
| `two_migrator` | migration |
| `two_admin` | quản trị |

Còn `two_owner` thì **không thể đăng nhập**.

Ý nghĩa thực tế của việc tách này: mật khẩu ứng dụng dùng hằng ngày để đọc ghi dữ liệu là một mật khẩu riêng, không phải mật khẩu migration hay quản trị.

## Hai: backup liên tục bằng pgBackRest và WAL archiving

Phần backup dùng pgBackRest cùng WAL archiving; trang tài liệu gọi đây là backup liên tục. Đến đây vẫn chưa nên an tâm, vì câu hỏi thật sự không phải "job backup có chạy không".

## Ba: diễn tập restore tự động

2server tự chạy diễn tập phục hồi (restore drill): phục hồi vào một container tạm để kiểm tra thực tế xem phục hồi có làm được không.

Đây là khác biệt giữa hai câu trả lời:

- "Container Postgres đang up, job backup thoát mã 0."
- "Chúng tôi đã restore thử vào một container tạm và nó lên được."

Câu đầu chỉ cho biết các tiến trình đang chạy. Câu sau mới cho biết dữ liệu về lại được. Chúng tôi từng viết về chuyện này ở bài [bốn dấu tick xanh không phủ lớp thật sự hỏng](https://2found.dev/vi/blog/dau-tick-xanh-khong-phu-lop-hong-that-su-vi/), nơi "backup thoát 0" là một trong bốn dấu tick đó.

## Điều 2server không làm

Trang tài liệu nói rõ: **không có HA hay failover tự động.** Nếu VM chứa cluster chết, không có node dự phòng nào tự lên thay; bạn cần có sẵn kế hoạch dựng lại từ backup.

Nghĩa là trước khi tin vào cách này, bạn nên tự trả lời ba câu:

1. Ứng dụng của bạn chịu được bao lâu khi database ngừng để restore?
2. Bản backup nằm ở đâu so với chính VM đó?
3. Ai sẽ chạy restore thật, và đã có ai từng làm chưa?

Nếu câu trả lời cho câu 1 là "gần như không được", bạn cần một thiết kế khác ngoài những gì trang này mô tả.

## Việc tiếp theo

Đọc [trang tài liệu PostgreSQL của 2server](https://2found.dev/docs/2server/postgres/index.md), rồi tự trả lời ba câu ở trên cho hệ thống của bạn. Sau đó hỏi chính mình: lần cuối bạn thấy một bản restore thật chạy lên là khi nào?