Trả lời nhanh: Backup database có ba tầng theo mức nghiêm trọng: tầng 1, dump hằng đêm (pg_dump/mysqldump qua cron, giữ 7-14 bản) đủ cho đa số dự án, chấp nhận mất tối đa một ngày dữ liệu; tầng 2, WAL archiving + PITR khôi phục về đúng một thời điểm bất kỳ, chuẩn của dữ liệu tiền nong; tầng 3, bản sao rời máy (quy tắc 3-2-1: 3 bản, 2 nơi, 1 bản ngoài máy chủ). Và điều quan trọng hơn mọi tầng: backup chưa từng tập restore chỉ là niềm tin, lịch tập mỗi quý một lần.
RAID không phải backup (nó chỉ chống hỏng ổ, không chống lệnh DELETE nhầm). Snapshot VPS không hẳn là backup database (có thể dính trạng thái ghi dở). Bài này xếp các lớp bảo vệ dữ liệu theo đúng thứ tự đáng đầu tư, kèm script dán được và, phần hay bị trốn, quy trình tập restore.
- Tầng 1: dump đêm + giữ 7-14 bản, 15 phút setup, cứu 90% kịch bản tai nạn
- Tầng 2: WAL/binlog archiving cho PITR, khôi phục về 14:59, ngay trước phút tay nhanh hơn não
- Tầng 3: quy tắc 3-2-1, một bản phải rời khỏi máy chủ (S3/máy khác/backup nhà cung cấp)
- Restore drill mỗi quý: backup được tập dượt mới là backup thật
Tầng 1: Dump hằng đêm - nền móng bắt buộc
# Postgres (cron cua user postgres, 2h sang, xoay 7 ban theo thu trong tuan)
0 2 * * * pg_dump -Fc shop > /var/backups/pg/shop-$(date +%u).dump
# MySQL
0 2 * * * mysqldump --single-transaction --routines shop | gzip > /var/backups/my/shop-$(date +%u).sql.gzHai chi tiết cứu mạng: -Fc (Postgres) cho restore chọn lọc từng bảng bằng pg_restore; --single-transaction (MySQL/InnoDB) dump nhất quán mà không khóa bảng, thiếu nó là site đứng hình lúc 2h sáng mỗi đêm. Dump nén trên ổ NVMe chạy nhanh và ít ảnh hưởng tải đêm, thêm lý do đặt lịch mạnh dạn mỗi ngày thay vì mỗi tuần.
Tầng 2: PITR - cỗ máy thời gian cho dữ liệu quan trọng
Kịch bản dump đêm không cứu được: 15h chiều chạy nhầm UPDATE không WHERE, dump gần nhất là 2h sáng, mất trắng 13 tiếng giao dịch. PITR (Point-In-Time Recovery) giải bằng cách lưu liên tục nhật ký thay đổi (WAL của Postgres, binlog của MySQL): khôi phục = base backup + tua nhật ký đến 14:59:59, ngay trước tai nạn.
Cách bật gọn cho Postgres: dùng pgBackRest hoặc wal-g, hai công cụ chuyên nghiệp lo trọn base backup + archive WAL về S3/thư mục ngoài, cấu hình một file. Đáng đầu tư khi: dữ liệu là tiền (đơn hàng, ví, công nợ) hoặc chi phí một giờ dữ liệu mất lớn hơn một buổi setup.
Tầng 3: Quy tắc 3-2-1 - vì máy chủ cũng có ngày xấu
Backup nằm cùng máy với database chết chung khi máy chết. Chuẩn 3-2-1: 3 bản dữ liệu, trên 2 loại lưu trữ, 1 bản rời hẳn máy. Đường rời máy rẻ nhất:
# day dump dem qua S3-compatible (Cloudflare R2/Backblaze) bang rclone
30 2 * * * rclone copy /var/backups/pg remote:shop-backups/$(date +%Y-%m)/Cộng backup máy chủ định kỳ của nhà cung cấp (như backup tuần sang hệ thống riêng của TND) là bạn có lớp 3 miễn phí, nhưng đừng để nó là lớp duy nhất: backup do chính bạn nắm restore được chủ động, không phụ thuộc ticket hỗ trợ lúc dầu sôi.
Restore drill: nghi thức mỗi quý 30 phút
- Tạo database tạm:
createdb shop_drill - Restore bản mới nhất:
pg_restore -d shop_drill /var/backups/pg/shop-5.dump - Kiểm 3 số sống còn: đếm đơn hôm qua, tổng tiền tháng, bản ghi mới nhất, khớp kỳ vọng?
- Ghi lại thời gian restore (đó chính là RTO thực tế của bạn) rồi xóa database tạm.
30 phút mỗi quý đổi lấy: biết chắc file backup không hỏng, biết chắc quy trình chạy, và biết chính xác mất bao lâu để sống lại, ba thứ mà đêm sự cố thật không cho bạn thời gian tìm hiểu.
Chọn tầng sao lưu theo mức chịu đựng mất dữ liệu
| Mất bao nhiêu dữ liệu là chấp nhận được | Cần tầng nào | Chi phí thêm |
|---|---|---|
| Một ngày | Kết xuất hằng đêm là đủ | Gần như không |
| Vài giờ | Kết xuất hằng đêm cộng kết xuất giữa ngày | Không đáng kể |
| Vài phút | Kết xuất cộng lưu nhật ký ghi liên tục | Dung lượng và một chút công cấu hình |
| Gần như không được mất gì | Lưu nhật ký ghi liên tục cộng máy dự phòng chạy song song | Thêm một máy chủ |
Câu hỏi phải trả lời trước khi cấu hình bất cứ thứ gì: mất bao nhiêu dữ liệu thì doanh nghiệp chịu được, và ngừng bao lâu thì chịu được. Hai con số này quyết định toàn bộ thiết kế, và nhiều người dựng bỏ qua bước này rồi cấu hình theo cảm giác.
Bộ lệnh cho tầng một, chạy được ngay
# Ket xuat hang dem, dinh dang nen, kem ngay trong ten pg_dump -U postgres -Fc tenCSDL > /sao-luu/db-$(date +%F).dump # Kiem tep vua tao co doc duoc khong, buoc nay hay bi bo qua pg_restore --list /sao-luu/db-$(date +%F).dump > /dev/null && echo "ban sao doc duoc" # Day ra may khac ngay trong dem rsync -avz /sao-luu/ may-luu-tru:/kho/db/ # Don ban cu hon 30 ngay find /sao-luu -name "db-*.dump" -mtime +30 -delete # Dat vao cron, 2 gio sang # 0 2 * * * /root/sao-luu-db.sh >> /var/log/sao-luu.log 2>&1
Dòng kiểm tệp vừa tạo là dòng đáng giá nhất trong đoạn trên. Rất nhiều hệ thống chạy sao lưu suốt hai năm rồi phát hiện tệp rỗng vào đúng ngày cần khôi phục.
Diễn tập khôi phục, ba mươi phút mỗi quý
- Lấy bản sao mới nhất, nạp vào một máy khác hoặc một container tách biệt.
- Bấm giờ. Con số này là thời gian ngừng thật của bạn, không phải con số trong tài liệu.
- Chạy vài truy vấn kiểm chứng: đếm số dòng các bảng chính, kiểm bản ghi mới nhất có mốc thời gian đúng không.
- Ghi lại kết quả vào một tệp: ngày diễn tập, thời gian nạp, vấn đề gặp phải.
Quy tắc ba hai một vẫn đúng: ba bản sao, hai loại phương tiện khác nhau, một bản ở nơi khác. Với hệ thống nhỏ, phiên bản thực dụng là: dữ liệu gốc trên máy chủ, bản sao trên cùng máy để khôi phục nhanh, và một bản đẩy sang máy hoặc dịch vụ lưu trữ khác.
Câu hỏi thường gặp
Snapshot VPS có thay được dump database không?
Bổ sung chứ không thay: snapshot chụp cả máy nhưng có thể dính trạng thái database đang ghi dở, và không restore chọn lọc từng bảng được. Dump/PITR là chuẩn của dữ liệu; snapshot là chuẩn của cả máy.
Backup có làm chậm database không?
Dump đêm trên NVMe với --single-transaction/-Fc: ảnh hưởng nhỏ và nằm giờ thấp điểm. WAL archiving gần như miễn phí (chép file log đã ghi sẵn). Nỗi lo này không phải lý do trì hoãn.
Giữ backup bao lâu là đủ?
Phổ thông: 7-14 bản ngày + 3-6 bản tháng. Dữ liệu kế toán theo quy định lưu trữ riêng thì dài hơn. Chi phí lưu dump nén rất rẻ so với giá của ngày cần đến nó.
n8n, Redis, file upload có cần backup kiểu này không?
Có, theo cách của từng loại: n8n = volume + export workflow (bài cài n8n có sẵn), Redis = RDB/AOF nếu chứa dữ liệu thật, file upload = rclone sang S3. Nguyên tắc chung một câu: thứ gì xóa đi làm bạn đau, thứ đó cần bản sao rời máy.
