Хранилища

Раздел Storage управляет ресурсами двух видов. Подключение к хранилищу хранит доступ к объектному или файловому хранилищу, которое работает в другом месте. Управляемое хранилище — S3-совместимое объектное хранилище, которое Opfield создаёт и запускает на ноде хранилища; новые кластеры используют SeaweedFS. Оба вида требуют тарифа Personal или выше. Хранилища служат местом назначения для резервного копирования баз данных, а управляемое хранилище может предоставить рабочим нагрузкам приватный доступ, ограниченный отдельными бакетами.

Вопрос	Подключение к хранилищу	Управляемое хранилище
Кто эксплуатирует службу	Провайдер или ваша команда хранения данных	Opfield — как SeaweedFS на одной ноде хранилища с ограниченным диском
Протоколы	S3 (AWS S3, Cloudflare R2, MinIO и другие S3-совместимые службы), SFTP, FTP, FTPS	S3
Обозреватель объектов	Да	Да
Место назначения резервных копий	Да	Да
Ключи доступа и привязки рабочих нагрузок	Нет	Да
Публичный доступ	Неприменимо	По умолчанию приватное; публичная точка доступа S3 включается явно
Удаление	Удаляет только сохранённое подключение в Opfield	Удаляет службу и стирает её данные

Подключения к хранилищам

Выберите Add Storage и укажите провайдера:

Провайдер	Параметры подключения
AWS S3, Cloudflare R2, MinIO, Other (S3-compatible)	Регион, идентификатор ключа доступа и секретный ключ доступа; адрес службы для всех провайдеров, кроме AWS; при необходимости токен сеанса, бакет по умолчанию и адресация в стиле пути (path-style, для MinIO включена по умолчанию)
SFTP	Хост, порт (по умолчанию 22), имя пользователя, пароль или закрытый ключ с необязательной парольной фразой, а также отпечаток SHA-256 SSH host key fingerprint сервера — он обязателен и проверяется при каждом подключении
FTP, FTPS	Хост, порт (21 или 990 для неявного FTPS), имя пользователя и пароль; FTPS поддерживает явный режим и Implicit TLS и всегда проверяет сертификат сервера по системному хранилищу доверенных сертификатов или по указанному вами CA Certificate

Для FTP, FTPS и SFTP каталоги внутри заданного Base Path отображаются как бакеты. SMB не поддерживается.

Opfield хранит секреты, отпечатки ключей хоста и сертификаты CA в зашифрованном виде и никогда не возвращает секреты в форму: пустое поле секрета сохраняет прежнее значение, но при изменении адреса службы, хоста, имени пользователя, протокола или настроек доверия секрет нужно ввести заново. Для раскрытия сохранённых учётных данных нужно право storage:credentials:reveal. storage:credentials:use позволяет резервному копированию баз данных и заданиям копирования использовать сохранённые учётные данные без их раскрытия. Бакет, на который ссылаются политики или история резервного копирования, удалить нельзя; для подключений к хранилищам см. Удаление хранилища, на которое ссылаются резервные копии.

Вкладка Objects позволяет просматривать бакеты и объекты, открывать и редактировать файлы, отправлять файлы, создавать папки и удалять файлы и папки. Пока хранилище отключено, вкладка недоступна. Создание бакета предлагается, когда в подключении нет бакетов, и требует storage:objects:admin. Через API можно также удалять бакеты и создавать предварительно подписанные ссылки на скачивание; такие ссылки недоступны для приватного управляемого хранилища, файлы из которого скачиваются через Opfield, а также для FTP, FTPS и SFTP. Запрос несуществующего объекта или бакета возвращает STORAGE_NOT_FOUND. См. Права доступа.

Клиенты MCP передают большие объекты без base64 в вызовах инструментов: download_storage_object проверяет storage:objects:read и возвращает одноразовую ссылку, действующую 15 минут, с готовой командой curl, которая передаёт объект через Opfield, а upload_storage_object загружает объект частями, которые Opfield проверяет. При использовании ссылка на скачивание заново проверяется по текущим правам владельца и срабатывает один раз.

Управляемое объектное хранилище

Выберите Deploy managed storage, чтобы развернуть объектное хранилище на ноде хранилища, при необходимости — в папке хранилищ; выбор папки предлагает только папки, где вы можете создавать хранилища. Новые кластеры используют SeaweedFS 4.47, закреплённый по неизменяемому дайджесту образа; изменить версию на месте нельзя. Нода хранилища сначала загружает образ из зеркала Opfield ghcr.io/the-square-labs/gateway, а при неудаче — из Docker Hub, в обоих случаях проверяя тот же дайджест. Если оба источника недоступны, создание останавливается с ошибкой MANAGED_STORAGE_IMAGE_PULL_FAILED.

Кластер работает на одной ноде хранилища; распределённые кластеры для SeaweedFS недоступны. Ограничения CPU, памяти (не меньше 512 МиБ) и диска задаются при создании; Console ограничивает размер диска свободным местом на ноде за вычетом её резерва. Диск — заранее выделенный образ ограниченного размера на ноде хранилища, как у управляемых баз данных: каждый кластер занимает на ней одно loop-устройство, а Docker-демон запускает движок только после того, как этот образ смонтирован; см. Для операторов: хранилище и прямой TLS. Корневые учётные данные создаёт Opfield; для их раскрытия нужно право storage:credentials:reveal.

После создания можно изменить имя, теги, CPU, память, swap, размер диска и публикацию S3. Диск можно только увеличить, а изменение отклоняется, пока ещё применяется предыдущее. Увеличение диска, а также включение или отключение публикации и смена её порта пересоздают контейнер хранилища; данные и ключи сохраняются. Также доступны Restart и повтор неудачного создания.

Имена управляемых хранилищ уникальны в пределах ноды хранилища. Создание или переименование управляемого хранилища с именем, которое уже использует другое управляемое хранилище на той же ноде, завершается ошибкой 409 MANAGED_STORAGE_NAME_IN_USE; если то хранилище не удалось создать, сначала повторите его создание или удалите его. Имя освобождается, как только начинается удаление хранилища. При обновлении Opfield до 2.11 более поздние кластеры с одинаковым именем на одной ноде переименованы с первым свободным суффиксом -2, -3, … вместе с их подключением хранилища; см. «Конфликты, разрешённые при обновлении до 2.11».

Управляемое хранилище по умолчанию приватно. Opfield обращается к нему через аутентифицированные маршруты Relay. Дополнительные пути доступа можно включить явно:

• Publish S3 endpoint открывает API S3 на порту хоста, по умолчанию 9000.
• TLS шифрует точку доступа S3 сертификатом Opfield Storage CA. Шифрование выбирается при создании кластера, включить его позже нельзя. Клиенты должны доверять этому центру сертификации: окно учётных данных показывает его отпечаток SHA-256 и позволяет скачать сертификат в файл storage-ca.pem или скопировать его. Через API GET /api/managed-storage/{id}/ca-certificate возвращает сертификат и отпечаток любому, кто может просматривать кластер, или ошибку MANAGED_STORAGE_TLS_DISABLED (409), если TLS отключён; инструмент MCP manage_managed_storage предоставляет то же самое через действие ca_certificate.

Кластеры SeaweedFS поддерживают только S3; служб FTP и SFTP у них нет. Opfield не изменяет межсетевые экраны хостов. Открывайте только порты, которые нужны определённому клиенту.

Резервное копирование баз данных и задания копирования обращаются к управляемому хранилищу через локальную точку подключения и проверяют его сертификат как localhost или 127.0.0.1. Opfield автоматически добавляет эти имена в сертификаты кластеров, созданных в более раннем выпуске. Пока новый сертификат применяется, резервные копии ждут в очереди с указанием причины и повторяются сами; ошибкой BACKUP_STORAGE_CERTIFICATE_OUTDATED они завершаются, только если сертификат не начал обслуживаться в течение 7 часов.

Продление сертификата TLS

Opfield автоматически продлевает сертификат кластера с TLS, проверяя его каждый час: когда прошло две трети срока действия, осталось 30 дней или меньше, не хватает нужного имени или сертификат выпущен другим центром сертификации. Демон ноды хранилища записывает новый сертификат, и движок загружает его без перезапуска; Opfield переключается на него только после того, как кластер начал его обслуживать. Storage CA не меняется, поэтому клиенты продолжают работать.

• В разделе Connection Details хранилища есть неприметная строка TLS Certificate с датой окончания срока действия и пометкой «renewed automatically» или «needs attention». Уведомление на странице появляется, только когда нужно вмешательство — продление не удалось, осталось 7 дней или меньше, продлённый сертификат ещё не загружен, продление ждёт демона ноды или центр сертификации ограничивает срок действия, — с причиной, датой окончания срока и кнопкой Renew now для тех, кто может изменять хранилище. На Dashboard также перечислены все управляемые хранилища и управляемые базы данных, сертификаты которых требуют внимания и которые вы можете просматривать. Через API и MCP продлить сертификат можно в любой момент.
• Перезапуск используется, только если осталось 7 дней или меньше, если вы разрешили его при ручном продлении или если вы продлеваете сертификат вручную на ноде, демон которой ещё не умеет загружать сертификаты на лету. Иначе такая нода сохраняет текущий сертификат до обновления демона.
• Кластеры SeaweedFS, созданные до 2.11, перечитывают файлы сертификата лишь раз в несколько часов, поэтому новый сертификат может начать обслуживаться с такой задержкой; чтобы применить его раньше, разрешите перезапуск.
• Пока продление не удаётся, Opfield поднимает событие уведомлений Managed Service Certificate Renewal Failed, которое снимается после успешного продления. Создайте для него правило уведомлений. Продления записываются в журнал аудита.
• API: GET /api/managed-storage/{id}/certificate и POST /api/managed-storage/{id}/certificate/renew с необязательным allowRestart; MCP и ассистент: действия certificate_status и renew_certificate инструмента manage_managed_storage. Для продления нужно право storage:edit; оно работает и после окончания льготного периода лицензии.

Ёмкость

Каждый бакет хранится как минимум в одном собственном томе данных, а размер томов Opfield рассчитывает по диску, поэтому закладывайте примерно один том данных на бакет и предпочитайте умеренное число бакетов. Когда диск заполнен, запись завершается ошибкой HTTP 500, а существующие объекты остаются доступными для чтения; освободите место, удалив объекты, или увеличьте диск в настройках — контейнер будет пересоздан, и запись возобновится.

Ключи доступа и привязки рабочих нагрузок

На странице хранилища вкладка IAM Keys выдаёт учётные данные S3 с необязательным именем, доступом только для чтения или для чтения и записи, ограничением до 64 бакетов (если бакеты не выбраны — ко всем бакетам) и необязательным сроком действия. Каждый ключ — отдельный субъект IAM в движке, ограниченный своими бакетами: он видит в списке только эти бакеты, читает объекты, а при доступе для чтения и записи также записывает и удаляет объекты, но не может создавать и удалять бакеты. Срок действия ключа контролирует сам движок, а отзыв ключа сразу удаляет его субъект. Секретный ключ показывается один раз при создании ключа. Для создания и отзыва ключей нужно право storage:iam.

В окне учётных данных показаны команды быстрого старта для AWS CLI и rclone. Для кластера с TLS они передают скачанный CA как --ca-bundle storage-ca.pem (AWS CLI) или --ca-cert storage-ca.pem (rclone). С ключом, ограниченным бакетами, rclone нужен параметр no_check_bucket = true (он уже есть в команде быстрого старта); без него rclone пытается создать бакет и получает ошибку 403.

Привязка управляемого хранилища даёт Container или Deployment приватный доступ к 1–32 бакетам. Добавьте её на вкладке Environment рабочей нагрузки; службы Compose не поддерживаются. Opfield выдаёт ключ, ограниченный этими бакетами, подключает рабочую нагрузку к собственной небольшой приватной сети привязки, которую обслуживает общий коннектор защищённых связей её ноды Docker, и сохраняет значения как управляемые секреты в переменных среды, по умолчанию S3_ENDPOINT, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, S3_BUCKET (первый бакет) и AWS_REGION. Ключ открывает только перечисленные бакеты, поэтому скомпрометированная рабочая нагрузка не сможет прочитать остальное хранилище. Перечисленные в привязке бакеты, которых ещё нет, создаются при создании привязки, потому что её собственный ключ создавать их не может. Для создания привязки нужны право storage:iam и право изменять переменные среды и секреты рабочей нагрузки; привязка к развёртыванию также требует docker:containers:manage для него, а при изменении его переменных среды — ещё и docker:containers:edit.

Привязка выдерживает до 64 одновременных соединений, и во время развёртывания их делят слоты Deployment; ограничьте пул соединений клиента S3 значением 32 или меньше на контейнер. Обзор рабочей нагрузки показывает состояние привязки рядом с привязками баз данных. См. Ёмкость привязки и пулы соединений.

Начиная с 2.11.1 привязки хранилища работают через общий коннектор, как привязки баз данных и связи контейнеров, без отдельного контейнера-коннектора для каждой привязки. Привязка, созданная до 2.11.1, переходит на него после обновления Docker-демона рабочей нагрузки, и сразу после перехода Opfield один раз пересоздаёт связанную рабочую нагрузку: Deployment выкатывается по схеме blue/green без простоя, Container один раз перезапускается. Привязкам, созданным в 2.11.1, пересоздание не нужно. Откат Docker-демона до 2.11.0 сам возвращает привязки обратно, тоже с одним пересозданием каждой рабочей нагрузки.

Рабочая нагрузка может быть не запущена: привязку можно создать для Container или Deployment, которые остановлены, циклически перезапускаются, завершились ошибкой или ещё не развёрнуты, и Opfield сохраняет её, не дожидаясь нагрузки. Пока нагрузка не запущена с этой привязкой, привязка отображается как pending (observedState: "target_applied" в API и MCP) и становится активной, когда нагрузка в следующий раз запустится или завершит текущее развёртывание; повторный запуск неудачной сборки из Git тоже её применяет. Через API, MCP или ассистента Container с источником Git можно привязать по имени ещё до первой сборки — тогда первая сборка запустит его уже с привязкой. Откат Deployment и переключение слота сохраняют текущие привязки. Нода Docker рабочей нагрузки должна быть подключена.

Для расширенной конфигурации nginx Route может также использовать дополнительную привязку Secure Link к готовому управляемому объектному хранилищу — без общей сети Docker и опубликованного порта S3; клиентам по-прежнему нужны учётные данные S3. Управляемое хранилище не может быть основной целевой службой Route. Для создания привязки нужны право изменять Route и право просматривать хранилище; см. Приватные целевые службы.

Удаление управляемого хранилища стирает его данные и автоматически удаляет его привязки рабочих нагрузок. Удаление отклоняется, пока на хранилище ссылаются привязки Secure Link из Route или активное задание копирования, а ссылки из резервного копирования обрабатываются так, как описано ниже.

Сети управляемых хранилищ (gateway-storage-*) скрыты от действий с сетями Docker: пользователи не могут подключать к ним контейнеры или отключать их, удалять эти сети или создавать в них контейнеры.

Копирование данных между хранилищами

Задание копирования копирует объекты на стороне сервера из одного хранилища S3 в другое, управляемое или внешнее, — например из устаревшего кластера MinIO в SeaweedFS или из внешнего бакета в управляемое хранилище. В 2.11 у заданий копирования нет экрана в Console: запускайте их через встроенного ассистента, MCP или REST API.

• Режимы: copy добавляет и перезаписывает объекты и ничего не удаляет. sync также удаляет объекты назначения, которых нет в источнике; используйте его только для осознанного завершающего прохода. dryRun ничего не записывает и сообщает о различиях.
• Используемые места назначения: sync в управляемое хранилище, которое ещё используют привязки рабочих нагрузок или ключи доступа с правом записи и запись в которое не заморожена, отклоняется с кодом STORAGE_COPY_DESTINATION_LIVE, потому что может удалить записанные этими клиентами объекты. Заморозьте запись в место назначения, используйте copy или передайте allowLiveDestination: true, если принимаете этот риск.
• Бакеты: "all" или список имён. Каждый бакет сохраняет имя в месте назначения. Недостающие бакеты создаются, если у вас есть storage:objects:admin для места назначения; передайте createBuckets: false, чтобы требовать существующие бакеты. Версионирование бакетов, правила жизненного цикла и политики бакетов не копируются.
• Выполнение: исполнитель резервного копирования на ноде хранилища передаёт объекты с помощью rclone, сохраняя метаданные объектов, например тип содержимого, а затем сравнивает обе стороны. Opfield выбирает подключённую ноду хранилища, демон которой поддерживает задания копирования, или вы указываете её в executorNodeId. К приватному управляемому хранилищу задание обращается через отдельные маршруты Relay, поэтому порт не публикуется, а контейнер не пересоздаётся. Учётные данные не покидают Opfield и исполнителя. Необязательные limits: timeoutSeconds (по умолчанию сутки, не больше семи), cpuCores, memoryMb и transfers.
• Отчёт проверки: завершённое задание сообщает по каждому бакету и в сумме число объектов и байтов с обеих сторон, число отсутствующих, различающихся и (для sync) лишних объектов с примерами ключей, а также clean. Копирование подтверждает только завершённое задание с clean: true; завершённое задание может сообщить и о различиях, например об объектах, которые клиенты записали во время его работы. Повторный запуск того же задания передаёт только изменения, а обмен источника и места назначения копирует данные обратно.
• Ограничения: в одно хранилище может записывать только одно активное задание, ни одно задание не может читать хранилище, в которое записывает другое, а исполнитель одновременно выполняет не больше двух заданий копирования.

Действие	REST API	MCP и ассистент
Запустить задание	POST /api/storage/copy-jobs с sourceStorageId, destinationStorageId, buckets, mode, dryRun и необязательными createBuckets, allowLiveDestination, executorNodeId и limits	copy_data_start инструмента manage_storage_connection
Следить за заданием и читать отчёт	GET /api/storage/copy-jobs/{id}	copy_data_status
Показать задания	GET /api/storage/copy-jobs	copy_data_list
Отменить задание	POST /api/storage/copy-jobs/{id}/cancel	copy_data_cancel

Задания копирования принимают идентификаторы подключений к хранилищам. Для управляемого хранилища используйте идентификатор его подключения (objectStorageConnectionId в сведениях об управляемом хранилище из API и MCP), а не идентификатор управляемого хранилища.

Отменённое или прерванное по тайм-ауту задание никогда не оставляет контейнер исполнителя, а его итоговое состояние сохраняется до того, как о нём сообщается, поэтому переживает перезапуск демона сразу после этого.

Для запуска задания нужны storage:objects:read и storage:credentials:use для источника, storage:objects:write и storage:credentials:use для места назначения и nodes:backups:execute для ноды-исполнителя. Opfield повторно проверяет права владельца задания при его отправке исполнителю. Запуск требует действующего тарифа Personal или выше; просмотр, список и отмена заданий работают и после окончания льготного периода лицензии.

Миграция с MinIO

Поставщик MinIO больше не распространяет её образы, поэтому Opfield 2.11 создаёт новые управляемые хранилища на SeaweedFS. Управляемые кластеры MinIO, созданные в предыдущих выпусках, продолжают работать как устаревший движок и помечаются в Console как Legacy MinIO engine:

• Они продолжают обслуживать S3, ключи доступа, привязки рабочих нагрузок, привязки Secure Link и имеющиеся службы FTP и SFTP, а повседневные операции работают, пока образ MinIO есть на ноде хранилища.
• Новые кластеры MinIO создать нельзя.
• Операция, которой нужно пересоздать контейнер и потому загрузить образ, — например изменение публикации, увеличение диска или восстановление потерянного контейнера, — завершается ошибкой MANAGED_STORAGE_ENGINE_IMAGE_UNAVAILABLE, если образа уже нет на ноде: загрузить его больше нельзя. Opfield сообщает об этом до того, как затрагивает контейнер или его данные.

Миграция с помощью ассистента

Кнопки миграции нет. Чтобы перенести кластер на SeaweedFS, попросите встроенного ассистента, например: Перенеси управляемое хранилище «files» с MinIO на SeaweedFS. Ассистент шаг за шагом выполняет руководство Opfield по миграции, сообщает результат каждого шага и спрашивает подтверждение перед переключением и перед выводом кластера MinIO из эксплуатации. Он действует с вашими правами, поэтому вам нужны области из раздела «Действия миграции». Клиент MCP, например Codex или Claude Code, может выполнить ту же миграцию теми же инструментами.

1. Предварительная проверка (только чтение). Ассистент проверяет, что кластер готов, перечисляет его бакеты, занятое место, ключи доступа, привязки рабочих нагрузок, Secure Link, политики и историю резервного копирования и проверяет, что на целевой ноде свободно не меньше 1,2 объёма данных и работает актуальный демон. Он останавливается, если кластер использует FTP или SFTP: в SeaweedFS их нет.
2. Создание цели. Ассистент создаёт кластер SeaweedFS, по умолчанию приватный. По запросу он использует корневые учётные данные MinIO, чтобы клиенты с ними продолжили работать.
3. Копирование без остановки. Задание копирования копирует все бакеты, пока приложения продолжают писать в MinIO. Пока клиенты пишут, отчёт может показывать различия, поэтому копирование повторяется, пока не будут различаться только недавние объекты; каждый запуск передаёт только изменения.
4. Переключение. Запись ненадолго приостанавливается; чтение продолжает работать.
   • Сначала резервное копирование: политики резервного копирования, которые пишут в кластер MinIO, переводятся на новый кластер или по вашему желанию приостанавливаются, а выполняющиеся резервное копирование и восстановление с этим кластером должны завершиться или быть отменены.
   • Заморозка записи: все ключи доступа и ключи привязок рабочих нагрузок, выданные Opfield в кластере MinIO, становятся доступными только для чтения, включая ключи, выданные во время заморозки. Opfield тоже перестаёт писать в кластер: отправка, удаление и изменение бакетов через обозреватель объектов, инструменты хранилищ и MCP завершаются ошибкой STORAGE_WRITES_FROZEN, а резервное копирование и восстановление, которые записывали бы в кластер, отклоняются. Заморозка отклоняется, пока выполняется резервное копирование или восстановление с этим кластером. Корневые учётные данные и задания копирования продолжают писать, поэтому копирование не прерывается. Ключи, выданные не через Opfield, перечисляются, чтобы вы остановили этих клиентов. Страница хранилища показывает, что запись приостановлена.
   • Завершающий проход: задание копирования в режиме sync выполняется, пока отчёт не станет чистым. До этого ничего не переключается.
   • Импорт ключей доступа: ключи доступа создаются в SeaweedFS с тем же идентификатором и секретом, поэтому их клиентам нужно сменить только адрес. Ключи с ограниченным сроком действия и идентификаторы, которые SeaweedFS не принимает, перечисляются для замены.
   • Перенос привязок рабочих нагрузок: каждая привязка переходит на новый кластер с тем же ключом, псевдонимом и переменными среды. Рабочая нагрузка не пересоздаётся: меняется только её приватный маршрут, а коннектор заменяется, если кластеры различаются по TLS. Все бакеты привязки должны существовать в новом кластере, иначе перенос отклоняется с кодом MANAGED_STORAGE_BINDING_BUCKETS_MISSING. Неудачный перенос откатывается, и привязка остаётся на MinIO; если вернуть её не удаётся, она остаётся на новом кластере, помечается как неисправная, и ассистент сообщает об этом.
   • Перенаправление Secure Link: привязки Secure Link из Route переключаются на новый кластер и сохраняют идентификатор и имя, поэтому использующие их конфигурации Route продолжают работать. Если новый кластер не отвечает или конфигурацию Route не удаётся применить, восстанавливается прежняя цель.
   • Проверка резервного копирования: для каждой перенесённой политики выполняется одно резервное копирование, а приостановленные политики после переноса снова включаются.
5. Проверка и вывод из эксплуатации. После того как вы подтвердите, что приложения работают, ассистент переносит завершённую историю резервного копирования в SeaweedFS. Переносятся только запуски, все файлы которых найдены там с записанными размерами; остальные остаются на MinIO и перечисляются, и перед удалением MinIO их нужно скопировать заново или забыть. Затем ассистент удаляет кластер MinIO, а опубликованный порт S3 можно перенести на новый кластер.

Пока MinIO не удалён, ассистент может откатить миграцию: заморозить новый кластер, скопировать обратно в MinIO записанное после переключения в режиме sync, пока отчёт не станет чистым, вернуть привязки, Secure Link и политики резервного копирования и разморозить MinIO. Ключи доступа MinIO, созданные до того, как Opfield стал назначать политику каждому ключу, имели полный доступ корневого пользователя; после заморозки и снятия заморозки у них остаётся только чтение и запись в своих бакетах.

Во время миграции никогда не перезапускайте и не обновляйте кластер MinIO, не повторяйте его создание и не меняйте его публикацию: каждое из этих действий пересоздаёт контейнер, а образ может быть уже недоступен для загрузки. Права storage:* уровня ресурса и размещение в папке не копируются на новый кластер — выдайте их заново. Версионирование бакетов, правила жизненного цикла и политики бакетов тоже не копируются.

Действия миграции

Чтобы выполнить миграцию без ассистента, вызывайте те же действия через REST API или MCP в указанном выше порядке. Действия управляемого хранилища принимают идентификаторы управляемых хранилищ, а задания копирования — идентификаторы подключений к хранилищам.

Шаг	REST API	MCP и ассистент	Право
Копирование данных	POST /api/storage/copy-jobs	copy_data_start инструмента manage_storage_connection	См. «Копирование данных между хранилищами»
Заморозка записи	POST /api/managed-storage/{id}/freeze-writes	freeze_writes инструмента manage_managed_storage	storage:iam
Снятие заморозки	POST /api/managed-storage/{id}/unfreeze-writes	unfreeze_writes	storage:iam; разрешено и после окончания льготного периода лицензии
Импорт ключей доступа	POST /api/managed-storage/{targetId}/iam-keys/import с sourceStorageId и необязательным keyIds	import_access_keys	storage:iam для обоих кластеров
Перенос привязки рабочей нагрузки	POST /api/managed-storage/{id}/bindings/{bindingId}/move с targetStorageId	move_binding	storage:iam для обоих кластеров и права на рабочую нагрузку, нужные для создания привязки
Перенаправление Secure Link	POST /api/proxy-hosts/{routeId}/additional-secure-links/{bindingId}/retarget с upstreamKind: "managed_storage" и managedStorageId	retarget инструмента manage_additional_secure_link	proxy:edit для Route и storage:view для нового кластера
Перенос истории резервного копирования	POST /api/managed-storage/{id}/backup-history/rehome с targetStorageId и необязательным dryRun	rehome_backup_history	storage:edit для обоих кластеров

Для заморозки записи нужен актуальный демон на ноде хранилища кластера MinIO; обновление демона не пересоздаёт контейнер MinIO. Сначала перенесите или приостановите политики резервного копирования, которые пишут в кластер: заморозка отклоняется, пока выполняется резервное копирование или восстановление с этим кластером, а её результат сообщает о политиках, которые ещё его используют. Частичная заморозка возвращает ошибку и оставляет кластер замороженным; запустите её снова, чтобы применить оставшиеся ключи. Перенос истории резервного копирования отклоняется, пока выполняются запуски резервного копирования, и никогда не меняет политики. Действиям нужен действующий тариф Personal или выше, кроме снятия заморозки, чтобы заморозку всегда можно было снять. Каждое действие записывается в журнал аудита.

Удаление хранилища, на которое ссылаются резервные копии

Политики резервного копирования и активные запуски всегда блокируют удаление подключения к хранилищу или управляемого хранилища: удалите или перенесите политики и дождитесь завершения запусков. Если на хранилище ссылается только завершённая история резервного копирования, удаление отклоняется с кодом STORAGE_BACKUP_HISTORY_EXISTS (409), пока вы не подтвердите Forget history and delete. Забытая история удаляется из Opfield, поэтому эти резервные копии больше нельзя восстановить или удалить из Opfield, а журнал аудита фиксирует, где находятся их файлы. Файлы подключённого хранилища остаются в его бакетах; файлы в управляемом хранилище стираются вместе с ним.

Через API передайте backupHistory=forget в DELETE /api/object-storage/{id} или DELETE /api/managed-storage/{id}. Инструменты хранилищ в AI Workspace и MCP принимают то же подтверждение в config.backupHistory. Чтобы сначала удалить отдельные резервные копии вместе с файлами, используйте историю резервного копирования.

Права доступа

Скоуп	Что разрешает
storage:view	Просмотр подключений, управляемых хранилищ, ключей доступа и привязок
storage:create	Создание подключений и управляемых хранилищ
storage:edit	Изменение настроек, перезапуск и повтор создания
storage:delete	Удаление подключений и управляемых хранилищ
storage:credentials:reveal	Раскрытие сохранённых учётных данных; включает storage:credentials:use
storage:credentials:use	Использование сохранённых учётных данных резервным копированием баз данных и заданиями копирования без их раскрытия
storage:iam	Создание, отзыв и импорт ключей доступа, заморозка и снятие заморозки записи, создание и перенос привязок рабочих нагрузок
storage:objects:read	Просмотр и скачивание объектов и создание предварительно подписанных ссылок на скачивание
storage:objects:write	Отправка объектов, создание префиксов и удаление объектов
storage:objects:admin	Создание и удаление бакетов
storage:folders:manage	Упорядочивание папок хранилищ

Скоупы можно ограничить одним хранилищем или папкой. Резервному копированию баз данных нужен только storage:credentials:use для места назначения, без доступа к объектам. См. справочник скоупов.

Границы эксплуатации

• Для хранилищ нужен тариф Personal или выше; для регистрации ноды хранилища он не нужен. См. Планы и права по тарифу.
• Ноды хранилища запускают управляемые базы данных, управляемые хранилища и задания резервного копирования; обычные контейнеры приложений и сборки выполняются на нодах Docker и Build Workers. См. роли нод.
• Управляемое хранилище находится на одном хосте. Храните резервные копии и другие важные копии вне его зоны отказа.
• Шифрование, сроки хранения и правила доступа на стороне места назначения настраивайте в той системе хранения, где находятся данные.