Retention policy

retention в iobackup работает по metadata/manifests, а не по glob-поиску файлов. При удалении backup retention удаляет не только manifest, но и физические объекты в destination (artifact + sidecar manifest-файл, если поддерживается provider-ом).

Почему это важно

• политика привязана к фактическим успешным backup run-ам;
• корректно работает без встроенного scheduler;
• учитывает реальную историю в bbolt.

Пример правил

В job можно описывать правила вида:

• keep_last_days
• keep_weekdays
• keep_month_days
• keep_last_successful

Backup удаляется только если он не попадает ни под одно правило.

Что хранится для retention

• manifest записи;
• время создания backup;
• статус backup;
• связи с job/task/run.

Это позволяет применять policy одинаково для local и S3 destination.

Аудит retention

Каждое действие retention логируется в agent log как retention cleanup event:

• backup_id, job_id, task_id
• destination_type
• artifact_path
• status (deleted, artifact_delete_failed, manifest_delete_failed)
• error (если есть)

Также события доступны через API:

curl -sS "http://127.0.0.1:8735/api/v1/retention/events"
curl -sS "http://127.0.0.1:8735/api/v1/retention/events?job_id=<job_id>"
curl -sS "http://127.0.0.1:8735/api/v1/retention/events?status=deleted"

Retention артефактов vs metadata retention

• Retention backup (политика в job) — удаляет артефакты и связанные объекты в destination по правилам keep_*, плюс записи в metadata, на которые ссылается политика (manifest/sidecar в пределах поддержки провайдера).
• metadata_retention / per-type дни — отдельная эксплуатационная политика для истории в bolt (runs, logs, events, revisions, …). В 0.17-fix.60 модель foundation: per-type лимиты задаются в конфиге агента, но отдельный worker, который агрессивно чистит каждый тип по своим дням, может быть неполным — уточняйте по коду и docs/architecture/metadata.md; не ожидайте, что «все типы уже подчищены автоматически как в финальном дизайне».

Sidecar manifest lifecycle

При успешном backup рядом с data-объектом создаётся sidecar (role=manifest в artifacts[]). При удалении по retention или явном delete агент старается удалить оба объекта. Если sidecar отсутствует (ручное вмешательство, сбой провайдера), rebuild метаданных из object storage будет неполным — опирайтесь на запись в bolt и резервные копии metadata DB.

Safety gaps (планируется ~0.18.4)

Следующее поведение в roadmap / hardening, не полагайтесь на него в текущей версии как на гарантию:

• dry-run retention по умолчанию для prod destructive путей;
• запрет удаления последнего успешного backup без явного флага;
• orphan deletion guard;
• edge cases S3/SSH lifecycle и согласованность версий объектов.

См. также

• Retention behavior — поля YAML (enabled, dry_run, алиасы keep_days / keep_last), dry-run audit.