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

Источник: https://modelium.tech/zhurnal/qdrant-snapshots/

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

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

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

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

Путь для контрольного примера: обезличенная коллекция с двумя известными точками → Qdrant на совместимом тестовом узле → снимок коллекции → файл за пределами исходного узла → восстановленная коллекция под **новым** именем → сверка ID, payload и результата поиска. Это протокол проверки, а не обещание сохранности произвольного кластера. Если вам сначала нужно создать коллекцию и проверить векторный поиск, начните с [локального Qdrant](/zhurnal/qdrant-lokalno/). [s1](#src-s1) [s3](#src-s3) [s4](#src-s4)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Повторите **тот же** векторный запрос и фильтр payload на исходном контрольном наборе и на восстановленной коллекции, сравните возвращённые ID и релевантные поля. Даже равное число точек не доказывает эквивалентность поиска или доступность нужной embedding-модели: это отдельные проверки. Гайд о [фильтрации Qdrant](/zhurnal/qdrant-filtry-metadannyh/) поможет провести отрицательный тест для чужой метки, но фильтр не заменяет серверные права доступа. [s4](#src-s4) [s5](#src-s5)

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

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

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

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

**Следующий шаг:** подготовьте изолированный [локальный Qdrant](/zhurnal/qdrant-lokalno/), восстановите под новым именем две обезличенные точки и сравните ID, payload и поиск с заранее сохранённым эталоном. [s3](#src-s3) [s4](#src-s4) [s8](#src-s8)

## Источники

1. [Qdrant: Snapshots, правила, состав и восстановление](https://qdrant.tech/documentation/snapshots/) — получено 2026-10-07
2. [Qdrant: Create a Snapshot tutorial](https://qdrant.tech/documentation/tutorials-operations/create-snapshot/) — получено 2026-10-07
3. [Qdrant: Local Quickstart](https://qdrant.tech/documentation/quickstart/) — получено 2026-10-07
4. [Qdrant: Points and retrieval](https://qdrant.tech/documentation/manage-data/points/) — получено 2026-10-07
5. [Qdrant: Collections and aliases](https://qdrant.tech/documentation/manage-data/collections/) — получено 2026-10-07
6. [Qdrant API: Create collection snapshot](https://api.qdrant.tech/api-reference/snapshots/create-snapshot) — получено 2026-10-07
7. [Qdrant API: Download collection snapshot](https://api.qdrant.tech/api-reference/snapshots/get-snapshot) — получено 2026-10-07
8. [Qdrant API: Recover from uploaded snapshot](https://api.qdrant.tech/api-reference/snapshots/recover-from-uploaded-snapshot) — получено 2026-10-07