Status and roadmap

Restow is in beta; 0.4.7 (29 October 2026) is the current release, and 0.1.0 was the first public release. 0.3.0 was tagged but never published: its release checks found the first two fixes, so 0.3.1 is the first release of the 0.3 line. This page states plainly what exists today and what does not, instead of leaving it implied. Planned items carry no version numbers and no dates, and a feature counts as shipped when it is in a published release, not before. 0.4.0 shipped other things than the earlier plan had for it, so everything that has not shipped sits under Next or Later.

Shipped (0.4.0 to 0.4.7), file shares, immutable backups, ransomware detection, SharePoint, archive capture from the mailbox, Microsoft 365 groups, update terms for license keys, objects that are no longer backed up, expiry reminders

0.4.0 and 0.4.1 were published on 16 October 2026, the next release of the line on 21 October 2026 (0.4.2) and the one after on 22 October 2026 (0.4.3) and the next on the same day (0.4.4), on 23 October 2026 the next (0.4.5) and the same day the one after (0.4.6), and on 29 October 2026 the next (0.4.7); 0.4.7 is the current version. Updating to 0.4.0 runs seventeen database migrations (0035 to 0051): read the release notes of 0.4.0 first. File share backup and the database move need the docker-compose.yml of 0.4.0, so run the 0.4.0 installer again after the update (see Running it again). SharePoint needs an added application permission and a new admin consent per tenant. Updating to 0.4.1 runs one more migration, 0052_pve_guest_repository_bytes, which only adds two columns and runs in seconds; updating to 0.4.2 runs six more (0053 to 0058), which add a table, columns and indexes and run in seconds; updating to 0.4.3 runs none; updating to 0.4.4 runs four more (0059 to 0062), which add the tables of the archive capture, new columns and indexes on archive_items and backup_jobs, two indexes on manifest_versions for the restore explorer and the capture ways of the mail jobs that already archive. The indexes are built inside the migration, where writes to the table wait (about a minute per ten million rows on SSD storage), so plan the update of a large installation outside the backup window; see Updates. Mail jobs that archived before 0.4.4 keep doing exactly that: nothing new starts by itself until an administrator switches Graph or IMAP archiving on in the job. Updating to 0.4.5 runs three more migrations (0063 to 0065: three nullable columns on the license table, the removal state of a machine on endpoints with a partial index over the removals that are due, and the protected object kind group); none of them rewrites a table. Microsoft 365 groups are opt-in: after the update no group is backed up until the protection rules switch “Protect all Microsoft 365 groups” on or single groups are included, and the first directory sync reads the groups of every Microsoft 365 source once in full. Every license key issued so far is a beta license and keeps covering every 0.x and 1.x release; since 0.4.5, a release that is started by hand and that a Business or Service Provider key does not cover stops before its migrations (see License and editions). Updating to 0.4.6 runs no migration; update restow-pve on every Proxmox VE node (the server offers it after its own update, and nodes update themselves when idle) before relying on container restores or boot tests. Updating to 0.4.7 runs four more migrations (0066 to 0069: two nullable columns on pve_guests, the column settings.pricing, the column settings.app_secret_alerts, and five nullable columns on protected_objects with two check constraints and a trigger that keeps them in step with the object’s status); none of them rewrites a table, and restow-pve needs no update. The update excludes no Proxmox VE guest and sets no price, and objects that were already orphaned count as confirmed. Disabled and unlicensed mailboxes and locked OneDrives and sites that failed every night are recognised by the first directory sync or backup after the update (a locked site by its first backup): expect one notice for each (an unlicensed user often has two, mailbox and OneDrive), or one warning for a tenant with many, and confirm them under protected objects once they are intended. Sources connected through their own app before 0.4.7 have no expiry date, so no reminder, until it is noted on the source’s page (“Expires”); a central app whose secret comes from the environment needs ENTRA_CLIENT_SECRET_EXPIRES_AT in .env and a restart of the api. Webhooks and notification recipients get the new events only once they are ticked in the notification matrix. The docker-compose.yml of 0.4.0 stays. Since 0.4.2, after a server update new runs wait while Proxmox VE nodes and agents install it (15 minutes at most); after an update by hand, “Update nodes and agents now” starts that step (since 0.4.3). Rolling back needs the database dump taken before the update. Unless marked otherwise, everything below is part of every edition (the Community core).

• File share backup (SMB and NFS) (0.4.0): Restow backs up an SMB share (Windows Server, Samba, a NAS) or an NFS export from the server, without an agent on the file server. It mounts the share read-only for one run in a short-lived runner container that the mounter starts, and backs it up with restic into a repository of its own. NTFS permissions (NFSv4 and POSIX ACLs on a best-effort basis) are kept in each restore point; open, unreadable and offline files are skipped and listed, and the run ends with warnings. Restore from a restore point as a ZIP, to a new folder, to the original location (overwrite, keep both, skip) or into another share, with permissions where the target allows it. SMB 2.1 to 3.1.1; SMB1 and NTLMv1 are refused. New installations start the mounter by default; an existing installation gets it through Enable network shares (opt-in updater). See File shares and Network shares.
• File share restore checks, copy jobs and budgets (0.4.0): every new restore point is checked by reading up to 20 sampled files back, the repository gets a weekly restic check of 5 percent of its data, and recovery readiness rates a share by its newest restore point. Copy jobs write the newest checked restore point of one share into a folder of another (mode overwrite or mirror) and are labelled as not being a backup. Budgets per share, per tenant and as a default (off by default, set by provider admins) warn at 80 percent and refuse new backups at 100 percent. File shares count in the status tab, the start page, readiness, warnings, history, statistics and the provider view. See File share restore, Copy jobs and Budgets and runners.
• Immutable backups (0.4.0): immutability per repository, off until an administrator turns it on. On S3, Object Lock (compliance or governance, 1 to 3650 days) locks the packs, manifests and wrapped keys of the chunk store (Microsoft 365, IMAP, Proxmox VE disks) and the objects of every restic repository (machines, file shares, Proxmox VE containers); Restow checks the bucket first, renews the lock of data that is still in use and never sends the governance bypass header. For directories (the Docker volume, an NFS share) a deletion delay makes Restow’s own code refuse to delete or overwrite a file until the period has passed; it protects against misuse of Restow, not against someone with access to the server, and the interface says that it is not immutability. Restore points show “Immutable until <date>”, green only for a compliance retention that the storage itself reported. Lowering the protection needs the provider owner with a recent sign-in. See Immutable backups.
• Ransomware detection with a retention hold (0.4.0): every new restore point of a machine, file share, Proxmox VE guest, mailbox, OneDrive, SharePoint site or IMAP account is judged for signs of ransomware from data the backup already has (the amount of change against the object’s own history, mass deletions, renamed extensions, known ransomware extensions and ransom notes, the entropy of sampled new files, the compression and deduplication ratio of the new data). A suspicious restore point gets a badge, and the restore views offer the newest one without findings. While it is unresolved, a retention hold stops retention and pruning of that object; only an administrator ends it (mark as false alarm, or release the hold, audited). It never reads the data a second time, never blocks a backup and is no virus scanner. Some signals need agent 0.4.0 on machines or restow-pve 0.4.0 on the node, and a signal without data says “not available”, never clean. It is on after the update; thresholds and switches are under Installation → Ransomware detection. See Ransomware detection.
• S3 endpoints need HTTPS (0.4.0): a new or changed S3 endpoint over plain http:// is refused, except to localhost, 127.0.0.1 and [::1]. Endpoints saved before keep working and say in red that they should move to HTTPS; S3_ALLOW_INSECURE=true accepts plain HTTP for test and development setups only.
• Notification matrix (0.4.0): under Integrations → Notifications the events are rows and the bell, every webhook and every notification recipient are columns, each with the quick choices “Errors only”, “Errors and warnings” and “All”. The update fills every column with exactly what the channel received before; a webhook created afterwards starts with the defaults of its format. New events: backup.succeeded and verify.completed, backup.suspicious and backup.suspicious_hold, boot_test.failed and boot_test.unproven, and installation.disk_low for provider admins. See Alerts and reports.
• Proxmox VE (preview): progress, boot tests, file restore, jobs (0.4.0, every edition, restow-pve 0.4.0 on the node): running backups show a progress bar and the helper’s own lines reach the run’s log; a Proxmox VE job can boot the newest restore point of each guest weekly or after every backup in isolation (off by default; green when the guest agent answered, yellow when the VM only started, red when it failed), and Boot test now asks for one by hand; Servers & clients → File restore lists every container with a restore point and, marked Preview, every VM, to browse and download files and folders as one ZIP (btrfs, ZFS, ReFS, LVM thin, RAID, BitLocker and LUKS are not readable; compare an important file with the original before relying on it); Proxmox VE jobs appear under Servers & clients → Jobs next to the machine jobs. Proxmox VE stays a preview in every edition, tested against the simulated node of the test suites, not against a real Proxmox VE cluster. See Boot tests and File restore.
• Agent policies (0.4.0): rules for the agents on servers and clients on three levels, the installation, the tenant and the backup job, each overriding the one above unless the installation locks it: a backup window, catching up missed backups, an upload limit, only on AC power and the number of automatic retries (0 to 10). A machine’s page shows the policy that applies to it and why a due backup waits. Window, catch-up, retries and the waiting reason need agent 0.4.0. See Agent policies.
• File restore for the restore role (0.4.0): restore operators open Servers & clients → File restore, read the restore points of machines and Proxmox VE guests and their immutability, browse them, download files as a ZIP and restore files onto a machine; settings, tokens, jobs, backing up, verify and boot tests, restoring a whole guest and revoking or deleting stay with the administrators. Every read, download and restore is audited.
• Data folders a job misses (0.4.0): the agent 0.4.0 reports which of a fixed list of Linux data folders exist and hold files (names only); the job editor names the folders the job’s machines really have and leaves out, and a machine’s page offers Add this folder to the job. A machine’s page says what it runs as (container, virtual machine, physical, with or without a desktop).
• Create recommended job (0.4.0): next to every “no job” notice and as “Protect everything without a job” on the dashboard’s readiness card, a preview of what the click creates or adds to, then one job per kind (mail, machines, Proxmox VE). Admins only, audited.
• Live view and dashboard (0.4.0): running backups in the sidebar with a spinner and a count, a livelier run drawer, “First backup: X of Y items” for a large mailbox, and Storage growth on the dashboard over 1 week to 1 year, with, where the free space is known, when the repository runs full at this growth. Service Provider adds All tenants in Jobs: every tenant with its jobs per kind, what runs and waits and the next run.
• SharePoint Online (0.4.0): every directory sync finds the tenant’s sites (sites of Microsoft 365 groups and Teams included, personal sites left to their owner’s OneDrive), and each site is a protected object of its own, in the mail jobs. A backup holds every document library, every list with its columns and each item’s field values as JSON, and the site’s description; restore in the explorer as a ZIP, into the original or another library (keep both, overwrite with SharePoint keeping the old file as a version, or skip existing) and list items as new items into their original list. Not backed up: Teams chats, attachments of list items, site design, navigation and workflows; permissions are kept as information and never restored. Needs Sites.ReadWrite.All (Sites.Read.All is enough to back up) and a new admin consent per tenant. See SharePoint Online.
• Runs in progress during an update (0.4.0): the install dialog counts what runs and waits in every tenant and asks: Stop them cleanly (the default), Wait until they finish (two hours at most) or Do not wait. From the confirmation until the update is over no new run starts; agents 0.4.0 hold their own schedules, older agents do not. A Proxmox VE backup that runs while Restow updates no longer fails. See Updates.
• Move the database, low disk space warning, kept dumps (0.4.0): Installation → Database shows where the database keeps its data and, with the opt-in updater, lets the provider owner move it to a directory on another disk (checked, copied, compared, test-started and switched, with automatic rollback); every 15 minutes the API checks the disk under the database and under the local default repository and warns provider admins below a tenth free, and always below 5 GiB; the Updates tab lists the pre-update dumps. The update preflight now adds up what an update writes and refuses one that does not fit. See Database.
• Integration API contract 1.4.0 (0.4.0, additive): GET /api/v1/status has fileShares and the readiness summary sharesWithoutJob, and events is optional when a webhook is created.
• Performance on large installations (0.4.0): memory stays bounded for file share catalogs of millions of files, SMB permission reuse, SharePoint sites with thousands of lists, large VM disk maps and Object Lock renewal.
• Stored data counts the restic repositories (0.4.1): Stored on Repositories → Usage, the dashboard, the statistics and the API now add the restic repositories of machines, file shares and Proxmox VE containers to the chunk store; before, a tenant with 10 GB of container backups saw “Stored 10.9 kB”. The deduplication saving, the growth and the chart stay figures of the chunk store, and say so.
• Proxmox VE (preview): an old node helper is named (0.4.1): a running container backup on a node with restow-pve before 0.4.0 says that progress needs 0.4.0, which version the node runs and to update the node; restow-pve now asks for an update two minutes after it starts, then every six hours.
• Stop a backup from the web app (0.4.2): Proxmox VE: “Stop backup” in the VMs & containers table, on the guest’s page and in the run drawer stops a running backup (the node ends the vzdump task through the Proxmox VE API, a backup started in Proxmox VE itself included) and “Withdraw” takes a queued one out at once. Per node, “Pause queue” and “Cancel all queued”, also for the whole tenant. Servers and clients: “Stop backup” on the machine’s page and in the run drawer; the agent stops restic cleanly with its next contact, within about a minute. Runs of file shares can be cancelled from the run drawer as well (Microsoft 365 and IMAP runs already could). A stopped run ends as cancelled, not as failed: no failure alert, and it does not count as the last backup. Every stop asks first and is audited. It needs restow-pve from 0.4.2 on the node and the agent from 0.4.2 on the machine; an older node ends a cancelled backup at its next upload, an older agent finishes it.
• Nodes and agents follow a server update (0.4.2): After the server runs the new release, new runs stay paused while Proxmox VE nodes and agents install it (they are idle then), until every reachable one reports it or 15 minutes have passed. Installation → Updates shows their progress and, for the ones not reached, the command for an update by hand. “Update to X.Y.Z” on a node’s page and on a machine’s page asks for the update at any time. restow-agent update on a machine installs the offered release at once, like restow-pve update on a node, through the same signed download as the automatic self-update; while a backup runs it refuses, and the agent updates itself once idle.
• Planned updates and a time zone of the installation (0.4.2): An update can be planned for a chosen date and time, up to 30 days ahead, besides the lead times from now: nothing pauses before, and everyone signed in sees a notice from a day before. The time is read in the installation’s time zone, which is chosen in the setup wizard (the browser’s zone preselected) and changed by an owner under Installation → Server & operation → Server; a new tenant starts with it. An installation set up before 0.4.2 keeps using RESTOW_TIME_ZONE, then TZ, then Europe/Berlin until an owner chooses one. When an update is available, the version in the sidebar becomes a highlighted “Update to X.Y.Z available” that leads to Installation → Updates, for those who may install updates.
• Proxmox VE: every new restore point is checked within minutes (0.4.2): Proxmox VE preview, in every edition. A new restore point of a VM or container is read back within minutes of its backup (a sample of its blocks, for a container a restic check of a subset), a bounded number per pass, besides the weekly check of every guest. The setting “Check every new restore point right after the backup” (Installation → Proxmox VE, owner) is on by default; off, a new restore point waits for the weekly check. Recovery readiness has “Check now” per guest and “Check all unverified”. A red check shows the error it found, for example restic’s, instead of only “blocks did not match or could not be read”. This is the sampled read-back, not a boot test; boot tests stay as in 0.4.0.
• Proxmox VE: a new backup chain for a container whose repository is gone (0.4.2): Proxmox VE preview, in every edition. After the primary repository changed with “keep existing backups where they are”, every container with an existing repository failed with “repository does not exist”. Before a backup gets its credential, the server now checks once per run that the repository is on the primary. Missing everywhere, a new repository and a new backup chain begin, shown on the guest page (“New backup chain started on” and the date) and in the audit log; the earlier restore points become “Not available” (no restore, no check, not counted for readiness, skipped by retention). Still on a retired target, the backup is refused with a clear message instead. “Reset repository” (the guest page’s danger zone, containers only) does the same on request: the guest’s name typed, a recent sign-in, audited. A file share whose repository went missing is not healed this way yet; that is planned.
• Proxmox VE: job cadences, the Restow server’s own VM and backups with warnings (0.4.2): Proxmox VE preview, in every edition. Proxmox VE backup jobs take the cadences of a mail job: every few hours, daily, on chosen weekdays, monthly or a cron expression, not more often than hourly. The VM that runs Restow itself is found by its SMBIOS UUID (restow-pve from 0.4.2 reports it) or marked by an admin; no job backs it up, and “Back up now” or putting it into a job needs a confirmation that names the risk of backing it up with Restow itself. A backup that vzdump ends with “TASK WARNINGS” after its restore point was committed counts as “Succeeded with warnings” instead of failed.
• Where backups land is shown (0.4.2): The tenant’s effective primary repository is named on a guest’s page and its new “Back up now” dialog, in the Proxmox VE job and connect dialogs, on a machine’s and a file share’s page and in the job editors, with the installation default on the server’s local disk highlighted. The Repositories section and the dialogs that add Proxmox VE nodes, machines and file shares warn “Backups land on the server’s own disk” when the primary is a directory on a disk of the server itself (not a network share).
• A storage move takes the restic repositories along (0.4.2): A “move” of the primary repository now also copies the restic repositories of containers, machines and file shares, verified by size and by SHA-256 like packs. It waits for running container backups and file share runs before it switches, and it copies the manifests of VM and container restore points. “Keep existing backups where they are” and promoting a copy are refused while containers or file shares have restic repositories, which only “move” takes along. A change of the primary is still refused while a machine of the tenant is active.
• Storage check: temporarily unreadable is not damaged (0.4.2): The storage check no longer rates a pack it could not read for the moment (a download cut off mid-transfer, a reset connection, a timeout, S3 asking to slow down, denied access) as damaged. It reads such a pack again, up to three times, and lists what stays unreadable as “temporarily unreadable” in Recovery readiness → Storage integrity, with the error, how many consecutive checks could not read it and when; every later check reads it first, and “Re-check these packs” reads only the flagged packs again. Objects using it are rated “Attention”; they become “Not restorable” only when a pack is proven damaged (missing, wrong size or checksum) or could not be read in 3 consecutive checks over at least 24 hours. Reads from S3, restores and restore checks included, resume a download that breaks off. The integration API’s storageIntegrity.state has the new value unreadable (contract 1.5.0, additive).
• Restore explorer: one entry per person, and a calendar by month (0.4.2): The restore explorer lists one entry per person: mailbox, OneDrive and a linked IMAP account are grouped, and the second column shows Mail, Calendar, Contacts and OneDrive, each with its own restore points. SharePoint and Teams sites have a section of their own, and an orphaned OneDrive is listed under its owner’s name as “Account deleted”. The list comes a page at a time, with search over names, addresses and account ids and a type filter in the database; it is fine up to about 10,000 people per tenant and slower beyond. A mailbox’s calendar has a month view, day by day across all its calendars or one, and a series opens onto its occurrences, derived from the stored pattern with the changed occurrences in place; events sort by when they start.
• Mail job editor: back up, archive or both (0.4.2): The first question of the mail job editor is what the job should do: back up, archive or both (both is the default for a new job). While it archives, the editor names how mail reaches the archive (Exchange journaling, set up once per tenant) with the way to its setup, and suggests backing up every 8 hours; backing up alone names the gap between two runs, in which mail that arrives and is deleted is in no backup. A job that only archives makes no backups on a schedule.
• Proxmox VE: VMs & containers in tabs, with search, filters and a detail panel (0.4.3): Proxmox VE preview, in every edition. VMs & containers has three tabs with counts: Guests, Backup jobs and Nodes. The guests table has a search over ID and name, filters by node, kind (VM or container), backup job (also “No backup job”) and state, a “Problems only” button, sortable columns, pages of 25 to 250 and the state in the address, so a link opens the same view. Each row shows one state badge, chosen by priority, with a small progress bar while its backup runs or “+N” for further problems. A click opens a detail panel with every state, the complete error and warnings of the last run in a copyable block, the restore check, the sizes, the job, the newest runs and the actions (back up now, stop, withdraw, check now, open the guest page). The Backup column reads “First: 32 GB on Oct 3 · Last: +210 MB”, and the panel shows the new data of the last 30 backups as small bars. The Nodes tab shows each node’s heartbeat, its restow-pve version with “Update to …” when it is behind, its Proxmox VE version, its guest count, its queue and its problems. The tables keep fixed column widths and one row height, so they no longer jump while backups run. Tested with DOM tests, not visually in a browser with thousands of guests.
• Proxmox VE: a locked repository no longer fails a restore check (0.4.3): Proxmox VE preview, in every edition. Right after a container backup, the new restore check often failed in red with a restic message about stale locks, although the check never ran: another run, usually the guest’s own backup, held the repository’s lock. A check that a lock keeps out is now postponed and tried again after ten minutes, the previous result standing. After two hours it reads “Could not check: repository locked” in yellow (Attention in Recovery readiness), never red and never green, with who holds the lock. Stale restic locks are removed before the check and before retention, a guest is not checked while a run of it is going, and a new restore point is checked two minutes after its commit at the earliest. restow-pve waits up to 15 minutes for the lock during a container backup. Restore checks that failed red because of a lock before the update stay red until “Check now”. Tested against a simulated Proxmox VE API and S3 store, not a real cluster.
• Update nodes and agents now (0.4.3): On the card of nodes and agents in Installation › Updates, “Update nodes and agents now” starts the step in which they follow the server when no update led into it: the server was updated by hand, or the answer to an announced update was lost. An administrator with every tenant starts it; new runs pause for at most 15 minutes while reachable nodes and agents that are behind install the release when idle, and the pause ends once they are done (audited as update.fleet_started with manual: true). Outside an update, nodes and agents that are behind show as “Update available”. Nodes on restow-pve 0.4.1 do not act on it and need one update by hand.
• Proxmox VE: restow-pve restarts the Proxmox VE daemons after it updates itself (0.4.3): Proxmox VE preview, in every edition. After a self-update, the Proxmox VE daemons kept the old storage plugin loaded until they restarted. restow-pve now restarts pvedaemon, pveproxy, pvestatd and pvescheduler as the installer does, and restow-pve update restarts the running restow-pve service too, so the node reports the new release with its next heartbeat. A node that an older restow-pve updated restarts the daemons once by itself. Nodes on restow-pve 0.4.1 need one update by hand: /opt/restow-pve/bin/restow-pve update, then systemctl restart restow-pve pvedaemon pvestatd pveproxy pvescheduler.
• Updates: no more false “The updater is not running” (0.4.3): Announcing an update could report “The updater is not running” although the updater accepted it a few seconds later. The api waited 5 seconds for an answer while the updater checks Docker, the Compose configuration, the disk space and the running version first (5 to 12 seconds on real installations); the update then ran without the pause of new runs, without the audit entry update.scheduled and without the step in which Proxmox VE nodes and agents follow the server. The api now waits up to a minute and, when the answer is still lost, reads the updater’s state again and treats the update as accepted when the updater shows it; the Updates tab says it is checking whether the update was accepted. The tab also no longer says “not running” for a few seconds now and then: the updater answers at once with its last check and checks again in the background.
• Archive capture: Microsoft 365 by Graph change notifications (0.4.4): Business and Service Provider. Restow archives Microsoft 365 mailboxes without journaling. It subscribes to Microsoft Graph change notifications for each archived mailbox and fetches every new mail within minutes of delivery (drafts are skipped, and immutable message ids keep a moved mail from being archived twice). A catch-up over every folder and the recoverable deletions runs every six hours by default and at once after a missed notification, and the existing mail of the mailbox is taken over once, in resumable pages, marked as captured later. No new Microsoft permission is needed. Notifications arrive only when the installation’s public URL is https on port 443 and reachable from Microsoft; otherwise every mailbox is polled, by default every 15 minutes, and the capture status says why. This is near-time capture and is not complete: a mail deleted for good before Restow fetched it can be missing, and of the Recoverable Items only the deletions folder is read. Graph cannot export mail over about 150 MB; such mail is logged, not archived. Restow cannot see whether the tenant keeps deleted mail (a retention policy or a litigation hold), because Graph v1.0 offers no way to read that: an administrator confirms it per source on the archive page, which shows the Exchange Online PowerShell commands that check it. Tested against a simulated Graph API, not against a real Microsoft 365 tenant.
• Archive capture: IMAP and Google Workspace by IMAP sync with IDLE (0.4.4): Business and Service Provider. IMAP and Google Workspace accounts are archived by a continuous sync. Activation records where every folder stands, the existing mail is taken over once (resumable, marked as captured later), and every later pass reads only new mail: a status check per folder, metadata first, and the source only of mail the archive does not hold for the account yet. All folders but Drafts are read; on Gmail and Google Workspace only All Mail, Spam and Trash, which hold every mail once. Where the server offers IMAP IDLE, Restow keeps one connection per account open (by default up to 300 accounts per worker) and archives new mail within moments, with a check of the other folders every five minutes by default; other accounts are polled every ten minutes by default. A source can be set to check at intervals only, for providers with a tight connection limit. A changed UIDVALIDITY reads the folder again without archiving anything twice. This is an approximation and is labelled as one: a mail moved or deleted right after delivery can be missed, and IMAP has nothing like a retention hold. Tested against a simulated IMAP server and the Dovecot of the release smoke run, not against a real Google Workspace tenant or hoster. IMAP sources with OAuth2 still cannot be created, so a Google Workspace account is recognised by its host or its folder list.
• Forwarded copies into the archive (0.4.4): Business and Service Provider. For mail systems without Exchange journaling, the provider sends a copy of every incoming and outgoing mail to Restow while the mail is in its transport: a BCC map in Postfix or mailcow, a Sieve redirect :copy, or the routing rule “Add more recipients” in Google Workspace. The journal receiver accepts such plain copies as well as Exchange journal reports. Every IMAP account can have an archive address of its own (issued on request, renewable, audited): a copy sent to it belongs to exactly that account, while a copy sent to the tenant’s journal address is assigned by its headers and the SMTP sender. A forwarded copy has no envelope like a journal report, so a BCC recipient shows only if the provider writes it into a header. The copy arises at the provider’s transport, before the user can touch the mail. The archive page shows for each account how to set the rule up (Postfix, mailcow, Sieve, Google Workspace) and whether copies arrive. Tested against the receiver itself, never against a real Postfix, mailcow, hoster or Google Workspace. The receiver does not check the sender (SPF).
• One archived item per mail, however many ways captured it (0.4.4): Business and Service Provider. Mail that reaches the archive by more than one way is recognised by its Message-ID and its content (the exact bytes or a hash of the body) and kept once. A capture that is not stronger than what the archive holds becomes a capture entry on that item; a stronger one (a forwarded copy after an IMAP sync, say) becomes the item and names the earlier one it replaces, which stays unchanged in the chain. The same Message-ID with another body is kept twice and flagged. Journal reports and imported messages stay items of their own. Search and the item’s detail name forwarded copies, mail captured later and the other ways that captured the same mail again; replaced captures are hidden unless asked for, and the export of a search follows that. Every writer of the archive now appends through one shared path and uploads the original before the tenant’s chain lock is taken, so a large report no longer holds up the other deliveries of the tenant.
• Mail job editor: only the capture ways that fit the mailbox (0.4.4): The editor of a mail job recognises the kind of mailbox (Microsoft 365, IMAP, Google Workspace over IMAP, IMAP on a Microsoft host) and offers only the capture ways that fit it: Microsoft Graph and Exchange journaling for Microsoft 365, IMAP archiving and forwarding for IMAP and Google Workspace. Each way is labelled as captured at transport or near-time, locked with the edition that has it, and at least one per kind is required. The defaults of a new job, and of a job that switches archiving on, are Graph and IMAP sync, each with a one-time takeover of the mail already in the mailbox. IMAP accounts on a Microsoft host get the hint to connect a Microsoft 365 source instead. Switching archiving or a way off asks first: new mail is no longer archived from then on, and the archive kept so far stays. A journal address is requested only while Exchange journaling is chosen. Jobs that archived before the update keep journaling only for Microsoft 365 and have no way yet for IMAP and Google Workspace accounts, so nothing new starts by itself: an administrator switches Graph or IMAP archiving on in the job. Pausing a job stops its scheduled backups only; archiving goes on.
• Archive page: capture status, hold confirmation, PowerShell commands and forwarding addresses (0.4.4): Business and Service Provider. The archive page shows the capture from the mailboxes (streams, how mail is noticed and why a mailbox is checked at intervals, counts of 24 hours and 7 days, the takeover of existing mail), the capture per mailbox with a catch-up on request and, per Microsoft 365 source, the hold confirmation with the read-only Exchange Online PowerShell commands that check it. Exchange journaling comes as ready-made PowerShell commands (connector, mailbox for undeliverable journal reports, journal rule) and a wait for the first report that checks every 5 seconds. Forwarding has an address per IMAP account (created, copied, renewed after a question), its status and instructions for Postfix, mailcow, Sieve and Google Workspace. A notice that can be put away names the mail jobs where Graph or IMAP archiving could be switched on, and the capture status lists the jobs that wait for a way.
• Alerts when archive capture stops (0.4.4): Business and Service Provider. The alert archive.failed (bell, rules, e-mail) now also reports a mailbox whose capture has been in error for more than an hour, an IMAP account whose forwarded copies stopped for 24 hours while its job wants them, and a journal address without reports for 24 hours, each only after it had received before and once per stretch. The bell and the mail say which of these it is and lead to its section of the archive page.
• Journal receiver limits and an archive chain that no longer forks (0.4.4): Business and Service Provider. One SMTP transaction delivers into one tenant’s archive; a recipient of a second tenant is answered 452 and delivered by the sender separately. The limit per sending IP rises from 60 to 600 connections per minute, and a new limit per archive address (300 per minute) answers 451. Mail to the journal address that is not a journal report is archived as a forwarded copy instead of as an incomplete report. Fixed: the archive chain could fork when two writers of one tenant stamped their items with the same time. Writers now take the last item in the order the chain check walks (time, then id) and stamp theirs strictly later.
• Restore explorer: large mailboxes and OneDrives open in milliseconds (0.4.4): Opening a large mailbox or OneDrive in the restore explorer no longer takes seconds to minutes. Every folder listing used to read all entries of the restore point twice per request and matched the folders below against them without an index; it now reads the folder’s children and the folders below it from two new indexes. In a test with 120,000 messages and 200,000 files, the mail folder list went from 2.5 s to 15 ms, the root of the mailbox and of the OneDrive from over a minute to 15 ms, and every OneDrive folder from 1.5 to 2.5 s to about 10 ms; a folder of 50,000 messages lists its first page in about 0.5 s (was 1.9 s). The versions OneDrive kept of a file and the calendar’s month view read the same indexes, and mail preview and attachment download read exactly the bytes of a chunk with a range request instead of downloading its whole pack of up to 64 MiB. Restore points of 0.3.4 and earlier that the worker has not converted yet are listed as before. The indexes are built while the update runs, which takes longer on a large installation (see the upgrade notes).
• Proxmox VE: the job dialog fits a desktop screen (0.4.4): Proxmox VE preview, in every edition. The Proxmox VE job dialog is twice as wide and lays its settings out in two columns from tablet width on (name and schedule with the next runs on the left; scope, restore points, restore check, boot test and guests on the right), so a job’s settings fit on a desktop screen without scrolling. On a phone it stays one column at full width.
• License keys with an update period (0.4.5): Business and Service Provider. A license key can carry the terms of its updates: an update period (updates_until) and a series. A key with an update period covers every release made up to the end of that day (UTC), whatever its version. A key without one covers a whole series: the key format restow-license-v1 names it, and a key without a series counts as series 1, which also covers every 0.x release. Every key issued so far is a beta license: it carries neither member and covers every 0.x and 1.x release, permanently. The key format takes the new members as optional and ignores members it does not know, so keys that the license server issues later keep verifying; the six members of today stay required and keep their rules. A key may also name the vendor signing key it was signed with (kid), so that a signing key can be rotated without breaking issued keys. Keys with the new members verify only from 0.4.5 on. Keys are still verified offline: Restow contacts no license server, and nothing stops while it runs, because a key has no expiry, only releases it covers and releases it does not.
• The image carries its release date (0.4.5): Every image carries the date of its release (RESTOW_RELEASED_AT, the commit date of the release tag), and GET /api/v1/status reports it as releasedAt. The release notes publish the same date in a released: line next to the image digests, which is how the update check knows the date of a release before it installs anything. License keys with an update period are measured against this date.
• The update check and the start honor the update period (0.4.5): Business and Service Provider. The update check marks the releases that the installed Business or Service Provider key does not cover and says so calmly on the Updates page: the installed version keeps working, and the newest covered version installs as usual. Restow refuses to install or plan an uncovered release (409 update-not-covered), and the bell and the update.available alert rules announce only the newest covered release. A release that is started by hand, past the update check, and that the installed key does not cover stops before its database migrations, with a log line naming the version, the end of the update period and the last covered release date; nothing needs to be restored to go back, and the opt-in updater puts the previous version back by itself. With RESTOW_RUN_AS_COMMUNITY=1 it starts as Community instead: the modules stay off and no data is changed. None of this applies to beta licenses, development builds, installations without a key or the public demo.
• License page: update terms, a notice before the end and renewal (0.4.5): Business and Service Provider. The license page shows which updates the installed key includes (“Updates: all 1.x (beta license)” or “Updates: until” with the date) and, from 30 days before the end of the period and after it, a short notice on the same page; no e-mail is sent. A new key replaces the active one even while that one is in force, which is how a renewal is installed: earlier keys stay in the history, and every installation or replacement is written to the audit log with the key’s update terms and whether they cover the running version. A key that does not cover the running version is refused (outside_update_period), and so is a key signed with a vendor signing key this version does not know yet (unknown_signing_key): update first, then install it.
• Public demo: a fast nightly reset (0.4.5): The public demo resets from a saved template instead of seeding again. After a full seed, deploy/demo/reset.sh saves a template (a dump of the demo database, its roles and a copy of every volume the seed writes) keyed by the release, the image ids and the .env, and restores it on the following nights, so the demo is offline for about 15 to 25 seconds instead of many minutes. The restore moves every system time forward by the template’s age, so the history still ends today and “last backup 12 minutes ago” stays true; the audit log, the mail archive and restic’s own snapshot times keep their real times, and sign-ins are removed. A template older than 7 days (configurable), a new release, new images, a changed .env or a failed restore lead to a full seed. The health checks of the demo’s services run every 2 to 5 seconds instead of every 10 to 15, so a reset waits less for services that are ready already. This concerns the public demo only, not an installation.
• Remove a revoked machine from Restow, with or without its backups (0.4.5): A revoked machine can be removed from Restow. “Remove from Restow” in its danger zone offers “Remove from the list, keep the backups until they expire” (the newest backup plus the longest rule of the machine’s retention, read as time) or “Delete the machine and its backups”, with the hostname typed and a recent sign-in. The machine leaves every list, picker, dashboard and count and its backup job; its runs, reports and audit entries stay. The worker deletes the machine’s restic repository on every target that holds files of it: the primary, its copies and retired primaries. Deleting now is refused while a legal hold over the tenant or an unresolved suspicious restore point holds the backups, and the worker waits for such a hold when the backups expire. Objects that the storage still locks (S3 Object Lock, a directory’s deletion delay) are deferred until their lock runs out, recorded like a refused prune. The machines page lists the removals still pending, with the date, the hold or the lock. Every step is audited. Migration 0064 adds the removal state to the machines.
• Revoke a machine that is gone, and a suggestion to do so (0.4.5): An uninstall that waits for a machine that is off now offers “Revoke now”, and a machine without contact for longer than a configurable number of days (30 by default, under Alerts of the machine) suggests revoking it, on its page and among what needs attention. The machine’s detail panel on Inventory shows the suggestion as a state and offers “Revoke now” and, once the machine is revoked, “Remove from Restow” as well.
• Warning when a directory repository lies on the system disk (0.4.5): Restow warns when a directory repository lies on the system disk of the Restow server, the disk under the operating system, Docker and the database: a full system disk stops everything, not only the backups. The api recognises it from inside its container by the device and the block device of the path, the installation default and the mounter’s shares included. The warning is shown on the Repositories page, in the “Backups land in” line of the job editors and on the dashboard’s storage tile, where provider admins also see the free space, its trend over the last week and when the disk would be full. The api now also watches the system disk for low disk space. Nothing is blocked.
• Microsoft 365 groups as protected objects: calendar and conversations (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, group. 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 changes in between), keeps only Microsoft 365 groups (security and distribution groups have no group mailbox) and orphans removed ones, whose restore points stay. Groups are opt-in: the protection rules get a switch “Protect all Microsoft 365 groups” (by default only selected groups, which means none unless you include them in the list of protected objects), and single groups can be included there. A mail job with scope “all” covers every protected group, like sites. Group mailboxes never count as protected mailboxes. Migration 0065 adds the object kind. After the update no group is backed up until the protection rules switch it on or groups are included; the first directory sync reads the groups of every Microsoft 365 source once in full.
• Group calendar and conversations: what a backup holds (0.4.5): A group’s backup holds its calendar, read by the same calendar code as a user’s (series masters with their exceptions), and every post of every conversation, stored as an RFC 5322 message under mail/Conversations with its file attachments when Graph hands them out (otherwise their absence is recorded). Where Graph refuses the app the event listing of a group calendar, Restow falls back to the group’s calendarView and one read per series master; a calendar that Graph refuses entirely is a warning on the run, not a failure. Only threads with new posts are read again. A group that no longer exists fails with the new cause graph.group_unavailable. No new Microsoft permission is needed: Group.Read.All and Calendars.ReadWrite were always required. Tested against a simulated Graph API, never against a real Microsoft 365 tenant: which calendar reads Graph allows an app on a group can differ by tenant, and the backup reports what it could not read.
• Group calendar and conversations: restore, download and export (0.4.5): The restore explorer lists groups in the “SharePoint & Teams” section 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 events and conversations, the conversations as mail in a Conversations folder. 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. The integration API reports lastSuccess.groups and ObjectKind includes group (contract 1.6.0, additive: clients that handle object kinds exhaustively should accept the new value), and the dashboard lists group calendars and conversations among the last backups.
• Start now and Stop on every job (0.4.5): Both job lists, Servers & clients and Mail & SaaS, have “Start now” and “Stop” on every row and in the row’s “…” menu: one button of a fixed size that says “Start now”, “Stop” while the job’s backups run or wait, and “Stopping…” once asked. Stopping asks first and says what it means for the kind of job. “Run now” is now called “Start now”. New API routes: POST /api/v1/backup-jobs/:id/cancel (every queued or running backup of a mail, machine, share or copy job in one request), POST /api/v1/pve/jobs/:id/run (a backup of every guest a Proxmox VE job (a preview) covers, like its schedule would, without moving the schedule) and POST /api/v1/pve/jobs/:id/cancel. All are audited, are for tenant administrators and provider roles that may operate, and are closed in the public demo.
• Detail panels on Inventory and the job lists (0.4.5): Inventory and the job lists open a detail panel like the one of VMs & containers: a click on a row, its name or its state opens it (?machine=<id> on Inventory, ?job=<id> on the job lists, so a link opens it). It lists every state, the full error and warning texts of the newest backup or failed run in a copyable monospace block (for a machine also the end of the log), what needs attention, the restore checks, the key facts, the newest runs and the actions. The tables keep their layout like VMs & containers: fixed column widths, one row height (loading rows included), one compact state badge per row (the most urgent of what applies; green only for a passed restore check) with the progress of a running backup beside it, one-line cells without tooltips and action buttons of one size. Columns that do not fit a screen give way from the right; the panel has everything.
• Dependencies: translation libraries and the Microsoft token code (0.4.5): Major update of the translation libraries, i18next 26 and react-i18next 17, updated together; texts, plurals and number and date formats read exactly as before in English and German. @azure/msal-node is no longer a dependency, because nothing used it: the Microsoft 365 app tokens, the admin consent and the IMAP OAuth2 sign-in use Restow’s own token client, unchanged.
• Fixes: attachments folder in the restore explorer, Proxmox VE job dialog on a phone, demo reset (0.4.5): In the restore explorer, a mail message stored as JSON (too large for a plain message) no longer shows an empty <subject>.attachments folder next to it: its attachments are restored with the message and were never listed, and the folder row that the backup records for them is now hidden from the listing, the folder tree and search. The job dialog of Proxmox VE (preview) stacks its three restore-point fields on a phone (390 px), so “Monthly restore points” no longer runs over the dialog’s edge. The reset script of the public demo now reads RESTOW_DEMO_COMPOSE_FILES from deploy/demo/.env, as its README always said, and refuses entries that are not compose files before anything is stopped.
• Checks of the Entra tenant and of an IMAP OAuth2 secret (0.4.5): The setup wizard accepts the Entra tenant for Graph mail only as a tenant id (GUID) or a verified domain, as Settings already did; anything else is refused (422) before it can reach the token URL. The URL was never open to another host (the value is URL-encoded and the login host is fixed), but a value such as .. changed its path. An IMAP OAuth2 secret is refused unless its tenantId is a tenant id, a verified domain, common, organizations or consumers, and its tokenEndpoint is an https URL. Neither the API nor the interface creates such secrets yet; the token request will also need the address policy of IMAP connections before XOAUTH2 is offered.
• Proxmox VE: restoring a container works on current Proxmox VE (0.4.6): Proxmox VE preview, in every edition. Restoring a container from Restow failed with Can’t use string (“restow”) as a HASH ref on current Proxmox VE, which passes the storage ID to the backup provider’s container restore before the info hash. Boot tests of containers (“Did not boot”) and “Restore as a new guest” of containers were affected; VMs were not. The plugin of restow-pve now accepts both forms; it is installed with the restow-pve update, which reloads the PVE daemons. Update restow-pve on every Proxmox VE node before relying on container restores or boot tests (the server offers it after its own update, and nodes update themselves when idle); until then they keep failing as before. For container restore points that read “Did not boot” or have a failed restore check from before 0.4.3, run “Boot test now” or “Check now” once the node is updated. Tested with Perl tests of the plugin (the container restore with and without the storage ID); not run against a real Proxmox VE node before the release.
• Ransomware detection: a new backup chain is no longer flagged (0.4.6): Proxmox VE preview, in every edition. The first backup of a container’s new backup chain (its repository was missing, or reset) was judged against the old chain and flagged as suspicious, because every file is new in an empty repository. The baseline now begins with the newest chain. A restore point flagged that way before the update stays flagged: mark it as a false alarm. The first backup of a new chain is also called “First backup” now, not “Incremental”.
• Removed machines keep their backups browsable (0.4.6): Until their backups are deleted, the page of a removed machine offers their restore, and nothing else: the restore points, browsing, the ZIP download and the repository key keep working for them, audited as before. The list of removed machines links “Restore files”. Restoring onto the machine and every other action stay refused (404); once the backups are deleted, the machine is gone for every reader. Before 0.4.6 the interface did not offer the backups that a removed machine keeps until they expire; since 0.4.6 it does.
• “Check queued” while a restore check waits (0.4.6): Proxmox VE preview, in every edition. After “Check now” of a VM or container, the row says “Check queued” under the last check, and the guest’s page says it above the earlier result, until the result is in; both refresh every few seconds meanwhile.
• Error texts open in a card that can be copied (0.4.6): Proxmox VE preview, in every edition. Error texts behind a badge or a cut-off line (the boot test, the restore check of a VM or container on its page and in the recovery readiness table) open on hover or keyboard focus in a card with the whole text, selectable and with a Copy button, instead of a browser tooltip. A boot test that did not boot shows the node’s message under its badge, on the guest’s page and in the recovery readiness table.
• Microsoft 365: disabled, unlicensed and locked objects read “Not backed up”, with the reason (0.4.7): A mailbox whose account is disabled or has no Exchange Online licence no longer fails its backup every night with “Microsoft rejected the request”. The backup asks Microsoft once whether the user exists but has no mailbox, marks the mailbox “Not backed up: account disabled” or “Not backed up: no licence” and ends neutral: no failed count, no red readiness because of age, not overdue, no backup.failed alert or job.failed webhook, existing backups kept. The directory sync sets the same state from its mailbox probe. Only Exchange’s answer counts, so a disabled account whose mailbox Microsoft still serves (a shared mailbox, a former employee) is backed up as before, and a 401 or 403 is never read this way. The same holds for a OneDrive or SharePoint site that Microsoft locked (HTTP 423, which Microsoft does to the OneDrive of an unlicensed account): once one cheap read confirms the lock, it reads “Not backed up: locked”, ends without retries and is no longer planned; the directory sync resumes it only when a read of the drive or site succeeds again. Backups resume by themselves after the directory sync that finds the account enabled or licensed again. A restore into the original mailbox is refused with the reason. Tested against a simulated Microsoft Graph API, not against a real Microsoft 365 tenant.
• Not backed up any more, please confirm (0.4.7): Objects that Restow no longer backs up because the source says they are gone, disabled, unlicensed or locked first read amber “Not backed up any more, please confirm”, with the reason and the date. That is no failure, no red and not overdue, but the warnings, the dashboard and the tenant’s readiness stay at least yellow (never green), the integration API counts them in readiness.toConfirm, and providers see inactive_to_confirm among a tenant’s alerts, until an administrator confirms “Yes, intended”: per object, or for several in the list by selection or by the list’s filter (at most 1000). Tenant administrators and provider teams with configure rights may confirm, and every confirmation is audited; through the API it can carry a note for the audit log. Confirmed objects read grey “Intentionally no longer backed up”, with who confirmed it and when. When the object becomes active again, the confirmation is dropped and backups resume; if it stops again later, Restow asks again. An excluded object that disappears from the source was never backed up and counts as confirmed. The list of protected objects filters by to_confirm and confirmed. The new events object.inactive (a notice per object and transition, in the bell by default) and object.inactive_many (one warning per tenant and day when more than 10 objects, or more than 20 percent of the objects backed up before, stop within a day) are part of the notification matrix; a webhook gets them as report.alert once they are ticked. Objects that were already orphaned before the update count as confirmed, so no long amber list appears. Migration 0069 stores the state.
• Integration API 1.7.0: orphaned also means no longer backed up (0.4.7): The one breaking change of the release: status “orphaned” in GET /api/v1/objects, GET /api/v1/users, the object of GET /api/v1/jobs and objects.orphaned of GET /api/v1/status now also covers objects that are still at the source but are no longer backed up (account disabled, no licence, or locked by Microsoft); before, it meant removed from the source. The new statusReason (account_disabled, no_license, locked, null for an object removed from the source) tells them apart, so an integration that treats orphaned as a deleted account should check it before it acts. Everything else in the contract moves additively: inactiveSince and statusConfirmedAt on objects, toConfirm in the readiness summary of status and verify/latest, a user’s recoveryReadiness that reads at least yellow while one of its objects waits for a confirmation, excluded Proxmox VE guests as guests.excluded (outside guests.total and guests.withoutJob), the skip reason inactive for POST /api/v1/jobs/backup, data.job.result on the job.completed and job.failed webhooks of a restore, and the new alert events. Clients that handle skip reasons or event names exhaustively should accept the new values.
• Backups that Microsoft Graph or the storage held back no longer count as failed (0.4.7): A Mail & SaaS backup that ends, after all its retries, with graph.throttled, graph.service_unavailable or storage.rate_limited reads “Held back by the service, retried” in amber instead of “Failed” in red, in every view: History, the all-tenants job overview, the objects list, the runs of a job, the job page, the dashboard and the run details. It is left out of the failed counts of the statistics and the dashboard, does not make the job failing (the run before it stands), does not make a warning red or end its acknowledgement, and raises no backup.failed alert and no job.failed webhook. The next scheduled run tries again, and an object held back for longer is caught by the overdue and readiness rules, which look at the age of the newest backup. A restore, export, import or check that a service held back has no next run and stays a failure. Earlier runs that ended with these causes read the same after the update and leave the failed counts of past periods. A background job also honours a Retry-After of up to 5 minutes now (before, waits were capped at about a minute, and Exchange refuses a retry before its mailbox concurrency penalty is over); requests from the interface keep the one-minute cap.
• A permission granted to the Microsoft 365 app takes effect without a new client secret (0.4.7): A token carries the app’s permissions as they were when it was issued, and Restow kept it until shortly before it expired (up to about an hour), so a permission that an administrator granted in between was refused until then or until a new secret was entered. When Graph answers 401 or 403, Restow now fetches a new token once and sends the request again, at most once a minute per tenant or source, so a run of refusals (an item the app may not read) does not fetch a token each time; refused sub-requests of a $batch are sent again once as well. A request refused again with the new token fails as before. This applies to backups, restores, the directory sync, the archive capture, the group search, the connection test and the consent check. 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. Notification mail through an app registration does not fetch a new token after a refusal yet: a Mail.Send permission granted later takes effect once the cached token expires.
• One queued backup no longer blocks the backup queue of every tenant (0.4.7): A queued backup of an object whose backup was still running (the next scheduled run, “Back up now”) blocked the backup queue of every tenant until that backup ended, because the job queue kept offering it first and handed out nothing. Such a job now waits for its object’s running backup and lets every other backup pass. Restow ships pg-boss 10.4.2 with a patch of its own for this; the images carry it, and anyone building from source keeps the patches folder.
• Reminders before the client secret or certificate of an app registration expires (0.4.7): Restow reminds provider administrators 30 days before the client secret or certificate of the central Microsoft 365 app registration expires, again 7 days before and once it has expired, each stage once per expiry date; the event installation.app_secret_expiring is a warning, an error once expired. A source that is connected through its own app registration gets the same reminders as source.app_secret_expiring, which tenant administrators can choose as well. The date is the one entered under Installation › Microsoft multi-tenant app (ENTRA_CLIENT_SECRET_EXPIRES_AT for a secret from the environment), the “Secret expires on” of a source’s own app, or the certificate’s own end; Restow does not read it from Microsoft Graph, which would need Application.Read.All. On a source, the connection card shows “Expires”, and the date can be noted, changed or removed there without entering the secret again. A new date, secret or certificate starts the reminders over. The bell names the stage (“expires in 5 days”, “Renew it now”, “has expired”), and the mail lists the date, the days left and the application ID and says how to renew without a gap: create the new secret, enter it with its new date, only then delete the old one in Entra. The expiry badge turns amber 30 days before the end instead of 60, and red from 7. Sources connected through their own app before 0.4.7 have no date yet: note it on the source’s page.
• Mailbox, OneDrive, SharePoint and IMAP: an error costs an area or an item, not the whole run (0.4.7): Mailbox backup: a 403 for calendars or contacts (permission missing, 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; a well-known folder that Graph refuses to resolve is treated as absent; a delta link that Graph rejects as an invalid sync state 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 no longer fails the run. SharePoint: a library or list that Graph will not give is an item failure that keeps its last copy, and the rest of the site gets its snapshot. OneDrive and SharePoint: an item that failed and came through later in the same run no longer stays among the failures, and a OneDrive whose drive Graph no longer finds fails as “OneDrive unavailable”, permanent and not retried. IMAP backup: a login that the server refuses for now (too many connections, an authentication backend that is down) and a download cap are the new transient cause imap.server_limit, retried by itself, instead of a wrong password or a full mailbox; messages deleted or moved during the backup are not counted as failures. IMAP archive capture: a message that the server refuses no longer holds back its folder or the whole pass (after three passes the capture gives up on it), and folders that a pass did not reach keep their state. Every $batch of Graph also sends an identical read only once, so a repeated request id cannot fail a batch, and a connection broken before Graph answered is retried for reads.
• Restores that did not restore anything are no longer reported as completed (0.4.7): A completed restore with failed items and none restored reads “Nothing restored” (red) and raises restore.failed and the job.failed webhook, with “Nothing was restored: N items failed.” as its error. One that skipped every item reads “Everything skipped” (amber) and stays restore.completed, saying so instead of claiming it restored something (info, not success, in chat channels). The job.completed and job.failed webhooks of a completed restore carry its counters in data.job.result (restored, skipped, failures, unverified).
• Recovery readiness and overdue backups: removed objects, members with a schedule of their own, running backups (0.4.7): An object removed from its source (a mailbox deleted in Microsoft 365, for example) no longer turns red because its last backup grows old: nothing backs it up any more and retention always keeps its newest restore point, so it is rated by whether that backup restores, without the age reasons, and is never overdue; a kept backup that does not restore stays red. The same rating applies in the statistics, the objects list, the tenant’s overall readiness, the integration API and the verify.completed notification; the table says “Removed from source, backups kept”, and the report page opens with a note “Removed from the source”. An object whose newest backup was never checked gets one more check from the weekly planner. For backup.overdue, a mailbox member with a schedule of its own is judged by that schedule or by the tenant’s mail jobs (the most relaxed one), whichever allows longer, so a weekly member of a daily job is no longer overdue two days after its backup, and an object whose backup has started and is still running (up to 21 days, a large first backup) is not overdue either.
• Proxmox VE: exclude a guest from backup on purpose (0.4.7): Proxmox VE preview, in every edition. An admin can exclude a VM or container from backup, for test VMs or guests that are backed up elsewhere: “Exclude from backup” on the guest’s page or, for a selection of a node’s guests, in the inventory; “Include again” takes it back. Tenant administrators and the administrators of the provider team may do so. No job backs an excluded guest up, not even the job for all guests, and the recommended job leaves it out; its own job stays recorded, so including it again restores what it had. Excluding withdraws its queued backups (a backup queued in the same moment is withdrawn at the node’s next heartbeat, before the node gets it), and “Back up now” and putting the guest into a job are refused until it is included again. An excluded guest counts nowhere as unprotected: not in the overviews, the recovery readiness, the warnings, backup.overdue, the statistics or the provider view, and it never keeps a tenant from green; the guest counts report it as excluded. In VMs & containers it reads “Excluded” (grey, never a problem) and has a state filter of its own, and the inventory shows “Excluded: N” per node. Its restore points stay restorable, and retention treats them as before. New route PUT /api/v1/pve/guests/:id/excluded, audited as pve.guest.excluded. The update excludes no guest; guests in no job keep counting as “in no backup job” until an admin excludes them. restow-pve needs no update for this.
• Proxmox VE: the size of the first backup and of a follow-up backup as text in the inventory (0.4.7): Proxmox VE preview, in every edition. The inventory shows the size of a guest’s first backup (“First backup on” with the date and the size stored) and what a follow-up backup adds on average (“Average per follow-up backup” with the size and the number of backups it is based on) as text in the guest’s row, not only in its tooltip, so both can be read and copied.
• Recommended job with the mail archive (0.4.7): While the installation offers archive capture from the mailbox (Business and Service Provider) and the tenant has mailboxes or accounts an archive can capture, “Create recommended job” and “Protect everything without a job” make the new mail job over all objects back up and archive. A mail job over all objects that exists and does not archive yet is switched to archiving instead (“Switch archiving on in …”); its schedules stay, and the change is audited like an edit in the job editor. The click uses the capture ways that need nothing set up in the tenant: Microsoft Graph for Microsoft 365 mailboxes, IMAP sync for the other accounts; journaling and forwarding stay a choice in the editor. The recommended job never changes a mail job over selected objects (its preview names them), and a mail job over all objects whose capture ways were chosen by hand is left as it is, which the preview says. The list of mail jobs shows “Switch archiving on” where the recommendation would switch it on. Without the capture, the recommended job is made as before, and existing mail jobs change only when an administrator applies it.
• Monthly prices and a price estimate per tenant for providers (0.4.7): Under Installation › Prices the owner of the installation enters a monthly price per mailbox and per GB or TB of stored backups, in EUR, CHF, USD or GBP (at most four decimals; a price left empty is not shown). Mailboxes are counted as in the mailbox usage (a OneDrive does not count twice); storage is the tenant’s stored backups, deduplicated and compressed, in decimal units (1 GB = 10^9 bytes). Provider admins with every tenant can read the prices, only the owner changes them, and each change is audited with the values before and after. Each tenant’s overview then shows provider admins a card “Price per month” with what the tenant comes to at these prices, one line for the mailboxes and one for the storage, and a link to the prices. Tenant users never see prices. Restow bills nothing and limits nothing, and the prices are empty after the update.
• Fixes: IMAP and list restores, job time limits, demo seed, wording (0.4.7): An IMAP restore whose connection drops now fails and is retried on a fresh connection, where the Message-ID check skips what was already appended, instead of ending “completed” with every remaining item failed. A retried SharePoint list restore in “keep both” mode no longer adds the items 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 mailbox the API accepted, so a duplicate address no longer picks another one. 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; 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. The seed of the public demo no longer fails when Restow queued an object’s first backup itself, which had left the demo on its “being reset” page. The job page names the phases of a SharePoint site backup (“Reading the site”, “Lists”) and of the discovery of sites and group mailboxes, and the retention notes say that the newest restore point of each object is always kept. “Remove from Restow” no longer says that file restore stops offering the backups of a removed machine (it offers them since 0.4.6), and the license page no longer lists sign-in with Microsoft among what Business unlocks, because it is not available yet.
• Dependencies: better-auth, mail libraries, Vite, React and the build tools (0.4.7): better-auth 1.7.14, mailparser 3.14.1, nodemailer 10.3.1, smtp-server 3.21.3, msgreader 1.29.0, Biome 2.6.4, Vitest 5.0.5, Vite 8.3.5, React 19.3.1 and, in the release pipelines, docker/login-action 4.7.0. zod 4 is not part of this release.
• Dependency advisories: ip-address, seroval and zod (0.4.7): ip-address 10.7.5 (from 10.7.2), a transitive dependency through socks, resolves a moderate advisory; socks comes with the IMAP library and is used only for connections through a SOCKS proxy, which Restow does not configure. seroval 1.7.5 (from 1.6.7, through the TanStack router) resolves GHSA-7rv5-mrxv-xcr9, GHSA-wp97-x4hv-qvhp and further advisories of its deserializer, and zod 4.6.7 (an override for the copy better-auth uses) resolves GHSA-mrhx-c7xc-m3w5 there. That advisory (memory use when validating a large array) also names zod 3, which Restow’s own request validation uses and for which no fixed 3.x exists; the audit of CI ignores this one advisory until Restow moves to zod 4. The request body limit of the api (1 MB on most routes) bounds it: a 1 MB array that fails element by element costs about 150 MB and a second of the api for that request.

Known issues: not tested against real systems before the 0.4.0 tag: a Proxmox VE node, the database move and the Enable network shares button through a real updater and its Docker helper container, and the new pages in a browser by hand. File shares were tested against Samba in the release smoke run, not against Windows Server (NTFS permissions, Backup Operators, a file kept open in Excel), a Synology or TrueNAS share, real NFS exports or a host with SELinux enforcing; there is no VSS over SMB, no alternate data streams, DFS namespaces, Kerberos or SMB1, file share repositories live on the primary repository only, tenant users have no self-service restore of shares and scheduled reports have no file share block yet. Agents older than 0.4.0 do not hold their own schedules while an update waits or runs. Files of Proxmox VE containers and VMs are downloaded as a ZIP; restoring single files into the running guest is not built, and VM file restore is a preview. Immutable backups, SharePoint Online, boot tests, VM file restore and agent policies were tested against simulated services only (a fake S3 with Object Lock, a simulated Microsoft Graph, a simulated Proxmox VE node), the ransomware signals with simulated attacks, not with live ransomware. Immutable backups: the installation’s default repository cannot be made immutable, restic index files are not locked, and space of deleted data comes back only once its lock has run out. SharePoint: attachments of list items, site design, navigation, workflows and permissions are not restored, and a deleted site or library is not recreated. In “This restore point contains”, Windows paths are listed but do not open. Known issue in 0.4.1: a repository’s size has no history, so the growth of Stored comes from the chunk store only, uploads that finish while the first measurement of a repository lists it may be left out until the next prune or retention run, and “Protected data” still counts the chunk store’s sources only. Known issues, up to 0.4.3: a file share whose repository went missing after a storage change is not yet healed the way a container’s is (a new backup chain); that is planned for a later release. The fix for the maintenance and update banner covering the top of window-sized pages was not verified visually in a browser. The new parts were tested against a simulated Proxmox VE API, S3 store and Microsoft Graph API only, never against a real Proxmox VE cluster, S3 provider or Microsoft 365 tenant. The restore explorer’s list of people is fine up to about 10,000 people per tenant and slower beyond. The redesigned VMs & containers page (0.4.3) was tested with DOM tests, not visually in a browser with thousands of guests. Further known issues, up to 0.4.4: archive capture was tested against a simulated Microsoft Graph API, a simulated IMAP server, the Dovecot of the release smoke run and the receiver itself, never against a real Microsoft 365 or Google Workspace tenant, Postfix, mailcow or hoster. Holds in a Microsoft 365 tenant are not detected, because Graph v1.0 offers no way to read them, so an administrator confirms them per source; of the Recoverable Items only the deletions folder is read, mail purged before Restow fetched it can be missing, and Graph cannot export mail over about 150 MB (such mail is logged, not archived). The journal receiver does not check the sender (SPF), and its limits count per api process. IMAP sources with OAuth2 still cannot be created in the API or the interface, so a Google Workspace account is recognised by its host or folder list. The integration API’s archive status and report count forwarded copies in their totals but do not list them as a channel of their own. Rolling back to 0.4.3 after the migrations was not tested: take a database backup before the update and restore it to go back. Further known issues, up to 0.4.6: group calendars and conversations were tested against a simulated Microsoft Graph API, never against a real Microsoft 365 tenant, and which calendar reads and writes Graph allows an app on a group can differ by tenant (the backup falls back to calendarView and reports what it could not read; a restore into a group brings back calendar events only, because Microsoft Graph lets no app post into a group conversation). Before 0.4.6 the interface did not offer the backups that a removed machine keeps until they expire; since 0.4.6 it does, for browsing and the ZIP download, never for restoring onto the machine. The fix that lets a container be restored on current Proxmox VE (since 0.4.6) was not run against a real Proxmox VE node before the release. Rolling back to 0.4.4 after the migrations 0063 to 0065 was not tested: take a database backup before the update and restore it to go back. Further known issues, up to 0.4.7: the detection of disabled, unlicensed and locked objects was tested against a simulated Microsoft Graph API, never against a real Microsoft 365 tenant, and an answer of Microsoft that Restow does not recognise as “no mailbox” or as a lock stays a counted failure, as before. The guest exclusion of Proxmox VE was not run against a real node, and excluding a selection of guests in the inventory sends one request per guest (when one fails, the guests before it stay excluded and the list refreshes). GET /api/v1/jobs has no field that sets a held-back or neutral backup apart from a failed one; read failure.code and the object’s statusReason. Notification mail sent through a Microsoft 365 app registration does not fetch a new token after a refusal, so a Mail.Send permission granted later takes effect once the cached token expires. The expiry date of a client secret is not read from Microsoft: without a date entered (under Installation, in ENTRA_CLIENT_SECRET_EXPIRES_AT or on the source) there is no reminder, and sources with an older own secret without an own app (shared client ID) have no date in Restow; switch them to an own app or the central app. A filter on the rating in the list of recovery readiness reports matches the stored rating, so a report stored before the update, or while the object was still at its source, can list an object removed from its source under red while it reads green; checks since 0.4.7 store the rating without the age. The readiness history of earlier days does not show the yellow of unconfirmed objects. A message that the IMAP archive capture gives up on, messages the backfill could not read and a well-known mail folder that Graph refused to resolve are named in the worker log only. IMAP sources with OAuth2 still cannot be created in the API or the interface. Rolling back to 0.4.6 after the migrations 0066 to 0069 was not tested: take a database backup before the update and restore it to go back.

Shipped (0.3.1 to 0.3.6), Proxmox VE preview, members, notifications

Released from 8 to 15 October 2026; 0.3.6 was the last release of the line. Updating from 0.2.x runs six database migrations and asks every installation to accept the setup notice once more: read the release notes of 0.3.1 first. Updating to 0.3.5 runs one more migration and converts the backup index in the background: see Upgrading to 0.3.5. Updating to 0.3.6 runs one more small migration (0034): see Upgrading to 0.3.6. Rolling back needs the database dump taken before the update.

• Proxmox VE (preview, from 0.3.1, every edition): backup of VMs and containers on Proxmox VE 8.4 and newer through the Backup Provider API. VM disks go over NBD with dirty bitmaps, so only changed 4 MiB blocks are uploaded; containers go through restic; a restore creates a new VMID in the pool restow-restore. The node side is a storage plugin shim (a separate work under AGPL-3.0-or-later) and the helper restow-pve (Apache-2.0), installed with /install/pve.sh. Guests count in readiness, warnings and overdue alerts. From 0.3.2 one command per node connects it, with an existing Proxmox VE API token as an alternative; from 0.3.3 every node shows in the inventory with its VMs and containers; 0.3.4 fixes the backup of unprivileged containers (run restow-pve update on every node after the server update).
• Several administrators in every edition (from 0.3.1): members with roles, Community included; limiting a member to chosen tenants stays part of Service Provider. Owners can reset a member’s access. Before a change of the public URL or the operating mode makes passkeys unusable, the settings name the affected accounts and refuse a self-lockout. The login page offers “Lost access?”. See Team and roles.
• NFS shares from the web interface (from 0.3.1) through the opt-in mounter, and, from 0.3.3, an NFS address straight in the path field of a repository. See NFS shares.
• Alerts in Discord, Slack and Microsoft Teams (from 0.3.1): a webhook gets a format, chosen from its URL. See Alerts and reports.
• Overdue backups and warnings (from 0.3.1): the event backup.overdue for mailboxes, OneDrives, IMAP accounts, machines and Proxmox guests, aware of the job schedules, with a deadline of its own per alert rule (24 to 720 hours). Warnings list why single items were not backed up and can be acknowledged with a note.
• Notification mail through Microsoft 365 or Google Workspace (from 0.3.1), with guides and plain error messages.
• Archive (from 0.3.1): an archive per mail job; journal reports assigned to the mailboxes they name; a chain check over every link, the daily anchors (now written every night) and optionally a sample of message contents; archived messages can be read and downloaded as .eml; search with paging and filters by sender, date and mailbox. A legal hold is released with a required, audited reason. See Archiving.
• Audit log export (Business and above, from 0.3.1): CSV, and JSON with hashes. The delivery logs export as CSV. See Audit log.
• What is protected, said plainly (from 0.3.1): machines that are in no backup job no longer count as protected anywhere; the directory, the backup jobs and the machines say which job backs up an object. Overview, Statistics shows the active tenant only; the statistics of every tenant have a page of their own.
• “Repository” everywhere (from 0.3.3): the interface says repository instead of storage location, in German “Repository”.
• Microsoft 365 mailbox backups no longer stop in the folders step (0.3.2): a folder that Microsoft listed twice made it refuse a whole batch (HTTP 400).
• Restore operator role (0.3.5): a role per tenant that sees and restores every backup of the tenant without administering it (jobs, storage, users). Creating a user or an invitation now always needs a role to be chosen. See Team and roles.
• Long first backups finish (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. A Microsoft Graph request that gets no answer within 5 minutes is retried. The worker gets 60 seconds to save checkpoints when it stops (stop_grace_period). Before, a first backup of a large mailbox that needed several days ended as failed after five interruptions.
• Proxmox VE (preview) says what a backup contains (0.3.5): a Backup column with what the newest restore point contains and what its run added, restore points that show their type (first backup, incremental, full read), and a container backup that restic could not read completely, shown as “Last backup incomplete” / “Succeeded with gaps” with the number of unreadable items and counted as “Incomplete” in the inventory. Proxmox VE stays a preview in every edition.
• Data-folder notice for Linux machine jobs (0.3.5): on machine jobs and File restore, a notice names the usual data folders (/opt, /srv, /var/lib, /home, …) that the job’s paths leave out, with a button to add them.
• Backup index as item versions (0.3.5): a backup no longer copies every item of a mailbox or OneDrive into the database. One row per version of an item means an unchanged item costs nothing on later backups; on an installation with 14 million index rows (25 GB) the index needs about 0.5 to 1.5 GB afterwards. The worker converts existing backups one at a time after the upgrade.
• Sign-in on a database role of its own (0.3.5): hardening, no known exploit. Up to 0.3.4 the application’s database role could also read and write the tables outside Row Level Security, among them the sign-in tables, the installation settings, the license and the job queue. Nothing to do beyond updating; DATABASE_AUTH_URL is optional. See Database.
• Proxmox VE (preview): protect guests from the inventory (0.3.6): in the Proxmox VE section of Servers & clients → Inventory, every VM and container (open a node) has its backup job as a choice (an existing job, none, or a new one) and Back up now. Guests can be ticked one by one, all of a node, or all without a job in one click (Select them), and then added to a job (Add to job…) or backed up together; New job… opens the job dialog and puts the selection into the new job. The inventory’s protection column is now called Protection (before, it had the same heading, Backup, as the column that shows what the newest restore point contains). Proxmox VE stays a preview in every edition.
• “Restart required” notice (0.3.6): Installation → Updates says when a service needs a restart, with the reason, a Restart now button and the command to copy, in the installation’s directory. The button goes through the updater, covers api, worker or scheduler only, is never available while an update runs and acts only after a confirmation; it is for the owner of the provider team and needs the updater of 0.3.6 (an older updater shows the command). Provider administrators see a notice on every page. Nothing restarts without a click. An available update now also stands next to the running version. Known issue: nothing records a restart request yet. See Restart required.
• The old backup index gives its disk space back by itself (0.3.6): after the 0.3.5 conversion of the backup index has finished, the api empties the old table within about 15 minutes; the api restart that 0.3.5 asked for is no longer needed. See Upgrading to 0.3.5.
• The installer updates docker-compose.yml (0.3.6): running install.sh again on an existing installation brings docker-compose.yml to the release named in .env (checked against the signed SHA256SUMS), keeps the previous file as docker-compose.yml.bak-<timestamp> and leaves .env as it is. Installations whose file has no mounter are brought up to date this way. See Running it again.
• Clearer NFS messages (0.3.6): when the mounter is not running, the command starts with the installation’s directory; a compose file from before the mounter is named as such, with the installer command that updates it; a missing NFS export names the export path and how to find the right one (showmount -e, Synology paths start with /volume1/, NFSv3). The Add a server path dialog is wider and no longer scrolls sideways. See NFS shares.
• Smaller changes (0.3.6): docker-compose.yml and .env.example keep only the comments a reader must not miss; the reference is the Release stack reference. Dependencies: patch and minor updates.

Known issues: Proxmox VE was tested against real qemu-nbd, qemu-img and restic and, for the node onboarding, against stand-ins for pveum and pvesm. Proxmox VE is a preview and not yet recommended as the only backup. NFS mounts, notification mail through Microsoft 365 and Google and the chat webhooks were tested against fakes only. While a mount from the path field waits for running jobs, new jobs still start. Archive immutability on local and NFS storage is enforced by the application only. The background conversion of the backup index (0.3.5) was tested on generated histories, not yet on a production database of 25 GB; how long it takes there is an estimate. Nothing in Restow records a restart request yet (0.3.6): the notice and the button are in place for updates that need them. The Docker error text for a missing NFS export (0.3.6) was taken from Docker’s documentation, not from a real failed mount. The known issues of 0.3.4 still apply.

Shipped (0.2.2), Microsoft 365 connections

Released on 6 October 2026. Updating needs no migration and no manual step.

• A Graph app of your own for a source (every edition): besides the consent invitation of the shared backup app, a source can be connected through an app the customer created by hand in their own tenant (tenant ID, application ID and a client secret or certificate). The credential is sealed in the organization’s secret store and never shown again. Tested with unit tests and the CI suites only, not against a real Microsoft 365 tenant.
• The tenant of the backup app connects without a consent link: “Connect own tenant directly” on the source page (provider owners only) uses a working app token as the proof. It needs the directory (tenant) ID of the app under Settings, Microsoft 365.
• Hetzner Object Storage preset with a location selector (Falkenstein, Nuremberg, Helsinki); buckets with a dot in their name are reached by path, and the Object Lock detection accepts the answers of S3-compatible services. Not tested against a real Hetzner bucket.
• Alpha channel for test builds: on Installation, Updates, “Use the alpha channel” selects a source of unsigned test builds. For test installations only, never for one with production data.

Shipped (0.2.1), the rest of 0.2.0

Released on 3 October 2026. Updating from 0.2.0 runs one additive migration; read the release notes first if you enabled the updater on 0.2.0 or run agents older than 0.2.1.

• A machine backs up once it is in a backup job: every machine without a job is marked “Without backup”, counted in a banner and offered “Create a job” or “Add to job…”. A newly enrolled machine waits for a job. See Backup jobs.
• Assign a machine to a person of the directory, with an “Assigned to” column in the machine table.
• Context menus on table rows: right-click, the context menu key, Shift+F10, a long press or the ⋯ button open a row’s actions; selectable tables get a selection bar and “New job from selection”.
• File restore with machines and mailboxes on one timeline, newest first, grouped by day, with a jump to a date.
• Default storage in the web interface (Installation → Default storage), checked by a probe before it is saved. See Backups and schedules.
• The updater starts with one command, updates itself after a signed update and switches a Community installation to the full build. See Updates.
• Servers back up their application data by default (/opt, /usr/local, /var/lib, /var/backups).
• Public demo with simulated running jobs.
• SMB is no longer named as a supported storage mount; network storage for local targets is NFS. Existing mounted paths keep working.

Shipped (0.2.0), structure and getting started

Released. Restow 0.2.0 reorganises the interface around three levels and adds backup jobs with live runs. Upgrading from 0.1.0 runs additive migrations and turns your schedules and machine settings into jobs; nothing is deleted. See the changelog of the release for the upgrade notes and the rollback.

• Installation, own organization and tenant settings: every setting has one place and one scope, the installation (server, notification mail, updates, license) and one settings page per tenant (connections, protection, jobs and schedules, backup retention, storage, agents, archive, notifications, integrations, members, audit log, master data), in place of the Setup tab bar of 0.1.0. Setup creates your own organization as an internal tenant.
• Tenant switcher with search in the menu (Service Provider): switch between tenants at the top of the menu and find one by name or customer number.
• Color scheme Restow or Neutral beside light and dark.
• Full-width tables with pinned columns.
• Guided installer with a reverse-proxy mode, encrypted to Restow by default.
• Setup wizard starting with the language choice. See Setup wizard.
• Get started as a checklist in the menu: a rocket entry at the bottom left opens a checklist for a new installation of seven steps (a working repository, a connected source, protected objects, active schedules, the first backup, the first passed restore check and the notification mail, which is the one optional step). The entry disappears once setup is complete.
• Recovery readiness linked to filtered tables: each state (passed, due, not finished and retried, failed, backup too old, never checked) filters the table below it.
• Overview across all tenants or one tenant (Service Provider).
• Jobs as templates: a 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; for servers and clients you pick the folders to back up and exclude file types. On the update, today’s schedules and machine settings become jobs; nothing is deleted.
• Live updates without reload and a run detail panel with throughput charts.
• Bandwidth limit with a time window.
• History including agent runs: every run, with filters by kind (backup, restore, restore check, export, import, maintenance) and by job. The retries of a restore check show as one line.

Shipped (0.1.0)

• First-run setup wizard: a one-time setup token from the server’s log (or RESTOW_SETUP_TOKEN), the operator notice, operating mode, public URL, first administrator (passkey-first, emergency password with mandatory TOTP as fallback), notification mail transport (SMTP or Microsoft Graph sendMail) with a test send. A lost owner account is recovered on the server’s command line (restow admin recover). See Setup wizard.
• Sign-in with passkeys once the installation is verifiably reachable over HTTPS, an emergency email-and-password path with a mandatory authenticator app, and per-user account management (passkeys, authenticator, sessions). Signing in with a Microsoft account was not available in 0.1.0 and still is not in 0.4.7; it is planned (see Next below). See Get started as an end user.
• Multi-tenancy with PostgreSQL Row Level Security isolating every tenant’s data.
• Microsoft 365 sources via the Entra admin-consent flow, with an explicit permission check; the app registration itself is entered and tested under Installation → Microsoft multi-tenant app, no .env editing required.
• Protection scope per source: everyone in the directory, one group, or individually selected objects, with bulk include/exclude/“follow the rules again” actions. Connecting a source queues its first directory sync immediately, and a newly protected object’s first backup queues automatically instead of waiting for a schedule.
• IMAP sources (password-authenticated). Each source uses one of three sign-in modes: one shared login for every mailbox under it, a separate password per mailbox, or a master account that signs in as each mailbox. OAuth2 for IMAP sources is not implemented yet; planned.
• Backup for Exchange Online (mail, calendar, contacts), OneDrive, and IMAP mailboxes, deduplicated and encrypted.
• Restore, non-destructive by default (recovered items are written alongside what is already there); 0.1.0 had no mode that overwrites. Automated weekly restore verification: a sampled read-back through the restore path, compared with the recorded hashes. 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.1.0, and still is not in 0.4.7.
• Configurable storage targets.
• Archive, in every edition: an append-only store with a SHA-256 hash chain and chain verification (tamper-evident), an Archive page for administrators with search over subject, addresses and body text (body text of imported mail; no attachment content) and reading an item, retention settings, export as EML in a ZIP or as MBOX, and an evidence report as JSON through the integration API (no PDF). The archive is filled by mail import with the option to archive at the same time (every edition) and by Exchange Online journal receipt (Business and above). Business and Service Provider add the layer designed for GoBD-compliant use: journal receipt over SMTP (needs a TLS certificate of your own), an enforced retention deletion run, and legal hold per tenant or per mailbox. Archive sync from IMAP and Microsoft 365 is planned, see Next below. See Archiving.
• The integration REST API.
• Backup retention: a tenant default plus per-object overrides on the Retention tab of the tenant setup. The daily retention run prunes restore points, always keeps the newest completed restore point of each object and never prunes anything under a legal hold.
• Audit log viewer (Business and above): list, filter by tenant, action, actor, target and date range, entry details and chain verification. Recording runs in every edition (every read and restore is written to an append-only, hash-chained log); the audit log export came with 0.3.1. See Audit log.
• Team with roles (Business and above in 0.1.0; every edition since 0.3.1): several provider administrators as owner, administrator, technician or read only, with every tenant or chosen ones. See Team and roles.
• Service Provider: several tenants in one installation, delegated tenant administrators who see and manage only their own tenant, the cross-tenant REST API with provider keys, limiting provider team members to chosen tenants, and the provider overview across all tenants (status, key figures, stale backups, failures, storage problems and alerts per tenant). See Multi-tenancy.
• Alerts and reports: alerts by e-mail, in the bell and by webhook when a backup fails, a restore check does not pass or storage is damaged, with a delivery log. See Alerts and reports.
• Scheduled reports (Business and above): daily, weekly, monthly or cron-scheduled summaries by e-mail. See Alerts and reports.
• Endpoint backup for servers and clients (every edition): an agent for Linux and macOS backs files up with restic into the tenant’s storage. It is append-only (it can add backups but never delete one), with retention, repository checks and restore tests (sampled read-back checks) on the server that feed recovery readiness. See Endpoint backup.
• Mail file import and export (every edition): EML, MSG, MBOX, ZIP and MailStore exports become an imported mailbox that you can browse, restore, download and optionally archive. Mail can be exported as EML in a ZIP or as MBOX. See Mail file import and export.
• Updates: an update check that is off until an administrator turns it on, and an optional updater (opt-in, it mounts the Docker socket) that announces maintenance, dumps the database first and rolls back by itself only while the database migrations of the new version have not run. After a migration, which cannot be undone, it stops, keeps the dump and tells you how to restore it. It runs from its own pinned image, installs only release images whose cosign signature it has verified, and builds from a repository only when the operator allows it on the server. See Updates.
• Failure explanations: every failed job, item, sync and verification says what happened, why and what to do. See Failure explanations.
• Operator notice: a step of the setup wizard, accepted together with the setup. See Operator notice.
• Restore explorer timeline: a slim timeline of restore points at the bottom of the explorer, the newest one centred. A folder without subfolders says so.
• Signed release images for amd64 and arm64 in two builds (full and Community) with SBOMs, a signed checksum list, signed agent releases, and a release smoke run of both builds before every release is published. See Verifying a release.
• Editions layout: the Business and Service Provider features live under ee/ in the same repository and release. The full images contain them, locked until a license key is installed under Installation → License; the Community images contain the Apache-2.0 core only. See License and editions.

The automated Microsoft 365 check of the release pipeline against a real tenant is not active yet: check 4, run against a dev tenant, was skipped in every release up to 0.4.7. The smoke run of the current release, 0.4.7, passed 12 of 13 checks in full for the full build and 9 of 13 for the Community build; these figures are read from the smoke reports attached to that release. Microsoft 365 backup and restore are covered by tests against a simulated Microsoft Graph API and IMAP servers. Every release runs a smoke test before it is published: a fresh install, health checks, passkey sign-in, IMAP backup and restore with a hash comparison, journal receipt and chain check, a restore without the server, several storage targets, a vulnerability scan, endpoint backup and restore, and mail import and export. Its Microsoft 365 check is the one that is skipped. The final smoke run of 0.1.0 (2026-10-01) passed, for the full build, 9 of 11 checks in full, 1 partly (the upgrade path does not exist yet, because there is no earlier release) and skipped 1 (Microsoft 365, no tenant); for the Community build it passed 7 in full, 1 partly (the same upgrade path) and skipped 3 (Microsoft 365, and by design the journal and storage target checks, which run in the full build). The endpoint agent ships for Linux and macOS, but the smoke run installed it only in a Linux container; the macOS installer and agent were not part of the release checks (the agent’s own tests ran natively on macOS). See Verifying a release.

Next

Decided and expected to come before the items under Later. No version numbers and no dates: an item moves to Shipped when a published release contains it, not before. The order inside this list is not a promise.

Everyday use

• Inventory and protection groups: building on the machine table of 0.2.1, protection groups assign new machines to a job by profile, operating system, host name or tag, and the install command can carry the job. The agent’s report of the usual Linux data folders, so that the job editor can suggest paths, shipped in 0.4.0 (data folders a job misses); protection groups did not.
• Complete wizards: step-by-step wizards for adding a source or an agent, switching on the archive and creating a tenant, with a step bar and drafts you can continue later. Drafts never hold secrets.
• Touch and search: the row actions of the context menus as a bottom sheet on touch screens, and a command palette that also finds mailboxes, machines and runs by ID.
• Pins and command palette: pin pages, tenants and tenant tabs to the top of the menu, a context menu on menu entries and tabs, and a command palette that reaches every page and tenant tab.

Microsoft, archive, brand

• Microsoft 365 app per tenant: beyond the Graph app of your own that a source can use since 0.2.2 (a client secret or certificate you enter), each tenant connects Microsoft 365 with its own app, registered in that tenant’s Microsoft directory. Restow creates a certificate per tenant whose private key never leaves Restow, guides through the registration with that tenant’s values, checks every permission and warns before the certificate expires. The installation-wide multi-tenant app with a consent link remains an option; existing connections keep working unchanged. Since 0.4.7, Restow already reminds 30 days before, 7 days before and once the client secret or certificate of the central app registration or of a source’s own app has expired; the date is entered (a certificate carries its own) and never read from Microsoft Graph.
• Replace mode for OneDrive files: an optional restore mode in which the current file becomes an earlier version in OneDrive’s own version history instead of being deleted. Mail, calendar and contacts will never be overwritten.
• Archive as a mail browser with visible proof per mail: the archive gets its own area and reads like a mailbox you can browse. Each mail shows its proof: the hash chain values, the last chain verification with its result (stored and recorded in the audit log) and the actual Object Lock state of the storage. Journaling puts a mail on record before the user sees it. Repositories get a purpose, backup or archive; an archive repository requires Object Lock or an explicit acknowledgement that it has none.
• Archive proofs and end-user search: an auditor export with chain values (CHAIN.txt), a signed PDF evidence report, a choice per mailbox between “back up only” and “back up and archive”, and self-service search, so end users can search their own long-term mail history (for example, everything older than 365 days, 2 years or 10 years) and restore or download what they find. Partly there since 0.4.2: the mail job editor asks per job whether it backs up, archives or both; per mailbox is not built. See Archiving and Usage.
• External daily anchors for the archive chain: The daily anchors of the archive’s hash chain, sent by e-mail or as an RFC 3161 timestamp. Since 0.3.1 the worker seals an anchor every night and the archive check compares against it, but the anchors stay inside Restow: nothing sends them out or timestamps them externally yet. Planned.
• Procedural documentation generator: A per-tenant document (Verfahrensdokumentation) generated from the actual configuration and a template, as Markdown and PDF, versioned and dated. The full procedural documentation stays your organization’s own responsibility. Planned.
• Sign-in with Microsoft and single sign-on (SSO) (Business and above): sign-in with a Microsoft account for people who already have a Restow account, and single sign-on. The sign-in code exists, but nothing yet links a Restow account to a Microsoft identity, and Restow never creates accounts, so nobody can sign in with Microsoft today and the login page does not offer it. Account linking is the missing piece.
• White label (Service Provider): your brand instead of Restow, with product name, logos for light and dark, accent color, sign-in page, support contact and sender name, set for the installation and overridable per tenant. It applies to the interface, the end-user portal, e-mails and PDF reports. Green stays reserved for passed restore checks.

Later

Decided, further away or not started, and not tied to a release. No version numbers and no dates.

Proof and operations

• Recovery readiness dashboard with trend: the share of backups proven restorable, split by state, with a twelve-week trend.
• Repository alerts: a warning at 80 percent and a critical alert at 90 percent of a repository’s capacity on local and NFS targets, and optionally above a size you set on any target, S3 included. New and existing installations get these rules preset. Since 0.4.0 provider admins already get a low disk space notice for the disk under the database and under the local default repository (below a tenth free, and always below 5 GiB). Since 0.4.5 the notice also covers the server’s system disk, and the Repositories page, the “Backups land in” line of the job editors and the dashboard’s storage tile warn when a directory repository lies on it.
• Capacity planning: utilization and growth per tenant and per repository, with a plain forecast such as “full in about N days”. Beyond what the dashboard shows since 0.4.0: the storage growth of the tenant you look at and, where the free space is known, when its repository runs full at that growth. Since 0.4.5 provider admins also see on the dashboard’s storage tile, for a repository on the system disk, the free space, its trend over the last week and the day that disk would be full.
• PDF reports: recovery readiness, a period (backups, restores, checks), the audit log and the tenants as PDF, each one recorded in the audit log with the file’s hash. The audit report comes with Business and Service Provider, the tenant reports with Service Provider.
• Signed restore proof (Business and above): a restore report with a checksum and signature that anyone can verify without Restow.
• Full test restore into a separate target, beyond the weekly sampled read-back. Today the optional test restore into a target is not wired up. For Proxmox VE guests, boot tests of restore points have shipped (0.4.0); for mail, OneDrive and files only the sampled read-back exists.
• Four-eyes approval (Business and above): a second person approves restores and deletions before they run.
• Role-scoped archive search with four-eyes release: A provider administrator can search a customer’s archive only after the tenant has released it (a four-eyes release), building on four-eyes approval. Planned.
• Retention policy per tenant: Today every tenant has the same fixed policy: 8 years, ending on 31 December of the year of receipt. Planned: a policy per tenant, selectable as 6, 8 or 10 years or unlimited, optionally per group of mailboxes, with the clock starting at the capture date or at the end of the calendar year.
• Archive search in attachments and by size: The archive search covers the subject, the addresses and the body text. Planned: search in attachments (PDF, DOCX, XLSX, TXT) and by mailbox and size.
• Deletion log as an entry of the archive chain: Every deletion after the retention period is written to the audit log today. Planned: a deletion log as an entry of its own in the hash chain, with the number of objects, the period and the hashes of the deleted objects.
• Archive check in the background, with progress: The archive check (chain, anchors and a sample of contents) runs in a single request today. Planned: a run in the background that shows its progress.
• Legal hold per search result: A legal hold covers a whole tenant or one mailbox today, with a required reason. Planned: a hold on a search result.
• Signed release.json: every release also publishes a machine-readable release.json with the image digests, signed with cosign like the images, so update tooling can check a release before it installs it.
• Self-healing, first stage: Restow detects problems and takes safe actions on its own: it retries, releases stale locks, re-checks, re-supplies missing data with a new backup and notifies you with the exact fix. It never deletes data or shortens retention, and every action is visible in the audit log. Three narrow cases exist: since 0.4.2, a container whose repository went missing begins a new backup chain by itself (audited, shown on the guest page; a file share is not covered yet), and the storage check reads a pack it could not read again before it rates anything damaged; since 0.4.3, Restow removes stale restic locks before a Proxmox VE restore check and before retention, and tries a check that a lock keeps out again instead of failing it. The general mechanism, with detection, safe actions and fix hints across the product, is not built.

Block level

• Filesystem snapshots in the agent (LVM, ZFS and btrfs on Linux, APFS on macOS), so files that change during a backup stay consistent. Today consistency comes from optional pre and post commands.
• Linux image backup at block level with bare-metal restore. Today the agent backs up files only.
• Windows agent with VSS and image backup. The web interface shows Windows as “Planned” today. Since 0.4.0 an SMB file share backs up a Windows file server from the server, without an agent and without VSS.
• Remote nodes as data movers: a second machine, for example at another site, does the backup work next to the data and writes to the repository. Nodes are added with a wizard, sign every request with their own key and receive the key material of one task at a time.
• Automatic scaling (opt-in): workers are added and removed by thresholds, with a cool-down and a maximum.

Integrations and formats

• Google Workspace backup: Gmail and Google Drive, alongside Microsoft 365 and IMAP. Not available yet.
• OAuth2 for IMAP sources. Not implemented yet; planned. Password sign-in works today.
• Agent mTLS: a client certificate per agent instead of a per-agent secret. Today each agent authenticates with its own secret over HTTPS.
• PST and OST import. The files are recognised and refused with an explanation. Until then, export from Outlook as MSG or EML, or convert to MBOX.
• PST export and MSG export of mail. Export as EML in a ZIP and as MBOX is available.
• SFTP as a storage target.

Not in scope for now

These are deliberate scope decisions, not oversights: Microsoft Teams chats, Public Folders, e-discovery case management and a mobile app. SharePoint Online sites used to be on this list; they ship since 0.4.0 (see Shipped), together with the SharePoint sites behind Teams. Since 0.4.5 the calendar and the conversations of the Microsoft 365 group behind a team are backed up as well, as a group mailbox (opt-in); Teams chats and channel messages are not. Disk images and bare-metal restore used to be on this list too; since 2 October 2026 they are planned, see Later. Server and client backup on Linux and macOS is not on this list: it ships with 0.1.0 (see Shipped). PST import is not on it either: it is planned (see Later). None of these is silently “coming soon” without a stated plan.

Editions

Community is the open-source core under the Apache License 2.0, free and without a license key: backup, restore and the archive (hash chain with chain verification, search over subject, addresses and body text of imported mail, fed by mail import with archiving), endpoint backup for servers and clients, mail file import and export, failure explanations and the opt-in update check, with a basic operations log (job history, errors). Every read and restore is recorded in the audit log in every edition. Restore is never limited by edition or mailbox count: there is no mailbox limit anywhere. Business is licensed for one organization, Service Provider for any number of tenants (your own customers); the software does not technically limit the number of mailboxes or tenants. Since 0.3.1 every edition has several administrators with roles; limiting a member to chosen tenants is Service Provider. Proxmox VE backup of VMs and containers (since 0.3.1) is a preview in every edition. Since 0.4.0 every edition also has file share backup, immutable backups, ransomware detection, the notification matrix, agent policies and SharePoint Online backup: the capabilities that an installed license key unlocks did not change with 0.4.0. Since 0.4.4 the license has one more capability, archive.mailboxCapture (Business and above), which switches on capture from the mailboxes; every Business and Service Provider license includes it without a new key, and the Community build keeps the capture service idle. Since 0.4.5 a license key can carry an update period and a series: every key issued so far is a beta license that covers every 0.x and 1.x release, the update check and the start of a release honor the terms of a key that has an update period, and Installation → License shows them; the capabilities that a key unlocks did not change since 0.4.4 (see License and editions). Business adds the archive’s layer designed for GoBD-compliant use (journal receipt, enforced retention, legal hold), the audit log viewer, scheduled reports (all available since 0.1.0), the audit log export (since 0.3.1) and, since 0.4.4, capture from the mailboxes (Microsoft 365 by Graph, IMAP and Google Workspace by IMAP sync; near-time) and forwarded copies, plus sign-in with Microsoft and single sign-on (SSO) (planned, Next) and four-eyes approval and a signed restore proof (planned, Later). Service Provider adds multiple tenants, the cross-tenant API, delegated tenant administrators, the provider overview across tenants and limiting a member to chosen tenants (all available); white label is planned (Next), and since 0.4.0 the Jobs pages list every tenant’s jobs under All tenants. The Business and Service Provider features live under ee/ in the same repository and are part of the full images; they are source-available, and production use needs a license key under the Restow license terms (English translation), installed under Installation → License. Business and Service Provider are sold now at a pre-sale price until general release; see pricing on restowbackup.com and License and editions. A live demo with synthetic data runs at demo.restowbackup.com.