Connecting sources

A source is where Restow backs up from. Restow supports two kinds: Microsoft 365 tenants (through Microsoft Graph: mail, calendars, contacts, OneDrives, since 0.4.0 SharePoint sites and, since 0.4.5, Microsoft 365 groups) and IMAP mailboxes (through IMAP, password-authenticated today; OAuth2 for IMAP sources is not implemented yet; planned). A third kind, Imported mail files, holds mail you bring in from files (see below). Servers, client computers, Proxmox VE guests and file shares are not sources: see Servers and clients are not sources. This page is the reference for how sources work day to day; for the exact, step-by-step walkthrough of connecting your first source, including the Entra app registration and its permissions, see First steps.

Microsoft 365

Restow talks to Microsoft 365 exclusively through the Microsoft Graph API. It never used Exchange Web Services (EWS), which Microsoft began switching off for Exchange Online in stages on 1 October 2026 (permanent retirement on 1 April 2027), and it does not use PowerShell remoting. Connecting a tenant uses the Entra admin-consent flow:

An administrator with the right privileges in the Microsoft 365 tenant grants Restow the permissions it asks for, scoped to what backup and restore actually need.
Restow checks the grant and reports exactly what was and was not consented to: a partial consent is shown as such, not silently treated as complete.
Once connected, Restow synchronizes the tenant’s directory (users, mailboxes, OneDrives, since 0.4.0 SharePoint sites and, since 0.4.5, Microsoft 365 groups) via Entra ID sync, on the protection scope you choose: all users, a specific group, everyone except an exclusion list, or only selected objects (mailboxes and OneDrives an admin picks individually, one at a time or through bulk Include, Exclude and “Follow the rules again” actions on the Protection tab of the tenant setup (Tenant settings → Protection), including “select all N matching” the active filter, up to 1,000 objects at once). A newly created source starts in the “all” or “group” scope; switch it to “only selected objects” afterward on the Protection tab if that’s what you want.

Connecting a source, or re-verifying one whose first sync never ran, queues that directory sync immediately, instead of waiting for the next scheduled run (up to six hours by default): a newly connected tenant’s mailboxes and OneDrives don’t sit empty in the meantime.

Backups then run incrementally using Microsoft Graph’s delta query support, so each run after the first only has to look at what changed. A newly protected object also gets its first backup queued automatically the moment it becomes active (an include, a directory sync finding it newly active, or, for IMAP, an account import) rather than waiting for the tenant’s next scheduled backup window.

Mailboxes and OneDrives are named by their person: the display name, else the address. The technical id is a tooltip. A SharePoint site is named by its title.

The first backup of a large mailbox shows First backup: X of Y items over all attempts, with an estimated time left; a OneDrive shows X items so far until it is fully listed, because Microsoft only names its item count after the full listing.

SharePoint Online

Since 0.4.0, every directory sync also finds the tenant’s SharePoint sites (sites 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 and runs in the mail jobs like a mailbox or a OneDrive. The protection rules have a sites mode: all sites (the default) or only the ones you select. Backup and restore are described on SharePoint Online.

SharePoint needs one more application permission, Sites.ReadWrite.All, on the backup’s app registration, and a new admin consent in every tenant that connected before: the customer’s admin opens the source’s consent link again (Create new consent link). Until then mail and OneDrive keep working, and the directory sync warns that sites are neither found nor backed up. The Entra walkthrough with the permission list is under First steps.

Microsoft 365 groups (since 0.4.5)

Since 0.4.5 Restow backs up the calendar and the conversations of Microsoft 365 groups, and of the groups behind Teams, as protected objects of their own kind, group. Every Microsoft 365 group has a group mailbox with one calendar and its conversations; security groups and distribution lists have none and are skipped. The files of a team stay in its SharePoint site (SharePoint Online); the chats and channel messages of Teams are not backed up.

Opt-in. Group mailboxes are not backed up unless you ask for them. The protection rules (Tenant settings → Protection → Sources and rules → Edit rules) have a switch Protect all Microsoft 365 groups (groups is selected by default, or all), and single groups can be included in the list of protected objects. That differs from SharePoint sites on purpose: a tenant with thousands of groups should not back them all up unasked after an update. A mail job with the scope “all” covers every protected group, like sites; a job with selected objects, the groups you chose. A newly protected group gets its first backup at once. Group mailboxes never count as protected mailboxes.
Finding them. The directory sync reads groups/delta as a second delta stream next to the users: a full enumeration on the first and every full sync, only the changes in between. It keeps only Microsoft 365 groups; a group that was deleted becomes an orphan and keeps its restore points. The first sync after the update to 0.4.5 reads the groups of every Microsoft 365 source once in full.
No new permission and no new admin consent. Groups use Group.Read.All and Calendars.ReadWrite, which the backup app always needed. If the tenant has not granted Group.Read.All, the directory sync warns that groups are not read (“Microsoft 365 groups are not read: the tenant has not granted the backup app Group.Read.All”) and leaves the groups it knows as they are: open the consent link again.
The calendar is backed up through the same code as a user’s calendar (series masters with their exceptions). Where Microsoft Graph refuses the event listing to an app, Restow falls back to the group’s calendarView and reads each series master once; that fallback cannot see events before its window. A calendar that Graph refuses entirely, also through an Exchange application access policy that excludes group mailboxes, is a warning on the run, not a failure, and the conversations are still backed up.
The conversations. Every post of every conversation is stored as an RFC 5322 message under mail/Conversations, with its file attachments when Graph hands them out (otherwise their absence is recorded). Only threads with new posts are read again. A group that no longer exists fails with the explanation This Microsoft 365 group no longer exists (graph.group_unavailable, see Failure explanations); the backups that exist stay restorable.
Restore. The Restore explorer lists groups in the section SharePoint & Teams with the areas Group calendar and Conversations. Download (EML, JSON) and export (EML, MBOX, PST) work as for mailboxes. A restore into a user’s mailbox brings back the events and the conversations; a restore into the group brings back calendar events only, because Microsoft Graph lets no app post into a group conversation (the report lists each post as not restorable). See Backup and restore.
Checks and the dashboard. The restore check, the ransomware signals and retention work as for mailboxes, and the dashboard lists group calendars and conversations among the last backups.
Not tested against a real tenant. Group calendars and conversations were tested against a simulated Graph API only, and which calendar reads Graph allows an app on a group can differ by tenant (known issues of 0.4.5).

Archive capture from Microsoft 365 mailboxes

Since 0.4.4 Restow can archive the mailboxes of a Microsoft 365 source by Graph change notifications: Microsoft tells Restow that a mail arrived, and the worker fetches it within minutes. It is near-time and not complete (see Archiving). What it needs from Microsoft 365 and from your network:

Permissions and consent: nothing new.

It uses the application permission Mail.ReadWrite that backup and restore already have. Subscribing to new mail in users/{id}/messages and fetching the mail are covered by it.
No new admin consent and no change to the app registration. A tenant that is connected for backup is ready. A change notification here carries no resource data, only the fact that a mail exists, so Restow needs no encryption certificate either.
A subscription belongs to the app that created it. If you connect the source with a different Entra app (the installation’s multi-tenant app or the source’s own app), Restow checks that every five minutes and creates the subscriptions again for the new app.
Microsoft allows 1000 subscriptions per mailbox across all apps; Restow uses one per archived mailbox.

The network: Microsoft calls into your installation. This is the one place where a connection comes from Microsoft. Microsoft Graph sends each notification as an HTTPS POST to two public addresses of your installation:

https://restow.example.com/api/v1/hooks/graph/notifications
https://restow.example.com/api/v1/hooks/graph/lifecycle

For this to work:

The public URL of the installation must be https://, with no port or port 443, on a name that Microsoft can resolve from the internet: not localhost, not a private address, not a name ending in .local, .internal or .lan. Restow takes the URL from Installation → Server & operation → Server if it is set there, else from RESTOW_PUBLIC_URL. The certificate must be one that Microsoft can validate when it checks the address; the Caddy edge with its own Let’s Encrypt certificate does that.
TCP 443 must be reachable from the internet to the web edge. A public installation has this already, because the agents need it. A host in a LAN behind a reverse proxy needs the proxy to pass /api/v1/hooks/graph/ through to Restow unchanged: POST requests, no sign-in or single sign-on in front of the path, no filter that keeps Microsoft out, and a body of at least 1 MiB (Restow rejects bigger bodies itself). See Network and ports.
The hooks answer fast, because Microsoft waits only seconds: the validation request when a subscription is created is answered with its token within 10 seconds, a notification with 202 within 3. Restow checks each notification against the subscription’s secret (clientState, stored only as a SHA-256 hash) and ignores anything else, also with 202. A notification never carries mail; it only queues a fetch.
Restow does not check the sender address of a notification; the secret decides. Restow ships no list of Microsoft’s source addresses for these calls, so do not restrict the hooks by source address unless you maintain Microsoft’s current list yourself.

Without a public HTTPS URL (a LAN-only or local installation, or a name Microsoft cannot reach) nothing breaks: Restow does not create subscriptions and checks every mailbox for changes every 15 minutes instead (ARCHIVE_GRAPH_POLL_MINUTES). The archive page says so, with the reason graph.notification_url_unavailable. If Microsoft refuses a subscription (for example because it cannot validate the address), the mailbox is checked at intervals meanwhile (graph.subscription_failed) and Restow tries again every hour. Even with notifications, a catch-up over every folder runs every 6 hours (ARCHIVE_GRAPH_CATCHUP_MINUTES) and at once after a missed notification.

Outbound, nothing changes: login.microsoftonline.com and graph.microsoft.com as for backup. Restow follows Microsoft’s throttling (429 with Retry-After) and creates and renews subscriptions in batches of at most 20, one batch per second and Microsoft tenant.

In the tenant, a retention policy or a litigation hold should keep deleted mail, so that mail deleted right after delivery is still captured. Graph v1.0 offers no way to read that. An administrator checks it with the read-only Exchange Online PowerShell commands that the archive page shows and confirms it per source; see Archiving. Restow reads only the deletions folder of the Recoverable Items. Mail purged before Restow fetched it can be missing, and Graph cannot export mail over about 150 MB (it is logged and not archived).

Notification mail through the backup app

If notification mail goes through the backup’s app registration (the Microsoft Graph transport, permission Mail.Send) from a tenant that never gave the app admin consent, the test of the notification mail says that the backup app has no admin consent in the sender mailbox’s tenant, and links the admin consent. Before 0.4.0 it reported “app not found” and asked you to check IDs that were right. See Notifications and reports.

Objects that are no longer backed up (since 0.4.7)

Since 0.4.7 Restow no longer lets a mailbox, OneDrive, SharePoint site or group mailbox fail every night when the source itself says there is nothing to back up. The object is marked Not backed up with the reason, its backups are kept, and an administrator is asked to confirm that this is intended. IMAP accounts are never marked this way: they have no directory sync, you maintain them by hand.

What the source reports	Label	`statusReason` in the API
The account is disabled and Exchange Online hosts no mailbox for it	Not backed up: account disabled	`account_disabled`
The account has no Exchange Online license (the mailbox was never provisioned, the license was removed, or the mailbox is inactive)	Not backed up: no licence	`no_license`
Microsoft locked the OneDrive or the site (HTTP 423, “Access to this site has been blocked”; Microsoft does this to the OneDrive of an unlicensed account after a while, and an administrator can lock a site)	Not backed up: locked	`locked`
The object no longer exists in the source	No longer in the source	`null` (status `orphaned` without a reason)

How Restow finds out. The directory sync probes the mailbox of each user, and the backup asks Microsoft once more before it marks anything: the user must still exist and Exchange must clearly say that there is no mailbox. Only Exchange’s answer counts, not the flag of the account: a disabled account whose mailbox Microsoft still serves (a shared mailbox, a former employee) is backed up as before. A 401 or 403 is never read this way; those stay permission failures. A lock is confirmed by one cheap read of the drive or site; a 423 that this read does not confirm stays a counted failure with its backup.failed alert, and a 423 on a single file stays an item problem. A site whose libraries all answer 423 ends without a restore point instead of carrying old copies forward.
What it means. No failure and no red readiness because of the age of the last backup, never overdue, no backup.failed alert and no job.failed webhook. Existing restore points stay restorable, and a restore into the original mailbox of such an account is refused with the reason (Backup and restore). The scheduler plans no run for the object.
It resumes by itself. Backups start again right after the directory sync that finds the account enabled or licensed again, or the lock lifted. The sync never turns a locked object active just because it is still listed: it reads each locked drive or site once more and resumes only when that read succeeds; otherwise the object stays locked and the sync reports that the check failed (lock_probe_failed).
Please confirm. Until an administrator confirms, the object reads amber, Not backed up any more, please confirm, with the reason and the date. It is no failure, but the warnings, the dashboard and the tenant’s recovery readiness stay at least yellow (never green), and a provider sees inactive_to_confirm among the tenant’s alerts. The dashboard card, the Warnings page and a banner on the list of protected objects lead there (Check and confirm, Show).
Yes, intended. An administrator confirms per object, or for several in the list of protected objects, by selecting rows or by the list’s filter (at most 1000 at once, behind a confirmation naming the count). The list filters by the states Not backed up any more, please confirm and Intentionally no longer backed up. Confirmed objects read grey, Intentionally no longer backed up, with who confirmed it and when. Tenant administrators and the provider roles that may configure (administrators and owners) may confirm; every confirmation is audited (directory.inactive.confirmed, directory.inactive.bulk_confirmed). The interface asks for no reason; through the API a confirmation can carry a note of up to 1000 characters for the audit log (API reference).
When it is active again, the confirmation is dropped and backups resume; if the object stops again later, Restow asks again. An object that was excluded and then disappears from the source was never backed up and counts as confirmed (Was excluded and never backed up). After the update to 0.4.7, objects that were already orphaned count as confirmed (Already not backed up before the update) and raise no notice.
Notices. The event Object no longer backed up, please confirm (object.inactive) is raised once per object and transition, a notice that shows in the bell by default. When more than 10 objects, or more than 20% of the objects of a tenant that were backed up before (and at least two), stop within a day, one warning per tenant and day, Many objects no longer backed up (object.inactive_many), replaces the notices, for example because licenses were removed or the sync scope is wrong. Both link to the objects that wait. See Notifications and reports.

The detection was tested against a simulated Microsoft Graph API, not against a real tenant; an answer of Microsoft that Restow does not recognise as “no mailbox” or as a lock stays a counted failure, as before (Upgrading to 0.4.7).

Reminders before an app credential expires (since 0.4.7)

A client secret or certificate of an app registration runs out, and from that day every Microsoft 365 backup that uses the app fails. Since 0.4.7 Restow reminds you 30 days before, again 7 days before and once it has expired, each stage once per expiry date. A new date (a new secret or certificate, a changed date) or another registration starts over, and a date first seen late raises only the stage it is in. Restow does not read the date from Microsoft Graph: that would need Application.Read.All, which it does not ask for. You enter it, or Restow reads the certificate’s own end (notAfter).

The central app (Installation → Microsoft multi-tenant app): enter the secret’s expiry date in the field Expires on, or set ENTRA_CLIENT_SECRET_EXPIRES_AT (YYYY-MM-DD, as Entra shows it) when the secret comes from .env, and restart the api. The api checks every 15 minutes (the first time two minutes after it starts; not in the public demo) and raises the installation event Microsoft 365 app credential expires (installation.app_secret_expiring, a warning, an error once expired) for the provider administrators: in the bell, and in the mails and webhooks of every rule that lists it. The page shows Expires with a badge that turns amber 30 days before the end and red from 7 days (counted in whole calendar days, UTC), and, for a secret from the environment without a date, how to set it.
A source with an app of its own (connection method Own Graph app): the form has Secret expires on (optional), and the source’s connection card shows Expires with the same badge and, within 30 days or once expired, what to do. For a client secret the date can be noted, changed or removed there without entering the secret again (Note expiry date, Change expiry date; audited as source.own_app.expiry_updated). The worker checks every Microsoft 365 source of an active tenant that is not disabled (also one in error) every five minutes and raises Own app credential of a source expires (source.app_secret_expiring), which tenant administrators can choose as well. A source connected through its own app before 0.4.7 has no date until you note it; a certificate gets its date when it is entered again. A source with an older own secret but without an own app (a shared client ID) has no date in Restow: switch it to an own app or to the central app.
What the reminders say. The bell names the stage (“expires in 5 days”, “Renew it now”, “has expired”) and leads to the source’s page or to Installation → Microsoft multi-tenant app. The alert mail lists the expiry date, the days left, the kind of credential, the application (client) ID and how to renew without a gap: create the new secret, enter it with its new date, and only then delete the old one in Entra. Both events are part of the Errors and warnings choice of the notification matrix and of the bell’s default, and each stage passes a rule’s throttle on its own.

IMAP

For an IMAP source, you provide the server (host, port, security) and how the source signs in. Today that means username and password authentication. Because IMAP-only mailboxes do not have an Entra directory to sync from, you add them as a manual list or import them from a CSV file (login, name, email columns, plus an optional password column).

Each source uses one of three sign-in modes:

Shared login (the default): one login and password on the source, used for every mailbox under it. This fits an app password or a backup account that your provider lets open all mailboxes.
Own password per mailbox: for providers where every mailbox has its own password and there is no master account. The source itself has no login to test. You add the mailboxes, then use Set password and Test sign-in on each mailbox in the Directory tab. A mailbox without a password cannot be signed in to, so it is not backed up until one is set.
Master user: one master account signs in as each mailbox, either in the master*mailbox form that Dovecot uses or as SASL PLAIN with an authorization ID. Your IMAP server has to support one of the two.

OAuth2 for IMAP sources (including Microsoft 365 and Google mailboxes reached over IMAP instead of Graph) is not implemented yet; planned. The same holds for archiving the account.

Archiving IMAP and Google Workspace accounts

Since 0.4.4 Restow can archive IMAP accounts continuously. It is near-time and not complete; where the provider can forward a copy, forwarding is the stronger way, and both can run together (what both capture is archived once).

What it reads. Every folder you can select except Drafts, also Sent, Trash and Spam. On Gmail and Google Workspace only All Mail, Spam and Trash, which hold every mail exactly once (Gmail would otherwise show a mail once per label). Restow recognizes a Google account by its host (imap.gmail.com, imap.googlemail.com) or by an OAuth2 source of Google; that decides which ways the job editor offers. When it reads the account, it also recognizes Gmail’s folder list ([Gmail]/All Mail).
How it notices new mail. On activation Restow records where every folder stands. Mail up to there is taken over once; after that it reads only what is new. With IMAP IDLE the server tells Restow within moments; every 5 minutes (ARCHIVE_IMAP_POLL_MINUTES) the same connection checks the other folders, and every 30 minutes a full pass runs as a safety net. Without IDLE, an account is checked by a login every 10 minutes (ARCHIVE_IMAP_LOGIN_POLL_MINUTES). The archive page says which accounts are polled and why: imap.idle_unsupported (the server has no IDLE), imap.idle_disabled (switched off for the source) or imap.idle_budget (no free place for it).
Sign-in is as for backup. Archiving uses the same credentials as the backup of the account (shared login, own password per mailbox or master user). Restow signs in with a password only: OAuth2 for IMAP sources is not available yet in the API or the interface, and Restow does not create or ask for app passwords. For a Google Workspace account that means a password that Google accepts for IMAP; whether that needs an app password depends on Google’s rules for your Workspace, which Restow cannot see. IMAP must be allowed for the account.
IMAP on a Microsoft host (outlook.office365.com and others) is archived like any account, but connecting the tenant as a Microsoft 365 source captures its mailboxes more completely. The job editor says so.

Connections: plan the limit of your provider. Many providers limit simultaneous connections per account (Gmail 15, Exchange Online 20, many hosters 2 to 5).

With IDLE, Restow keeps one connection per account open all the time. During a pass or a takeover it uses a second one briefly, and a running backup uses up to two more, so one account can use up to four connections at the same time. The mail clients of your users need their own.
Each worker process watches up to ARCHIVE_IMAP_IDLE_MAX accounts with IDLE (300; 0 switches IDLE off). More accounts than that are checked by a login at intervals.
For a provider with a tight limit, open the source and set Archiving → Watch accounts with IMAP IDLE to Check at intervals only. No connection then stays open; Restow checks the accounts for new mail every few minutes. The workers take the setting over within a minute. Through the API it is PATCH /api/v1/sources/:id with {"archiveIdle": "off"} ("auto" is the default).

Forwarding copies from the mail provider

For providers without Exchange journaling, the provider itself can send a copy of every incoming and outgoing mail to Restow while it transports the mail. That captures mail before a user can delete it, which is stronger than IMAP archiving, and it needs no IMAP connection. It has two halves: rules at the provider, and a receiver on your side. Restow cannot set the rules; it generates the addresses and the configuration to copy.

What you set up as the operator. The receiver is the SMTP receiver of the journal setup, so you do this once for journaling and forwarding together; the steps are on Exchange journaling and TLS certificate:

In .env: JOURNAL_SMTP_PORT=25, JOURNAL_SMTP_BIND=0.0.0.0 (release stack) and JOURNAL_HOSTNAME=archive.example.com, the host name only. Restart the api.
DNS: an A or AAAA record for that host name (or an MX record that points to a host with one) that leads to this server.
Open TCP 25 inbound from the internet (or from your provider’s mail servers) straight to the receiver, never through Caddy (Network and ports).
A TLS certificate from a publicly trusted authority for that host name (JOURNAL_TLS_CERT_PATH, JOURNAL_TLS_KEY_PATH). STARTTLS is mandatory: the receiver refuses a sender that does not upgrade to TLS (530), so the provider’s mail server must be able to use it. Without a valid certificate the receiver does not start.
If a hoster forwards the mail of many accounts, the limits per sending IP address (JOURNAL_RATE_PER_IP, 600 connections per minute) and per archive address (JOURNAL_RATE_PER_ADDRESS, 300 deliveries per minute) are per api process; raise them if copies are refused with 421 or 451.

Two kinds of address. Rules are written per account or per domain, so Restow has two:

Archive address of an account: archive+<token>@<journal host>. A copy to it belongs to exactly that IMAP account, which makes the assignment certain. Use it for rules per account.
The tenant’s journal address: journal+<token>@<journal host>, the one of Exchange journaling. A copy to it is assigned to the mailboxes whose address stands in the copy’s headers (From, To, Cc, Delivered-To and others) or in MAIL FROM. Use it for rules for a whole domain, and for Google Workspace.

What you set up at the provider. In the mail job, choose Forwarding to the archive address (IMAP) or Routing to the archive address (Google Workspace) for the account’s kind. On the Archive page, in Forwarding to the archive, press Create address for each account (an address is issued once). The tabs Postfix, mailcow, Sieve and Google Workspace then show the configuration with the addresses filled in:

Postfix (a server of your own): one line per account in sender_bcc_maps (outgoing mail) and recipient_bcc_maps (incoming mail), for example anna@example.com archive+<token>@archive.example.com; then postmap and postfix reload. For all accounts of a domain at once, always_bcc to the tenant’s journal address.
mailcow: under E-Mail, Configuration, BCC, add a BCC map for each mailbox, once of the type sender and once of the type recipient, with the account’s archive address as the target.
Sieve (Dovecot Pigeonhole, many hosters): in the account’s filter, require ["copy"]; redirect :copy "archive+<token>@archive.example.com";. Sieve sees incoming mail only; outgoing mail comes in through IMAP archiving.
Google Workspace: in the Admin console under Apps, Google Workspace, Gmail, Routing, add a rule for inbound, outbound, internal sending and internal receiving messages, and under Also deliver to choose Add more recipients with the tenant’s journal address. The address is created in the Exchange journaling section of the archive page, which needs a valid journal host; open that section once. Changes can take up to an hour. Forwarding set by a single user in Gmail is not supported: it needs a confirmation in the mailbox and the user can switch it off.

Check it. The status of each account reads Copies arriving, No copies yet or No copy for over 24 hours, with the counts of 24 hours and 7 days. An account that received copies before and gets none for 24 hours raises the alert No forwarded copies for 24 hours (Notifications and reports).

Limits of a forwarded copy. It has no envelope like a journal report, so BCC recipients are visible only if the provider writes them into a header (Delivered-To, X-Original-To). MAIL FROM is often an SRS address of the forwarder. The receiver does not check the sender (SPF); the random token in the address is the secret. If you renew an archive address, the old one stops working at once and copies sent to it are refused: change the rule at the provider immediately. One SMTP transaction delivers into one tenant’s archive.

Imported mail files

Imported mail files is a source that holds mail you bring in from files instead of syncing it from a server: EML files, folders or ZIP archives, MSG, MBOX (Thunderbird, Apple Mail) and MailStore exports in EML or MSG form. There is one per tenant, with no server and no credentials. Add it under Tenant settings → Connections → Add source → Import mail files, then upload files in the browser or pick files from the tenant’s folder on the server.

Nothing is backed up from this source, because there is no mailbox to read from. Each import instead produces an imported mailbox that you browse and restore in the Restore explorer, export as files, and optionally ingest into the archive. See Mail file import and export.

Servers and clients are not sources

Servers and client computers are not sources. They are endpoints: a small agent on the machine sends file backups to your Restow instance, and you set them up in the section for endpoint backup, not under Sources. See Endpoint backup. The VMs and containers of Proxmox VE are not sources either: you connect the Proxmox VE nodes under Servers & clients → VMs & containers. See Proxmox VE backup. File servers are not sources either: since 0.4.0 Restow backs up their SMB and NFS shares from the server, like Proxmox VE guests, without an agent on the file server, and you add them as file shares. See File shares.

What connecting a source does not do

Connecting a source does not immediately expose any mailbox data anywhere in the Restow UI beyond backup status: end users only ever see their own data after they sign in themselves (see For end users), and every administrator read of user data is written to the audit log.