How BYOVault Works

Two ways a backup job starts

Every Microsoft 365 backup job begins one of two ways: you click Backup Now in the dashboard, or a schedule’s configured time arrives.

Both paths converge on the same backup engine. Once a run is underway there is no difference between a manual and a scheduled job — both go through the identical steps described below, and both support the same pause, cancel, and retry behavior.

• Manual runs can be scoped to a subset of your Microsoft 365 workloads (SharePoint, OneDrive, Exchange) instead of all of them. BYOVault prevents duplicate runs from being started for the same tenant and workload at the same time.
• Scheduled runs fire on the cron you configure for them. Independent schedules (for example, a SharePoint schedule and a separate Exchange schedule) can run at the same time as each other without conflict. If a scheduled run is still in progress when its next scheduled time arrives, that tick is skipped rather than queuing a second overlapping run.
• File-server sources work differently: a scheduled run for a file server is picked up by the on-prem agent installed on your network, rather than running through BYOVault’s cloud backup engine directly. See File Servers for how the agent itself operates.

Inside a backup run

Once started, a backup run works through a sequence of steps, retrying automatically if an individual step fails:

• Start the job. BYOVault confirms the job is not a duplicate of one already running or already finished, then marks it as running.
• Authenticate. BYOVault obtains a Microsoft Graph access token for the tenant’s connected Entra app registration.
• Enumerate resources. BYOVault calls Graph to list the tenant’s SharePoint sites and mailboxes, then narrows that list to whatever the tenant’s configured backup scope (or the job’s own workload selection) actually includes.
• List drives and folders. For every in-scope site, OneDrive, and mailbox, BYOVault builds the full list of drives and mail folders that need to be backed up, independently for each requested workload — selecting OneDrive alone, for example, does not pull in SharePoint sites as a side effect.
• Back up each drive or folder. Each drive and each mail folder is processed on its own, with a bounded number of them in flight at once, described in detail below.
• Finish the job. Once every drive and folder has been attempted, the job is marked one of three ways:
  • Completed — everything succeeded.
  • Partial — some items failed after exhausting their own retries, while others succeeded and at least some data was actually transferred.
  • Failed — every single item failed.
  A best-effort retention pass then runs; a failure there is logged but does not change the backup job’s own final status.

A large tenant’s full drive-and-folder list is processed in bounded batches rather than all at once, so that a very large backlog cannot grow without bound within a single run.

What happens to a single file

Detecting what changed

Per-drive backup work only looks at what changed: for each drive, BYOVault asks Graph for the items that changed since that drive’s last successful run (or does a full scan, the first time).

For each changed file, BYOVault first checks whether a file matching that exact item, size, and last-modified timestamp was already confirmed uploaded in an earlier attempt. This makes an interrupted run (a pause, a cancel, a restart) resume cheaply instead of re-uploading content that already made it to storage. Exchange mailbox folders follow the same changed-items, skip-if-already-uploaded approach, one message at a time instead of one file at a time.

Streaming, compression, and encryption

For a file that does need uploading, content is downloaded from Graph in chunks rather than loaded into memory whole, so a single large file does not dictate BYOVault’s memory footprint. Content is compressed before encryption, and both happen incrementally as the file streams through — this is what keeps memory usage constant regardless of file size.

Encryption uses AES-256-GCM. Compressed, encrypted bytes are written to your Azure Blob container or S3 bucket as they are produced, and BYOVault’s own infrastructure holds the encryption key material and the resulting catalog entry, not a second copy of the file content itself.

Exchange messages follow the same compress-then-encrypt sequence but as a single unit rather than a chunked stream, since a message is read from Graph in one piece.

Verifying and cataloging the upload

Once a file’s upload finishes, BYOVault cross-checks the number of bytes actually downloaded from Graph against the file size Graph itself reported for that item. This means a connection that drops mid-download without raising an error cannot be silently recorded as a successful upload of a truncated file.

On success, BYOVault records that the file was uploaded successfully, for the skip-if-unchanged check described above, and records catalog details in BYOVault’s own catalog:

• Filename and folder path
• Size
• A content hash
• The location the encrypted data was written to in your storage account

That catalog entry — not a re-scan of your storage account — is what later powers version history and restore.

Progress, pause, and cancel

As each batch of files finishes, the job’s progress counters and current-file indicator are updated. BYOVault checks for a pending pause or cancel request once per completed drive or folder.

A cancelled job stops without further changes. A paused job stops cleanly and can be resumed later, at which point it picks up wherever it left off, based on what had already been confirmed uploaded.

For the workload-specific detail this page does not cover, see the following pages:

• What is and is not captured for each workload, and how change detection actually decides a file has changed — Workloads and Incremental Backup & Change Detection
• How the on-prem file-server agent’s own path differs from the Microsoft 365 flow above — File Servers
• How encryption keys are derived and held — Encryption Algorithm and Key Derivation & Hierarchy