← All features

Microsoft 365 and IMAP backup

By Lucas Flores, IT Systeme Flores UG. Last updated 2026-10-29

Restow backs up Exchange Online mailboxes (mail, calendar and contacts), OneDrive and, since 0.4.0, SharePoint Online sites, incrementally through the Microsoft Graph API, and any IMAP mailbox over IMAP, password-authenticated today (OAuth2 for IMAP sources is not implemented yet; planned). Since 0.4.5 it also backs up the calendar and the conversations of Microsoft 365 groups, if you switch that on. Every restore drawn from that backup is written to the hash-chained audit log in every edition: who ran it, when, for whom, and from where. The audit log viewer (search, filter, details, chain verification) ships in Business and Service Provider, and since 0.3.1 so does the export of the log, as CSV and as JSON with hashes.

How the Microsoft 365 side works

Backup runs incrementally via Microsoft Graph's delta-query mechanism, so a normal run only fetches what changed since the last one instead of re-scanning a whole mailbox or OneDrive. Users, mailboxes and OneDrives come in automatically through Entra ID directory sync (Graph users/delta), with the protected scope controlled per tenant: everyone, a specific group, or an exclusion list. Microsoft throttles the Graph API, especially for a large tenant's first backup. Restow shows that wait instead of hiding it, the same honesty rule that applies to every other progress or limit in the product. A backup that Graph or the storage still holds back after all its retries reads "Held back by the service, retried" in amber, not "Failed" in red, and raises no failure alert and no failure webhook; the next scheduled run tries again (since 0.4.7). A background job now honours a Retry-After of up to 5 minutes (before, about a minute), because Exchange refuses a retry before its penalty for too many parallel requests is over. Microsoft began switching off Exchange Web Services (EWS) for Exchange Online on 1 October 2026 (for good on 1 April 2027); Restow never used it and talks to Microsoft only through Microsoft Graph.

Since 0.3.5, a first backup that takes days can continue after an interruption. If a backup is interrupted by its time limit of 23 hours or by a worker restart, after it saved a checkpoint, it continues without using up one of its retries, for up to 21 days after it first started, and the run view shows the interruption as information, not as an error. A Microsoft Graph request that gets no answer within 5 minutes is retried, instead of hanging until the job's time limit; requests and throttling waits end with the job.

The first backup of a large mailbox shows "First backup: X of Y items" over all attempts, with an estimated time left, and a OneDrive shows "X items so far" until it is fully listed.

More on this: OneDrive backup.

Objects that are no longer backed up

Since 0.4.7, a mailbox whose account is disabled or has no Exchange Online licence, and a OneDrive or SharePoint site that Microsoft locked (HTTP 423, which Microsoft does to the OneDrive of an unlicensed account), no longer fail every night. The backup first asks Microsoft whether the user exists but has no mailbox, or confirms the lock with one cheap read. Only then the object reads "Not backed up: account disabled", "Not backed up: no licence" or "Not backed up: locked", the run ends neutral without retries, existing backups are kept, and nothing counts as failed or overdue. Only Exchange's answer counts: a disabled account whose mailbox Microsoft still serves, such as a shared mailbox, is backed up as before, and a 401 or 403 is never read this way. Backups resume by themselves after the directory sync that finds the account enabled or licensed again, or the lock lifted.

So that nothing goes quiet, every object that Restow stops backing up, also one that was removed from its source, first reads amber "Not backed up any more, please confirm", with the reason and the date. The tenant's readiness stays at least yellow, never green, and providers see it among the tenant's alerts, until an administrator confirms "Yes, intended" for one object or for a selection or a filtered list of up to 1000. The object then reads grey "Intentionally no longer backed up", with who confirmed it and when; when it becomes active again, the confirmation is dropped, and if it stops again later, Restow asks again. One notice per object, or one warning per tenant and day when many stop at once, goes through the notification matrix. After the update, objects that were already orphaned count as confirmed. An object removed from its source is rated by whether its newest kept backup restores, not by how old it is.

Since 0.4.7 an error also costs less: a 403 for calendars or contacts fails only that area and keeps the mail of the run, a delta link that Graph rejects leads to a full resync, a message that Exchange cannot convert to MIME is stored as JSON with its attachments, and a permission that an administrator grants to the app later takes effect without a new client secret.

SharePoint Online sites

Since 0.4.0, every directory sync also finds the tenant's SharePoint sites, those of Microsoft 365 groups and Teams included; personal sites are left to their owner's OneDrive. Each site is a protected object of its own in the mail jobs, like a mailbox or a OneDrive, and the protection rules have a sites mode: all sites (the default) or only the selected ones. A backup holds every document library (with the OneDrive engine: delta per library, optional versions, checkpoints), every list with its columns and each list item's field values as JSON, and the site's description. A library or list that Graph refuses is reported and keeps its last copy. A new site gets its first backup at once, and a site that was deleted fails with a clear cause.

In the restore explorer a site shows its libraries, folders, files, lists and items. You can download them as a ZIP; restore files and folders into the original library or another library of a backed-up site of the same source ("Keep both", "Overwrite", where SharePoint keeps the old file as a version, or "Skip existing"); and restore list items into their original list as new items, writable fields only. Restore checks sample library files like those of a OneDrive.

It needs an added permission and a new consent. The backup app needs the application permission Sites.ReadWrite.All (Sites.Read.All is enough to back up, not to restore), and the customer's administrator has to open the source's consent link again. Until then mail and OneDrive keep working, and the directory sync warns that sites are neither found nor backed up. Not backed up: Teams chats, attachments of list items, site design, navigation and workflows. Permissions are kept as information and never restored, a deleted site or library is not recreated, and list items go back only into their original list.

More on this: SharePoint Online backup.

Microsoft 365 groups: calendar and conversations

Since 0.4.5, the calendar and the conversations of Microsoft 365 groups, and of the groups behind Teams, are protected objects of their own kind. The directory sync reads the groups as a second delta stream next to the users and keeps only Microsoft 365 groups (security and distribution groups have no group mailbox); a deleted group is orphaned, and its restore points stay. Groups are opt-in: the protection rules have a switch "Protect all Microsoft 365 groups", off by default, and single groups can be included in the list of protected objects. A mail job with scope "all" covers every protected group, and group mailboxes never count as protected mailboxes. After the update no group is backed up until you switch it on, and the first directory sync reads the groups of every Microsoft 365 source once in full.

A backup holds the group's calendar (series with their exceptions, read by the code that reads a user's calendar) and every post of every conversation as a mail message, with its file attachments where Graph hands them out; otherwise the missing attachments are recorded. If Graph refuses the app the event listing of a group calendar, Restow falls back to the group's calendar view and reads each series once; a calendar that Graph refuses entirely is a warning on the run, not a failure. Only threads with new posts are read again. No new Microsoft permission is needed: Group.Read.All and Calendars.ReadWrite were always required.

In the restore explorer, groups sit in the "SharePoint & Teams" section with the areas "Group calendar" and "Conversations". Download as a ZIP (EML, JSON) and export (EML, MBOX, PST) work as for mailboxes. A restore into a user's mailbox of the same source brings back events and conversations (the conversations as mail). A restore into the group itself brings back calendar events only, because Microsoft Graph lets no app post into a group conversation; each post is reported as not restorable, with the ways that work. Restoring a group is no impersonation, because a group belongs to no person. Not backed up: Teams chats and channel messages, and the attachments of calendar events.

The backup index

Since 0.3.5, the index of which items a backup contains is stored as one row per version of an item, not as a copy of every item for each backup. An item that did not change costs nothing on later backups. After the update, the worker converts the index of existing backups in the background, one backup at a time; backups, browsing and restores keep working meanwhile. Since 0.3.6, once the conversion has finished, the API gives the old table's disk space back by itself, within about 15 minutes; the API restart that 0.3.5 asked for is no longer needed. On 0.3.5 itself, restart the API once after the conversion.

Connecting a Microsoft 365 source

A source connects to Microsoft 365 in one of three ways:

• The consent invitation of the shared backup app, which the customer's administrator accepts.
• A Graph app of your own for that source (since 0.2.2): an app the customer created by hand in their own tenant. You enter the tenant ID, the application ID and a client secret or a certificate. The credential is sealed in the organisation's secret store and never shown again. The guide lists every permission with a copy button and says that no redirect URI is needed. Since 0.4.7 you can enter the secret's expiry date as well ("Secret expires on", optional): Restow then reminds you 30 days before, 7 days before and once it has expired, and the connection card shows "Expires".
• For the tenant the backup app itself lives in, a direct connection without a consent link (provider owners only). A working app token for that tenant is the proof, so the consent round trip, which Entra refuses for an app that is not installed there, is skipped. It needs the directory (tenant) ID of the app under Settings, Microsoft 365.

How the IMAP side works

Any IMAP mailbox is a valid backup source, authenticated today with a password. Per IMAP source you choose how Restow signs in: one shared login and password used for every mailbox (the default), a separate password per mailbox, or one master account that impersonates each mailbox. OAuth2 for IMAP sources (Microsoft 365 or Google over IMAP) is not implemented yet; planned. IMAP-only tenants (ones without an Entra ID directory to sync from) are added by a manual mailbox list or CSV import instead.

More on this: IMAP mailbox backup.

Backup jobs, live runs and history

A backup job says what is backed up, when, into which repository, for how long, and how often a restore check proves it, for many mailboxes, OneDrives, IMAP accounts or machines at once, with overrides per object or machine. There are jobs for mail and for servers and clients. You can limit how much bandwidth a backup may use, within a time window that you set. Running jobs and tables update on their own, without reloading the page, and a run opens a detail panel with charts of its throughput. The history lists every run, including the runs of agents on servers and clients, with filters by kind (backup, restore, restore check, export, import, maintenance) and by job. The directory and the job pages say which job backs up an object.

Since 0.4.2 the first question of a mail job is what it should do: back up (restore folders, calendar, contacts and whole mailboxes as they were at a restore point), archive (keep every mail tamper-evident, captured before users can change or delete it) or both, which is the default for a new job. Archiving captures mail by the ways the editor offers for each kind of mailbox in the job: since 0.4.4 Microsoft Graph or Exchange journaling for Microsoft 365, and IMAP sync or copies the mail provider forwards for IMAP and Google Workspace accounts, each labelled as captured at transport or near-time, with at least one per kind (the defaults of a new job are Graph and IMAP sync, each with a one-time takeover of the mail already in the mailbox). Near-time capture is not complete; the archive section says what it does not promise. The ways are part of Business and above; without them the choice is kept, but they capture nothing. Jobs that archived before 0.4.4 keep journaling only, so nothing new starts by itself. A job that only archives makes no backups on a schedule (a run started by hand still backs up). When a job archives, the editor suggests backing up every 8 hours instead of more often, as a suggestion only: the schedule stays as you set it. When it only backs up, the editor names the gap between two runs, in which mail that arrives and is deleted is in no backup, and that backups are not tamper-evident. Since 0.4.7 "Create recommended job" and "Protect everything without a job" also archive where the installation offers capture from the mailbox: the new mail job over all objects backs up and archives, and a mail job over all objects that does not archive yet is switched to archiving, with its schedules kept; a job over selected objects is never changed.

Alerts, warnings and notification mail

Alert rules send an e-mail, an entry in the notification bell or a signed webhook when a backup fails, a restore check does not pass or storage is damaged, and every delivery is logged. A webhook can post a chat message instead: Discord, Slack or Microsoft Teams, chosen from the webhook's URL, beside the signed Restow envelope. A 4xx answer from a chat service ends a delivery at once instead of retrying it.

The event backup.overdue covers mailboxes, OneDrives, IMAP accounts, machines and Proxmox guests, takes the schedules of the backup jobs into account, and an alert rule can set a deadline of its own, from 24 to 720 hours. Warnings list why single items were not backed up (folder, subject, date, cause and what to do) and can be acknowledged with a note. The bell leads to the cause, and a Notifications page keeps the history.

Since 0.4.0 the notification matrix under Integrations, Notifications shows the events as rows, grouped and marked by severity, and the bell, every webhook and every notification recipient as columns, each with the quick choices "Errors only", "Errors and warnings" and "All". An alert rule no longer sends an event to a channel whose column has it off. Nothing changed on update, because the migration filled every column with what the channel received before. A webhook created later starts with the defaults of its format: Discord, Slack and Teams get errors and warnings, a signed JSON webhook gets everything. Saving the matrix is written to the audit log.

Since 0.4.7 Restow also reminds you before the client secret or certificate of the central Microsoft 365 app registration, or of a source's own app, expires: 30 days before, again 7 days before and once it has expired (the events installation.app_secret_expiring for provider administrators and source.app_secret_expiring, which tenant administrators can choose as well). The date is entered, or is the certificate's own end; Restow does not read it from Microsoft. Objects that stop being backed up raise object.inactive (one notice per object) or object.inactive_many (one warning per tenant and day).

Notification mail is sent through SMTP, through Microsoft 365 (an app of your own with Mail.Send, or the backup app) or through Google Workspace (a service account with gmail.send), with guides and plain error messages.

Servers, clients, file shares, Proxmox VE and mail files

Microsoft 365 and IMAP are not the only sources. In every edition, an agent for Linux and macOS backs up servers and clients to your own Restow, over outbound HTTPS only and append-only: the machine can add backups but never delete them. See server and client backup. SMB shares and NFS exports are backed up from the Restow server, with no agent on the file server, see file shares. VMs and containers on Proxmox VE 8.4 and newer are backed up as a preview, also in every edition, see Proxmox VE backup. Mailboxes that only exist as files (EML, MSG, MBOX, a MailStore export) can be imported as a legacy mailbox and exported again, see mail import and export.

When a backup fails

Every failed job, item, sync and verification says what happened, why and what to do, instead of showing a bare error string. Failures are classified under a stable cause code: a missing Microsoft 365 permission, named; admin consent missing; throttling, with the wait Microsoft asked for; an IMAP login that failed; storage that is full or refuses access; a hash mismatch. A disabled or unlicensed account, and a OneDrive or site that Microsoft locked, is no failure since 0.4.7: it reads "Not backed up" with the reason. Each one comes with next steps that link to the right settings page, and the technical details (HTTP status, Graph error code, request IDs, with secrets removed) stay available for a support case. See the failure explanations in the documentation.

Stated limits, not hidden ones

• Microsoft Teams chats and channel messages are not part of the scope for now. Of a Microsoft 365 group, the calendar and the conversations are backed up if you switch it on; the attachments of calendar events are not.
• IMAP sources sign in with a password only. OAuth2 for IMAP sources is not implemented yet; planned.
• Microsoft 365 backup and restore, SharePoint sites and group calendars and conversations included, have not yet been run against a real Microsoft 365 tenant in the release checks. They are covered by tests against a simulated Graph API. The first backup of a large tenant can take days because of Graph throttling, and the job shows the wait. No Microsoft 365 tenant was used before 0.3.5 was tagged, so neither the continuation of long first backups nor the retry after 5 minutes has run against a real tenant. The detection of disabled, unlicensed and locked objects was tested the same way; an answer of Microsoft that Restow does not recognise stays a counted failure.
• The expiry date of a client secret is entered, not read from Microsoft: without a date there is no reminder, and a source that was connected through its own app before 0.4.7 has none until it is noted on the source's page.
• The conversion of the backup index of an existing installation was tested on generated histories, not yet on a production database of 25 GB; how long it takes there is an estimate.
• A Graph app of your own for a source was tested with unit tests and the CI suites only, not against a real Microsoft 365 tenant. The chat webhooks and notification mail through Microsoft 365 or Google Workspace were tested against fakes only.
• Proxmox VE backup is a preview and not yet recommended as the only backup. Details on the Proxmox VE page.
• Google Workspace backup (Gmail, Google Drive) is planned. Teams chats and Exchange Public Folders are deliberately out of scope for now, and SharePoint sites have the limits listed above. PST and OST import is planned: today such files are recognised and refused with an explanation, and mail files come in as EML, MSG, MBOX or ZIP. See the roadmap for what's planned after.
• Server and client backup has no Windows agent yet, no disk images or bare-metal restore yet (it is file-based; images are planned), and no LVM, ZFS or btrfs snapshots and no mTLS yet. Details on the server and client backup page.

Frequently asked

See how restore works next →

Read more in Learn: does Microsoft 365 back up your data? →

Read more in Learn: RPO and RTO, how a schedule sets how much data you can lose →