Выполнение backup в v1 строится как поток:
source stream -> (compression/checksum) -> destination put -> manifest
Практически это означает:
io.Reader;stream — строгий streaming (без полного локального
artifact-файла).file — допускается локальный staging.directory — source может выдавать директорию, затем она
должна быть передана/упакована.auto — сначала streaming, fallback только если явно
разрешен staging.По умолчанию:
artifact.mode = autoartifact.staging.enabled = falseТо есть фактически default-путь — streaming-first и ошибка при невозможности стриминга.
Для s3 destination upload выполняется через
aws CLI, передавая поток в stdin:
aws s3 cp - s3://bucket/prefix/object
Runner для upload выбирается в YAML:
destination.config.upload.runner.mode: local (по
умолчанию)destination.config.upload.runner.mode: dockerЭто сделано для совместимости с S3-совместимыми backend-ами, где
прямой SDK upload может давать ошибки подписи, и для хостов без локально
установленного aws CLI.
При artifact.staging.enabled: true (и режимах, где
операция действительно буферизует) промежуточные данные попадают в
каталог временных/run-директорий агента (см.
docs/operator/runbook.md,
examples/iobackup-agent.env.example). Конкретный путь
задаёт эксплуатация; в roadmap v0.17.x планируется явный лимит размера и
политика при ENOSPC.
Временные файлы должны очищаться после успеха, ошибки или отмены задачи — детали реализации по провайдеру см. в коде операции backup.
contextПо отмене context закрываются reader/writer, внешним
командам (pg_dump, aws, ssh и
др.) передаётся сигнал завершения там, где это поддержано runner’ом.
Итоговый статус task/run фиксируется оркестратором (константы в
internal/storage/models.go; полная state-machine — backlog
docs/roadmap0.17-0.18.md §6).
Централизованная матрица «streaming vs staging-required» входит в
план backlog §11. Оценочный статус компонентов:
docs/internal/roadmap/status-matrix.md.