Login

Backup và restore database: quy tắc 3-2-1 và cách thử khôi phục

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

Có hai loại người: những người đã mất dữ liệu và những người sắp mất dữ liệu. Ổ đĩa hỏng, lệnh xóa nhầm, mã độc, lỗi triển khai: đều có thể xảy ra. Sao lưu là bảo hiểm rẻ nhất bạn có, nhưng chỉ khi nó thật sự khôi phục được.

Quy tắc 3-2-1

Quy tắc kinh điển được nhiều người thực hành:

  • 3 bản sao dữ liệu (bản gốc cộng hai bản sao lưu).
  • 2 loại phương tiện lưu trữ khác nhau.
  • 1 bản đặt ở nơi khác (khác máy chủ, tốt nhất khác địa điểm hoặc khác nhà cung cấp).

Bản sao lưu nằm cùng ổ đĩa với dữ liệu gốc không giúp gì khi ổ hỏng. Bản sao chỉ nằm cùng tài khoản cloud cũng có thể bị xóa chung nếu tài khoản bị xâm nhập.

Sao lưu MySQL và PostgreSQL

Hai công cụ dòng lệnh cơ bản:

mysqldump -u root -p --single-transaction --routines tendb > tendb.sql

pg_dump -U postgres -Fc tendb > tendb.dump

Với MySQL, cờ --single-transaction cho bản sao nhất quán với bảng InnoDB mà không khóa bảng lâu. Với PostgreSQL, định dạng -Fc (custom) nén sẵn và cho phép khôi phục chọn lọc. Mật khẩu không nên gõ trực tiếp trong lệnh vì lộ trong lịch sử; hãy dùng file cấu hình riêng với quyền truy cập hạn chế hoặc biến môi trường.

Khôi phục

mysql -u root -p tendb < tendb.sql

pg_restore -U postgres -d tendb_moi --clean --if-exists tendb.dump

Thông thường nên khôi phục vào một cơ sở dữ liệu mới để kiểm tra trước, thay vì ghi đè ngay lên dữ liệu đang chạy.

Tự động hóa bằng script và cron

#!/bin/bash
set -euo pipefail
NGAY=$(date +%F)
DIR=/backup/db
mkdir -p "$DIR"
pg_dump -U postgres -Fc tendb > "$DIR/tendb-$NGAY.dump"
find "$DIR" -name 'tendb-*.dump' -mtime +14 -delete

Script sao lưu mỗi lần chạy và xóa bản cũ hơn 14 ngày. Lên lịch bằng cron vào giờ ít người dùng, rồi sao chép bản sao lưu sang nơi khác bằng rsync hoặc đẩy lên kho lưu trữ đối tượng. Nhớ mã hóa bản sao lưu nếu chứa dữ liệu nhạy cảm.

Sao lưu không có nghĩa là khôi phục được

Câu nói đáng nhớ: bản sao lưu chưa từng thử khôi phục thì chưa thể gọi là bản sao lưu. Hãy định kỳ:

  1. Khôi phục bản gần nhất vào một máy hoặc container thử nghiệm.
  2. Kiểm tra dữ liệu: số bản ghi hợp lý không, bảng quan trọng có đủ không?
  3. Đo thời gian khôi phục để biết sự cố sẽ mất bao lâu.
  4. Ghi quy trình khôi phục thành tài liệu để người khác cũng làm được lúc khẩn cấp.

Hai chỉ số cần biết

  • RPO (Recovery Point Objective): chấp nhận mất tối đa bao nhiêu dữ liệu, tính theo thời gian. Sao lưu mỗi đêm nghĩa là có thể mất đến một ngày.
  • RTO (Recovery Time Objective): chấp nhận ngừng dịch vụ tối đa bao lâu để khôi phục.

Nếu một ngày dữ liệu là quá nhiều, cần sao lưu thường xuyên hơn hoặc dùng sao lưu liên tục (như lưu nhật ký giao dịch để khôi phục tới thời điểm bất kỳ).

Lỗi thường gặp

  • Chỉ sao lưu cơ sở dữ liệu mà quên file người dùng tải lên và file cấu hình.
  • Sao lưu thất bại trong im lặng mà không có cảnh báo.
  • Bản sao lưu và dữ liệu gốc chung một chỗ.
  • Dùng cách sao chép file khi cơ sở dữ liệu đang ghi, dẫn đến bản sao hỏng.
  • Giữ khóa mã hóa ở cùng chỗ với bản sao lưu, hoặc mất khóa.

Kết luận

Hãy áp dụng quy tắc 3-2-1, tự động hóa sao lưu, đặt cảnh báo khi thất bại và quan trọng nhất là thử khôi phục định kỳ. Dành một giờ để làm điều này hôm nay có thể cứu bạn khỏi một tuần hoảng loạn sau này.

Nếu bạn muốn học về cơ sở dữ liệu và vận hành đi cùng nhau, hãy xem các khóa học trên codebem.com.

author_photo
Nguyễn Đình Cường

0 comment