Direct answer: Microsoft Graph delta is a state-synchronization mechanism, not an audit log, backup, or version-history feed. It can make incremental capture efficient only when the implementation completes every page, treats links as opaque, handles replays and resets, reconciles periodically, and stores recoverable snapshot content separately.
For SharePoint document libraries and OneDrive, the documented route is GET /drives/{drive-id}/root/delta. The first round enumerates the current hierarchy across one or more pages. Each page returns an @odata.nextLink until the round completes with an @odata.deltaLink. Persist and call the entire returned URL; do not extract, decode, or construct the token. Microsoft's driveItem delta reference is the source of truth.
Capture and Recovery Implication Matrix
| Resource | Documented delta scope | Capture implication | Recovery implication |
|---|---|---|---|
| SharePoint or OneDrive drive items | /drives/{drive-id}/root/delta and equivalent site/user forms | Latest state per item; deleted facet; parent and rename handling by stable ID | Content, metadata, hierarchy, permissions, and versions still need explicit snapshot and restore designs |
| SharePoint list items | /sites/{site-id}/lists/{list-id}/items/delta | Separate synchronization from document-library drives; test fields, attachments, and deletions | List-item capture does not prove list schema or attachment restore |
| Exchange messages | Delta is scoped to a mail folder, not one tenant-wide message feed | Discover folders and maintain state per folder | Folder relationships and item fidelity require separate restore proof |
| Teams chats | /users/{id}/chats/getAllMessages/delta | Current API returns messages from chats involving the user; delta only returns messages within the last eight months | Eight months is a retrieval horizon, not a documented token lifetime or restore capability |
| Teams channel messages | Use the currently documented channel-message APIs and change mechanisms for the selected API version | Do not assume the chat delta route or an undocumented per-channel delta route applies | Captured messages still need a supported restore or export path |
| Resources without delta support | Full enumeration or another documented change mechanism | Track paging, watermarks where valid, and periodic reconciliation | Enumeration can capture state but does not create a restore handler |
The list-item route is documented separately in Microsoft's listItem delta reference. The current Teams chat route and eight-month result horizon are documented in chats-getAllMessages delta. Do not translate that horizon into a claim that a token remains valid for eight months.
Correct Drive Delta Procedure
- Discover scope: enumerate sites and every drive or document library that the backup policy includes. Delta is drive-scoped.
- Start a round: call the documented delta route with the approved query and headers. Store the request configuration with the job.
- Drain every page: follow each
@odata.nextLink. A crash after page three must not make page four look complete. - Stage by stable ID: the same item can appear more than once. Apply the last occurrence, process deleted facets, and do not depend on a returned path for every parent or rename.
- Capture content separately: a changed driveItem indicates state to process. Download and verify content when the snapshot requires it. Delta is not historical file-version capture.
- Commit atomically: publish the new snapshot and its final
@odata.deltaLinkonly after all pages and required content are durable. - Resume with the whole link: replay the stored deltaLink for the next round and remain tolerant of repeated changes.
- Reconcile: schedule a full inventory comparison to detect scope changes, missed drives, permission gaps, or implementation defects.
Permissions Need Their Own Design
A normal driveItem response does not prove a complete permission snapshot. Microsoft documents special preference headers for permission-change scanning, an annotation for sharing changes, and elevated permission requirements for correctly processing that scanning scenario. Fetching the item's permissions can still be necessary. Treat this as a security architecture decision: document why the application needs each permission, then test direct grants, sharing links, inheritance, removals, and inaccessible identities.
Permission capture and permission restore are separate. A backup can accurately record a grant and still lack a safe way to recreate it. The SharePoint backup guide contains the workload-level acceptance matrix.
Resets, Throttling, and Partial Failure
Do not publish a universal 30-day drive token lifetime. Microsoft documents fixed token limits for some resources, cache-dependent limits for others, and reset conditions caused by expiry, maintenance, or migration. A delta request can return 410 Gone with a Location header containing the URL for resynchronization. Follow the documented response rather than constructing a replacement token. Microsoft's delta query overview covers replays, resets, and token duration.
For 429 Too Many Requests, honor Retry-After. Keep item-level failures visible, bound retries, and prevent one poison item from silently advancing a checkpoint. A completed job must mean every required page and item is either durable or explicitly failed.
Seeded Engineering Pilot
- Create, edit repeatedly, rename, move, and delete drive items between two delta rounds. Compare final state by ID.
- Rename a parent folder and prove descendant paths remain reconstructable without assuming all descendants reappear.
- Change and remove direct permissions and sharing links; verify the selected headers, permission endpoint, and reconciliation behavior.
- Terminate a worker after an intermediate page and after content download but before checkpoint commit. Prove a retry is idempotent.
- Inject a documented reset response in the test harness and prove the service follows the resync URL without deleting retained historical snapshots.
- Inject 429, 5xx, timeout, duplicate item, and poison-item responses; verify observability and final job state.
- Restore items from snapshots before and after the changes. Delta correctness passes only when the stored state is recoverable.
Pass/Fail Evidence Checklist
- Record resource ID, request route, API version, headers, page count, item count, and checkpoint transaction.
- Retain redacted nextLink/deltaLink fingerprints, reset count, reconciliation count, retry count, and item-level errors.
- Compare source and snapshot IDs, parent IDs, deletion state, content hashes, metadata, permissions, and timestamps.
- Prove crash recovery, replay handling, reset handling, throttling, and full reconciliation with repeatable test cases.
- Fail if a checkpoint advances past an unrecorded page, required content failure, or unresolved scope change.
- Fail the product requirement if captured state cannot be restored to the required destination and fidelity.
North Brook Vault Fit and No-Fit Boundaries
North Brook Vault uses Graph delta processing for selected handlers and full enumeration where delta is not supported. This page does not claim that every handler uses delta or that delta eliminates throttling. The service should be evaluated through job history, item errors, snapshot state, and representative restore tests.
It is a no-fit where the requirement is a complete event log, continuous capture, every intermediate file state, or automatic restore for every captured object. For the distinction between general Graph capture and Microsoft's Backup Storage APIs, see the Microsoft 365 Backup API guide.
Review Graph-based backup coverage Discuss a Graph recovery consultation Review managed-service pricing