Backup và khôi phục dữ liệu CapRover tránh mất sạch khi sự cố

Khi sự cố xảy ra, thứ cứu bạn không phải là may mắn mà là bản backup tốt

CapRover giúp triển khai ứng dụng nhanh, gọn và khá “thân thiện” với đội ngũ nhỏ. Nhưng cũng vì sự tiện lợi đó mà nhiều người rơi vào một cái bẫy quen thuộc: hệ thống chạy ổn trong nhiều tháng, rồi đến khi VPS lỗi, ổ đĩa hỏng, cập nhật sai cấu hình, xóa nhầm volume hoặc migration database thất bại thì mới cuống lên tìm cách cứu dữ liệu.

Thực tế, backup không phải việc để làm sau cùng, mà là một phần của vận hành ngay từ ngày đầu. Với CapRover, dữ liệu không chỉ nằm ở source code hay image Docker, mà thường nằm trong database, persistent volumes, file upload của người dùng, cấu hình ứng dụng và thông tin triển khai. Nếu không hiểu rõ mình cần backup cái gì, bạn rất dễ rơi vào tình huống “có backup nhưng vẫn không khôi phục được”.

Bài viết này sẽ giúp bạn xây dựng một quy trình backup và khôi phục dữ liệu trên CapRover theo hướng thực tế, dễ áp dụng, để giảm tối đa rủi ro mất mát khi sự cố xảy ra.

Hiểu đúng: trên CapRover, bạn cần backup những gì?

Trước khi nói đến công cụ hay lệnh, cần xác định rõ phạm vi dữ liệu cần bảo vệ. Trong môi trường CapRover, thường có 4 nhóm quan trọng:

1. Dữ liệu database

Đây là phần quan trọng nhất với hầu hết hệ thống: MySQL, MariaDB, PostgreSQL, MongoDB, Redis persistence hoặc các database chạy dưới dạng app/container trên CapRover.

Lưu ý quan trọng: sao chép trực tiếp thư mục dữ liệu của database khi container đang chạy có thể tạo ra bản backup không nhất quán. An toàn hơn là dùng công cụ dump chuyên dụng như:

- mysqldump cho MySQL/MariaDB - pg_dump cho PostgreSQL - mongodump cho MongoDB

2. Persistent volumes

CapRover hỗ trợ gắn persistent data để lưu dữ liệu qua các lần redeploy. Đây có thể là:

- thư mục upload ảnh, tài liệu, video - file generated bởi ứng dụng - cache quan trọng - dữ liệu dịch vụ không phải database

Nếu bạn chỉ backup source code mà quên volume, khi restore app có thể chạy lại nhưng mất toàn bộ file người dùng đã tải lên.

3. Cấu hình và bí mật triển khai

Bao gồm:

- biến môi trường - domain mapping - SSL configuration - app settings - Nginx config tùy chỉnh - token, API key, webhook secret

Một lỗi phổ biến là backup được database nhưng không lưu lại cấu hình, khiến quá trình khôi phục kéo dài vì phải dựng lại từng app bằng tay.

4. Hạ tầng máy chủ

CapRover thường chạy trên một VPS hoặc cloud instance. Nếu máy chủ gặp sự cố, bạn không chỉ cần dữ liệu mà còn cần khả năng dựng lại môi trường nhanh. Vì vậy nên ghi chép hoặc tự động hóa:

- phiên bản Ubuntu/Debian đang dùng - phiên bản Docker - cách cài CapRover - DNS và reverse proxy liên quan - firewall rules - cron job backup

Nguyên tắc backup an toàn trên CapRover

Một chiến lược backup tốt không chỉ là “có file backup”, mà phải đảm bảo khôi phục được khi cần.

Áp dụng quy tắc 3-2-1

Đây là nguyên tắc kinh điển nhưng luôn đúng:

- 3 bản sao dữ liệu - 2 loại lưu trữ khác nhau - 1 bản nằm ngoài máy chủ chính

Ví dụ thực tế:

- 1 bản trên chính server CapRover - 1 bản đồng bộ sang object storage hoặc VPS khác - 1 bản lưu định kỳ ở nơi độc lập như S3, Backblaze B2, Wasabi hoặc máy backup nội bộ

Nếu backup nằm cùng một ổ đĩa với server production, khi ổ đĩa hỏng thì backup cũng mất theo.

Tách backup theo loại dữ liệu

Không nên gom mọi thứ thành một file duy nhất nếu điều đó làm restore khó khăn. Hãy tách rõ:

- backup database - backup thư mục volume - backup cấu hình app - backup thông tin hạ tầng

Cách này giúp bạn phục hồi linh hoạt hơn, ví dụ chỉ cần restore database mà không động vào file upload.

Tự động hóa và có lịch rõ ràng

Backup thủ công chỉ phù hợp khi thử nghiệm. Trong môi trường thật, hãy đặt lịch:

- database: hàng ngày hoặc nhiều lần mỗi ngày - volume chứa upload: hàng ngày - cấu hình hệ thống: sau mỗi lần thay đổi lớn hoặc hàng tuần

Có thể dùng cron để chạy script backup và đẩy file lên remote storage.

Cách backup dữ liệu trên CapRover hiệu quả

Backup database đúng cách

Với MySQL/MariaDB

Cách phổ biến là chạy dump từ bên trong container hoặc từ máy chủ có thể truy cập database:

mysqldump -u root -p --all-databases > backup-all.sql

Nếu chỉ backup một database ứng dụng:

mysqldump -u user -p database_name > app-backup.sql

Mẹo thực tế:

- thêm timestamp vào tên file để dễ quản lý - nén file sau khi dump bằng gzip - kiểm tra file dump có dung lượng hợp lý, không rỗng

Với PostgreSQL

pg_dump -U postgres database_name > app-backup.sql

Hoặc dump định dạng custom để restore linh hoạt hơn:

pg_dump -U postgres -Fc database_name > app-backup.dump

Với MongoDB

mongodump --uri="mongodb://user:pass@host:27017/dbname" --out=/backup/mongo

Điểm quan trọng: luôn ưu tiên công cụ dump logic thay vì copy nóng thư mục data của database đang chạy.

Backup persistent volumes

CapRover thường lưu persistent app data trong Docker volumes hoặc thư mục mount. Bạn cần xác định chính xác volume nào chứa dữ liệu quan trọng.

Một cách phổ biến là dùng tar để đóng gói thư mục volume:

tar -czf uploads-backup-$(date +%F).tar.gz /path/to/volume

Nếu app có lượng file lớn, bạn nên:

- backup theo incremental nếu công cụ hỗ trợ - loại bỏ file tạm, cache không cần thiết - kiểm tra quyền truy cập file sau khi restore

Với dữ liệu người dùng tải lên, đây là phần thường bị bỏ sót nhất nhưng lại ảnh hưởng lớn đến trải nghiệm sau khôi phục.

Backup cấu hình CapRover và ứng dụng

Dù CapRover tập trung vào triển khai nhanh, bạn vẫn nên lưu lại riêng:

- danh sách ứng dụng đang chạy - biến môi trường từng app - domain của từng app - cấu hình deploy - SSL và các tinh chỉnh đặc biệt

Cách đơn giản là duy trì một tài liệu vận hành nội bộ hoặc script export cấu hình định kỳ. Nếu hệ thống của bạn dùng GitOps hoặc lưu captain-definition trong repo, đó là lợi thế lớn vì có thể tái dựng app nhanh hơn.

Ngoài ra, hãy lưu ở nơi an toàn các thông tin:

- tài khoản quản trị CapRover - access token - SSH key - API credentials

Nơi lưu backup: đừng chỉ để trên cùng một server

Một bản backup tốt nhưng nằm cùng máy chủ production vẫn là rủi ro lớn. Hãy đẩy dữ liệu sang nơi khác như:

- S3-compatible storage - Google Cloud Storage - VPS backup riêng - NAS nội bộ - dịch vụ backup có mã hóa

Nếu backup chứa dữ liệu nhạy cảm, nên:

- mã hóa trước khi upload - giới hạn quyền truy cập - bật versioning nếu storage hỗ trợ

Quy trình khôi phục: phần quan trọng hơn cả backup

Rất nhiều đội ngũ có backup nhưng chưa từng thử restore. Đó là một rủi ro lớn, vì đến lúc sự cố xảy ra bạn mới phát hiện file backup lỗi, thiếu hoặc không tương thích.

Khi cần restore, nên làm theo thứ tự nào?

1. Dựng lại hạ tầng cơ bản

Trước tiên, tạo lại VPS hoặc máy chủ mới:

- cài Docker - cài CapRover - cấu hình DNS trỏ đúng - mở firewall và port cần thiết

2. Khôi phục ứng dụng và cấu hình

Tạo lại app trên CapRover, gắn domain, thêm biến môi trường, cấu hình volumes. Nếu có repo và captain-definition, quá trình này sẽ nhanh hơn nhiều.

3. Restore dữ liệu database

Ví dụ với MySQL:

mysql -u root -p database_name < app-backup.sql

Với PostgreSQL:

pg_restore -U postgres -d database_name app-backup.dump

Sau khi restore, cần kiểm tra:

- bảng dữ liệu có đủ không - encoding đúng không - migration có tương thích phiên bản app hiện tại không

4. Restore file và volume

Giải nén file backup về đúng thư mục mount hoặc volume tương ứng:

tar -xzf uploads-backup.tar.gz -C /path/to/restore

Sau đó kiểm tra:

- quyền sở hữu file - quyền đọc/ghi của container - đường dẫn mount có khớp với app cũ không

5. Khởi động app và test nghiệp vụ

Đây là bước nhiều người làm quá sơ sài. Đừng chỉ thấy app mở được là xong. Hãy kiểm tra:

- đăng nhập - đọc/ghi database - upload/download file - job nền, queue, email, webhook - kết nối với dịch vụ ngoài

Những sai lầm phổ biến khiến backup “vô dụng”

Chỉ backup source code

Code có thể lấy lại từ Git, nhưng dữ liệu người dùng thì không. Trong đa số tình huống, mất dữ liệu mới là thiệt hại lớn nhất.

Không kiểm tra khôi phục định kỳ

Backup chỉ có giá trị khi restore thành công. Ít nhất mỗi tháng hoặc mỗi quý, hãy thử khôi phục vào môi trường staging.

Không theo dõi dung lượng và trạng thái backup

Nhiều cron job chạy “thành công” nhưng file tạo ra rỗng hoặc upload remote thất bại. Bạn nên có:

- log backup - cảnh báo khi job lỗi - cảnh báo khi dung lượng bất thường

Không có retention policy

Nếu giữ backup mãi mãi, bạn sẽ tốn dung lượng; nếu xóa quá sớm, có thể mất điểm khôi phục cần thiết. Một chính sách thực tế có thể là:

- backup ngày: giữ 7-14 bản - backup tuần: giữ 4-8 bản - backup tháng: giữ 3-12 bản

Kết luận: backup tốt là backup đã được diễn tập

Với CapRover, việc backup không quá phức tạp, nhưng cần làm có hệ thống. Điều cốt lõi là xác định đúng dữ liệu quan trọng, tự động hóa quy trình, lưu bản sao ngoài server chính và quan trọng nhất là thường xuyên kiểm tra khả năng khôi phục.

Nếu bạn đang vận hành ứng dụng production trên CapRover, hãy bắt đầu từ những bước thực tế nhất:

- liệt kê toàn bộ database, volume và cấu hình quan trọng - tạo script backup tự động theo lịch - đẩy backup sang nơi lưu trữ độc lập - thử restore trên môi trường test - ghi lại runbook xử lý sự cố

Sự cố hạ tầng không phải chuyện “có thể” mà là chuyện sớm hay muộn sẽ xảy ra. Khi đó, thứ tạo ra khác biệt giữa vài giờ gián đoạn và một cuộc khủng hoảng dữ liệu chính là quy trình backup/restore mà bạn chuẩn bị từ trước. Nếu làm tốt, CapRover vẫn là một nền tảng rất hiệu quả, linh hoạt và đủ an toàn cho nhiều hệ thống thực tế.