Backup and restore

What gets backed up

Exchange Online: mail, calendar and contacts, incrementally through Microsoft Graph delta queries.
OneDrive: files, including older file versions Restow has captured, incrementally through Microsoft Graph.
SharePoint Online sites (since 0.4.0): every document library, every list with its columns and the field values of each list item, and the site’s description, through Microsoft Graph. Sites of Microsoft 365 groups and Teams are included; personal sites are the OneDrives. It needs an extra permission and a new admin consent per tenant. See SharePoint Online.
Microsoft 365 groups (since 0.4.5, opt-in): the group calendar and every post of every conversation of a Microsoft 365 group, and of the group behind a team, as a protected object of their own, through Microsoft Graph. They need no new permission. See Microsoft 365 groups.
IMAP mailboxes: mail, over IMAP, password-authenticated today (OAuth2 for IMAP sources is not implemented yet; planned).
Servers and clients: files, through the Restow agent on Linux and macOS, into restic repositories in your storage target. See Endpoint backup.
File shares (SMB and NFS) (since 0.4.0): backed up from the server, without an agent on the file server, with their permissions (NTFS, and NFSv4 or POSIX ACLs on a best-effort basis), into restic repositories. See File shares.
VMs and containers of Proxmox VE (a preview, since 0.3.1, in every edition): VM disks as changed blocks, containers through restic, from Proxmox VE 8.4 on. A restore creates a new guest next to the original; since 0.4.0 you can also browse a restore point and download single files of a container or a VM (the VM part is a Preview), and boot the newest restore point of a guest in isolation as a test. See Proxmox VE backup.

Mail you import from files is not backed up from anywhere: it is stored as an imported mailbox, in the same format as an IMAP backup (see Mail file import and export).

Every backup run of a mailbox, OneDrive, SharePoint site, Microsoft 365 group or IMAP account is content-defined-chunked, deduplicated within a tenant, and encrypted before it reaches storage (AES-256-GCM, one key per tenant), and produces a snapshot, a point in time you can browse and restore from later: a single mail, a folder, a file, an older file version, or an entire mailbox/OneDrive/IMAP account. A SharePoint site gives you libraries, folders, files, lists and list items. See Backups and schedules for how runs are triggered and scheduled.

Partial failures cost an area or an item (since 0.4.7)

A refusal or a broken answer from Microsoft or from an IMAP server now costs the smallest part that it touches, not the whole run, and a run that cannot go on stops at a checkpoint and resumes from it. The run page and the failure explanations say what happened.

Mailbox. A 403 for calendars or contacts (a permission that is missing, or an access policy that covers mail only) fails that area and keeps the mail of the run, instead of discarding the snapshot. A 401 in the middle of a run checkpoints and resumes, instead of abandoning a partial first backup. A well-known folder that Graph refuses to resolve (400, 403) is treated as absent and named in the worker log only, and a stored delta link that Graph rejects as an invalid sync state (400) leads to a full resync. A message that Exchange cannot convert to MIME is stored as JSON with its attachments, like an oversized one. A subfolder deleted while its parent was listed is recorded as a failure of the parent and no longer fails the run.
SharePoint. A library or list that Graph will not give (400, 501, or a lasting 500 for a list template or a library’s permissions) is an item failure that keeps its last copy, and the rest of the site gets its snapshot. 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 that an earlier attempt finished. A library that is gone no longer reads “this user has no OneDrive”.
OneDrive and SharePoint files. An item that failed and came through later in the same run (listed twice in a delta feed, or retried) no longer stays among the failures, files that a host sends compressed are no longer taken for truncated downloads, and cancelling a job during a throttling wait no longer records items as failed. A OneDrive whose drive Graph no longer finds (the user was deleted, or retention is over) fails as graph.onedrive_unavailable, permanent and not retried, instead of as an item.
IMAP. A login or a read that the server refuses for a limit (too many connections for the account, an authentication backend that is down, a download cap) is imap.server_limit, transient and retried by itself, instead of a wrong password or a full mailbox; such a cap fails the folder as a whole and the next run resumes. Messages that were deleted or moved during the backup are not counted as failures, and a run whose connection dropped too often fails as imap.connection_lost. In the archive capture, one message that the server refuses or does not deliver no longer holds back its folder or the pass, and the capture gives up on it after three passes. See Archiving.
Microsoft Graph. A connection that broke before Graph answered (reset, refused, a temporary DNS failure, a timeout) is retried with backoff for requests that only read, and is not reported as throttling. A token endpoint that cannot be reached is asked twice more (after 1 and 4 seconds) and then fails the run, which resumes from its checkpoint, instead of recording every item as failed. Every $batch sends an identical read only once, so a delta page or a retry can never repeat a request id.
Jobs. The time limit of a job counts from when the queue handed it out, also while it waits for a free slot of its tenant, so a job that waited out its time stops before it starts and no retry runs beside a late attempt. A cancel that lands while an attempt starts or fails is kept. A job that the reconciler ends for good raises the job.failed webhook, the bell and the notification rules like any other, and its checkpoint is cleared.

Restoring: browse, select, restore

The Restore explorer (Mail & SaaS → Restore explorer) browses a backup as it looked at any point in time (folders, individual mails, files and their version history) and restores or downloads what you select, either one item at a time or the entire backup at once. A search box covers names, paths and mail subjects at the selected point in time.

One entry per person (since 0.4.2). The list on the left shows each person once. The mailbox, the OneDrive and an assigned IMAP account of a person are grouped under their directory user, and the second column shows what their backups hold: Mail, Calendar, Contacts and OneDrive (and Mail (IMAP)), each with the restore points of its own object and a marker No backup yet or Removed where that applies. Since 0.4.7 an area whose object is still at the source but no longer backed up carries Not backed up: account disabled, Not backed up: no licence or Not backed up: locked instead (see Objects that are no longer backed up). SharePoint sites (with the files of the Teams channels) and, since 0.4.5, Microsoft 365 groups have a section of their own, SharePoint & Teams (called SharePoint & Teams sites before 0.4.5). A OneDrive for Business belongs to exactly one user: after the account was deleted it stays in the list under the name of its owner, marked Account deleted, with every restore point it ever made. The list comes a page at a time (50 entries; Show more), and the search (names, addresses and account ids) and the type filter run in the database, so a tenant with more than 10,000 people never loads everyone at once. The entry of the signed-in person comes first. The list of people groups the protected objects of the tenant for every page it serves, which is fine up to about 10,000 people per tenant and slower beyond (a known issue in 0.4.2). The data comes from GET /api/v1/snapshots/people, see API reference.

Groups (since 0.4.5). A Microsoft 365 group has the areas Group calendar and Conversations. Download as ZIP gives each post as an .eml file and each event as .json; export gives the conversations as EML, MBOX or PST, like the mail of a mailbox (the calendar is skipped and counted). A restore into a user’s mailbox (target Another account, the address of a mailbox of the same Microsoft 365 source) brings back the events into that user’s calendar and the conversations as mail into a folder Conversations; with Keep both they go into a restore calendar and below the restore folder. A restore into the group (target Original location) brings back calendar events only, into the group’s one calendar: Microsoft Graph lets no app start or answer a group conversation, so the report lists each post as not restorable, and the dialog says that only the group calendar goes back. Restore the conversations into a user’s mailbox, or download or export them. A group belongs to no person, so restoring it is not an admin restore on someone’s behalf and needs no reason, but it is audited as usual; only restore operators and administrators see groups, and there is no Overwrite.

Calendars (since 0.4.2). A mailbox’s calendar opens as a List or as a Month. The list sorts events by when they start (newest first or upcoming first, columns When, Location and Organizer) and no longer by subject. The month view shows the days of the month across all calendars of the mailbox, or one, and a recurring appointment stands once in the list as a Series that opens onto its occurrences. The API works the occurrences out from the stored pattern, puts the stored exceptions in their place and follows the time zone of the series through daylight saving time. An occurrence that was deleted on its own is not recorded in the backup (Microsoft Graph v1.0 does not report cancelled occurrences), so it can still show, as it would come back when the series is restored. Opening a calendar is written to the audit log (snapshot.calendar.read), and backups made since 0.4.2 also record the location of an event and the end of a series.

At the bottom of the Restore explorer a slim timeline shows the restore points of the selected account, oldest on the left and newest on the right. The restore point you are browsing sits in the centre, and the timeline opens on the newest one. Each marker shows whether a restore check has proven that backup can be read back. In the folder tree, a folder without subfolders says so.

Two more marks can sit on a restore point. A red Suspicious badge says that Restow found signs of ransomware in it; when the newest restore point is suspicious, the explorer offers the newest one without findings (see Ransomware detection). Immutable until with a date says that the repository holds the restore point’s data locked until that date, in green only when the storage itself reported a compliance lock (see Immutable backups).

Restore explorer speed (since 0.4.4)

A large mailbox or OneDrive used to take seconds to minutes before its folders showed in the Restore explorer. Every folder listing read all entries of the restore point (every message of the mailbox, every file of the OneDrive), twice per request, and matched the folders below against them without an index; a folder whose subfolders have no entry of their own, such as the root of a mailbox with its mail and calendar or the root of a OneDrive, grew with the square of the entries and could time out. Since 0.4.4 the listing reads the children of the folder and the folders below it from two new indexes (migration 0061_explorer_parent_index; see Upgrading to 0.4.4 for the time the update needs on a large installation).

The release notes give these figures, measured with 120,000 messages and 200,000 files in one restore point:

Listing	Before	Since 0.4.4
The mail folder list	2.5 s	15 ms
The root of the mailbox and of the OneDrive	over a minute	15 ms
Every OneDrive folder	1.5 to 2.5 s	about 10 ms
The first page of a folder of 50,000 messages	1.9 s	about 0.5 s
The versions OneDrive kept of a file, and the calendar’s month view	130 ms and 260 ms	under 50 ms

Other parts are quicker too. The restore points of an account load alongside its owner’s entry in the list of people, one round trip less before a mailbox or OneDrive shows its folders. The mail preview, the attachment download and the calendar series read each chunk of the message from storage with a byte-range request for exactly its bytes, instead of the whole pack (up to 64 MiB) for every preview; a chunk that is damaged on every target is still read through its whole pack, as before. The archive’s content check reads the same way. Restore points of 0.3.4 and earlier that the worker has not converted yet are listed as before, without the speed-up.

Preview of a message

The Restore explorer shows a selected mail in a preview. A mail can come from anyone, so Restow reads it for the preview in a separate helper process with a time limit and a memory limit, never in the api process itself (see Mail file import and export).

Simplified view. If the formatted view of a message would be too expensive to prepare, the preview shows the text of the message instead, marked Simplified view: images and layout are missing. This also applies to HTML longer than 12 MiB. Download the message to see all of it.
Could not be read. If the message cannot be read within the limits at all, the preview says that it could not be read and shows the header data from the backup. Download and restore still work, because they use the stored bytes and parse nothing.
Attachments of such a message. Downloading a single attachment of a message that cannot be read within the limits is refused (preview-unreadable). Download the whole message as EML, or restore it.
Busy. When all preview processes are busy and their queue is full, the preview and the attachment download answer preview-busy. Try again in a few seconds. If it happens often, raise PREVIEW_PARSE_WORKERS (see Environment variables).

Restore is built to be non-destructive

This is the product’s firm rule: restore is not meant to overwrite an existing original in a mailbox or OneDrive. When you restore into the original location, Restow asks what to do if something with the same name is already there:

Keep both (the default): nothing existing is touched; the restored item is written in alongside it. Mail restores go into a new, clearly named folder (for example “Restored 2026-09-23 1432”); a file that would collide with one already there is restored under a new name.
Skip existing: items that are still there are left exactly as they are; only what’s actually missing is restored.

You can also restore into another account of the same tenant (mailbox, OneDrive or IMAP account; for a SharePoint site, another library of a backed-up site of the same source; restore operators and tenant administrators only), or download as a ZIP: mails as .eml, other files as they are, together with a checksum list, from a link valid for 24 hours. An older file version that OneDrive itself kept (separate from Restow’s own backups) is download-only.

Before you confirm, the dialog shows a preview of what’s about to happen: the source (object and point in time), the target and mode, and, for an admin restoring another person’s data, a note that this is recorded as an admin restore on their behalf, plus a required reason (a SharePoint site belongs to nobody, so it needs none). Every restore is written to the audit log: who requested it, when, exactly what and where, on whose behalf if applicable, and from which IP address. There is currently no printable or exportable restore-confirmation view beyond that audit-log entry.

Restores that restored nothing (since 0.4.7)

A restore that finished but put nothing back no longer reads as a success.

Nothing restored (red): a completed restore with failed items and none restored. It raises restore.failed and the job.failed webhook, with “Nothing was restored: N items failed.” as its error.
Everything skipped (amber): a restore that skipped every item. It stays restore.completed and says so instead of claiming that it restored something; in chat channels it is information, not success.
The job.completed and job.failed webhooks of a completed restore carry its counters in data.job.result: restored, skipped, failures and unverified. A restore that completed without restoring anything while items failed has data.job.status completed and still raises job.failed.
Into an account that cannot receive it. A restore into the original mailbox of a user whose account is disabled or has no Exchange Online license, or into a OneDrive or site that Microsoft locked, is refused with the reason, for example “The account is disabled in Microsoft 365, so there is no mailbox to restore into. Enable it again to restore there.” Restore into another account instead, or download as a ZIP. See Objects that are no longer backed up.
Retried restores do not double up. An IMAP restore whose connection drops fails and is retried on a fresh connection, where the Message-ID check skips what was already appended, instead of ending as completed with every remaining item failed. A retried SharePoint list restore in Keep both mode no longer adds the items that the interrupted attempt added, and a retried contacts restore in that mode no longer creates contacts twice. A restore into a mailbox given by address resolves the same mailbox that the API accepted (through the directory user’s address, never an orphaned or imported mailbox), so a duplicate address no longer picks another one.

Imported mailboxes

A mailbox you import from files appears in the Restore explorer like any other account, marked Imported: folder tree, search, preview, print view, download, and restore into an existing IMAP account or a Microsoft 365 mailbox. There is no original to restore into, so restoring to the original location is not available for it. See Mail file import and export.

SharePoint sites

A site is restored from the same Restore explorer (account type SharePoint sites, areas Libraries and 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, writable fields only. Permissions are kept as information and never restored, and a deleted site or library is not recreated. Only restore operators and administrators see sites. See SharePoint Online.

Servers and clients

Servers and clients are restored from their own pages, not from the mailbox Restore explorer: browse a backup, download files as a ZIP, or restore into a new folder on the machine, never over existing files. See Restore for servers and clients. Restore operators open these pages too (since 0.4.0): they read the restore points, browse them, download files and restore files onto a machine.

File shares, and Proxmox VE guests

File shares are restored from their own page, File shares (since 0.4.0): browse a restore point and download it as a ZIP, restore into a new folder, into the original location (overwrite, keep both or skip) or into another share, with the permissions where the target allows it. See File share restore. A Proxmox VE guest is restored as a new guest next to the original; the files of a container or a VM restore point can be browsed and downloaded as a ZIP under Servers & clients → File restore. See Proxmox VE backup.

Export as files

You can export a mailbox or folders from a backup, an imported mailbox or the archive as files: EML files in a ZIP (with MANIFEST.csv and SHA256SUMS) or as MBOX. The download link is valid for 24 hours, and every request and download is written to the audit log. See Mail file import and export.

Restore verification (recovery readiness)

A backup Restow has not read back is not treated as trustworthy. A scheduled restore check (weekly by default) reads back a random sample of items (for a SharePoint site, files of its libraries) from the latest backup through the restore path (the same chunk index, pack fetch and AES-256-GCM decryption a real restore uses) and compares their size and SHA-256 hash with the manifest, rating each protected object Ready, Attention or Not restorable; a backup nothing has read back yet is Not verified, whatever an earlier backup scored. It does not restore into a Microsoft 365 mailbox, OneDrive or IMAP account: the optional test restore into a target is not wired up in 0.4.7. See How Restow checks that a backup can be restored for exactly what is checked and what it does not check yet, First steps for running one by hand, and Backups and schedules for putting it on a schedule. Servers and clients are rated the same way, from a restore test of sample files: see Servers and clients.

Stated limits

Microsoft Teams is covered in part: chats and channel messages are not backed up and not restorable, in this version. The files of a team are in the document library of its SharePoint site and are backed up with that site; since 0.4.5 the calendar and the conversations of the Microsoft 365 group behind the team can be backed up as a group mailbox (opt-in).
IMAP sign-in is by password. Each IMAP source uses a shared login, a password per mailbox or a master account (see Connecting sources). OAuth2 for IMAP sources is not implemented yet; planned.
Microsoft 365 against a real tenant: backup and restore of Microsoft 365, SharePoint Online sites included, have not yet been run against a real Microsoft 365 tenant in the release checks. They are covered by tests against a simulated Microsoft Graph API (release smoke check 4 was skipped for lack of credentials). See Verifying a release. Restow uses only Microsoft Graph, never Exchange Web Services, which Microsoft switched off for Exchange Online on 1 October 2026.
Servers and clients are backed up file by file, not as disk images, and there is no bare-metal restore. The agent ships for Linux and macOS, but the release checks installed it only in a Linux container.
SharePoint Online: attachments of list items, site design, navigation, workflows and permissions are not restored (permissions are kept as information); a deleted site or library is not recreated; list items go back only into their original list. See SharePoint Online.
PST and OST files cannot be imported yet.
First backup of a large tenant: Microsoft throttles the Graph API, so a first backup can take days rather than hours. Restow shows this wait in the job’s progress instead of hiding it. From 0.3.5 a backup that is interrupted by its time limit (23 hours) or by a worker restart, after it saved a checkpoint, continues without using up one of its retries, for up to 21 days after it first started, and the run view shows such an interruption as information, not as an error. Since 0.4.0, a run that a restart or an update stops before its first checkpoint no longer uses up an attempt either, and the update dialog can stop Microsoft 365 and mail runs cleanly with a checkpoint (see Updates). 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. Since 0.4.7 a background job honours a Retry-After of up to 5 minutes (before, waits were capped at about a minute, and Exchange refuses a retry before its mailbox concurrency penalty is over); requests from the web interface keep the one-minute cap. A backup that Microsoft Graph or the storage still held back after all its retries reads Held back by the service, retried (amber), not failed: the next scheduled run tries again (Failure explanations).