Quotas & Limits: Timing & Retry
Session timeout values you can plan around, plus an overview of how BYOVault handles timeouts and retries during backup, restore, and key operations.
Session and token timing
See Authentication & Session Security for the full mechanism. The values themselves:
| Property | Value |
|---|---|
| Operator JWT absolute expiry | 480 minutes (8 hours) from issuance, fixed |
| Operator session idle timeout | Configurable per account, 5–120 minutes (default 30) |
| End-user (self-service portal) session idle timeout | Fixed at 30 minutes — not configurable in the current release |
Microsoft Graph HTTP client
Backup and restore against SharePoint, OneDrive, and Exchange all go through Microsoft Graph.
Requests that are throttled or time out are retried automatically with backoff. A request that keeps failing after retrying fails outright rather than retrying indefinitely, and that failure is then handled by the same step-level retry behavior described below.
BYOK wrap/unwrap RPC
See Customer-Managed Keys (BYOK) for what this call does. When a tenant has an active BYOK configuration, BYOVault calls out once per file to wrap or unwrap that file’s randomly generated File Key under the customer’s own KMS or Key Vault key.
KMS availability (AWS)
BYOK on AWS KMS routes every wrap, unwrap, and health-check call through BYOVault’s own AWS-hosted infrastructure with no internal retry loop.
An unreachable key or an unhealthy customer key surfaces immediately as an error, not a delayed one after retrying.
File server agent (Windows)
See File Servers for the workload itself.
The agent’s ordinary calls — polling for jobs, reporting status, checking for updates — use a standard timeout. Restore file downloads are given a longer allowance to account for large transfers.
Uploads and status reports that fail due to a transient network error are retried automatically with backoff.
Backup and restore step retries
Every step of a backup or restore job — each drive, mailbox folder, or file — runs independently and retries automatically with backoff before being recorded as failed.
A step that exhausts its retries does not fail the entire job: the specific drive or folder is recorded as failed and the rest of the batch continues. The job’s final status (completed, partial, or failed) is computed once every drive and folder in the tenant has been attempted.
Tenant-workload locking
Before a backup job starts, BYOVault acquires a lock for that tenant’s workload so the same workload can’t be backed up concurrently by two overlapping jobs.
If the process holding the lock crashes before releasing it, the lock does not wedge that tenant’s workload indefinitely — it self-expires and the workload becomes available again.