Snapshot và backup khác nhau thế nào? Hiểu đúng để server gặp sự cố vẫn còn dữ liệu

Snapshot và backup khác nhau thế nào là câu mình hay được hỏi nhất mỗi khi một team bắt đầu tự vận hành server production. Nhiều bạn bấm "tạo snapshot" mỗi tối rồi yên tâm là đã có backup, đến lúc ổ đĩa hỏng hoặc lỡ tay xoá nhầm volume mới biết bản snapshot đi theo luôn. Lý do là hai khái niệm này dùng chung một chữ "sao lưu" trong cách nói hằng ngày, nhưng cơ chế và mục đích lại khác hẳn. Bài này giúp các bạn phân biệt rõ hai thứ, biết lúc nào dùng cái nào và dựng được một quy trình khôi phục chạy được thật.

Bài này giúp bạn

• Hiểu cơ chế snapshot (copy-on-write) và backup (bản sao độc lập) để không nhầm cái này thay cho cái kia.
• Biết cách tạo snapshot database đúng cách để bản khôi phục không bị hỏng.
• Có checklist dựng backup tối thiểu cho server: lịch chạy, lưu ở đâu, giữ bao lâu, kiểm tra restore.

Snapshot và backup khác nhau ở điểm nào?

Câu trả lời ngắn: snapshot là "ảnh chụp" trạng thái của một ổ đĩa tại một thời điểm và thường nằm cùng hệ thống lưu trữ với dữ liệu gốc; backup là một bản sao độc lập, nằm ở nơi khác và khôi phục được kể cả khi hệ thống gốc mất hẳn. Phần dưới đi vào từng điểm để các bạn thấy vì sao khác biệt đó quyết định việc có cứu được dữ liệu hay không.

Snapshot hoạt động như thế nào?

Phần lớn snapshot ở tầng ổ đĩa (LVM, ZFS, volume của các nhà cung cấp cloud) dùng cơ chế copy-on-write hoặc redirect-on-write. Lúc tạo snapshot, hệ thống gần như không chép dữ liệu nào; nó chỉ đánh dấu mốc thời gian. Từ sau mốc đó, block nào sắp bị ghi đè thì block cũ mới được giữ lại cho snapshot. Vì vậy snapshot tạo rất nhanh và ban đầu tốn rất ít dung lượng.

Hệ quả quan trọng: snapshot vẫn phụ thuộc vào dữ liệu gốc. Những block không thay đổi từ lúc chụp được dùng chung giữa bản gốc và snapshot. Nếu ổ gốc hỏng, pool lưu trữ lỗi hoặc ai đó xoá cả volume, snapshot thường mất theo. TechTarget mô tả đúng điểm này khi nói snapshot là công cụ khôi phục nhanh chứ không thay được bản sao lưu đầy đủ (TechTarget: storage snapshot).

Backup là gì và vì sao phải nằm ở nơi khác?

Backup là bản sao đầy đủ (hoặc full kết hợp incremental) của dữ liệu, được chép sang một hệ thống lưu trữ khác: server khác, object storage, dịch vụ backup, thậm chí một datacenter khác. Bản backup tự đứng được: muốn khôi phục chỉ cần chính bản đó, không cần ổ đĩa gốc còn sống.

Đổi lại, backup chậm hơn và tốn dung lượng hơn snapshot, vì phải đọc rồi truyền dữ liệu qua mạng. Một bản backup chưa từng được thử khôi phục cũng chưa chắc dùng được. Phần sau của bài sẽ nói về việc kiểm tra restore.

Bảng so sánh snapshot và backup

Vì sao người ta nói "snapshot không phải là backup"?

Vì snapshot không vượt qua được đúng những sự cố mà backup sinh ra để xử lý: hỏng phần cứng lưu trữ, xoá nhầm cả volume hoặc cả project, ransomware mã hoá dữ liệu khi kẻ tấn công có quyền quản trị. Snapshot rất hợp để "quay lui nhanh" khi chính các bạn làm hỏng một thứ gì đó, còn backup để "sống sót" khi mất hẳn hệ thống. Hai công cụ bổ sung cho nhau, không thay thế nhau (ISPsystem: a snapshot is not a backup).

Một chỗ hay gây hiểu nhầm nữa là tính năng nhân bản dữ liệu của nhà cung cấp. Ví dụ, trang Cloud Server của Bizfly Cloud có nêu dữ liệu lưu trữ được nhân bản 3 lần để giảm rủi ro mất dữ liệu do hỏng phần cứng. Nhân bản giúp chống hỏng ổ, nhưng lệnh DROP TABLE hay rm -rf cũng được nhân bản y hệt sang cả 3 bản. Vì thế các bạn vẫn cần backup có nhiều phiên bản theo thời gian.

Dùng snapshot và backup thế nào cho đúng?

Hiểu khác biệt rồi thì câu hỏi tiếp theo là: trong vận hành hằng ngày, việc nào giao cho snapshot, việc nào giao cho backup, và làm sao để bản khôi phục dùng được thật. Mình gom thành bốn việc dưới đây.

Dùng snapshot làm "điểm quay lui" trước thay đổi lớn

Snapshot phát huy tác dụng nhất trước những thao tác có rủi ro: nâng cấp hệ điều hành, đổi phiên bản database, chạy migration lớn, sửa cấu hình hàng loạt. Quy trình gọn nhất là: tạo snapshot, thực hiện thay đổi, kiểm tra ứng dụng, rồi xoá snapshot sau vài ngày nếu mọi thứ ổn.

Ví dụ với LVM trên Linux (cú pháp lvm2, áp dụng cho Ubuntu 24.04):

# Tạo snapshot 5 GB cho logical volume chứa dữ liệu
sudo lvcreate --size 5G --snapshot --name data_before_upgrade /dev/vg0/data

# Xem snapshot đã dùng bao nhiêu phần trăm vùng copy-on-write
sudo lvs -o lv_name,origin,data_percent

# Nếu nâng cấp hỏng: gộp snapshot về lại volume gốc (cần unmount hoặc reboot để áp dụng)
sudo lvconvert --merge /dev/vg0/data_before_upgrade

# Nếu mọi thứ ổn: xoá snapshot để giải phóng chỗ
sudo lvremove /dev/vg0/data_before_upgrade

Lưu ý --size là dung lượng để chứa các block bị thay đổi. Nếu vùng này đầy, snapshot LVM loại cũ sẽ bị đánh dấu hỏng. Đây là lý do không nên để snapshot sống hàng tuần.

Snapshot database: crash-consistent và application-consistent

Đây là chỗ nhiều bạn dính lỗi nhất. Snapshot chụp ổ đĩa đúng lúc database đang ghi dở thì bản chụp chỉ ở trạng thái crash-consistent, giống như server vừa bị rút điện. Database có cơ chế phục hồi thì vẫn khởi động lại được, nhưng có điều kiện.

• PostgreSQL: tài liệu chính thức cho biết có thể dùng "frozen snapshot" của volume chứa thư mục dữ liệu khi server đang chạy; khi khởi động từ bản này, PostgreSQL sẽ coi như vừa bị crash và replay WAL. Điều kiện là phải có cả file WAL trong snapshot, và nếu dữ liệu với WAL nằm trên nhiều ổ khác nhau thì các snapshot phải được chụp cùng lúc, nếu không bản khôi phục có thể hỏng (PostgreSQL: File System Level Backup). Chạy CHECKPOINT trước khi chụp sẽ rút ngắn thời gian phục hồi.
• MySQL: tài liệu MySQL hướng dẫn chạy FLUSH TABLES WITH READ LOCK, tạo snapshot từ một shell khác, rồi UNLOCK TABLES để có bản chụp nhất quán (MySQL: Backup Methods). Lệnh khoá chặn ghi trong vài giây, nên hãy chạy vào giờ thấp điểm.

Muốn bản khôi phục ở trạng thái application-consistent, tức database đã ghi xong mọi thứ, hãy dùng công cụ backup của chính database: pg_dump / pg_basebackup với PostgreSQL, mysqldump --single-transaction với bảng InnoDB. Nếu các bạn đang phân vân chọn database nào, bài MySQL và PostgreSQL nên chọn loại nào? trong series này có so sánh chi tiết.

# PostgreSQL: dump định dạng custom, khôi phục chọn lọc được bằng pg_restore
pg_dump -Fc -d shop -f /backup/shop_$(date +%F).dump

# MySQL (InnoDB): dump nhất quán mà không khoá bảng lâu
mysqldump --single-transaction --routines --triggers shop > /backup/shop_$(date +%F).sql

Dựng backup: lịch chạy, nơi lưu và thời gian giữ

Một bản backup dùng được cần trả lời ba câu hỏi.

1. Chạy bao lâu một lần? Câu trả lời phụ thuộc vào việc các bạn chấp nhận mất tối đa bao nhiêu dữ liệu. Backup mỗi đêm nghĩa là có thể mất gần trọn một ngày dữ liệu. Database có giao dịch liên tục thì cần thêm sao lưu WAL hoặc binlog liên tục.
2. Lưu ở đâu? Ít nhất một bản phải nằm ngoài server và ngoài hệ thống lưu trữ của server đó. Có thể đẩy lên object storage hoặc dùng dịch vụ backup có lập lịch. Ví dụ, trang Bizfly Cloud Backup mô tả cơ chế backup incremental, lập lịch theo giờ, ngày, tuần, tháng và khôi phục sang máy khác. Dù dùng dịch vụ nào, các bạn hãy tự kiểm tra lại các tính năng này trên tài khoản của mình trước khi đưa vào quy trình.
3. Giữ bao lâu? Hãy giữ nhiều mốc thời gian, ví dụ 7 bản theo ngày, 4 bản theo tuần, 6 bản theo tháng. Lý do là lỗi dữ liệu thường được phát hiện muộn: nếu chỉ giữ bản tối qua, các bạn có thể đang giữ một bản backup của dữ liệu đã hỏng.

Kiểm tra restore định kỳ

Backup chưa restore thử thì chưa thể coi là backup. Mỗi tháng, hãy dựng một server hoặc container tạm, khôi phục bản mới nhất vào đó rồi chạy vài truy vấn kiểm tra.

# Khôi phục bản dump PostgreSQL vào database tạm để kiểm tra
createdb shop_restore_test
pg_restore -d shop_restore_test /backup/shop_2026-11-12.dump
psql -d shop_restore_test -c "SELECT count(*) FROM orders;"

Hãy ghi lại thời gian restore thực tế. Con số này là thời gian dừng dịch vụ thật khi có sự cố, và thường dài hơn nhiều so với ước tính ban đầu.

Lỗi thường gặp khi dùng snapshot và backup

Các tình huống dưới đây là ví dụ minh hoạ tổng hợp từ những lỗi phổ biến, không phải một sự cố cụ thể có số liệu.

Câu hỏi thường gặp

Snapshot có thay được backup không? Không. Snapshot thường nằm cùng hệ thống lưu trữ với dữ liệu gốc nên mất theo khi ổ hỏng hoặc volume bị xoá. Hãy dùng snapshot để quay lui nhanh và dùng backup để khôi phục khi mất hẳn hệ thống.

Có cần dừng database trước khi tạo snapshot không? Không bắt buộc, nhưng phải đảm bảo bản chụp nhất quán. Với PostgreSQL, snapshot phải chứa cả WAL và được chụp đồng thời nếu dữ liệu nằm trên nhiều ổ. Với MySQL, hãy dùng FLUSH TABLES WITH READ LOCK trong lúc chụp.

Nên giữ snapshot bao lâu? Chỉ nên giữ trong vài ngày, đủ để chắc chắn thay đổi vừa làm không gây lỗi. Cần lưu trữ dài hạn thì dùng backup với chính sách giữ theo ngày, tuần, tháng.

Nhà cung cấp cloud đã nhân bản dữ liệu thì có cần backup nữa không? Vẫn cần. Nhân bản chống hỏng phần cứng nhưng cũng nhân bản luôn các thao tác xoá nhầm hoặc dữ liệu bị mã hoá. Backup có nhiều phiên bản theo thời gian mới cho phép quay lại trạng thái trước sự cố.

Kết luận

Snapshot và backup khác nhau ở chỗ snapshot giúp quay lui nhanh, còn backup giúp khôi phục khi mất hẳn hệ thống. Nguyên tắc là dùng snapshot trước mỗi thay đổi rủi ro, và luôn có ít nhất một bản backup độc lập nằm ngoài server. Việc đầu tiên nên làm ngay hôm nay là restore thử bản backup gần nhất vào một môi trường tạm và ghi lại thời gian khôi phục. Bài tiếp theo trong series DevOps thực chiến sẽ nói về IOPS, chỉ số quyết định tốc độ của cả database lẫn việc backup và restore.