7.19 Snapshot và phục hồi
Snapshot là file tar chứa dữ liệu và cấu hình của một collection, trên một node, tại một
thời điểm. Ba chữ “một” đó là toàn bộ nội dung cần cẩn thận của mục này.
Ba ràng buộc phải biết trước
Phần tiêu đề “Ba ràng buộc phải biết trước”1. Snapshot là theo từng node
Phần tiêu đề “1. Snapshot là theo từng node”Trong cụm phân tán, bạn phải tạo snapshot riêng cho từng node. Một snapshot chỉ chứa dữ liệu nằm trên node tạo ra nó.
Đây là chỗ hỏng phổ biến nhất: chạy một lệnh tạo snapshot trên cụm 3 node, tưởng đã sao lưu xong, rồi phát hiện chỉ có một phần ba dữ liệu vào đúng lúc cần phục hồi.
2. Snapshot cấp collection không chứa alias
Phần tiêu đề “2. Snapshot cấp collection không chứa alias”Alias phải được di chuyển hoặc phục hồi riêng. Nếu quy trình triển khai của bạn dựa vào alias (7.2), hãy sao lưu chúng như một phần riêng của quy trình.
3. Ràng buộc phiên bản khi phục hồi
Phần tiêu đề “3. Ràng buộc phiên bản khi phục hồi”Snapshot chỉ phục hồi được sang cụm chạy cùng minor version hoặc minor kế tiếp.
Ví dụ: snapshot lấy từ v1.18.1 phục hồi được sang v1.18.x (x ≥ 1) hoặc v1.19.x. Không phục hồi được sang v1.20.
Hệ quả vận hành: snapshot không phải là kho lưu trữ dài hạn. Một snapshot để một năm gần như chắc chắn không restore được vào cụm hiện tại. Nếu bạn cần lưu trữ dài hạn, hãy giữ dữ liệu nguồn (văn bản gốc + khả năng sinh lại embedding), không phải snapshot.
Cùng logic với đường nâng cấp ở 7.5: Qdrant là hệ đi từng minor một, cả khi nâng cấp lẫn khi phục hồi.
Hai cấp snapshot
Phần tiêu đề “Hai cấp snapshot”| Cấp collection | Toàn bộ storage | |
|---|---|---|
| Endpoint | POST /collections/{name}/snapshots | POST /snapshots |
| Chứa | Cấu hình collection, mọi point, mọi payload | Mọi collection + alias |
| Có alias? | ❌ | ✅ |
| Dùng được ở chế độ phân tán? | Có (từng node) | Không |
Snapshot toàn bộ storage chỉ dùng được cho triển khai một node. Ở chế độ phân tán nó không chứa đủ file cần thiết.
Ba cách phục hồi
Phần tiêu đề “Ba cách phục hồi”| Cách | Khi nào dùng | Hạn chế |
|---|---|---|
| Từ URL hoặc file cục bộ | File đã nằm trên node, hoặc tải được từ một URL | URL phải node đó với tới được |
| Tải file lên | Di chuyển dữ liệu sang cụm khác | Truyền qua HTTP, chậm với file lớn |
Lúc khởi động (cờ --snapshot) | Một node, tự host | Không dùng được ở chế độ nhiều node |
Phục hồi từ URL có một cái bẫy bảo mật, và nó cũng là lý do Qdrant Cloud chặn hẳn cách này: xem phần SSRF ở 7.20.
Với cách khởi động, collection đích phải chưa tồn tại, nếu không tiến trình sẽ thoát với
lỗi. Có cờ --force_snapshot để ghi đè, và tên của nó đã nói lên mức độ cẩn trọng cần có.
⚠️ priority — tham số làm hỏng nhiều lần phục hồi nhất
Phần tiêu đề “⚠️ priority — tham số làm hỏng nhiều lần phục hồi nhất”Khi phục hồi vào một node không rỗng, dữ liệu trong snapshot và dữ liệu đang có sẽ xung
đột. priority quyết định bên nào thắng:
| Giá trị | Nghĩa |
|---|---|
replica (mặc định) | Ưu tiên dữ liệu đang có, không phải snapshot |
snapshot | Ưu tiên dữ liệu trong snapshot |
no_sync | Phục hồi không đồng bộ gì thêm — trường hợp đặc biệt |
Đọc kỹ dòng đầu: mặc định là replica, tức là ưu tiên dữ liệu hiện có.
Hệ quả trực tiếp, và Qdrant nói thẳng điều này:
Phục hồi một collection mới từ snapshot mà quên đặt
priority: "snapshot"sẽ cho bạn một collection RỖNG. Vì collection trên cụm chưa có điểm nào, và nguồn “đang có” được ưu tiên hơn.
Đây là loại lỗi khiến người ta tưởng snapshot bị hỏng. Nó không hỏng — bạn vừa bảo Qdrant hãy ưu tiên cái rỗng.
no_sync dành cho tình huống bạn tự quản lý và chuyển shard bằng tay. Dùng sai nó để lại
cụm ở trạng thái hỏng. Nếu bạn không chắc mình cần nó, bạn không cần nó.
Snapshot lưu ở đâu
Phần tiêu đề “Snapshot lưu ở đâu”Cấu hình trong storage.snapshots_config
(config.yaml v1.19.0):
snapshots_path: ./snapshotssnapshots_config: snapshots_storage: local # hoặc "s3" # s3_config: { bucket, region, access_key, secret_key }Hỗ trợ S3 trực tiếp là thứ đáng bật cho production: snapshot nằm cùng đĩa với dữ liệu gốc thì nó không bảo vệ bạn khỏi sự cố đĩa — nó chỉ bảo vệ khỏi lỗi thao tác.
Snapshot ≠ backup
Phần tiêu đề “Snapshot ≠ backup”Phân biệt này quan trọng cho việc thiết kế quy trình khôi phục:
| Snapshot | Backup (khái niệm của Qdrant Cloud) | |
|---|---|---|
| Là gì | Archive logic của một collection | Bản sao vật lý ở mức đĩa |
| Cấp độ | Collection, từng node | Cả cụm |
| Ràng buộc phiên bản | Có (cùng minor hoặc kế tiếp) | Ít bị ràng buộc hơn |
| Dùng cho | Di chuyển, sao lưu chọn lọc, nhân bản | Khôi phục thảm hoạ |
Ở bản tự host, bạn không có “backup” theo nghĩa này — bạn có snapshot, cộng với bất cứ cơ chế snapshot đĩa nào mà hạ tầng của bạn cung cấp (EBS snapshot, LVM, ZFS). Với hệ quan trọng, hãy dùng cả hai.
Quy trình khôi phục nên có
Phần tiêu đề “Quy trình khôi phục nên có”Viết ra và diễn tập, vì mọi ràng buộc ở trên chỉ lộ ra khi bạn thật sự thử:
- Sao lưu định kỳ mọi node, đẩy lên S3, có xoay vòng.
- Sao lưu alias riêng (hoặc dùng snapshot toàn bộ storage nếu chạy một node).
- Ghi lại phiên bản Qdrant đi kèm mỗi snapshot. Không có nó thì ràng buộc minor version biến snapshot thành một câu đố.
- Diễn tập phục hồi ít nhất một lần, vào một cụm trống, với
priority: "snapshot". - Giữ được dữ liệu nguồn. Với hệ RAG, đường phục hồi cuối cùng luôn là “nạp lại từ tài liệu gốc và sinh lại embedding”. Nếu đường đó không tồn tại, bạn đang phụ thuộc hoàn toàn vào snapshot — và snapshot có hạn sử dụng.
Điểm 5 là điểm khác biệt lớn nhất giữa vector database và cơ sở dữ liệu thường: dữ liệu trong Qdrant là dữ liệu dẫn xuất. Nếu bạn còn văn bản gốc và còn model, bạn dựng lại được tất cả. Hãy thiết kế cho điều đó thay vì coi Qdrant là nguồn sự thật.