SharePoint Online backup, self-hosted
By Lucas Flores, IT Systeme Flores UG. Last updated
Restow backs up the SharePoint Online sites of a Microsoft 365 tenant, with their document libraries and lists, through the Microsoft Graph API. It runs on your own server and writes to storage you choose, and you browse and restore a site in the same Restore explorer as a mailbox or a OneDrive. It is available since 0.4.0, in every edition, Community included. It needs one more application permission and a new admin consent in every tenant that was connected before, and it was tested against a simulated Microsoft Graph, not against a real tenant: Restow is a beta.
How a site is found and protected
Every directory sync lists the tenant's sites. Sites of Microsoft 365 groups and of Teams are included; personal sites are left out, because they are the OneDrives that are protected through their owner. Each site becomes a protected object of its own, of the type "SharePoint site", and it runs in the mail jobs like a mailbox or a OneDrive. A job that covers everything that is in no other job therefore covers every site too. A newly protected site gets its first backup at once.
The protection rules of a source have a switch of their own, "Protect all SharePoint sites". On (the default), every site of the tenant is backed up and you exclude single sites in the list of protected objects; off, no site is backed up unless you include it. The group scope, the exclusion list and the switch for shared mailboxes do not apply to sites. Switching the mode never deletes a backup: a site that leaves the scope is no longer backed up and keeps its restore points. A site that Microsoft no longer lists is marked as removed from the source, and its restore points stay.
A site that Microsoft locked (an administrator locked it, or it belongs to
an account without a licence, and it answers HTTP 423 at site level or in
every library) ends without a restore point since 0.4.7, instead of carrying
old copies forward. After one cheap read confirms the lock, the site reads
"Not backed up: locked", a neutral state with no retries, no failed count and
no backup.failed alert, and the scheduler stops planning it; its
restore points stay. Like every object Restow stops backing up, it first
reads amber "Not backed up any more, please confirm" until an administrator
confirms "Yes, intended" (readiness stays at least yellow until then). The
directory sync reactivates a site that is still listed only when a read of
the site succeeds; a site that is no longer listed is marked as removed from
the source with the reason "No longer in the source", not as locked. A
restore into the original location of a locked site is refused with the
reason.
What a backup of a site holds
Each run of a site produces one restore point:
| Part of the site | What is saved |
|---|---|
| Document libraries | Every document library, including the one of the site's pages and the one for its assets. Files with their folders, saved by the same engine as OneDrive: Microsoft's delta query per library (later runs read only what changed), optional older versions and checkpoints, so a long run continues where it stopped. |
| Lists | Every visible list, with its columns. Hidden system lists and libraries that appear as lists are skipped. |
| List items | The field values of each item as JSON, with its content type, author and dates. |
| The site itself | Its title, address and description. |
Lists have no delta query, so a run reads every list in full; an item that
did not change reuses its stored bytes, and storage does not grow with it.
A library or list that Microsoft Graph refuses (403, 404 or 423, and since 0.4.7
also 400, 501 or a lasting 500 for a list template or a library's
permissions) is reported as a failed item and keeps its last copy, and the
rest of the site gets its snapshot; the run ends "with warnings". A 500 or
502 for a library's contents still fails the job, which resumes from its
checkpoint, and a resumed site counts the item failures of the libraries an
earlier attempt finished. A library that is gone no longer reads "This user
has no OneDrive that Restow can reach". A site
that was deleted in Microsoft 365 fails with the message "This SharePoint
site no longer exists"; its earlier restore points stay restorable.
Microsoft throttles SharePoint like OneDrive, and Restow uses the same
client, the same waits, the same backup queue and the same parallelism per
tenant: the first backup of a large site can take long, and Restow shows
the wait instead of hiding it. Since 0.4.7 a backup that Microsoft Graph or
the storage still holds back after all its retries reads "Held back by the
service, retried" in amber instead of "Failed" in red: it is left out of the
failed counts, raises no backup.failed alert and no
job.failed webhook, and the next scheduled run tries again. A
background job also honours a Retry-After of up to 5 minutes (before 0.4.7,
about a minute).
Since 0.4.7 the job page names the phases of a site backup ("Reading the site", "Lists") and of the discovery of sites ("Finding sites") and of group mailboxes ("Finding group mailboxes").
The extra permission and a new admin consent
SharePoint needs one application permission that mail and OneDrive do
not: Sites.ReadWrite.All (Microsoft Graph, application
permission). It is optional, so a tenant that consented before 0.4.0
still counts as complete and mail and OneDrive are not affected.
| Permission granted | Sites found and backed up | Restore into a site |
|---|---|---|
Sites.ReadWrite.All |
Yes | Yes |
Sites.Read.All only |
Yes | No (a download as ZIP still works) |
| Neither | No | No |
- The operator adds the permission to the backup's app registration (Microsoft Graph, application permissions) and grants consent in their own tenant.
- Every customer's administrator consents again. An added permission applies in a customer tenant only after a new admin consent: on the Microsoft 365 source, "Create new consent link", valid for one hour. A source that is connected through the customer's own Graph app has no consent link: add the permission to that app, grant consent there and run "Verify permissions" on the source.
-
The next directory sync finds the sites. While the
permission is missing, the source shows "SharePoint sites are not backed
up" (or "SharePoint sites can be backed up, not restored into" with
Sites.Read.Allonly), and the directory sync warns that sites are neither found nor backed up. Sites that are already known stay as they are.
A permission that an administrator grants to the app later takes effect without a new client secret: since 0.4.7, when Graph answers 401 or 403, Restow fetches a new token once and sends the request again, at most once a minute per tenant or source.
Restore
Open the Restore explorer and pick a site in the section "SharePoint & Teams", then a restore point. A site has two areas: "Libraries" (folders and files, with the older versions where Restow captured them) and "Lists" (list items). Only restore operators and tenant administrators see sites; end users never do.
-
Download as ZIP works for any selection: files, folders
and list items as JSON files, together with
site.json, the description of the site, its libraries and its lists. -
Files and folders go back into their original library,
at the path they had, or into another library of a backed-up site of
the same Microsoft 365 source (add
:/Folderto restore into a subfolder). Restow uploads large files in sessions and compares size and hash of what it wrote with the backup. - List items go back only into their original list, as new items, and only the writable fields: system, read-only, hidden and calculated columns are left out, and SharePoint sets the creation and modification dates and the authors of a new item itself.
The restore dialog asks what to do "If an item already exists": "Keep both" (the default: a file that exists is restored under a new name, list items are added as new items), "Overwrite" (a file that exists is overwritten, and SharePoint keeps the replaced file as an earlier version; a list item that still exists gets its backed-up values back) or "Skip existing". Overwrite is offered for SharePoint sites only: restores into mailboxes and OneDrives never overwrite. A site belongs to no person, so restoring it is not an admin restore on someone's behalf and needs no reason, but every restore is written to the audit log.
Proven restorable, and watched for ransomware
A restore check, set in the backup job (weekly by default), reads up to 20 sampled files of a site's libraries back and compares them with what was backed up, the same check as for a OneDrive. List items are not part of the sample. The result feeds Recovery readiness next to mailboxes and machines; see the verification page.
Every new restore point is also judged for signs of ransomware. For a site that rests on the amount of change and on compression and deduplication; deletions, renamed extensions, names and entropy are not available for a site, and a signal without data says "not available", never "clean". Details on the ransomware detection page. If you turn on immutable backups for the tenant's repository, the data of sites is locked like that of mail and OneDrive (see storage).
There are no new alert events: failed, succeeded and overdue backups are reported for sites like for mailboxes, with the site as the object. In the status, sites are listed next to mailboxes and OneDrives but count as no protected mailbox.
What is not backed up
- Microsoft Teams chats and channel messages. The files of a channel are in the library of the team's site and are backed up with it.
- Attachments of list items: Microsoft Graph v1.0 has no interface for them.
- Site design and themes, navigation, web parts outside the library of the site's pages, the site template and the content type hub: not backed up, or kept as information only.
- Permissions: the sharing of libraries and items is saved as information and never restored; site groups and memberships are not saved.
- Workflows (SharePoint 2010 and 2013), Power Automate and Power Apps.
- SharePoint Server on premises.
Stated limits, not hidden ones
- SharePoint backup and restore were tested against a simulated Microsoft Graph API, not against a real Microsoft 365 tenant, and that includes the detection of a locked site: an answer of Microsoft that Restow does not recognise as a lock stays a counted failure. Restow is a beta: run it beside your existing backup, and restore a few files and list items by hand before you rely on it.
- A deleted site or library is not recreated. List items go back only into their original list, and a restore that you start again in "Keep both" adds them again; a retry of an interrupted restore does not (since 0.4.7).
- The restore check samples library files; list items are not checked.
- The first backup of a large site can take long, because Microsoft throttles SharePoint. A backup that stays held back after all its retries reads "Held back by the service, retried" and is tried again at the next scheduled run.
- Teams chats and channel messages are not covered; neither are the attachments of list items, the design of a site or its permissions (listed above).
Editions
SharePoint Online backup and restore are part of the Community core and therefore in every edition: Community, Business and Service Provider. The Community edition is free and has no mailbox limit. For the whole picture of what each edition adds, see pricing.
Frequently asked
Does Restow back up SharePoint Online?
Yes, since 0.4.0, in every edition. Through Microsoft Graph it backs up the document libraries of every site, every visible list with its columns and the field values of each list item, and it restores files, folders and list items from the Restore explorer. It was tested against a simulated Microsoft Graph, not against a real Microsoft 365 tenant, and Restow is a beta.
Which permission does it need, and does every customer have to consent again?
The backup app needs the Microsoft Graph application permission Sites.ReadWrite.All. Sites.Read.All is enough to find and back up sites, not to restore into them (a download as ZIP still works). A tenant that connected before 0.4.0 has to consent again: the operator adds the permission to the app registration, then the customer's administrator opens the source's consent link again ("Create new consent link"). A source that uses the customer's own Graph app has no consent link: add the permission to that app, grant consent there and run "Verify permissions". Until then mail and OneDrive keep working, and the directory sync warns that sites are neither found nor backed up. A permission that an administrator grants to the app later takes effect without a new client secret (since 0.4.7).
Does it back up the sites of Microsoft 365 groups and Teams?
Yes. Sites of groups and Teams are found like any other site, and the files of a team are in the document library of its site. Personal sites are left out because they are OneDrives, which are protected through their owner. Teams chats and channel messages are not backed up. Since 0.4.5 the calendar and the conversations of the Microsoft 365 group behind a team can be backed up too, if you switch that on.
Are list item attachments, permissions and the site design backed up?
No. Attachments of list items are not backed up, because Microsoft Graph v1.0 has no interface for them. Site design and themes, navigation, web parts outside the pages library, the site template and the content type hub are not backed up or kept as information only. Sharing and permissions are saved as information and never restored; site groups and memberships are not saved at all. Workflows (SharePoint 2010 and 2013), Power Automate and Power Apps are not backed up either.
How do I restore a single file or a list item?
In the Restore explorer pick the site in the section "SharePoint & Teams", choose a restore point and open "Libraries" or "Lists". Files and folders go back into their original library or into another library of a backed-up site of the same source; list items go back into their original list as new items. If an item already exists you choose "Keep both" (the default), "Overwrite" (SharePoint keeps the replaced file as an earlier version) or "Skip existing". Any selection can also be downloaded as a ZIP.
Can Restow recreate a deleted site or library?
No. A deleted site or library is not recreated; you restore into a library that exists. List items go back only into their original list, and a restore that you start again in the mode "Keep both" adds the items again, while a retry of an interrupted restore does not (since 0.4.7). The restore points of a site that was deleted in Microsoft 365 stay restorable.
What happens when a library or list cannot be read?
Microsoft Graph can refuse a library or a list (403, 404 or 423, and since 0.4.7 also 400, 501 or a lasting 500 for a list template or a library's permissions). Restow reports it as a failed item and keeps its last copy; the rest of the site is backed up, and the run ends with warnings that explain what happened and what to do. A 500 or 502 for a library's contents still fails the job, which resumes from its checkpoint. If Microsoft locked the whole site (423 at site level or in every library), the run ends without a restore point instead, and once one read confirms the lock the site reads "Not backed up: locked" (neutral, no retries, no failed count) until the directory sync finds it readable again. The detection of a lock was tested against a simulated Graph API, not a real tenant.
Does it work with SharePoint Server on premises?
No. Only SharePoint Online, through Microsoft Graph, is supported.
Is SharePoint backup in the Community edition?
Yes. It is part of the Community core and therefore in every edition, and the sites do not count as protected mailboxes. Restow is a beta: run it beside your existing backup until you have restored from it yourself.
Documentation
The documentation has the details: SharePoint Online (what is backed up, the extra permission, restore, failures), connecting sources and the Entra walkthrough with every permission under first steps.