Bài 29: Backup database và kiểm tra restore

# PostgreSQL
pg_dump -Fc dbname > dbname.dump
createdb dbname_restore
pg_restore -d dbname_restore dbname.dump

ls -lh dbname.sql dbname.dump 2>/dev/null || true
sha256sum dbname.sql 2>/dev/null || true</pre><h2>4. Tình huống thực tế</h2><div class="note"><p>Website có backup database hằng ngày nhưng chưa từng restore. Anh tạo database test, restore backup vào đó và kiểm tra số bảng/dữ liệu để chứng minh backup dùng được.</p></div><h2>5. Quy trình áp dụng an toàn</h2><ol><li>Viết cấu hình hoặc command trong môi trường lab.</li><li>Kiểm tra syntax/plan/status trước khi apply.</li><li>Chạy với phạm vi nhỏ trước.</li><li>Quan sát log, metric và health check.</li><li>Ghi lại thay đổi vào tài liệu vận hành.</li><li>Chuẩn bị rollback hoặc version trước đó.</li></ol><h2>6. Lỗi thường gặp</h2><ul><li>Copy cấu hình từ mạng mà không hiểu biến/môi trường.</li><li>Không lưu file cấu hình vào Git.</li><li>Không kiểm tra log sau khi apply.</li><li>Không có môi trường test/staging.</li></ul><div class="warn"><strong>Lưu ý production:</strong> Công cụ tự động hóa giúp làm nhanh hơn, nhưng cũng có thể làm sai hàng loạt nhanh hơn. Luôn giới hạn phạm vi khi mới triển khai.</div><h2>7. Checklist</h2><div class="check"><ul><li>Có file cấu hình rõ ràng.</li><li>Có bước kiểm tra trước khi apply.</li><li>Có log/health check sau khi apply.</li><li>Có rollback/version cũ.</li><li>Có tài liệu ai chạy, chạy khi nào, kết quả gì.</li></ul></div><h2>8. Bài tập</h2><ol><li>Dựng một lab nhỏ theo lệnh mẫu.</li><li>Chạy lệnh kiểm tra trạng thái trước/sau.</li><li>Tạo một lỗi cấu hình nhỏ và sửa lại.</li><li>Viết checklist production cho chủ đề này.</li></ol><div class="next"><strong>Bài tiếp theo:</strong> Prometheus và Grafana nhập môn</div></div>

Chốt ý nhanh

Chủ đề	Điểm cần nhớ
Backup database	Chỉ có giá trị khi restore được và restore đúng dữ liệu cần thiết.
Sai lầm phổ biến	Ai cũng nghĩ mình có backup, cho đến lúc restore mới biết file hỏng hoặc quy trình thiếu.
Production mindset	Backup là một quy trình cần kiểm thử định kỳ, không phải một lệnh chạy xong rồi quên.

Phần thực hành mở rộng: backup database phải đi kèm restore drill

Nếu chỉ dạy cách dump database mà không dạy restore, bài học sẽ thiếu mất nửa quan trọng nhất. Người vận hành cần hiểu backup chỉ là lời hứa; restore mới là bằng chứng.

Lab 1: Dump database bằng mysqldump hoặc pg_dump

mysqldump -u root -p appdb > appdb.sql
pg_dump -U postgres appdb > appdb.sql

Mục tiêu là hiểu output backup đang ở dạng nào: logical SQL dump, không phải snapshot toàn máy.

Lab 2: Kiểm tra file backup sau khi tạo

ls -lh appdb.sql
head -20 appdb.sql
gzip -c appdb.sql > appdb.sql.gz
ls -lh appdb.sql.gz

Đừng chỉ nhìn file có tồn tại. Hãy mở đầu file để xem nó có thực sự là dump hợp lệ không.

Lab 3: Restore vào môi trường test

mysql -u root -p -e "create database appdb_restore_test"
mysql -u root -p appdb_restore_test < appdb.sql

psql -U postgres -c "create database appdb_restore_test"
psql -U postgres appdb_restore_test < appdb.sql

Đây là phần quan trọng nhất: restore vào môi trường riêng để chứng minh backup dùng được.

Lab 4: Kiểm tra tính đúng đắn sau restore

đếm số bảng
kiểm tra vài record quan trọng
xác nhận charset/collation nếu cần
kiểm tra user/app có kết nối được không

Lab 5: Tạo checklist backup job

chạy lúc nào
giữ bao lâu
lưu ở đâu
mã hóa hay không
ai nhận alert nếu backup fail
bao lâu test restore một lần

Tình huống thực tế

Một backup job đêm nào cũng sinh file SQL, nhưng thực ra dump bị lỗi quyền ở nửa chừng hoặc dung lượng 0 byte. Không restore test, cả đội vẫn tưởng mọi thứ ổn cho đến ngày sự cố thật xảy ra.

Lỗi phổ biến

Có backup nhưng không có restore drill.
Lưu backup trên cùng máy với database.
Không kiểm tra dung lượng và nội dung file dump.
Không alert khi backup fail.

Kết bài

Sau bài này, anh nên có phản xạ rất rõ: backup không được đo bằng số file, mà bằng khả năng khôi phục thật. Từ đây sang Prometheus và Grafana, trọng tâm sẽ dịch sang quan sát hệ thống liên tục để phát hiện vấn đề sớm hơn trước khi phải dùng đến backup.