Sao lưu dữ liệu AI nội bộ là việc tạo và kiểm tra định kỳ các bản sao của mọi thành phần cần để dựng lại hệ thống AI của doanh nghiệp: cấu hình triển khai (Docker, biến môi trường, prompt hệ thống), cơ sở dữ liệu người dùng và lịch sử hội thoại, cơ sở dữ liệu vector, tài liệu nguồn của kho tri thức, và danh sách chính xác phiên bản mô hình đang dùng. File mô hình tải lại được nên không cần sao lưu thường xuyên, nhưng cấu hình và dữ liệu do doanh nghiệp tạo ra thì không thay thế được. Áp dụng nguyên tắc 3-2-1, có ít nhất một bản không xóa được và kiểm thử khôi phục hằng tháng.
Sao lưu dữ liệu AI khác gì sao lưu file thông thường
Sao lưu dữ liệu AI không chỉ là chép thư mục tài liệu sang ổ khác. Một hệ thống AI nội bộ gồm nhiều lớp phụ thuộc nhau: mô hình, máy chủ mô hình, giao diện người dùng, cơ sở dữ liệu, kho vector, bộ lập chỉ mục, cấu hình mạng. Mất bất kỳ lớp nào cũng khiến hệ thống không chạy hoặc chạy sai.
Ba đặc điểm riêng cần lưu ý:
- Dung lượng không cân xứng: file mô hình rất lớn nhưng tải lại được; file cấu hình rất nhỏ nhưng mất là phải mò lại từ đầu.
- Dữ liệu sinh ra liên tục: lịch sử hội thoại, phản hồi người dùng, nhật ký, chỉ mục mới sau mỗi lần đồng bộ tài liệu.
- Phụ thuộc phiên bản: cơ sở dữ liệu vector tạo bằng một mô hình embedding cụ thể. Khôi phục kho vector nhưng dùng mô hình embedding khác là kết quả tìm kiếm sai hoàn toàn.
Vì vậy, mục tiêu không phải “lưu mọi thứ” mà là đảm bảo dựng lại được hệ thống trong thời gian chấp nhận được. Hai chỉ số nên xác định trước: mất tối đa bao nhiêu giờ dữ liệu là chấp nhận được (RPO) và cần khôi phục trong bao lâu (RTO).
Danh mục cần sao lưu và tần suất khuyến nghị
Bảng dưới là danh mục cho hệ thống điển hình gồm Ollama hoặc vLLM, Open WebUI, cơ sở dữ liệu vector và kho tài liệu trên NAS. Điều chỉnh theo phần mềm thực tế bạn dùng.
Hãy lập một tài liệu “sổ tay khôi phục” ghi rõ từng thành phần nằm ở đâu, sao lưu bằng công cụ nào, ai chịu trách nhiệm. Bản thân tài liệu này cũng phải được sao lưu ở nơi không phụ thuộc vào server AI.
| Thành phần | Mức quan trọng | Tần suất | Cách sao lưu |
|---|---|---|---|
| File docker-compose, biến môi trường, cấu hình proxy | Rất cao | Mỗi lần thay đổi | Lưu trong kho Git riêng tư, khóa bí mật tách riêng |
| Prompt hệ thống, mẫu prompt, cài đặt mô hình | Rất cao | Mỗi lần thay đổi | Xuất ra file, đưa vào Git |
| Cơ sở dữ liệu người dùng, lịch sử chat | Cao | Hằng ngày | Dump cơ sở dữ liệu rồi sao lưu |
| Cơ sở dữ liệu vector | Trung bình đến cao | Hằng ngày hoặc sau mỗi lần lập chỉ mục | Snapshot hoặc xuất bản sao khi dừng ghi |
| Tài liệu nguồn kho tri thức | Rất cao | Snapshot hằng giờ, sao lưu hằng ngày | Snapshot NAS và sao lưu ngoài |
| File mô hình | Thấp | Khi đổi mô hình | Ghi tên, phiên bản, mã băm; giữ một bản trên NAS |
File mô hình: ghi lại phiên bản thay vì sao lưu liên tục
Một mô hình lượng tử hóa có thể nặng vài GB đến vài chục GB, sao lưu hằng ngày là lãng phí vì nội dung không đổi. Tuy nhiên, “tải lại được” có hai rủi ro: nguồn có thể gỡ bản cũ, hoặc tên mô hình giữ nguyên nhưng nội dung được cập nhật, khiến hành vi AI thay đổi mà bạn không biết.
Cách làm khuyến nghị
- Ghi chính xác định danh: tên mô hình, phiên bản, mức lượng tử hóa, nguồn tải, ngày tải.
- Lưu mã băm SHA256 của file mô hình để xác minh khi khôi phục.
- Giữ một bản trên NAS cho mỗi mô hình đang chạy thực tế; xóa bản cũ khi đã thay thế ổn định.
- Với Ollama: lưu lại Modelfile tùy chỉnh (tham số, prompt hệ thống, độ dài ngữ cảnh), vì đây là phần bạn đã đầu tư công chỉnh.
- Với mô hình tinh chỉnh riêng: đây là tài sản không tải lại được, cần sao lưu đầy đủ trọng số, bộ adapter, dữ liệu huấn luyện và cấu hình huấn luyện như dữ liệu quan trọng nhất.
Ghi chép này cũng giúp khi kiểm tra sự cố: nếu câu trả lời AI đột nhiên khác đi, bạn biết ngay mô hình có bị thay đổi hay không.
Sao lưu cơ sở dữ liệu vector và lịch sử hội thoại đúng cách
Cơ sở dữ liệu là phần dễ sao lưu sai nhất. Chép thư mục dữ liệu khi phần mềm đang ghi có thể tạo ra bản sao hỏng, chỉ phát hiện khi cần khôi phục.
Nguyên tắc
- Dùng công cụ xuất của chính phần mềm: PostgreSQL dùng
pg_dump, SQLite dùng lệnh sao lưu trực tuyến, các cơ sở dữ liệu vector như Qdrant, Chroma, Milvus có cơ chế snapshot riêng, xem tài liệu chính thức của phiên bản bạn dùng. - Hoặc dừng ghi trước khi chép: tạm dừng container, chụp snapshot ổ đĩa, khởi động lại. Chỉ mất vài giây, nên chạy ngoài giờ.
- Lưu kèm thông tin mô hình embedding: tên, phiên bản, số chiều vector. Thiếu thông tin này, kho vector khôi phục được nhưng không dùng được.
Có cần sao lưu kho vector nếu lập chỉ mục lại được?
Về lý thuyết, kho vector tạo lại được từ tài liệu nguồn. Thực tế, lập chỉ mục lại hàng chục nghìn tài liệu có thể mất nhiều giờ GPU, và các chỉnh sửa thủ công như gắn thẻ, phân quyền, loại bỏ tài liệu lỗi sẽ mất. Với kho nhỏ, có thể chấp nhận lập chỉ mục lại; với kho lớn, sao lưu hằng ngày rẻ hơn nhiều so với thời gian ngừng hệ thống.
Lịch sử hội thoại chứa dữ liệu nhạy cảm, bản sao lưu phải được mã hóa và áp cùng thời hạn lưu giữ như hệ thống chính.
Quy trình sao lưu 3-2-1 cho hệ thống AI nội bộ
Chuẩn bị
Một NAS hoặc ổ sao lưu trong văn phòng, một nơi lưu trữ ngoài văn phòng (dịch vụ lưu trữ đám mây hoặc thiết bị ở chi nhánh), công cụ sao lưu có mã hóa và loại bỏ trùng lặp như restic hoặc BorgBackup.
- Đưa cấu hình vào Git: toàn bộ file triển khai, prompt, Modelfile vào kho Git riêng tư; khóa API và mật khẩu lưu trong trình quản lý bí mật, không đưa vào Git.
- Viết script sao lưu hằng đêm: dump cơ sở dữ liệu, snapshot kho vector, gom vào một thư mục tạm.
- Sao lưu bản thứ nhất lên NAS bằng công cụ có mã hóa, giữ theo lịch: 7 bản hằng ngày, 4 bản hằng tuần, 6 bản hằng tháng.
- Sao lưu bản thứ hai ra ngoài văn phòng, ưu tiên nơi hỗ trợ khóa đối tượng hoặc lưu giữ bất biến.
- Gửi thông báo kết quả qua email hoặc nhóm chat mỗi sáng: thành công, dung lượng, thời gian.
- Cập nhật sổ tay khôi phục mỗi khi hệ thống thay đổi.
Nguyên tắc mở rộng thường được nhắc tới là 3-2-1-1-0: ba bản sao, hai loại phương tiện, một bản ngoài văn phòng, một bản không thể sửa xóa, và không lỗi khi kiểm tra khôi phục.
Kiểm thử khôi phục: bước hay bị bỏ qua nhất
Một bản sao lưu chưa từng được khôi phục thử chỉ là giả định. Lịch kiểm thử tối thiểu:
- Hằng tháng: khôi phục cơ sở dữ liệu và kho vector lên một máy thử hoặc máy ảo, đăng nhập bằng tài khoản thử, hỏi vài câu về tài liệu đã biết.
- Hằng quý: diễn tập dựng lại toàn bộ hệ thống từ đầu trên máy trống, chỉ dùng sổ tay khôi phục và bản sao lưu. Đo thời gian thực tế, so với RTO đã đặt.
- Sau mỗi thay đổi lớn: đổi phần mềm, đổi mô hình embedding, nâng cấp cơ sở dữ liệu.
Kiểm tra kết quả
- Người dùng thử đăng nhập được, thấy lịch sử hội thoại cũ.
- Câu hỏi về tài liệu trong kho tri thức trả về đúng nguồn trích dẫn.
- Phân quyền giữ nguyên: tài khoản phòng kinh doanh không đọc được tài liệu nhân sự.
- Mã băm file mô hình khớp với ghi chép.
Ghi lại thời gian và các vướng mắc mỗi lần diễn tập, bổ sung vào sổ tay. Diễn tập lần đầu thường phát hiện ít nhất một thứ bị quên, ví dụ chứng chỉ HTTPS hoặc tài khoản dịch vụ trên NAS.
Lỗi thường gặp khi sao lưu hệ thống AI
- Chỉ sao lưu file mô hình: tốn dung lượng nhất nhưng ít giá trị nhất, trong khi cấu hình và cơ sở dữ liệu lại bị bỏ qua.
- Chép thư mục cơ sở dữ liệu khi đang chạy: bản sao hỏng, chỉ phát hiện lúc cần dùng.
- Không ghi mô hình embedding: khôi phục kho vector xong nhưng tìm kiếm trả kết quả vô nghĩa.
- Bản sao lưu nằm trên cùng server: hỏng ổ hoặc ransomware là mất cả hai.
- Bản sao lưu không mã hóa: lịch sử hội thoại chứa dữ liệu nhạy cảm nằm trần trên ổ sao lưu hoặc dịch vụ đám mây.
- Khóa API, mật khẩu đưa vào Git: lộ thông tin khi kho Git bị chia sẻ nhầm.
- Tài khoản sao lưu có quyền xóa: kẻ tấn công chiếm server dùng chính tài khoản đó xóa sạch bản sao.
- Không ai nhận thông báo lỗi: sao lưu thất bại âm thầm nhiều tuần.
Khi nào có thể đơn giản hóa
Nếu bạn chỉ dùng AI cục bộ trên một máy cá nhân, không có kho tri thức hay lịch sử quan trọng, chỉ cần lưu lại danh sách mô hình và cấu hình công cụ. Sao lưu đầy đủ như trên dành cho hệ thống phục vụ nhiều người.
Hãy coi cấu hình là tài sản quý nhất: mọi thay đổi cấu hình, prompt hệ thống, Modelfile đều phải đi qua Git trước khi áp dụng. Khi có sự cố, một kho Git sạch cộng bản dump cơ sở dữ liệu giúp dựng lại hệ thống nhanh hơn rất nhiều so với một ổ sao lưu chứa đầy file mô hình.
Câu hỏi thường gặp
Có cần sao lưu file mô hình AI không?
Không cần sao lưu thường xuyên vì tải lại được, nhưng nên giữ một bản trên NAS và ghi lại tên, phiên bản, mã băm. Mô hình tự tinh chỉnh thì phải sao lưu đầy đủ vì không tải lại được.
Cơ sở dữ liệu vector sao lưu thế nào cho an toàn?
Dùng cơ chế snapshot hoặc xuất dữ liệu của chính phần mềm, hoặc dừng ghi trước khi chép. Luôn lưu kèm thông tin mô hình embedding đã dùng để tạo kho vector.
Sao lưu hệ thống AI bao lâu một lần là đủ?
Cấu hình sao lưu mỗi lần thay đổi, cơ sở dữ liệu người dùng và kho vector hằng ngày, tài liệu nguồn snapshot hằng giờ trong giờ làm việc. Điều chỉnh theo mức mất dữ liệu chấp nhận được của công ty.
Ransomware có mã hóa được bản sao lưu AI không?
Có, nếu bản sao lưu nằm trên ổ hoặc thư mục mà máy bị nhiễm truy cập được với quyền ghi xóa. Cần ít nhất một bản không thể sửa xóa hoặc tách khỏi mạng.
Lịch sử chat AI có nên sao lưu không?
Nên, nếu lịch sử có giá trị tra cứu hoặc yêu cầu lưu trữ. Nhưng bản sao lưu phải mã hóa và áp cùng thời hạn lưu giữ, xóa như hệ thống chính vì chứa dữ liệu nhạy cảm.
Dùng công cụ gì để sao lưu server AI chạy Linux?
Các công cụ mã nguồn mở như restic hoặc BorgBackup hỗ trợ mã hóa, loại bỏ trùng lặp và nhiều đích lưu trữ. Kết hợp với lệnh xuất cơ sở dữ liệu và Git cho cấu hình.
