Verify pipeline (PR-3)

Структура результата проверки и коды (reason): verify-behavior.md.

verify в iobackup проверяет восстановляемость артефакта: агент читает объект из destination, пересчитывает checksum и сравнивает с manifest.

Это отдельный шаг после backup, который подтверждает, что артефакт можно реально прочитать и его содержимое не повреждено.

Verify vs metadata check vs future validation

Механизм	Что проверяет
`POST …/artifacts/{backup_id}/verify`	Читает объект в destination, сверяет checksum/size с манифестом.
`iobackupctl metadata check` / `POST …/metadata/check`	Только bolt: схема, bucket’ы, индексы; не скачивает artifacts из S3/SSH.
Future validation worker (roadmap)	Формат контейнера, unpack, `restore_smoke` — сейчас в манифесте поля `checks` / `restore` в основном placeholder.

См. также docs/architecture/metadata.md, docs/reference/manifest-schema.md.

Автоматический verify после run (policy)

В job YAML можно включить авто-проверку:

spec:
  policies:
    verify:
      after_run: true
      limit_per_task: 1

Тогда после завершения backup-run (если есть успешные task) агент автоматически запускает async verify-run.

API

Запустить проверку:

curl -sS -X POST \
  -H "Authorization: Bearer $IOBACKUP_API_TOKEN" \
  "http://127.0.0.1:8735/api/v1/artifacts/<backup_id>/verify"

Запустить async verify по job (последние успешные backup по каждой task):

curl -sS -X POST \
  -H "Authorization: Bearer $IOBACKUP_API_TOKEN" \
  "http://127.0.0.1:8735/api/v1/jobs/<job_id>/verify?limit_per_task=1"

Ответ: 202 Accepted + verify_run_id.

Ответ содержит объект verification_result:

verification_id
backup_id, job_id, task_id, run_id
expected_checksum, actual_checksum, checksum_algorithm
expected_size_bytes, actual_size_bytes
status (success/failed)
error (если есть)
started_at, finished_at

История проверок:

curl -sS -H "Authorization: Bearer $IOBACKUP_API_TOKEN" \
  "http://127.0.0.1:8735/api/v1/verifications"

Статус verify-run:

curl -sS -H "Authorization: Bearer $IOBACKUP_API_TOKEN" \
  "http://127.0.0.1:8735/api/v1/job-verifications/<verify_run_id>"

Список verify-run:

curl -sS -H "Authorization: Bearer $IOBACKUP_API_TOKEN" \
  "http://127.0.0.1:8735/api/v1/job-verifications?job_id=<job_id>"

Фильтры:

backup_id
job_id
status

Пример:

curl -sS -H "Authorization: Bearer $IOBACKUP_API_TOKEN" \
  "http://127.0.0.1:8735/api/v1/verifications?job_id=filesystem-local&status=success"

CLI

go run ./cmd/iobackupctl --server http://127.0.0.1:8735 --token-env IOBACKUP_API_TOKEN artifact verify <backup_id>
go run ./cmd/iobackupctl --server http://127.0.0.1:8735 --token-env IOBACKUP_API_TOKEN job verify <job_id> --limit-per-task 1
go run ./cmd/iobackupctl --server http://127.0.0.1:8735 --token-env IOBACKUP_API_TOKEN verification list
go run ./cmd/iobackupctl --server http://127.0.0.1:8735 --token-env IOBACKUP_API_TOKEN verification get <verification_id>
go run ./cmd/iobackupctl --server http://127.0.0.1:8735 --token-env IOBACKUP_API_TOKEN verify-run list
go run ./cmd/iobackupctl --server http://127.0.0.1:8735 --token-env IOBACKUP_API_TOKEN verify-run get <verify_run_id>

Prometheus metrics

Добавлены метрики verify:

iobackup_verifications_total{destination_type,status}
iobackup_verification_duration_seconds{destination_type,status}

Что важно в эксплуатации

run.status=success не гарантирует восстановляемость; нужен периодический verify.
При failed проверяйте error, mismatch checksum/size и доступность destination.
Для retention policy рекомендуется периодически verify последних N backup перед hard-delete старых.