Rất nhiều chủ doanh nghiệp và lập trình viên khi được hỏi về backup VPS thường trả lời với vẻ khá an tâm: "Bên nhà cung cấp hosting có bật tự động backup hàng tuần rồi" hoặc "Em có viết script cron chạy mỗi đêm, sáng nào cũng thấy file .sql sinh ra đều đặn."
Thế nhưng, đến một ngày VPS gặp sự cố lỗi ổ đĩa, thao tác nhầm trong lúc bảo trì, hoặc đơn giản là doanh nghiệp cần chuyển website sang một nhà cung cấp mới, mở file backup ra thì mới phát hiện:
- Bản tự động của nhà cung cấp đã ngừng chạy từ tháng trước do ổ đĩa đầy hoặc dịch vụ phụ trợ gặp lỗi mà không ai nhận được thông báo.
- Bản backup chỉ chứa mỗi database, toàn bộ ảnh sản phẩm, file PDF hóa đơn và tài liệu khách hàng upload suốt thời gian qua nằm ở thư mục ngoài thì không hề được sao lưu.
- File backup có dung lượng hàng gigabyte nhưng giải nén ra thì bị lỗi dữ liệu vì script nén sống database lúc đang ghi dở.
Một dòng trạng thái báo "backup thành công" chưa trả lời được câu hỏi cốt lõi: Nếu chiếc VPS gặp sự cố phải dựng lại ngay hôm nay, doanh nghiệp mất bao lâu để đưa website hoạt động trở lại, và dữ liệu có thực sự nguyên vẹn hay không?
Một chiến lược backup thực tế không bắt đầu bằng việc đi tìm phần mềm nào xịn nhất. Nó bắt đầu từ việc hiểu rõ dữ liệu của bạn đang nằm ở đâu và doanh nghiệp chịu đựng được mức thiệt hại nào.
Bước 1: Lập danh mục những gì cần để dịch vụ hoạt động lại
Nén toàn bộ VPS có thể hữu ích trong một số kịch bản, nhưng nó không thay thế việc biết chính xác thành phần nào phải được phục hồi. Hãy lập một danh mục ngắn cho từng tài sản và dependency:
| Thành phần | Điều gì xảy ra nếu mất? | Có thể tái tạo không? | Cách chuẩn bị phục hồi |
|---|---|---|---|
| Database | Mất tài khoản, đơn hàng hoặc nội dung mới | Thường không | Backup nhất quán theo engine, tần suất theo RPO, có restore test |
| File người dùng tải lên | Mất ảnh, tài liệu hoặc tệp đính kèm | Thường không | Bản sao có version hoặc backup gia tăng, kiểm tra file mẫu |
| Cấu hình Nginx, firewall, Compose | Không dựng lại đúng hệ thống | Có thể nhưng tốn thời gian | Quản lý phiên bản hoặc backup sau thay đổi, ghi rõ bản đang chạy |
| Secret và khóa | Ứng dụng không kết nối hoặc không giải mã được dữ liệu | Không phải lúc nào cũng tái tạo được | Lưu trong cơ chế bảo mật riêng và kiểm tra quyền khôi phục dự phòng |
| Source code và build artifact | Không deploy lại đúng phiên bản | Có nếu remote Git và registry còn truy cập được | Ghi commit, image digest và nơi lưu artifact |
| DNS, CDN và dependency bên ngoài | Dịch vụ dựng lại nhưng người dùng vẫn không truy cập được | Tùy nền tảng | Lưu bản ghi cấu hình cần thiết trong runbook phục hồi |
| Log cần cho điều tra hoặc tuân thủ | Mất bằng chứng về sự cố | Không | Retention riêng theo mục tiêu, không trộn với dữ liệu ứng dụng |
Danh mục này giúp bạn biết thứ gì phải backup, thứ gì chỉ cần quản lý phiên bản và thứ gì cần một runbook để tái tạo. Tần suất của từng nhóm sẽ được quyết định ở bước RPO, không mặc định tất cả cùng chạy mỗi ngày.
Bước 2: Đặt mục tiêu RPO và RTO bằng bài toán tiền bạc
RPO và RTO là hai thuật ngữ kỹ thuật nghe có vẻ trừu tượng, nhưng thực chất chúng là hai câu hỏi kinh doanh rất thực tế:
- RPO (Recovery Point Objective - Bạn chấp nhận mất bao nhiêu dữ liệu?):
Nếu bạn chỉ backup database 24 giờ một lần vào lúc 02:00 sáng. Đến 16:00 chiều hôm sau VPS bị hỏng, bạn sẽ mất trắng toàn bộ dữ liệu phát sinh từ 2h sáng đến 4h chiều (14 tiếng). Nếu website ít cập nhật, khoảng mất dữ liệu 14 tiếng có thể chấp nhận được. Với hệ thống nhận đơn hoặc ghi nhận giao dịch liên tục, cùng khoảng thời gian đó có thể vượt quá mức doanh nghiệp chịu được. Khi ấy, cần rút ngắn chu kỳ backup hoặc dùng cơ chế bảo vệ dữ liệu phù hợp hơn với engine đang chạy.
- RTO (Recovery Time Objective - Website được phép sập trong bao lâu?):
RTO không phải là thời gian bạn bấm chuột tải file backup về máy (chỉ mất 5 phút). RTO là tổng thời gian từ lúc phát hiện sự cố cho đến khi khách hàng truy cập lại bình thường. Khoảng thời gian này bao gồm: cấp máy chủ thay thế, cài đặt môi trường, nạp dữ liệu, kiểm tra chức năng và chuyển traffic. Muốn biết RTO có thực tế hay không, bạn phải đo thời gian trong một lần diễn tập thay vì ước lượng theo cảm giác.
Đọc thêm bài RPO và RTO khác nhau thế nào trong một sự cố thật? để biết cách chọn con số phù hợp với quy mô doanh nghiệp mà không làm đội chi phí hạ tầng.
Bước 3: Xác định snapshot bảo vệ được trước sự cố nào
Nhiều nhà cung cấp VPS có tính năng Snapshot (chụp nhanh toàn bộ ổ đĩa chỉ bằng một cú nhấp chuột). Snapshot rất tiện khi bạn chuẩn bị nâng cấp hệ điều hành hoặc cập nhật phần mềm lớn, nếu lỗi thì có thể quay về trạng thái cũ ngay lập tức.
Snapshot có thể là một điểm khôi phục nhanh, nhưng mức bảo vệ phụ thuộc vào cách nhà cung cấp lưu snapshot, retention, tài khoản quản lý và khả năng xuất dữ liệu sang nơi khác. Nếu VPS và snapshot cùng nằm trong một failure domain hoặc cùng phụ thuộc vào một tài khoản bị chiếm quyền, một sự cố vẫn có thể làm mất cả hai đường phục hồi.
Vì vậy, hãy ghi rõ snapshot đang bảo vệ trước loại sự cố nào và bổ sung ít nhất một bản sao có failure domain cùng quyền truy cập tách biệt khi dữ liệu đủ quan trọng. Bài Snapshot có thay thế backup được không? phân tích chi tiết hơn ranh giới này.
Bước 4: Dùng quy tắc 3-2-1 như điểm khởi đầu
Quy tắc 3-2-1 là một điểm khởi đầu dễ nhớ:
- 3 bản sao dữ liệu: 1 bản đang chạy thực tế trên VPS + 1 bản sao lưu trên Object Storage + 1 bản tải về lưu trữ lạnh.
- 2 loại hoặc hệ thống lưu trữ có failure mode khác nhau: Không chỉ tạo thêm một thư mục trên cùng VPS hoặc cùng ổ đĩa.
- 1 bản ở ngoài hệ thống nguồn: Bản này cần tách cả vị trí lẫn quyền truy cập ở mức phù hợp với rủi ro.
Object Storage ở một tài khoản hoặc nhà cung cấp tách biệt có thể là một lớp lưu trữ phù hợp. Công cụ như rclone hỗ trợ chuyển dữ liệu, nhưng không tự giải quyết retention, mã hóa, quyền xóa hoặc việc tài khoản nguồn bị chiếm quyền. Với dữ liệu quan trọng, hãy cân nhắc versioning, retention lock hoặc một bản offline; đồng thời lưu khóa mã hóa ở nơi vẫn truy cập được khi VPS chính bị mất.
Xem hướng dẫn cấu hình chi tiết từng bước tại bài Quy tắc backup 3-2-1 áp dụng cho một VPS nhỏ ra sao?.
Bước 5: Phối hợp Database và File upload trong cùng thời điểm
Một lỗi kinh điển khi vận hành là lên lịch backup database lúc 2h sáng, nhưng lại để script nén ảnh upload chạy lúc 4h sáng.
Khoảng hở hai tiếng đồng hồ này sẽ tạo ra tình trạng "lệch pha": database trỏ tới những file ảnh chưa kịp được sao lưu, hoặc ngược lại. Khi khôi phục hệ thống, website sẽ đầy rẫy các biểu tượng ảnh vỡ (404 Not Found).
Database và file upload cần được phối hợp theo một mốc backup có thể đối chiếu. Tùy ứng dụng, bạn có thể tạm dừng thao tác ghi, dùng cơ chế snapshot nhất quán hoặc ghi manifest chứa thời điểm và phiên bản của từng thành phần. Mục tiêu là biết chính xác bộ database nào đi cùng bộ file nào khi restore; xem Backup database và backup file cần phối hợp thế nào?.
Bước 6: Thử khôi phục và đo kết quả
Một job báo thành công mới chỉ cho biết tác vụ đã chạy hết. Nó chưa chứng minh file đầy đủ, dữ liệu không hỏng hoặc ứng dụng có thể hoạt động sau khi phục hồi.
Rất nhiều người chỉ vỡ lẽ ra bản backup của mình không dùng được khi bắt tay vào dựng lại hệ thống: file nén bị lỗi mật khẩu, lệnh export thiếu quyền, hoặc database yêu cầu phiên bản MySQL mới hơn mà trước đó không ai kiểm tra.
Tần suất diễn tập phụ thuộc vào RPO, RTO, mức độ thay đổi và mức quan trọng của hệ thống. Trong mỗi lần thử:
- Dựng một môi trường tách biệt, không trỏ nhầm traffic và không cho phép thao tác thử ghi vào production.
- Tải bản backup mới nhất về và làm theo quy trình để dựng lại website từ con số không.
- Kiểm tra dữ liệu, file người dùng, đăng nhập và các hành trình quan trọng bằng tài khoản test.
- Ghi lại điểm khôi phục thực tế, tổng thời gian phục hồi, lỗi gặp phải và việc cần sửa trong runbook.
Quy trình từng bước kiểm tra trong môi trường an toàn được tổng hợp đầy đủ tại Checklist thử restore website trên môi trường tách biệt.
Ma trận quyết định cần hoàn thành
Trước khi chọn công cụ, hãy hoàn thành một dòng cho từng tài sản theo mẫu:
Tài sản → hậu quả nếu mất → RPO → cách sao lưu → nơi lưu → retention → cách restore test
Sau đó, kiểm tra thêm bốn câu hỏi:
- Job có báo khi thất bại hoặc không chạy đúng lịch không?
- Bản sao có tách khỏi failure domain và quyền xóa của hệ thống nguồn không?
- Khóa mã hóa và credential khôi phục có còn dùng được khi VPS chính bị mất không?
- Lần restore test gần nhất có chứng minh được dữ liệu, chức năng và thời gian phục hồi không?
Retention được xác định theo tốc độ thay đổi và thời gian có thể mất trước khi một lỗi âm thầm bị phát hiện; xem thêm Nên giữ backup trong bao lâu và xoay vòng thế nào?. Khi đã có các câu trả lời trên, bạn có thể đưa chúng vào Kế hoạch disaster recovery tối thiểu cho website doanh nghiệp để biến backup thành một đường phục hồi có thể thực hiện.
