Restow 0.4.2

Restow 0.4.2. Released 2026-10-21, channel beta.

Beta release. Run it alongside your existing backups, not as your only one, until
you have verified restores against your own data.

Summary

Restow 0.4.2 stops a running backup from the web app (Proxmox VE, servers and clients,
file shares) and lets Proxmox VE nodes and agents follow a server update before new runs
start. A container whose repository went missing after a storage change begins a new
backup chain instead of failing, and a storage "move" now copies the restic repositories
of containers, machines and file shares. Every new Proxmox VE restore point is checked
within minutes of its backup. The storage check tells a pack it could not read for the
moment (a transfer or permission error) from a damaged one. The restore explorer lists one
entry per person and shows a mailbox's calendar by month; the mail job editor asks first
whether a job backs up, archives or both. The installation has a time zone of its own, and
restow-agent update installs the offered agent release at once. Six database migrations.

Breaking Changes

None. The public API's storageIntegrity.state has the new value unreadable (integration
API contract 1.5.0, additive); clients that handle its values exhaustively should accept
it. "Keep existing backups where they are" is refused while containers or file shares have
restic repositories (see Fixed and Upgrade Notes).

Added

• Proxmox VE: "Reset repository" for a container (guest page, danger zone): the guest's name
  typed, a recent sign-in, audited (pve.repository.reset). Its restore points become
  unavailable at once and the next backup begins a new chain
  (POST /api/v1/pve/guests/:id/repository/reset).
• Where backups land: GET /api/v1/storage/destination names the tenant's effective primary
  repository. The guest page and its new "Back up now" dialog, the PVE job and connect dialogs,
  a machine's and a file share's page and the job editors show it; the installation default on
  the server's local disk is highlighted. The Repositories section and the dialogs that add PVE
  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).
• Proxmox VE: every new restore point is checked within minutes of its backup, a bounded
  number per pass, besides the weekly check of every guest. Installation › Proxmox VE has the
  setting "Check every new restore point right after the backup" (on by default;
  GET/PUT /api/v1/settings/pve). One database migration.
• Proxmox VE in Recovery readiness: "Check now" per guest and "Check all unverified"
  (POST /api/v1/pve/guests/:id/verify, POST /api/v1/pve/verify-unverified); the footer
  names the Microsoft 365 schedule as such and says how VMs and containers are checked.
• 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 Restow server's own VM: found by its SMBIOS UUID (restow-pve 0.4.2 reports it with the
  inventory) or marked by an admin on the guest's page. It is marked in the lists and the job
  editor, no job backs it up, and "Back up now" and putting it into a job need a confirmation
  that names the self-backup risk (docs/PVE.md, "The Restow server's own VM").
• Stop a backup from the web app, without SSH on the node. Proxmox VE: Stop in the VMs &
  containers table, on the guest's page and in the run drawer withdraws a queued backup at once
  and stops a running one: restow-pve now keeps its heartbeat going while a backup runs, gets
  the cancel order with it and stops the vzdump task through the PVE API (a backup started in
  PVE: its provider). The run ends cancelled, not failed, and shows "Cancelled by ".
  Per node: Pause queue (no new backup starts until resumed) 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 heartbeat (every minute while
  it backs up). Runs of file shares can now be cancelled from the run drawer as well (Microsoft
  365 and IMAP runs already could). Every stop asks first and is audited.
• 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. The Updates tab shows their progress and,
  for the ones not reached, the command for an update by hand. Update to on a
  node and on a machine asks for the update at any time.
• Updates can be planned for a chosen date and time (in the installation's time zone) besides
  the lead times from now; nothing pauses before, and everyone sees a notice from a day before.
• restow-agent update on a machine, like restow-pve update on a node: it installs the
  release the server offers right away, through the same signed download as the automatic
  self-update, restarts the service and says what it did; while a backup runs it refuses and the
  agent updates itself once idle. The Updates tab names it for agents that were not reached
  (and the service restart for agents before 0.4.2).
• The installation has a time zone of its own: chosen in the setup wizard (the browser's zone
  preselected) and changed by an owner under Installation › Server & operation › Server, with
  a searchable list of zones. Planned updates are read in it and a new tenant starts with it.
  Without a choice, RESTOW_TIME_ZONE, then TZ, then Europe/Berlin apply as before.
• When an update is available, the version in the sidebar becomes a highlighted, gently
  pulsing Update to available that leads to Installation › Updates (for those
  who may install updates; no animation with reduced motion).
• Restore explorer: a mailbox's calendar has a month view, day by day across all its calendars
  or one, and a series in the list opens onto its occurrences, derived from the stored pattern
  with the changed occurrences in place (new GET /api/v1/snapshots/:id/calendar, audited as
  snapshot.calendar.read).
• Restore explorer: one entry per person. A person's mailbox, OneDrive and IMAP account are
  grouped; 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, an orphaned OneDrive
  is listed under its owner's name as "Account deleted". The list comes a page at a time from
  the new GET /api/v1/snapshots/people (keyset paging, search over names, addresses and
  account ids, type filter, all in the database), so tenants with 10,000+ people never load
  everyone at once. The snapshot objects carry ownerKey and ownerName.
• Mail job editor: the first question 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 the capture
  (Exchange journaling) with the way to its setup and suggests backing up every 8 hours;
  backing up alone names the gap between two runs.

Changed

• A red restore check of a guest shows the error it found (for example restic's) in the guest
  list, Recovery readiness and on the guest page, instead of only "blocks did not match or
  could not be read".
• /virtualization: the State column keeps its width and height while a backup reports
  progress; long messages are cut, with the whole text in the tooltip.
• Storage integrity: a pack the storage check could not read (a download cut off
  mid-transfer, a reset connection, a timeout, S3 asking to slow down, or denied access) is
  no longer shown or rated as damaged. Recovery readiness › Storage integrity lists it as
  "temporarily unreadable" with the error, how many consecutive checks could not read it,
  and when first and last; 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. When the packs read
  intact again, the storage finding ends and the object's restore checks rate it again. The
  public API's storageIntegrity.state has a new value, unreadable.
• A run that was stopped on request is cancelled (machines: a new run and task status);
  it raises no failure alert and does not count as the last backup.
• Database: index protected_objects (tenant_id, user_id) for a person's objects.
• Restore explorer: calendar events sort by when they start (newest first, or upcoming first)
  instead of by subject, with When, Location and Organizer columns.
• Exchange backup: an event's metadata records its location and the end of a series range.

Fixed

• Proxmox VE: after the primary repository changed with "keep existing backups where they
  are", every container with an existing repository failed with repository does not exist
  (exit 10): the server trusted repository_ready_at and never checked the repository was on
  the new primary. Before a backup gets its restic credential the server now checks it (once
  per run). Missing everywhere, a new repository and a new backup chain begin, visible on the
  guest page ("New backup chain started on …: the previous repository was not found at …") and
  in its history, audited as pve.repository.reinitialized; the earlier restore points become
  unavailable (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. Restores read the
  repository from whichever target holds it. One database migration.
• Storage: "Keep existing backups where they are" and promoting a copy are refused
  (storage-switch-blocked-by-repositories; the dialog offers "keep" disabled) while
  containers or file shares have restic repositories, which only "move" takes along.
• Storage: a "move" now copies the restic repositories of containers, machines and file shares
  (from the target that holds each one), verified by size and by SHA-256 like packs, waits for
  running container backups and file share runs before it switches, and retention of
  containers and file shares waits for it. It also copies the manifests of VM and container
  restore points, which it treated as pruned before. A retired location is no longer removable
  while it alone holds a container's or file share's repository.
• Proxmox VE backups ended with "TASK WARNINGS: 1" and restow-pve reported them as failed
  although the restore point was committed: restow-pve asks vzdump for no notes any more, the
  storage plugin takes a notes update as a no-op, and a backup vzdump ends with warnings after
  its restore point was committed counts as "Succeeded with warnings".
• restow-pve's late task result was refused with "404 Task not found" once the server had
  closed the task (by the run's own end, the worker, or its expiry during an outage): the
  server takes it and settles the run (a committed restore point always counts as succeeded),
  a task whose run is still open no longer expires, and restow-pve keeps a result the server
  could not take and sends it again with the next heartbeat instead of losing it.
• The storage check read each pack once: a download that broke off mid-transfer (Node's
  "aborted", which the S3 client does not retry) made a ~65 MB pack "unreadable", the page
  said "2 packs are damaged … No intact copy exists in any repository", and the mailbox was
  rated "Not restorable" although a restore check read 20 of 20 items back byte-exact. The
  check now reads a pack again after a transfer error, whole, up to 3 times (2 s and 8 s
  apart), hashing as it streams into a buffer of the pack's recorded size. Reads from S3
  (restores and restore checks included) resume a body that breaks off from the first
  missing byte, pinned to the object's ETag.
• The maintenance and update banner covered the top of pages that size themselves to the
  window: the layout now accounts for the banner's height, also when it wraps to several
  lines.
• The update progress said "Downloading {image}" (and "{file}", "{services}"): those steps
  now name the version instead of a placeholder the updater never fills.
• Switching the tenant on a job's page opens the jobs of that kind in the new tenant instead of
  saying that the job does not exist; any detail page gives way to its list.

Security

None.

Upgrade Notes

New image and six database migrations, which run in seconds whatever the size of the
installation:

• 0053_pve_repository_chains: a container's new backup chains
  (pve_guests.repository_chains) and pve_snapshots.unavailable_at.
• 0054_pve_runs_042: the Restow server's own VM (pve_guests.restow_server_detected,
  restow_server_flagged, self_backup_confirmed_at), pve_snapshots.verify_requested_at
  and the installation's Proxmox VE settings (settings.pve_settings).
• 0055_pack_read_failures: a new, empty table. Packs an earlier storage check reported
  unreadable count as temporarily unreadable after the update and are read again first by
  the next check; no full check is needed.
• 0056_cancel_and_fleet_update: cancel requests and cancelled states for tasks and runs, a
  node's paused queue, "update now" for nodes and machines, the phase fleet of the job-start
  pause, settings.planned_update.
• 0057_explorer_people: an index on the protected objects of a person in a tenant, for the
  restore explorer's list of people.
• 0058_installation_time_zone: settings.time_zone. An existing installation has no time
  zone of its own after the update: RESTOW_TIME_ZONE, else TZ, else Europe/Berlin applies
  until an owner chooses one under Installation › Server & operation › Server
  (docs/UPDATING.md, "The installation's time zone").

No new required environment variables, and the docker-compose.yml of 0.4.0 stays.

• Proxmox VE nodes should run restow-pve 0.4.2: it reports the Restow server's own VM, keeps
  its heartbeat going while a backup runs (for Stop and the progress) and no longer reports
  backups with "TASK WARNINGS" as failed. The fleet update after the server update installs
  it on every reachable node; the Updates tab names the command for the others.
• Stopping a running backup needs restow-pve 0.4.2 on the node and agent 0.4.2 on the machine;
  an older node ends a cancelled backup at its next upload (the server refuses it), an older
  agent finishes it. Both update themselves with this release.
• "Keep existing backups where they are" (and promoting a copy) is refused while containers
  or file shares have restic repositories; change the primary repository with "move", which
  now takes them along.
• Storage check reports from before 0.4.2 are read again: packs they listed as unreadable
  count as temporarily unreadable, not damaged, and the next check reads them first. An
  object rated "Not restorable" only because of such a pack is rated "Attention" until that
  check.
• Integration API contract 1.5.0 (additive): storageIntegrity.state can be unreadable.
• Rollback: the migrations only add a table, columns, indexes and enum values and widen a
  check; 0.4.1 starts with them, but runs and tasks in the state cancelled are unknown to
  it.

Known Issues

• 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); this comes in 0.4.3.
• 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 groups the tenant's protected objects in the
  database for every page it serves; that is fine up to about 10,000 people per tenant and
  slower beyond.
• The known issues of 0.4.1 still apply.

Verification

Before the tag, on the release branch (main plus the 0.4.2 workstreams): lint and typecheck
of all workspaces, the i18n tests, the server installer tests, the v1 OpenAPI test, gofmt, go
vet and the Go tests of the agents, the Perl tests of the Proxmox VE plugin, and the unit and
Postgres suites of every changed package on Postgres 16. The release smoke runs in the
release pipeline; no real Proxmox VE cluster, S3 provider or Microsoft 365 tenant was used
before the tag.

Release pipeline, 2026-10-21:

Check	Result	Duration
1. Install: images, compose up, migrations (new install and upgrade)	PASS	92s
2. Health endpoints, worker and scheduler registered	PASS	0s
3. Passkey sign-in E2E with a virtual authenticator, tenant creation, i18n de/en	PASS	2m 07s
4. Microsoft 365 backup and restore against the dev tenant	SKIPPED	0s
5. IMAP backup and restore against Dovecot, hash comparison	PASS	8s
6. Journal receipt, chain verification, export	PASS	3s
7. Standalone restore with restow-restore from the storage of check 5	PASS	25s
8. Storage targets: S3 (Garage), local path, mounted directory	PASS	20s
9. Image scan (Trivy) and dependency audit (pnpm audit)	PASS	20s
10. Endpoint backup: the agent enrolls, backs up a folder, restores it	PASS	12s
11. Mail import (folder and upload) and export (EML ZIP, MBOX), compared by hash	PASS	10s
12. File share backup against Samba: back up, browse, ZIP, restore with permissions, copy job	PASS	2m 15s

11 of 12 checks passed in full, 0 partly, 1 skipped, 0 failed. The full report, including the reason for every skipped or partial check, is attached to the release as smoke-report.md.

The Community images were smoke-tested on their own (smoke-report-community.md, smoke-report-community-arm64.md): amd64 PASS with gaps: 9 of 12 checks passed in full, 0 partly, 3 skipped (see the reasons below); arm64 PASS with gaps: 9 of 12 checks passed in full, 0 partly, 3 skipped (see the reasons below).

Images

Two builds of the same release. The full build is the Apache-2.0 core plus the Business and Service Provider modules (Restow Enterprise License), which stay locked until a license key is installed. The Community build is the Apache-2.0 core alone.

ghcr.io/restow-backup/restow:0.4.2
ghcr.io/restow-backup/restow-web:0.4.2
ghcr.io/restow-backup/restow-community:0.4.2
ghcr.io/restow-backup/restow-web-community:0.4.2

The digests of the multi-arch manifests (the opt-in updater verifies the pulled images against the two lines of its build):

restow: sha256:c32ddf2839819a10d069bda7d7d19eba2ae3fd8256208f574452c975a175994b
restow-web: sha256:701e86bc748e735dcb298412828739b67155657fbc9e91f8482c2edc30304f11
restow-community: sha256:5a455ed3e627ab6029fb02d10894b8fb4c347e0ab5eb9019eb2afe528f13b63b
restow-web-community: sha256:646b6c9f9bb3efcba5e56315ae93bf2ff23094d9c59240a91cc56cd6e6ad1693

All four images are multi-arch (linux/amd64, linux/arm64), signed with cosign (keyless) and carry an SPDX SBOM as attestation. Verify any of them with:

cosign verify ghcr.io/restow-backup/restow:0.4.2 \
  --certificate-identity-regexp '^https://github.com/restow-backup/restow/\.github/workflows/release\.yml@refs/tags/v' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com
cosign verify ghcr.io/restow-backup/restow-web:0.4.2 \
  --certificate-identity-regexp '^https://github.com/restow-backup/restow/\.github/workflows/release\.yml@refs/tags/v' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com
cosign verify ghcr.io/restow-backup/restow-community:0.4.2 \
  --certificate-identity-regexp '^https://github.com/restow-backup/restow/\.github/workflows/release\.yml@refs/tags/v' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com
cosign verify ghcr.io/restow-backup/restow-web-community:0.4.2 \
  --certificate-identity-regexp '^https://github.com/restow-backup/restow/\.github/workflows/release\.yml@refs/tags/v' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

docker-compose.yml and env.example are the release stack (deploy/release/); install.sh installs it on a dedicated Linux VM (README.md, "Install with the script"; install.sh.sha256 for sha256sum -c after the download); restow-agent-THIRD_PARTY_NOTICES.txt holds the licenses of the agent binaries and of the restic they run; SHA256SUMS lists every file of this release and is signed (SHA256SUMS.sigstore.json).