Skip to content

Audit-Based Delta Sync

Audit-based delta sync uses source-provider activity records to plan a smaller set of changes after a job already has a successful full-tree baseline.

When you will see it

The audit-based delta controls are relevant only when the selected source Storage Repository and job configuration support them. They are shown for supported cloud or business sources and hidden for local-source jobs.

When the feature is not enabled, the detailed controls stay out of the normal path.

What operators should expect

  • the setting is job-specific
  • support depends on the source provider, account type, and authentication context
  • the first live run after enabling still needs a successful full-tree baseline when no trusted baseline exists
  • provider cursor or watermark state controls the next audit window; it is not simply the last run start time
  • repeated provider records are reconciled into the final target-side effect where possible
  • some changes may still become scoped fallback syncs when the provider signal is incomplete or unsafe

Enable audit-based delta sync only when:

  • the source provider supports it for your setup
  • you understand the account context used by the Storage Repository
  • a full-tree baseline has completed successfully
  • you still have a fallback plan for full validation when needed

Baseline and cursor behavior

Audit-based delta sync separates two concepts:

  • the provider cursor or watermark, which says where provider activity ingestion should continue
  • the successful applied boundary, which says which source changes have already been applied safely to the target

This means a run may read provider activity using a cursor while planning only the actions that are newer than the last trusted applied boundary. The run detail page shows this planning context so you can tell whether a run used a baseline boundary, a prior successful delta boundary, or a provider bootstrap window.

Run visibility

Delta runs still appear in job history and run detail. Review:

  • normalized source activity
  • planned target actions
  • fallback sync scopes
  • execution feedback from the runner
  • failed action details and recovery scopes

If a delta run reports fallback scopes, that does not always mean the job is unsafe. It means the planner chose a more conservative scoped sync for a specific area instead of replaying individual actions.

When to run a scan or full validation

Use a scan or ordinary full-tree validation when:

  • provider activity is delayed or incomplete
  • a cursor requires reset
  • there were many out-of-band changes
  • a delta run used broad fallback scopes
  • you changed filters, source paths, or target paths

See also