-
File shares (SMB and NFS)
-
File share backup and restore
Back up an SMB share (Windows Server, Samba, a NAS) or an NFS export from the server, without an agent on the file server. Restow mounts it read-only for one run in a short-lived runner container that the mounter starts, and keeps NTFS permissions (NFSv4 and POSIX ACLs on a best-effort basis) in every restore point. Open, unreadable and offline files are skipped and listed, and the run ends with warnings. Restore 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 one gets it through "Enable network shares". Tested against Samba in the release smoke run, not against Windows Server, a Synology or TrueNAS share, real NFS exports or a host with SELinux enforcing. No VSS over SMB: files that are open with an exclusive lock are skipped.
0.4.0
Every edition
-
File shares: restore checks, copy jobs and budgets
Every new restore point is checked by reading up to 20 sampled files back and comparing them, 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, in overwrite or mirror mode; a copy job keeps no versions and is 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. Not yet: repositories other than the primary one, self-service restore for tenant users and a file share block in scheduled reports.
0.4.0
Every edition
-
Protection against ransomware and misuse
-
Immutable backups
Immutability per repository, off until an administrator turns it on (Repositories, "Change immutability"). 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, treats a deletion the storage refuses as not yet, 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; verification results and warnings appear on the repository card, the dashboard and the provider view. Lowering the protection needs the provider owner with a recent sign-in. Tested against a simulated S3 with Object Lock, not yet against a real service; the installation's default repository cannot be made immutable.
0.4.0
Every edition
-
Ransomware detection with a retention hold
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, and 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, so clean older restore points are not pruned while encrypted ones pile up; only an administrator ends a hold (false alarm or release, 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. On after the update, with its thresholds and switches under Installation, Ransomware detection. Tested with simulated attacks, not with live ransomware.
0.4.0
Every edition
-
S3 endpoints need HTTPS
A new or changed S3 endpoint over plain http:// is refused, for provider admins and the installation default too, 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.
0.4.0
Every edition
-
Notifications
-
Notification matrix
Under Integrations, Notifications the events are rows, grouped and marked by severity, and the bell, every webhook and every notification recipient are columns, each with the quick choices "Errors only", "Errors and warnings" and "All". Saving is audited. The update fills every column with exactly what the channel received before, so nothing changes at first; a webhook created afterwards starts with the defaults of its format, and an alert rule no longer sends an event to a channel whose column has it off. New events: backup.succeeded and verify.completed for mail and the bell, backup.suspicious and backup.suspicious_hold, boot_test.failed and boot_test.unproven, and installation.disk_low for provider admins.
0.4.0
Every edition
-
Proxmox VE (preview)
-
Proxmox VE: progress of a running backup
VMs & containers, the inventory and the guest's page show a progress bar ("34% · 3.2 GB of 9.4 GB · 85 MB/s"), and the helper's own lines (the run id, what restic added, what it could not read) reach the run's log; a backup that succeeded with gaps names the first 20 unreadable items. Container backups now let restic scan first, so there is a total to show progress against. Needs restow-pve 0.4.0 on the node. Tested against the simulated node of the test suites, not against a real Proxmox VE node.
0.4.0
Every edition
-
Proxmox VE: boot tests of restore points
A Proxmox VE job can boot the newest restore point of each guest weekly or after every backup (off by default; a memory limit of 8 GiB and five minutes for the guest agent by default), and "Boot test now" asks for one by hand. The node restores it as a new guest in the pool restow-restore, isolates it before the start (network links down, passthrough devices, serial ports, bind mounts and the hook script removed), waits for the QEMU guest agent and destroys it in every case. Green when the guest agent answered, yellow when the VM only started, red when the restore, the start or the boot failed; recovery readiness rates the newest restore point by its boot test. One test per node at a time, never beside a backup. Needs restow-pve 0.4.0; tested against the simulated node, not a real Proxmox VE cluster.
0.4.0
Every edition
-
Proxmox VE: file restore of containers and VMs (Preview)
Under Servers & clients, File restore, every container with a restore point is listed in the group "Proxmox VE containers" and every VM in "Proxmox VE VMs", marked Preview: browse a restore point and download files and folders as one ZIP, read by the server from the guest's repository; reads and downloads are audited. For VMs each readable file system of the disks is a folder (GPT and MBR partitions and linear LVM volumes with ext2, ext3, ext4, XFS, NTFS or FAT), read in a restricted child process with nothing mounted on the server or the node. Not readable: btrfs, ZFS, ReFS, LVM thin, RAID, BitLocker and LUKS, NTFS-compressed and EFS files; the XFS and NTFS logs are not replayed, so compare an important file with the original before relying on it. Restoring single files into a running guest is not built.
0.4.0
Every edition
-
Proxmox VE jobs in Servers & clients
Proxmox VE jobs appear under Servers & clients, Jobs next to the machine jobs, with a Type column, the guests per job, schedule, last and next run, and "2 of 5 guests done" while a round runs; a backup started by hand shows as a row until it ends. New job is a menu with one entry per type, and the Proxmox VE job form lists the VMs and containers to put into the job. A guest's page shows the average a follow-up backup adds.
0.4.0
Every edition
-
Servers and clients
-
Agent policies
Rules for the agents on servers and clients on three levels: the installation (Installation, Agent policy), the tenant and the backup job. Each level may override a setting unless the installation locks it, and every view says where a value comes from. The settings: a backup window (weekdays and a time range) in which scheduled backups, catch-ups and retries may start; catching up missed backups as soon as the machine is on again or in the next window, optionally only up to a maximum age; an upload limit for jobs without one of their own; 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; the upload limit and AC power reach older agents too. Tested against simulated services only.
0.4.0
Every edition
-
File restore for the restore role
Restore operators (the restore role of a tenant) open Servers & clients, File restore: they list the machines, read their restore points and immutability, browse them, download files as a ZIP and restore files onto the machine. For Proxmox VE they read the overview and a guest's restore points and browse and download files of container and VM restore points. 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 with the operator as actor.
0.4.0
Every edition
-
Data folders a job misses, and what a machine runs as
The agent 0.4.0 reports which of a fixed list of Linux data folders (/opt, /usr/local, /srv, /var/www, Docker and Podman volumes, the PostgreSQL, MySQL and MongoDB folders under /var/lib) 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), and a Linux machine in a container or a virtual machine without a desktop gets the server profile; the file browser of a restore point says which folders it contains.
0.4.0
Every edition
-
Jobs, live view and dashboard
-
Create recommended job
Next to every "no job" notice (jobs, inventory, sources, directory, VMs & containers) 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 every 8 hours; machines per system and profile; one Proxmox VE job, daily at 22:00 in snapshot mode). A second click adds to the same job instead of making another. Admins only, recorded in the audit log.
0.4.0
Every edition
-
Running backups in the sidebar and a livelier run drawer
The Jobs entries and VMs & containers show a spinner with the number of running backups and the waiting ones; the tooltip lists them and a click opens the run. In the run drawer the charts move with time between measurements, the numbers count up, the time left counts down, and a line says when the run last reported (or that Microsoft Graph throttles it). The first backup of a large mailbox shows "First backup: X of Y items" over all attempts, with an estimated time left; a OneDrive shows "X items so far" until it is fully listed.
0.4.0
Every edition
-
All tenants in Jobs
Under "All tenants", Jobs of Mail & SaaS and of Servers & clients list every tenant with its jobs per kind, what runs and waits, how the newest backups ended and the next run, with filters and sorting; a row opens the tenant's jobs read-only. The view stays fast on large installations by reading through an index and keeping each tenant's figures for 30 seconds.
0.4.0
Service Provider
-
Storage growth on the dashboard
The dashboard shows how the stored data of a tenant grew over 1 week, 1 month, 3 months or 1 year; from 3 months on the estimate is a band between the slowest and the fastest growth, and where the free space is known it says when the repository runs full at this growth.
0.4.0
Every edition
-
Microsoft 365
-
SharePoint Online: backup and restore of sites
Every directory sync finds the tenant's SharePoint sites (the 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 like mailboxes and OneDrives; the protection rules have a sites mode, all sites or chosen ones. A backup holds every document library (optionally with versions), every list with its columns and each item's field values as JSON, and the site's description. Restore in the explorer: download as ZIP; files and folders into the original or another library of a backed-up site (keep both, overwrite with SharePoint keeping the old file as a version, or skip existing); list items into their original list as new items, writable fields only. Not backed up or restored: Teams chats, attachments of list items, site design, navigation and workflows; permissions are kept as information and never restored; a deleted site or library is not recreated. Needs the application permission Sites.ReadWrite.All (Sites.Read.All is enough to back up) and a new admin consent per tenant. Tested against a simulated Microsoft Graph, not a real Microsoft 365 tenant.
0.4.0
Every edition
-
Updates, database and storage
-
Runs in progress during an update
The install dialog counts what runs and waits in every tenant and asks what to do: "Stop them cleanly" (the default: Microsoft 365 and mail runs save a checkpoint and stop; runs on agents and of file shares are waited for, 30 minutes at most), "Wait until they finish" (two hours at most) or "Do not wait". From the confirmation until the update is over no new run starts, and schedules that fall due meanwhile run afterwards; everyone signed in sees a banner. Agents 0.4.0 hold their own schedules and wait; agents older than 0.4.0 do not, so a backup such a machine starts by itself during an update may fail if the API restarts under it. A Proxmox VE backup that runs while Restow updates no longer fails: the node keeps trying for five minutes.
0.4.0
Every edition
-
Move the database to another disk
Installation, Database shows where the database keeps its data, its size, the free space under it and under the local default repository, and what the next update needs. With the opt-in updater the provider owner moves the database to a directory on another disk: checked first (another local file system, ext4, XFS, Btrfs or ZFS, room for the data), then copied, compared file by file, test-started and switched, with automatic rollback on any failure; the old copy is kept and blocked from starting until it is removed. The updater's preflight now adds up what an update writes and refuses one that does not fit, and the Updates tab lists the pre-update dumps (the owner can download or delete one). The move was not tested through a real updater and its Docker helper before the release.
0.4.0
Every edition
-
Low disk space warning
Every 15 minutes the API checks the disk under the database (through the updater) and under the local default repository. Below a tenth free, and always below 5 GiB, provider admins get a notice in the bell, and alert rules that list "Low disk space" send it, once per episode.
0.4.0
Every edition
-
Performance on large installations
Memory stays bounded whatever the size: the first catalog of a file share streams into the database in batches of 5,000 files, SMB permission reuse keeps a compact index so that shares with millions of files do not run out of memory, SharePoint sites with thousands of lists no longer take quadratic time, the block maps of browsed VM disks are cached by size, and Object Lock renewal sends 32 requests at a time and continues an interrupted pass where it stopped. The ransomware judgement and the All tenants view of Jobs read through indexes.
0.4.0
Every edition
-
0.4.1
-
Stored data counts the restic repositories
Repositories, Usage, the Stored tile of the dashboard, the statistics and the API counted only the packs of the chunk store: a tenant with 10 GB of container backups saw "Stored 10.9 kB". Stored now adds the restic repositories of machines, file shares and Proxmox VE containers, and the usage card shows how much is in the chunk store and how much in restic repositories. The size of a container's repository is measured once at its first upload after the update, then counted per upload and deletion and measured again after a prune. The deduplication saving, the growth and the chart stay figures of the chunk store and say so; a repository's size has no history, and "Protected data" still counts the chunk store's sources only.
0.4.1
Every edition
-
Proxmox VE: an old node helper is named
A running container backup on a node with restow-pve before 0.4.0 showed "No progress reported yet" for its whole run. It now says that progress needs restow-pve 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, instead of only after six hours; the update still waits until no backup or restore runs.
0.4.1
Every edition
-
0.4.2
-
Stop a backup from the web app
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.
0.4.2
Every edition
-
Nodes and agents follow a server update
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 <version>" 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.
0.4.2
Every edition
-
Planned updates and a time zone of the installation
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 <version> available" that leads to Installation › Updates, for those who may install updates.
0.4.2
Every edition
-
Proxmox VE: every new restore point is checked within minutes
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.
0.4.2
Every edition
-
Proxmox VE: a new backup chain for a container whose repository is gone
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 <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.
0.4.2
Every edition
-
Proxmox VE: job cadences, the Restow server's own VM and backups with warnings
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.
0.4.2
Every edition
-
Where backups land is shown
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).
0.4.2
Every edition
-
A storage move takes the restic repositories along
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.
0.4.2
Every edition
-
Storage check: temporarily unreadable is not damaged
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).
0.4.2
Every edition
-
Restore explorer: one entry per person, and a calendar by month
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.
0.4.2
Every edition
-
Mail job editor: back up, archive or both
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. Since 0.4.4 the editor also offers the capture ways that fit each kind of mailbox (see 0.4.4).
0.4.2
Every edition
-
0.4.3
-
Proxmox VE: VMs & containers in tabs, with search, filters and a detail panel
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.
0.4.3
Every edition
-
Proxmox VE: a locked repository no longer fails a restore check
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.
0.4.3
Every edition
-
Update nodes and agents now
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.
0.4.3
Every edition
-
Proxmox VE: restow-pve restarts the Proxmox VE daemons after it updates itself
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.
0.4.3
Every edition
-
Updates: no more false "The updater is not running"
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.
0.4.3
Every edition
-
0.4.4
-
Archive capture: Microsoft 365 by Graph change notifications
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.
0.4.4
BusinessService Provider
-
Archive capture: IMAP and Google Workspace by IMAP sync with IDLE
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.
0.4.4
BusinessService Provider
-
Forwarded copies into the archive
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).
0.4.4
BusinessService Provider
-
One archived item per mail, however many ways captured it
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.
0.4.4
BusinessService Provider
-
Mail job editor: only the capture ways that fit the mailbox
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.
0.4.4
Every edition
-
Archive page: capture status, hold confirmation, PowerShell commands and forwarding addresses
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.
0.4.4
BusinessService Provider
-
Alerts when archive capture stops
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.
0.4.4
BusinessService Provider
-
Journal receiver limits and an archive chain that no longer forks
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.
0.4.4
BusinessService Provider
-
Restore explorer: large mailboxes and OneDrives open in milliseconds
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).
0.4.4
Every edition
-
Proxmox VE: the job dialog fits a desktop screen
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.
0.4.4
Every edition
-
0.4.5
-
License keys with an update period
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.
0.4.5
BusinessService Provider
-
The image carries its release date
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.
0.4.5
Every edition
-
The update check and the start honor the update period
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.
0.4.5
BusinessService Provider
-
License page: update terms, a notice before the end and renewal
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.
0.4.5
BusinessService Provider
-
Public demo: a fast nightly reset
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.
0.4.5
Every edition
-
Remove a revoked machine from Restow, with or without its backups
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.
0.4.5
Every edition
-
Revoke a machine that is gone, and a suggestion to do so
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.
0.4.5
Every edition
-
Warning when a directory repository lies on the system disk
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.
0.4.5
Every edition
-
Microsoft 365 groups as protected objects: calendar and conversations
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.
0.4.5
Every edition
-
Group calendar and conversations: what a backup holds
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.
0.4.5
Every edition
-
Group calendar and conversations: restore, download and export
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.
0.4.5
Every edition
-
Start now and Stop on every job
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.
0.4.5
Every edition
-
Detail panels on Inventory and the job lists
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.
0.4.5
Every edition
-
Dependencies: translation libraries and the Microsoft token code
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.
0.4.5
Every edition
-
Fixes: attachments folder in the restore explorer, Proxmox VE job dialog on a phone, demo reset
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.
0.4.5
Every edition
-
Checks of the Entra tenant and of an IMAP OAuth2 secret
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.
0.4.5
Every edition
-
0.4.6
-
Proxmox VE: restoring a container works on current Proxmox VE
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.
0.4.6
Every edition
-
Ransomware detection: a new backup chain is no longer flagged
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".
0.4.6
Every edition
-
Removed machines keep their backups browsable
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.
0.4.6
Every edition
-
"Check queued" while a restore check waits
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.
0.4.6
Every edition
-
Error texts open in a card that can be copied
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.
0.4.6
Every edition
-
0.4.7
-
Microsoft 365: disabled, unlicensed and locked objects read "Not backed up", with the reason
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.
0.4.7
Every edition
-
Not backed up any more, please confirm
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.
0.4.7
Every edition
-
Integration API 1.7.0: orphaned also means no longer backed up
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.
0.4.7
Every edition
-
Backups that Microsoft Graph or the storage held back no longer count as failed
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.
0.4.7
Every edition
-
A permission granted to the Microsoft 365 app takes effect without a new client secret
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.
0.4.7
Every edition
-
One queued backup no longer blocks the backup queue of every tenant
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.
0.4.7
Every edition
-
Reminders before the client secret or certificate of an app registration expires
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.
0.4.7
Every edition
-
Mailbox, OneDrive, SharePoint and IMAP: an error costs an area or an item, not the whole run
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.
0.4.7
Every edition
-
Restores that did not restore anything are no longer reported as completed
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).
0.4.7
Every edition
-
Recovery readiness and overdue backups: removed objects, members with a schedule of their own, running backups
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.
0.4.7
Every edition
-
Proxmox VE: exclude a guest from backup on purpose
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.
0.4.7
Every edition
-
Proxmox VE: the size of the first backup and of a follow-up backup as text in the inventory
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.
0.4.7
Every edition
-
Recommended job with the mail archive
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.
0.4.7
Every edition
-
Monthly prices and a price estimate per tenant for providers
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.
0.4.7
Every edition
-
Fixes: IMAP and list restores, job time limits, demo seed, wording
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.
0.4.7
Every edition
-
Dependencies: better-auth, mail libraries, Vite, React and the build tools
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.
0.4.7
Every edition
-
Dependency advisories: ip-address, seroval and zod
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.
0.4.7
Every edition
By Lucas Flores, IT Systeme Flores UG. Last updated