Backup PostgreSQL trên VPS Việt Nam bằng pg_dump và kiểm tra phục hồi

Một bản sao lưu PostgreSQL chỉ có ý nghĩa khi phục hồi được và dữ liệu đúng. Nhiều website đặt trên VPS Việt Nam chạy pg_dump theo lịch nhưng chưa thử restore; đến lúc database lỗi mới phát hiện backup thiếu role, extension hoặc không phù hợp phiên bản server. Quy trình sau giúp bạn xây dựng một phép thử có thể kiểm chứng, thay vì chỉ nhìn thấy file .sql hay .dump trong ổ đĩa.

Lệnh minh họa cần thay theo môi trường. Hãy dùng tài khoản có quyền phù hợp và nơi lưu file được bảo vệ. Không đưa chuỗi kết nối chứa mật khẩu lên public repository.

pg_dump làm được gì và không làm được gì?

pg_dump tạo một bản sao logic của cơ sở dữ liệu, có thể bao gồm schema và dữ liệu. Với định dạng custom (-Fc), bạn thường có thể dùng pg_restore để chọn đối tượng phục hồi linh hoạt hơn. Tuy nhiên, đây không phải bản sao toàn bộ máy chủ PostgreSQL: role, quyền cấp hệ thống và cấu hình server cần được xử lý riêng tùy phương án sao lưu.

Một lần pg_dump không tạo được khả năng phục hồi tới từng giây trước sự cố giống một chiến lược WAL/PITR đã cấu hình. Với cơ sở dữ liệu lớn, cửa sổ backup và thời gian restore có thể kéo dài; cần xác định RPO/RTO dựa trên yêu cầu nghiệp vụ thực tế.

Tạo backup logic an toàn

Ví dụ định dạng custom với host local và database minh họa:

pg_dump -h 127.0.0.1 -U backup_user -d app_db \
  -Fc -f /secure-backups/app_db_2026-10-10.dump

Không lưu bản sao duy nhất trên cùng ổ đĩa với database. Nếu ổ VPS hỏng hoặc tài khoản root bị xâm phạm, backup cùng máy có thể không còn giá trị. Nên có bản sao ở vị trí độc lập, giới hạn quyền truy cập và chính sách lưu giữ phù hợp với dữ liệu khách hàng.

Sau khi lệnh kết thúc, kiểm tra mã thoát, dung lượng file, checksum và log. File có dung lượng lớn không tự chứng minh cấu trúc dữ liệu đầy đủ. Với custom format, pg_restore -l /secure-backups/app_db_2026-10-10.dump cho phép liệt kê nội dung archive.

Phục hồi trên database thử nghiệm

Khôi phục vào một database khác với production và tài khoản có quyền phù hợp. Ví dụ:

createdb -h 127.0.0.1 -U restore_user app_db_restore_test
pg_restore -h 127.0.0.1 -U restore_user \
  -d app_db_restore_test /secure-backups/app_db_2026-10-10.dump

Tùy nội dung backup, chủ sở hữu object, extension và schema đã có, cần điều chỉnh --no-owner, --no-acl hoặc quy trình tạo role. Không sao chép một lệnh restore production có cờ --clean sang môi trường thật nếu chưa đánh giá vì lệnh có thể xóa đối tượng hiện hữu.

Kiểm tra dữ liệu sau restore

So sánh danh sách bảng, row count của các bảng chính, phiên bản schema và khả năng ứng dụng truy cập database thử. Với dữ liệu lớn, không phải mọi bảng đều có thể COUNT(*) toàn bộ mỗi lần; bạn có thể thiết kế checksum và kiểm tra chọn mẫu cân bằng tải. Kiểm tra riêng file upload hoặc đối tượng trên object storage nếu ứng dụng tham chiếu tới chúng, vì pg_dump không tự sao lưu toàn bộ file ngoài database.

Thử một kịch bản khôi phục thực tế với thời gian bấm đồng hồ: từ lúc nhận cảnh báo tới lúc dịch vụ thử sẵn sàng. Con số đó giúp đánh giá RTO thực hơn là dự đoán dựa trên kích thước file.

Lịch backup và giới hạn cần lưu ý

Một website ít cập nhật có thể chấp nhận lịch backup khác với cửa hàng có đơn hàng liên tục. Hãy đặt lịch dựa trên mức dữ liệu được phép mất, không dựa đơn thuần vào số lần backup “thường thấy”. Cần mã hóa bản lưu, phân quyền tải xuống, cảnh báo khi job thất bại và định kỳ thử restore.

Không trộn lẫn backup với snapshot: snapshot máy/ổ có ích trong một số kịch bản nhưng tính nhất quán database phụ thuộc cách chụp và hệ thống. Nếu cần PITR, hãy nghiên cứu backup vật lý và WAL archiving đúng phiên bản PostgreSQL.

Bạn có thể xem VPS Việt Nam để ước lượng dung lượng cần thiết cho database và lưu trữ tạm trong quá trình backup. Bài viết không hàm ý dịch vụ đang bán mặc định đã có backup tự động.

Đọc tiếp trong cùng chủ đề

Xem thêm: Đo hiệu năng NVMe trên VPS Việt Nam bằng fio: IOPS, latency và an toàn. Đối chiếu nhu cầu thực tế với trang VPS Việt Nam và thông tin gói đang bán.