Data Residency & Data Flow

Backup: Microsoft Graph or agent, into your storage

Microsoft 365 backup

A Microsoft 365 backup (SharePoint, OneDrive, or Exchange) is handled by BYOVault’s backup service. For each file, the service downloads content from Microsoft Graph, compresses and encrypts it as it arrives, and streams the resulting ciphertext directly into your storage account. Download and upload run concurrently: the file is never accumulated in full in memory or on disk before the upload begins.

Nothing written to BYOVault’s database by this process carries file content — only the resulting storage path, a ciphertext checksum, and size.

File server backup

A file server backup follows the equivalent shape through a different path. BYOVault’s own agent, installed on your machine, reads the file, and BYOVault’s API receives it in chunks. Each chunk is compressed and encrypted independently as it is read, streaming the resulting ciphertext directly to your storage account — the plaintext file is never buffered in full on BYOVault’s side.

What this means for your data

In both cases the content genuinely transits BYOVault’s own compute — it has to, since encryption happens there — but it is held only for the moment it is being compressed, encrypted, and forwarded. Nothing about a backup operation writes your file content to any BYOVault-controlled database, cache, or disk that persists after the request completes.

Download/restore: the one synchronous, in-process path

Downloading a backed-up file is the single restore path that runs synchronously, inside BYOVault’s API itself. That request follows a fixed sequence:

• BYOVault resolves which storage account currently holds the requested file (primary, or a retention vault if the file has already been archived).
• It fetches the ciphertext into memory and decrypts it there.
• It verifies the result against the recorded checksum and decompresses it.
• It streams the plaintext back to the browser in the same HTTP response.

Nothing is written to durable storage along the way — the decrypted bytes exist only for the duration of that one request, then are returned directly to the requester.

In-place restore — injecting a file back into a SharePoint/OneDrive drive or an Exchange mailbox — does not follow this synchronous path. It runs as a background job that performs its own download-decrypt-reupload-to-Graph sequence; the operator or end user checks job status rather than receiving content directly.

See Download a File and In-Place Restore: SharePoint & OneDrive for the request-level detail of each.

Retention vault moves, same cloud provider: account-to-account, never through BYOVault

When a tenant’s primary storage and its retention vault are on the same cloud provider, the scheduled archiving sweep moves a file’s bytes directly from the primary account to the vault account using that provider’s own server-side copy capability.

Zero file-content bytes transit BYOVault’s own servers for this move — BYOVault only issues the copy instruction and later verifies the result by comparing metadata (size and checksum, where available), never by re-downloading the file itself.

The exact mechanism differs by provider:

• AWS S3: authorization is a scoped grant, added once at the moment the vault is locked, giving the vault account read access to the primary bucket — any existing permissions on your bucket are left untouched. The vault account then copies each file directly, authenticated as itself, with no per-file token minted at all.
• Azure Blob: there is no standing grant. Each individual file copy is authorized by a short-lived, read-only authorization token scoped to that one file, minted fresh at copy time. The vault account uses that token to copy the file directly from the primary account; BYOVault polls the copy status until Azure reports success. The token is not reusable and is never stored.

On AWS, if the scoped grant is missing, revoked, or otherwise denied, the move falls back to the cross-provider path below for that file rather than failing outright.

Either way, the original file in primary storage is deleted only after the copy in the vault has been independently verified. A failure at any earlier step leaves the primary original untouched and the file eligible to be retried on a future sweep.

Retention vault moves, different cloud providers: through BYOVault’s own servers

When primary storage and the retention vault are on different cloud providers — for example, primary on Azure Blob and the vault on AWS S3, or the reverse — no server-side, account-to-account copy capability exists between the two providers.

Instead, BYOVault itself performs a download-verify-delete sequence:

• Downloads the ciphertext (and its manifest sidecar, for files split into multiple encrypted blocks) from the primary account.
• Writes it to the vault account.
• Reads it back from the vault to verify it is byte-for-byte correct.
• Only then deletes the original from primary.

This is the same sequence the same-provider path falls back to when its own grant is unavailable.

Summary

For how your storage credentials are held to make any of this possible, see Storage Credentials. For the archiving schedule that triggers vault moves, see Archiving.