[Infra/Backend] Đừng nhầm lẫn Snapshot và Backup: Cú lừa chí mạng khiến System Admin bay màu

Chào anh em, lại là mình đây.

Làm backend hay devops, chắc hẳn anh em ít nhất một lần trải qua cái cảm giác "lạnh sống lưng" này: Đêm deploy một tính năng lớn, chạy file migration update database. Chạy xong phát, check lại thấy data cũ bị update sai tè le, hoặc lỡ tay gõ nhầm lệnh DROP TABLE. Mồ hôi mẹ mồ hôi con túa ra, sếp thì đang giục "xong chưa em để anh test".

Lúc này, câu hỏi cứu mạng duy nhất là: "Trước khi làm, mày có chụp Snapshot lại chưa?"

Thế nhưng, đời không như mơ. Rất nhiều anh em (thậm chí đi làm 2-3 năm) vẫn đang mù mờ và gộp chung khái niệm "Snapshot" với "Backup" làm một. Dẫn đến những pha xử lý đi vào lòng đất, khi server chết hẳn thì lôi Snapshot ra khôi phục và nhận ra... chả có cái gì cả.

Hôm nay, mình sẽ giải ngố cho anh em về cái gọi là Snapshot, bản chất ảo ma của nó và tại sao nó lại là "viên thuốc hối hận" cực mạnh trong thế giới IT.

1. Snapshot rốt cuộc là cái quái gì?

Dịch sát nghĩa đen, Snapshot là "ảnh chụp nhanh".

Trong hệ thống (Server, Virtual Machine, Database), Snapshot là một bản ghi lại chính xác trạng thái và dữ liệu của hệ thống tại một thời điểm cụ thể (Point-in-time).

Hãy tưởng tượng thế này: Bàn làm việc của anh em đang ngổn ngang sổ sách, ly cafe, cái lap. Anh em lấy điện thoại ra chụp cái "tách". Bức ảnh đó chính là Snapshot. Nó ghi lại chính xác vị trí cái ly ở đâu, quyển sổ đang mở trang mấy. Nếu anh em lỡ tay làm đổ ly cafe, anh em chỉ cần nhìn vào bức ảnh đó và "undo" (phục hồi) mọi thứ về y xì vị trí ban đầu. Thời gian khôi phục cực kỳ nhanh chóng.

2. Sự khác biệt sinh tử: Snapshot KHÔNG PHẢI là Backup!

Đây là cái bẫy mà 90% các thanh niên mới nhậm chức DevOps dẫm phải.

• Backup (Sao lưu): Là anh em copy toàn bộ dữ liệu (100GB) sang một cái ổ cứng khác, hoặc ném lên Cloud (S3). Nó tốn thời gian, tốn băng thông, nhưng nó an toàn. Nếu cái ổ cứng gốc cháy thành tro, anh em vẫn còn bản copy ở chỗ khác để đắp vào.
• Snapshot (Chụp nhanh): Nó hoạt động dựa trên cơ chế Copy-on-Write (hoặc Redirect-on-Write). Khi anh em bấm "Chụp", nó không hề copy 100GB data sang chỗ khác. Nó chỉ tạo ra một cái mốc (pointer). Từ giây phút đó trở đi, nếu có dữ liệu nào MỚI ghi vào hoặc BỊ THAY ĐỔI, nó mới lưu những cục data thay đổi đó ra một block riêng.

Bi kịch xảy ra ở đâu? Vì Snapshot chỉ lưu những "sự thay đổi", nên nó phụ thuộc 100% vào ổ đĩa gốc. Nếu cái server của anh em bị cháy ổ cứng vật lý, hay datacenter bị ngập nước... thì cái Snapshot đó cũng vô dụng! Mất ổ gốc = Mất trắng. Không thể lôi Snapshot ra cứu được.

3. Thực chiến: Dev xài Snapshot ở những ngóc ngách nào?

Tuy không thay thế được Backup, nhưng Snapshot lại là một món vũ khí "đánh nhanh rút gọn" không thể thiếu:

A. "Thuốc hối hận" trước khi Deploy / Nâng cấp OS

Trước khi chạy một script update nguy hiểm trên VPS, thay đổi cấu hình Nginx phức tạp, hay upgrade version của Database. Cứ lên AWS/GCP bấm "Take Snapshot" cái ổ đĩa (EBS Volume). Tốn có vài giây. Lỡ tay gõ rm -rf /* hay update xịt khiến server không boot lên được? Chỉ việc Rollback từ Snapshot. 5 phút sau server sống lại như chưa hề có cuộc chia ly.

B. Snapshot trong Database (Đặc biệt là Elasticsearch)

Đối với các hệ quản trị database lớn hoặc các Search Engine như Elasticsearch, Snapshot là cơ chế cực kỳ phổ biến để sao lưu cluster. Khi cluster quá to (vài Terabyte), việc dump data ra file text là bất khả thi. Snapshot sẽ giúp lưu trạng thái của các index cực kỳ nhanh, và chỉ lưu những đoạn data mới (incremental) cho các lần chụp sau, tiết kiệm vô số không gian lưu trữ.

C. Snapshot trong Event Sourcing (Kiến trúc phần mềm)

Nếu anh em chơi hệ Microservices với Kafka và Event Sourcing, data không lưu trạng thái cuối, mà lưu một chuỗi các event (ví dụ: Tạo giỏ hàng -> Thêm item A -> Thêm item B -> Xóa item A). Để tính ra giỏ hàng cuối cùng, code phải chạy lại từ đầu. Nhưng nếu có 1 triệu event thì sao? Load lại chắc chết! Lúc này, người ta dùng cơ chế Snapshot State: Cứ sau 1000 events, tính toán ra cái trạng thái hiện tại và "chụp" lại lưu xuống DB. Lần sau gọi, hệ thống chỉ cần bốc cái Snapshot mới nhất + đọc vài event gần đây là xong. Tốc độ bàn thờ!

4. Những cú bóp team khi lạm dụng Snapshot

Xài sướng là thế, nhưng Snapshot cũng có "lời nguyền" của nó:

1. Dùng để lưu trữ lâu dài: Như đã nói, Snapshot không phải backup. Lưu nó 1-2 ngày trước lúc deploy thì được. Chứ để cả tháng là dở.
2. Giảm Performance (Hiệu năng): Khi một cái ổ cứng (hoặc VM) đang "gánh" trên lưng quá nhiều Snapshot cũ, mỗi lần hệ thống muốn đọc/ghi data, nó phải dò ngược qua chuỗi các pointer của Snapshot để biết data thực sự nằm ở block nào. Kết quả: I/O disk giảm thê thảm, server chậm rì. Deploy xong, chạy ngon nghẻ 1-2 hôm thì nhớ xóa Snapshot cũ đi nhé!
3. Tưởng rẻ mà hóa đắt: Trên các nền tảng Cloud (AWS, Azure), Snapshot tính tiền theo GB lưu trữ thực tế. Quên xóa Snapshot cả năm trời, đến cuối tháng nhìn bill từ Amazon gởi về thì chỉ có nước khóc ròng.

Chốt hạ

Snapshot = Phục hồi nhanh tại chỗ (Quick Rollback). Dành cho những lúc vọc vạch, deploy, sửa cấu hình. Backup = Phòng chống thảm họa (Disaster Recovery). Dành cho những lúc cháy nhà, sập server, hacker tống tiền ransomware.

Thiếu 1 trong 2 cái này, cuộc đời của System Admin và Backend Dev sẽ thiếu đi những giấc ngủ ngon. Hy vọng anh em đọc xong bài này sẽ clear được mindset và không bao giờ chết vì cái lỗi "Em tưởng chụp Snapshot rồi là an toàn" nữa.

Anh em đã bao giờ phải dùng đến cái "quyền năng" Rollback từ Snapshot để cứu rỗi cuộc đời sau một pha nghịch ngu chưa?