Перейти к содержанию
modelium.
Начать с задачи
←

Qdrant snapshots: резервная копия коллекции и проверка восстановления

Qdrant snapshot сохраняет состояние отдельной коллекции: её конфигурацию, точки и payload, но не алиасы. Создайте снимок через API, скачайте и храните файл вне исходного узла, затем восстановите под новым именем в изолированном стенде и сравните точки и поисковый результат. Для распределённой коллекции одного снимка одного узла недостаточно.

Срез документации — 7 октября 2026 года. Это инструкция для самостоятельной проверки: Modelium не запускал Qdrant и не утверждает, что восстановление или поиск прошли на чьей-либо инфраструктуре. Ниже речь о snapshot коллекции, а не резервной копии всего узла. s1

Когда snapshot коллекции решает задачу?

Если локальный RAG хранит в Qdrant уже построенные векторы документов, снимок отдельной коллекции даёт способ сохранить её конфигурацию, точки и payload, а затем проверить восстановление в отдельной коллекции. Он не включает алиасы: записывайте их отдельно, если приложение обращается к алиасу. Файлы документов, версия embedding-модели, код построения индекса и настройки приложения в состав этого снимка не входят — их потребуется хранить отдельно, чтобы воспроизвести весь RAG-стек. s1 s5

Путь для контрольного примера: обезличенная коллекция с двумя известными точками → Qdrant на совместимом тестовом узле → снимок коллекции → файл за пределами исходного узла → восстановленная коллекция под новым именем → сверка ID, payload и результата поиска. Это протокол проверки, а не обещание сохранности произвольного кластера. Если вам сначала нужно создать коллекцию и проверить векторный поиск, начните с локального Qdrant. s1 s3 s4

Snapshot не заменяет план восстановления после аварии. В распределённой установке снимок коллекции создают на каждом узле отдельно: файл одного узла не содержит все данные других. Qdrant отдельно описывает storage snapshots и Cloud Backups; полная копия хранилища предназначена для single-node, а Cloud Backups — иной механизм восстановления. Не переносите приведённый ниже single-node сценарий на кластер без схемы его шардов и реплик. s1 s2

Что подготовить, чтобы не затронуть рабочий поиск?

Возьмите тестовый self-hosted Qdrant и две заранее известные обезличенные записи. Официальный quickstart показывает запуск через Docker с постоянным томом и локальным REST на localhost:6333; проверьте, что порт тестового экземпляра не открыт наружу. Для рабочего узла заранее запишите версию, имена коллекций, состояние алиасов, число контрольных точек и идентификаторы нескольких документов. Секрет API не размещайте в статье, истории команд или снимках экрана; в защищённой установке запросам нужен заголовок api-key. s3 s5 s6

Проверьте совместимость до теста: Qdrant разрешает восстановление в ту же minor-версию с patch не ниже исходного либо в следующую minor-версию. Например, приведённый в документации снимок v1.18.1 допускается для v1.18.x с x ≥ 1 или для v1.19.x; не считайте обратное восстановление гарантированным. Уточните точные версии ваших узлов и документации, прежде чем рисковать данными. s1

Зафиксируйте исходную коллекцию, например docs_test, и имя новой целевой docs_restore_test. Не выбирайте рабочее имя ни при какой неопределённости. Если индекс использует алиас, сохраните отдельно имя алиаса и его текущую цель: collection snapshot алиас не переносит. Для теста используйте только собственные обезличенные точки и изолированный сервер. s1 s5

Как создать и сохранить snapshot?

Отправьте POST /collections/docs_test/snapshots на REST-адрес исходного узла. В ответе с status: ok API возвращает result.name, размер, время создания и, если доступно, checksum; запишите именно возвращённое имя, не конструируйте его по дате. При необходимости список доступных файлов возвращает GET /collections/docs_test/snapshots. Официальный учебный пример отдельно обходит узлы распределённой коллекции и сохраняет снимок с каждого. s1 s2 s6

Скачайте полученный файл через GET /collections/docs_test/snapshots/{result.name}. Храните его в отдельном защищённом месте, не только рядом с исходным хранилищем Qdrant: локальная потеря диска иначе лишит вас и индекса, и его снимка. Проверьте, что скачался файл, а не JSON-ошибка или страница входа; запишите контрольную сумму SHA-256 файла и имя исходной коллекции, узел и версию Qdrant. Эта сохранённая сумма — ваш проверочный артефакт, а не утверждение, что сервер автоматически проверил её при восстановлении. s1 s2 s7

Не переименовывайте скачанный архив так, чтобы потерять связь с result.name, и не отправляйте файл с приватными payload на публичное хранилище. Каталог snapshot по умолчанию находится на диске исходного узла, а в контейнере — /qdrant/snapshots; создание файла само по себе ещё не является внешним бэкапом. s1 s7

Как восстановить копию без перезаписи продакшена?

На отдельном тестовом узле проверьте имя docs_restore_test и совместимость версий, затем загрузите сохранённый файл через POST /collections/docs_restore_test/snapshots/upload?priority=snapshot как multipart-поле snapshot с файлом .snapshot. Документация Qdrant описывает этот путь для переноса файла на новый сервер; если коллекция отсутствует, endpoint создаёт её. Для уже существующей цели он может перезаписать данные на узле, поэтому новое имя и отдельный сервер — обязательная страховка, а не косметическое переименование. s1 s8

При подключении к удалённому Qdrant передавайте нужный api-key по защищённому каналу, не добавляя его в текст или лог эксперимента. Endpoint также предоставляет параметр checksum для проверки SHA-256 до recovery: если используете его, берите из вычисленной суммы именно загружаемого файла. Дождитесь успешного ответа recovery, но не считайте один status: ok проверкой полноты данных: это проверяется следующими шагами. s6 s8

Альтернативный PUT /collections/{collection_name}/snapshots/recover принимает URL либо локальный путь, доступный самому узлу Qdrant; путь на ноутбуке пользователя не становится путём сервера. Для сценария с уже скачанным файлом удобнее multipart upload. В Qdrant Cloud восстановление по URL ограничено сетевой политикой, поэтому проверяйте допустимый способ отдельно для вашей среды. s1

Как проверить данные и поиск после восстановления?

Сначала запросите сведения о новой коллекции и сравните настройки векторов с исходной; затем через GET /collections/docs_restore_test/points/{id} проверьте несколько известных ID, payload и при необходимости вектор. Для полной сверки используйте POST /collections/docs_restore_test/points/scroll с пагинацией, а не первые две случайные записи: REST API Qdrant предоставляет чтение точек и обход коллекции. Сравнивайте идентификаторы и поля с контрольным набором до снимка. Если данные продолжали изменяться после создания снимка, не ждите в копии более поздних правок. s4 s5

Повторите тот же векторный запрос и фильтр payload на исходном контрольном наборе и на восстановленной коллекции, сравните возвращённые ID и релевантные поля. Даже равное число точек не доказывает эквивалентность поиска или доступность нужной embedding-модели: это отдельные проверки. Гайд о фильтрации Qdrant поможет провести отрицательный тест для чужой метки, но фильтр не заменяет серверные права доступа. s4 s5

Запишите матрицу результата: имя источника и копии, версии, snapshot result.name, SHA-256 загруженного файла, контрольные ID и payload, совпадение поиска, алиасы и ошибки. Если тест не прошёл, не переключайте алиас и не удаляйте исходную коллекцию; разберите версию, файл, имя цели и ответы API. Успешная загрузка файла без чтения контрольной точки не считается подтверждённым восстановлением. s1 s4 s5 s8

Что оставить в плане эксплуатации после теста?

Периодически повторяйте создание и восстановление на отдельном узле и храните копии по политике доступа и сроков. Если используется алиас, восстановите его связь отдельно и только после проверки данных: алиасы не входят в collection snapshot, а обновления алиасов Qdrant выполняет атомарно. Для распределённого кластера составьте отдельный план снимков всех узлов и проверьте его именно на кластерной конфигурации. s1 s2 s5

Не включайте этот snapshot в заявленную «полную резервную копию RAG», если не сохранены исходные документы, модель эмбеддингов и код построения индекса. Не выводите требования к RAM/VRAM из размера файла снимка или весов модели. Modelium не проводил восстановление и не оценивал время RTO/RPO или качество выдачи: результат появляется только после вашего теста. s1 s4

Следующий шаг: подготовьте изолированный локальный Qdrant, восстановите под новым именем две обезличенные точки и сравните ID, payload и поиск с заранее сохранённым эталоном. s3 s4 s8

Источники

  1. Qdrant: Snapshots, правила, состав и восстановление. Получено 07.10.2026.
  2. Qdrant: Create a Snapshot tutorial. Получено 07.10.2026.
  3. Qdrant: Local Quickstart. Получено 07.10.2026.
  4. Qdrant: Points and retrieval. Получено 07.10.2026.
  5. Qdrant: Collections and aliases. Получено 07.10.2026.
  6. Qdrant API: Create collection snapshot. Получено 07.10.2026.
  7. Qdrant API: Download collection snapshot. Получено 07.10.2026.
  8. Qdrant API: Recover from uploaded snapshot. Получено 07.10.2026.