Khi quản trị một máy chủ VPS hoặc cloud server, bạn sẽ thường thấy tính năng Snapshot đi kèm bảng điều khiển của nhà cung cấp. Chỉ cần bấm một nút, vài giây hoặc vài phút sau hệ thống đã lưu lại một bản chụp toàn bộ ổ đĩa. Thao tác này tiện lợi đến mức không ít người dùng coi snapshot chính là giải pháp backup duy nhất của mình và không thiết lập thêm bất kỳ cơ chế sao lưu nào khác.
Ở chiều ngược lại, nhiều tài liệu kỹ thuật lại khẳng định một cách cứng nhắc rằng "snapshot không phải là backup". Cách nói này chưa hoàn toàn chính xác. Trên thực tế, nhiều hệ thống cloud hiện đại dùng chính snapshot dạng incremental để làm điểm khôi phục (point-in-time recovery point) với tốc độ phục hồi rất nhanh.
Vấn đề cốt lõi không nằm ở tên gọi tính năng. Câu hỏi thực tế mà bạn cần trả lời là: Bản snapshot hiện có sẽ bảo vệ được hệ thống trước những tình huống sự cố nào, và khi nào nó không thể thay thế một bản backup độc lập?
Snapshot thường mạnh về tốc độ; backup độc lập bảo vệ tốt hơn trước sự cố chung quyền truy cập hoặc hạ tầng.
Điểm mạnh thực tế của snapshot
Snapshot là bản ghi trạng thái của toàn bộ ổ đĩa (block-level) tại một thời điểm nhất định. Khi tạo snapshot lần đầu, hệ thống sao lưu các khối dữ liệu hiện có; ở các lần tiếp theo, cơ chế thường chỉ ghi nhận phần dữ liệu thay đổi (incremental) để tiết kiệm dung lượng.
Trong công việc quản trị hàng ngày, snapshot phát huy tác dụng rõ rệt nhất ở các tình huống sau:
- Tạo điểm quay đầu an toàn trước khi thay đổi hệ thống: Trước khi bạn nâng cấp phiên bản hệ điều hành (như Ubuntu 22.04 lên 24.04), cập nhật gói phần mềm lõi hoặc thay đổi cấu hình mạng phức tạp, chụp nhanh một snapshot là việc rất nên làm. Nếu quá trình nâng cấp bị xung đột thư viện hoặc server không thể khởi động lại (unbootable), bạn chỉ cần vài phút để rollback toàn bộ ổ đĩa về ngay trước thời điểm thao tác.
- Tốc độ tạo và phục hồi rất nhanh: Thay vì phải nén từng thư mục, tải dữ liệu về máy rồi giải nén lại khi gặp sự cố, snapshot cho phép tạo ngay một ổ đĩa mới từ điểm lưu trữ ở tầng hạ tầng của nhà cung cấp.
- Dựng môi trường thử nghiệm (staging/test): Bạn có thể dùng snapshot của VPS production để tạo ra một máy ảo thử nghiệm riêng biệt, giúp đội ngũ kỹ thuật chạy thử các bản cập nhật mà không gây ảnh hưởng đến hệ thống đang chạy thật.
Tuy nhiên, sự tiện lợi ở tầng ổ đĩa cũng che đi những giới hạn rất lớn nếu bạn chỉ dựa duy nhất vào snapshot.
Những giới hạn quan trọng khi chỉ dùng snapshot
Để hiểu vì sao snapshot đơn thuần không thể thay thế hoàn toàn một chiến lược backup bài bản, chúng ta cần xem xét cách dữ liệu được ghi nhận và phạm vi phục hồi khi sự cố phát sinh.
1. Tính nhất quán của dữ liệu: Crash-consistent và Application-consistent
Đây là khác biệt kỹ thuật quan trọng nhất giữa snapshot ổ đĩa và backup chuyên dụng:
- Crash-consistent: Hầu hết các nút bấm "Create Snapshot" trên bảng điều khiển VPS hoạt động ở mức chụp nhanh ổ đĩa mà không báo trước cho các phần mềm đang chạy. Trạng thái này giống hệt như khi máy chủ bị rút phích cắm đột ngột lúc đang hoạt động. Nếu database (MySQL, PostgreSQL) đang thực hiện dở một transaction lớn trong bộ nhớ RAM và chưa kịp ghi xuống đĩa, dữ liệu đó có thể bị thiếu hoặc bảng dữ liệu rơi vào trạng thái cần phục hồi tự động khi khởi động lại.
- Application-consistent: Một bản backup chuẩn mực thường chủ động phối hợp với ứng dụng hoặc database (chẳng hạn thông qua lệnh flush bảng, khóa tạm thời hoặc chạy công cụ dump chuyên dụng như
mysqldump,pg_dump). Quá trình này đảm bảo toàn bộ giao dịch đang dở dang được xử lý trọn vẹn, tạo ra một bản lưu trữ hoàn chỉnh và nhất quán về mặt logic nghiệp vụ.
Nếu bạn chụp snapshot trong lúc hệ thống đang có lượng truy cập cao và database ghi nhận liên tục, việc khôi phục từ snapshot có thể đưa bạn về một trạng thái dữ liệu không toàn vẹn.
2. Sự cố chia sẻ quyền truy cập và tài khoản (Failure Domain)
Phần lớn snapshot được lưu trữ ngay trên hạ tầng của chính nhà cung cấp cloud mà bạn đang thuê VPS. Bản snapshot có thể tách biệt khỏi ổ đĩa gốc (source volume), nghĩa là nếu ổ đĩa gốc bị lỗi phần cứng, bạn vẫn có thể tạo ổ đĩa mới từ snapshot.
Thế nhưng, cả VPS và snapshot thường cùng nằm trong:
- Một tài khoản quản trị duy nhất trên trang quản lý của nhà cung cấp.
- Một cụm trung tâm dữ liệu hoặc cùng một khu vực địa lý (region).
- Cùng một bộ khóa mã hóa (encryption key) hoặc cùng chính sách thanh toán.
Nếu tài khoản quản trị bị lộ thông tin đăng nhập, kẻ xâm nhập có thể xóa sạch cả VPS lẫn các bản snapshot lưu kèm trong bảng điều khiển. Hoặc nếu nhà cung cấp dịch vụ gặp trục trặc về thanh toán, tài khoản bị tạm khóa, bạn sẽ mất luôn quyền truy cập vào cả máy chủ lẫn các bản snapshot lưu trên đó.
Một bản backup độc lập thực sự cần được chuyển ra bên ngoài: lưu trên một dịch vụ lưu trữ đám mây tách biệt (như S3, Cloudflare R2), hoặc tải về một hạ tầng hoàn toàn khác với tài khoản và thông tin xác thực riêng.
3. Đơn vị khôi phục (Granularity)
Khi một nhân sự vô tình xóa nhầm một thư mục hình ảnh sản phẩm hoặc một bảng cấu hình trong database, nhu cầu thực tế là lấy lại đúng thư mục hoặc bảng dữ liệu đó trong thời gian ngắn nhất.
Với bản backup dạng file hoặc file dump database:
- Bạn chỉ cần mở bản nén hoặc chạy lệnh import đúng bảng bị mất mà không làm gián đoạn các phần khác của website.
Với snapshot toàn bộ ổ đĩa:
- Bản snapshot chỉ cho phép bạn rollback cả ổ đĩa về quá khứ. Nếu làm vậy, mọi đơn hàng và tương tác mới phát sinh từ thời điểm chụp snapshot đến hiện tại sẽ bị xóa sạch theo.
- Để lấy lại một file đơn lẻ từ snapshot, bạn thường phải tạo một ổ đĩa mới từ snapshot, gắn ổ đĩa đó vào một VPS phụ, mount thư mục rồi copy thủ công file cần thiết ra ngoài. Quy trình này tốn nhiều công sức và kéo dài thời gian xử lý sự cố.
4. Thời gian lưu trữ và kiểm soát lịch sử (Retention)
Snapshot trên cloud thường được tính phí theo dung lượng lưu trữ thực tế. Nếu bạn giữ quá nhiều bản snapshot cũ qua các tháng, chi phí lưu trữ hạ tầng sẽ tăng lên rất nhanh. Hơn nữa, snapshot không được sinh ra để phục vụ việc lưu trữ lịch sử dài hạn (chẳng hạn lưu bản sao cuối tháng của 12 tháng qua để phục vụ đối soát kế toán).
Một hệ thống backup tiêu chuẩn thường có chính sách xoay vòng rõ ràng (giữ 7 ngày gần nhất, 4 tuần gần nhất và 3 tháng gần nhất), tự động dọn dẹp các bản quá hạn và nén tối ưu dung lượng để tiết kiệm chi phí.
Bảng so sánh thực tế giữa Snapshot và Backup độc lập
| Tiêu chí | Snapshot ổ đĩa | Backup chuyên dụng / độc lập |
|---|---|---|
| Phạm vi bảo vệ | Toàn bộ ổ đĩa, hệ điều hành và môi trường cài đặt | Dữ liệu ứng dụng cốt lõi: database, file tải lên, mã nguồn |
| Tính nhất quán dữ liệu | Thường là crash-consistent (giống mất điện đột ngột) | Application-consistent (đảm bảo logic toàn vẹn của database) |
| Đơn vị khôi phục | Cả ổ đĩa; muốn lấy 1 file phải dựng ổ đĩa phụ | Linh hoạt: có thể phục hồi từng bảng, từng file hoặc toàn bộ |
| Mức độ độc lập | Nằm chung nhà cung cấp, chung tài khoản quản trị | Lưu trữ ở hạ tầng tách biệt (khác tài khoản, khác nhà cung cấp) |
| Tốc độ phục hồi hệ điều hành | Rất nhanh (vài phút là đưa server về mốc cũ) | Chậm hơn nếu phải cài lại môi trường từ đầu |
| Tình huống sử dụng tối ưu | Nâng cấp OS, sửa cấu hình hệ thống, rollback trước deploy | Mất dữ liệu logic, hỏng database, mất quyền tài khoản, chuyển máy chủ |
Mô hình phối hợp hiệu quả cho doanh nghiệp
Thay vì đối đầu giữa hai khái niệm, giải pháp an toàn và thực tế nhất cho một hệ thống website doanh nghiệp là phối hợp cả hai công cụ đúng với thế mạnh của chúng:
Lớp 1: Dùng Snapshot cho tầng hạ tầng và các thay đổi rủi ro
- Bật tính năng snapshot tự động định kỳ của nhà cung cấp (ví dụ: giữ 1 đến 2 bản gần nhất) để có phương án dựng lại VPS nhanh chóng nếu hệ điều hành gặp trục trặc.
- Luôn chủ động tạo 1 bản snapshot thủ công ngay trước khi can thiệp sâu vào server (nâng cấp kernel, đổi phiên bản web server, cập nhật cấu hình mạng). Sau khi hệ thống chạy ổn định sau vài ngày, bạn có thể xóa bản snapshot này để tiết kiệm chi phí.
Lớp 2: Dùng Backup độc lập cho dữ liệu cốt lõi
- Thiết lập lịch backup tự động mỗi ngày cho database (dùng công cụ dump chuyên dụng để đảm bảo tính toàn vẹn) và các thư mục tài liệu/hình ảnh do người dùng tải lên theo hướng dẫn tại Backup database và backup file cần phối hợp thế nào?.
- Áp dụng quy tắc backup 3-2-1 cho VPS nhỏ: mã hóa file backup và tự động đồng bộ sang một dịch vụ lưu trữ khách quan (như bucket S3 hoặc máy chủ lưu trữ thứ hai).
- Áp dụng quy tắc xoay vòng retention theo ngày, tuần, tháng để luôn có điểm khôi phục của các ngày và tuần trước đó.
Khi có sự phân định rõ ràng trong chiến lược backup VPS tổng thể: nếu máy chủ bị lỗi hệ điều hành hoặc cấu hình sau khi update, snapshot sẽ giúp bạn phục hồi trong vài phút. Còn nếu xảy ra sự cố hỏng database, thao tác xóa nhầm dữ liệu nghiệp vụ hoặc rủi ro tài khoản quản trị, bản backup độc lập sẽ là cứu cánh cuối cùng giúp doanh nghiệp không bao giờ mất đi tài sản quý giá nhất. Để chắc chắn dữ liệu có thể khôi phục được, đừng quên tham khảo checklist thử restore website trên môi trường tách biệt.
Checklist kiểm tra tính năng snapshot trên VPS của bạn
Trước khi coi snapshot là một phần trong kế hoạch an toàn dữ liệu, hãy tự kiểm tra 5 câu hỏi sau:
- Snapshot của bạn được tạo tự động hay đang phụ thuộc vào việc nhớ bấm tay? Nếu là tự động, khi tiến trình snapshot bị lỗi (do đầy dung lượng hoặc lỗi thẻ thanh toán), bạn có nhận được email cảnh báo không?
- Snapshot có đang lưu cùng một tài khoản với máy chủ không? Nhà cung cấp của bạn có cho phép sao chép snapshot sang một vùng (region) hoặc tài khoản dự phòng khác không?
- Database trên máy chủ có dung lượng lớn và ghi liên tục không? Bạn đã từng thử dựng một máy chủ từ snapshot để kiểm tra xem database có khởi động lên trơn tru và dữ liệu có nguyên vẹn hay không?
- Chi phí lưu trữ snapshot hiện tại là bao nhiêu? Hệ thống có cơ chế tự động xóa bớt các bản snapshot cũ hay đang tích lũy dung lượng ngày một lớn?
- Bạn đã có phương án dự phòng nào nếu một ngày không thể đăng nhập vào trang quản lý của nhà cung cấp VPS?
