Direct answer: a SharePoint backup plan must inventory each required object and assign separate capture and restore paths. "Backs up SharePoint" is not a useful acceptance criterion because a site contains document libraries, files, folders, lists, list items, attachments, versions, pages, columns, content types, permissions, taxonomy, workflows, apps, and Teams-connected sites.
Jump to SharePoint list backup coverage and restore limits.
Use native tools when they meet the scenario. SharePoint recycle bins normally retain deleted items for 93 days from original deletion. File version history follows the configured organization, site, or library version policy. Files Restore can roll a document library back for activity in the previous 30 days; it is not a native full-site rollback. For a comparison with Microsoft 365 Backup and independent copies, start with the SharePoint recovery decision guide.
North Brook Vault SharePoint Coverage Matrix
| SharePoint object | Current capture statement | Current restore statement | Pilot requirement |
|---|---|---|---|
| Site | Registered site handler | No current claim of complete site creation or full-site rollback | Inventory identity, URL, owners, templates, and required site properties |
| List | Registered list handler | No current list-structure restore claim | Test schema, settings, views, attachments, and destination needs separately |
| List item | Registered item and list-item-version handlers | Current selective restore handler covers list items | Test fields, attachments, lookups, people fields, versions, IDs, and conflicts |
| Site drive and drive item | Captures current document-library drive items, content, and metadata through registered handlers | Current selective restore handler covers site drive items | Test files, folders, paths, metadata, permissions, destination, and conflicts |
| Historical document version | Not a separate current handler | No North Brook Vault historical file-version restore claim | Use native version history or another product if this is mandatory |
| Site page | Registered site-page handler | Current selective restore handler covers site pages | Test web parts, references, layout, assets, publication state, and target behavior |
| Content type or column | Registered handlers | No current restore claim | Determine whether capture-only evidence is useful or structural recreation is required |
| Term group | Registered handler | No current restore claim | Test taxonomy dependencies and document manual reconstruction steps |
| Permissions and other configuration | Coverage depends on the applicable object and Graph behavior | No universal permission or configuration restore claim | Test every required direct, inherited, link, group, and owner outcome |
The matrix deliberately does not convert a registered capture handler into a restore promise. North Brook Vault currently restores list items, site drive items, and site pages. Other captured objects can still support visibility or future workflows, but they do not satisfy a structural recovery requirement without a tested restore path.
SharePoint List Backup: Items, Attachments, Columns, and Restore Limits
A SharePoint list backup has at least two layers. The list container defines schema and behavior: columns, content types, views, formatting, validation, permissions, forms, rules, and integrations. List items contain field values and can also have attachments and version history. Selectively restoring an item does not recreate a deleted list or its dependencies.
When deciding how to backup SharePoint, separate native deleted-item recovery from backup restore. Recycle-bin recovery can return a recently deleted list or item within the applicable SharePoint window. A retained North Brook Vault list-item snapshot can support selective item restore where the current handler applies, but universal list reconstruction is not claimed. An alternate destination must already have a compatible list and dependencies unless a separately verified process creates them.
| List layer | Capture boundary | Selective restore boundary | Evidence required |
|---|---|---|---|
| List container and schema | Registered list handler; inventory template, settings, and schema | No universal list-structure restore claim | List ID, template, settings, schema export, and documented reconstruction owner |
| Columns and content types | Registered column and content-type handlers | No current restore claim | Internal names, types, required/unique rules, defaults, content-type bindings, and order |
| Views, formatting, forms, and rules | Do not assume coverage from list or item handlers | No universal restore claim | Classify each requirement as native/manual, separately protected, or unsupported |
| List permissions | Object and Graph behavior vary; inventory inheritance and unique access | No universal permission restore claim | Owners, groups, direct grants, inheritance, and post-restore access test |
| Item fields | Registered list-item handler; exact field types must be piloted | List items are selectively restorable | Text, number, choice, date, Boolean, person, lookup, hyperlink, and metadata comparisons |
| Attachments | Must be verified rather than inferred from item capture | Must be verified in the current restore handler | Attachment count, name, size, hash, and restored access |
| Item versions | Registered list-item-version handler | Do not assume selective item restore recreates the historical version chain | Captured version count and explicit current restore behavior |
| Lookups, people, and taxonomy | Values depend on target lists, identities, and term sets | Restore can fail, remap, or create a different value when dependencies differ | Source and target dependency IDs plus rendered-value comparison |
| Author, editor, and timestamps | Capture available metadata and record source values | Service APIs may assign new identities or times during recreation | Source/restored author, editor, created, modified, and item ID comparison |
| Deleted list or alternate destination | Snapshot may contain items even when the original list is gone | Item restore does not prove list reconstruction; target schema must be compatible | Native list recovery or precreated target list, field mapping, conflict rule, and test restore |
Microsoft explains native list and library version behavior in How does versioning work in a list or library? and deleted-object recovery in Restore items in the recycle bin. Those native paths and North Brook Vault selective restore should be tested separately in a SharePoint backup and restore plan.
Seeded List-Item Recovery Test
SHAREPOINT LIST RECOVERY TEST
Test date:
Site/list URL:
Source list ID:
Original destination:
Alternate compatible list:
SEED
[ ] Create text, number, choice, date, Boolean, hyperlink, and person fields.
[ ] Add lookup and managed-metadata fields with known dependencies.
[ ] Create one item with every field populated and two attachments.
[ ] Record item ID, field values, attachment hashes, author, and timestamps.
[ ] Edit the item twice so list-item versions exist.
[ ] Capture a backup, then delete the item.
RESTORE
[ ] Test native recycle-bin recovery and record its result separately.
[ ] Restore the retained item to the original list.
[ ] Restore to the alternate list only after matching schema is verified.
[ ] Repeat with an existing matching item to test skip/update/duplicate behavior.
PASS
[ ] Current handlers captured every required field and attachment.
[ ] Required item data is selectively restored to an approved destination.
[ ] Lookup, person, and taxonomy values resolve correctly.
[ ] Author/timestamp/ID changes are documented and accepted.
[ ] Version-chain behavior is verified, not assumed.
[ ] No unexplained duplicate or field conflict remains.
FAIL
[ ] The required list must be reconstructed but no tested path exists.
[ ] A required attachment, version, permission, or dependency is unsupported.
[ ] Alternate restore depends on missing columns, content types, or term sets.For list-item conflicts, define a business key in addition to the SharePoint item ID. A recreated item can receive a new ID, so duplicate prevention may need a composite such as case number, external record ID, or another unique field. Decide whether the restore should skip, create, or update a match. Never infer update-in-place behavior without a representative test and an approved rollback plan.
Admin Procedure
- Discover sites: include communication sites, group-connected team sites, private/shared channel sites, hub sites, inactive sites, and excluded sites.
- Inventory objects: count libraries, files, folders, lists, items, attachments, pages, content types, columns, term groups, permissions, workflows, and apps.
- Classify criticality: assign business owner, data class, RPO, RTO, retention, and required recovery destination to each site or object class.
- Inspect native controls: document recycle-bin procedures, library version policies, Files Restore, Purview retention, and whether Microsoft 365 Backup protects the site.
- Review consent and scope: verify Graph application permissions, admin consent, access restrictions, site exclusions, and preflight results.
- Run full capture: reconcile expected versus discovered sites, drives, lists, and item counts. Resolve item-level errors before accepting the baseline.
- Run incrementals: verify supported delta and enumeration behavior using the Graph delta engineering guide.
- Restore required objects: use seeded items and retain object-level evidence. A completed backup job alone is not acceptance.
Microsoft's SharePoint and OneDrive resiliency documentation explains recycle bins and Files Restore. Current version policy behavior is documented in document-library version history limits. If full-site or Microsoft-managed selected-content recovery is required, test the current Microsoft 365 Backup restore procedure as a separate candidate.
Seeded Pilot Scenarios
- Create a nested document-library tree with Office, PDF, large, and non-ASCII filenames; add custom metadata and a unique permission.
- Create a file, capture it, edit it twice, rename and move it, then delete it. Restore snapshots from before and after each material change.
- Create a custom list with text, choice, date, person, lookup, and managed-metadata fields. Add an attachment and multiple item versions.
- Create and publish a modern site page with web parts and referenced assets; then edit and delete it.
- Create a content type, site column, and taxonomy dependency. Confirm capture, then document that unsupported structural restore does not pass a reconstruction requirement.
- Break one permission inheritance boundary and remove one sharing grant. Compare captured and restored access behavior.
- Force destination conflicts for a file, list item, and page; record overwrite, skip, rename, merge, or failure behavior.
Pass/Fail Evidence Checklist
- Record tenant, site URL and ID, library/list ID, source item IDs, parent IDs, snapshot ID, and test timestamps.
- Reconcile expected and captured sites, drives, lists, pages, items, attachments, versions, and item errors.
- For drive items, compare content hashes, paths, sizes, MIME types, metadata, identities, timestamps, and permissions.
- For list items, compare every required field type, attachment, item version, ID behavior, and destination.
- For pages, compare layout, web parts, links, assets, publication state, and rendering.
- Record operator, recovery point, destination, conflict option, start/finish time, throttling, retries, and failures.
- Fail if any required structural object is capture-only, any historical file version is assumed covered, or measured recovery misses RPO/RTO.
Product Fit and No-Fit Boundaries
North Brook Vault fits requirements centered on managed scheduled capture of supported SharePoint objects and tested selective restoration of list items, site drive items, and site pages. It manages service infrastructure and storage and documents the service boundary during onboarding.
It is not currently a fit for complete site rollback, guaranteed site reconstruction, historical document-library file-version backup, universal permissions restoration, native Object Lock, compliance certification, or legal-production export. Combine native controls, Microsoft 365 Backup, manual configuration recovery, or another product where those outcomes are mandatory.
Once the workload pilot passes, place the accepted recovery paths into the SharePoint disaster recovery runbook.
Review SharePoint object coverage Discuss a SharePoint recovery consultation Review managed-service pricing