Backup Schedule Design

A tenant can have more than one schedule

Each schedule belongs to a tenant and carries its own name, its own cron expression and time zone, and its own workload set (any combination of SharePoint, OneDrive, Exchange, and file server sources). Nothing requires a tenant’s workloads to share a single schedule.

A common pattern is one schedule named something like “SharePoint & OneDrive” that fires in the morning, and a second, separate schedule named “Exchange” that fires at night, both against the same tenant.

Why two schedules on the same tenant do not collide

Before a scheduled dispatch starts a backup run for a workload, a per-workload lock prevents duplicate runs on that same (tenant, workload) pair — not a single lock for the whole tenant.

The lock also automatically expires if a run is interrupted, so a crash never leaves a workload stuck and unable to run again.

Because the lock is per workload rather than per tenant, a schedule covering SharePoint and OneDrive and a second schedule covering Exchange can fire and run at the same time, for the same tenant, without either one waiting on the other.

A dispatch only skips its tick if a workload it needs is already locked or already has an active job — and that check only ever looks at the specific workloads the firing schedule names, not at every workload the tenant has anywhere.

Fire times are staggered automatically, not literally at the time you pick

BYOVault automatically staggers schedule start times across accounts to avoid contention, so your backup may start a few minutes after the time shown — this is expected. The time shown and edited in the dashboard is the cron time you set; the time the schedule actually fires may be slightly later.

This exists to avoid a thundering herd: without it, every tenant defaulted to the same nightly cron expression would attempt to start at the identical instant, all contending for the same downstream Microsoft Graph throughput at once. Spreading schedules out means this contention is avoided by construction rather than by a client having to hand-pick an off-hour time to avoid other tenants.

When to split a workload onto its own schedule

The practical reason to use more than one schedule on a tenant is size, not just a preference for organizing things by workload type. A single schedule’s workloads all run together, so a workload that takes disproportionately long extends how long that entire run takes.

The common case: a large Exchange organization

A very large Exchange organization is the common case, since mailbox content is fetched and stored per message rather than in bulk. Bundling that workload into the same nightly schedule as smaller, fast-finishing workloads means those smaller workloads finish only when the large one does, even though nothing about them individually is slow.

Decoupling with a separate schedule

Putting the large workload on its own schedule, at its own time, decouples the two: the fast workloads’ schedule completes on its own timeline, and the large workload’s schedule can be given a start time and cadence suited to how long it actually takes, without either one blocking or slowing the other.

Because the (tenant, workload) lock and the dispatch duplicate-check are both scoped to the specific workloads a schedule names, running the large workload on a separate schedule does not introduce any coordination burden beyond creating the second schedule itself.

Practical guidance

• Group workloads onto one schedule when they are all similarly sized and there is no reason to treat them differently — a single combined schedule is simpler to review and audit than several near-identical ones.
• Split out a workload onto its own schedule once it is large enough that its run time is visibly longer than the tenant’s other workloads, so a slow run stops determining when everything else reports done.
• Do not attempt to avoid overlap manually by picking distant cron times for schedules on the same tenant — the per-workload lock already makes concurrent schedules on disjoint workloads safe, and the automatic stagger already accounts for contention across tenants.

See Workloads for what each workload actually backs up, and Incremental Backup & Change Detection for how a schedule’s run avoids re-transferring content that has not changed since its last run.