Qdrant - Vector Database
Snapshots: резервные копии
Ваш коллега случайно запустил скрипт удаления 'test' коллекции - и удалил production. Без бэкапов. Восстановить 50 миллионов векторов заняло 18 часов. Snapshots - это страховка от таких ситуаций.
- **Pre-migration backup:** snapshot перед обновлением Qdrant или изменением параметров коллекции — rollback за минуты вместо часов
- **Hourly S3 backups:** автоматический cron job создаёт snapshot каждый час, загружает в S3, соблюдает retention policy
- **Staging refresh:** ежедневный snapshot production → загрузка на staging для тестирования на реальных данных без риска
Предварительные знания
Что такое snapshot и когда использовать
**Snapshot** в Qdrant - это консистентная копия состояния коллекции (или всего инстанса), сохранённая в файл `.snapshot`. Snapshot-ы используют copy-on-write механизм: создание занимает секунды независимо от размера коллекции. Qdrant поддерживает два типа: - **Collection snapshot** - один снимок конкретной коллекции: векторы + payload + индексы - **Full snapshot** - снимок всего инстанса: все коллекции одновременно Когда использовать snapshots: - **Перед миграцией** - обновление Qdrant, смена параметров коллекции - **Disaster recovery** - периодические бэкапы в S3/GCS - **Копирование данных** - перенос коллекции между инстансами - **Тестирование** - snapshot production-данных для staging
**Формат файла:** `.snapshot` - это tar-архив с внутренней структурой Qdrant. Файл нельзя открыть как обычный архив для просмотра данных - он предназначен исключительно для восстановления через Qdrant API. **Размер** snapshot примерно равен объёму данных на диске коллекции (не сжатый). Collection snapshot хранится в `/qdrant/snapshots/{collection_name}/`, full snapshot - в `/qdrant/snapshots/`.
| Параметр | Collection snapshot | Full snapshot |
|---|---|---|
| Покрытие | Одна коллекция | Все коллекции |
| Endpoint | POST /collections/{name}/snapshots | POST /snapshots |
| Время создания | Секунды (CoW) | Секунды (CoW) |
| Восстановление | Без остановки | Требует пустого инстанса |
| Use case | Миграция, бэкап одной коллекции | Полный бэкап инстанса |
Вы планируете обновить Qdrant с v1.8 на v1.10 в production. Какой snapshot-стратегии придерживаться?
Операции со snapshot-ами: скачивание, загрузка, восстановление
После создания snapshot его можно **скачать**, **восстановить** на том же или **загрузить** на новый инстанс. Восстановление snapshot не требует остановки Qdrant - коллекция будет пересоздана из snapshot, при этом существующие данные в коллекции заменяются.
**CI/CD применение:** snapshot перед деплоем нового кода, который меняет структуру payload или индексы. Workflow: `pre-deploy hook → createSnapshot → deploy → smoke tests → если fail: recoverFromSnapshot`. Snapshot занимает секунды, rollback - минуты, вместо ручного восстановления часами.
Вы хотите перенести коллекцию 'products' с dev-сервера на staging. Staging-сервер доступен по HTTP, но не имеет доступа к файловой системе dev-сервера. Какой метод использовать?
Production backup стратегия: автоматизация и S3
**Production backup** для Qdrant строится вокруг трёх принципов: 1. **Периодичность** - snapshot каждые N часов через cron или scheduled job 2. **Внешнее хранилище** - snapshot копируется в S3/GCS (не на том же сервере) 3. **Retention policy** - хранить последние N snapshot-ов, удалять старые Важно: snapshot vs WAL-based backup. Qdrant не предоставляет streaming WAL репликацию во внешнее хранилище. **Snapshot - единственный встроенный механизм бэкапа.** Для RPO < 1 часа: snapshot каждые 30-60 минут.
**Snapshot vs continuous backup:** Qdrant не поддерживает WAL-shipping (как PostgreSQL). Между snapshot-ами данные не бэкапируются. При RPO = 1 час и потере сервера вы теряете до 1 часа данных. Для критических данных: snapshot каждые 15-30 минут + мониторинг успешности бэкапов (алерт если последний бэкап > 2 часов назад).
«Snapshot - это медленно, лучше использовать репликацию как бэкап»
Snapshot создаётся за секунды (copy-on-write). Репликация защищает от отказа узла, но не является бэкапом - при удалении данных реплика тоже синхронизирует удаление.
Qdrant snapshot использует snapshot isolation на уровне хранилища (rocksdb). Физическое создание snapshot = создание hard links на файлы сегментов. Это занимает миллисекунды даже для 100GB коллекции. Репликация - защита от hardware failure одного узла, snapshot - защита от логических ошибок (случайное удаление, corrupted data, migration failure).
В 03:15 сервер Qdrant упал. Последний успешный backup был в 03:00. В коллекции было записано 5000 точек между 03:00 и 03:15. Что произойдёт при восстановлении из backup?
Итоги
- **Collection snapshot** — снимок одной коллекции; **Full snapshot** — всего инстанса. Оба создаются за секунды (copy-on-write).
- **Операции:** createSnapshot → download (fetch GET) → upload (PUT /snapshots/upload) → recover (PUT /snapshots/recover) → deleteSnapshot
- **Восстановление:** recover принимает URL или локальный путь на Qdrant-сервере; upload принимает файл напрямую
- **Production стратегия:** периодические snapshots → S3 → retention policy (последние N бэкапов)
- **RPO** определяется частотой snapshot-ов: hourly snapshot = до 1 часа потери данных при disaster
Что дальше
Научились делать бэкапы. Следующий шаг - оперативная работа с большими объёмами данных через scroll и batch операции.
- Scroll и Batch операции — Для экспорта данных перед snapshot-ом или верификации после восстановления
- Distributed Qdrant — Snapshot стратегия меняется в распределённом кластере - snapshots по шардам
- Cloud vs Self-hosted — В Qdrant Cloud бэкапы управляются платформой - snapshot API используется иначе
Вопросы для размышления
- Ваша коллекция занимает 200GB. Snapshot создаётся за секунды, но скачивание занимает 10 минут. Как организовать бэкап с минимальным влиянием на production трафик?
- Как проверить целостность snapshot после загрузки в S3? Какие метрики использовать для мониторинга успешности бэкапов?
- В Qdrant Cloud (managed) доступна ли функция snapshot через API? Как отличается стратегия бэкапа для managed vs self-hosted?