Inventory, guests and restore points

Restow shows the guests of your Proxmox VE nodes in three places, for administrators:

Servers & clients → Inventory, in the section Proxmox VE: one row per node with the state of its guests, since 0.3.3. Here you also protect guests.
Servers & clients → VMs & containers: three tabs with counts, Guests, Backup jobs and Nodes. Here you search and filter the guests, connect nodes and create jobs.
The page of one guest, opened from either list: its restore points and its runs. Here you restore.

The guest list is filled by the nodes: guests appear within a minute after a node is connected, and a node reports its guests every five minutes after that.

Since 0.4.0 the sidebar entry VMs & containers shows a spinner with the number of running backups, and the number of waiting ones beside it. The tooltip lists them, and a click opens the run.

The inventory

In Servers & clients → Inventory (with the filter All or Servers), the section Proxmox VE appears once a cluster is connected. Its header links to VMs & containers (Open VMs & containers).

Every node is a row that you can open. The row shows:

the node’s state, Connected or Disconnected (a node is connected while it reported within the last three minutes),
the number of VMs and containers (“VMs and containers: N”),
and counts: Protected, Failed, Incomplete, No job, Not backed up yet and, since 0.4.7, Excluded: N (guests that an administrator excluded from backup, see Excluding a guest from backup), each shown only when it is above zero. Exclude from backup for a selection of the node’s guests is on the open row, and Include again is in the row of an excluded guest.

The open row lists the guests of the node with these columns:

Column	What it shows
ID, Name	The ID in Proxmox VE and the name, with VM or Container. The name opens the guest’s page.
Status	The state in Proxmox VE: Running, Stopped, Paused or Suspended.
Backup job	The job the guest is assigned to. This is also where you choose it.
Backup	What the newest restore point contains and what its run added, see Sizes.
Protection	Where the guest stands with its backups, with the time of the last successful backup. A backup that waits for its node shows Waiting for the node, a running one its progress, see Progress of a running backup.
	Back up now for the guest.

The Protection column

The column is called Protection. (Before 0.3.6 it was called Backup, like the column that shows the size, which made the two easy to mix up.) A guest has one of these states. They are listed worst first: the first one that applies is shown.

State	When
Excluded from backup	An administrator excluded the guest on purpose (since 0.4.7). It leads the row’s badge Excluded, whatever its earlier runs and checks said, is never a problem and counts nowhere as unprotected.
Not backed up (template or gone)	The guest is a VM template or is no longer reported by its node. It is not counted.
No backup job	The guest is assigned to no job.
Last run failed	The newest finished backup run failed. The reason is shown under the badge and, since 0.4.6, in a card with the whole text that opens on hover or keyboard focus. A run that was stopped on request is cancelled, not failed, and does not count as the last backup.
Not backed up yet	In a job, but no backup has succeeded yet.
Last backup incomplete	The last backup succeeded, but restic could not read some items of a container. See Succeeded with gaps.
Protected	In a job, and the last backup succeeded and is complete.

The counts in the node row use the same states, and an excluded guest is in none of the others. A guest that is covered only by a job for All guests in no other backup job is not assigned to a job, so the inventory shows it as No backup job, although it is backed up. This is still so in 0.4.7. See Backup jobs and protection.

VMs & containers

Since 0.4.3 the page has three tabs, each with a count: Guests (the default), Backup jobs and Nodes. A tab that needs you says how many guests or nodes need attention. The tab, the search, the filters, the order, the page and the open guest are part of the address, so a link opens the same view for a colleague.

The Guests tab

The table shows ID, Name (with an icon for a VM or a container), State, Last backup, Node, Backup, Backup job and the button Back up now (Stop or Withdraw while a backup of the guest waits or runs). The columns keep a fixed width and every row one height, loading rows included, and long texts are cut to one line, so the table does not jump while backups run.

Above it:

Search over the ID and the name.
Filters by Node, by kind (VMs only or Containers only), by Backup job (also No backup job) and by state: Problems, Failed, Warnings or gaps, Restore check failed, postponed or not possible, Waiting, Running, Not backed up, Backed up and, since 0.4.7, Excluded. An excluded guest matches only the filter Excluded, never Problems, and sorts after every problem.
Problems only (N): guests whose last run failed, that succeeded with warnings or gaps, whose restore check failed or could not run, that wait for a node that is disconnected or paused, or that are not backed up.
The count of what the filters leave (“12 guests of 340”), and sortable columns: ID, Name, Node, Last backup, Backup (by size) and State (the most urgent first).
Pages of 25, 50 (the default), 100 or 250 guests. The page filters, sorts and pages the guests in your browser and draws one page of rows at a time.

The State column shows one badge per row, the state that matters most. Beside it, a running backup shows a small progress bar and its percentage, and any other guest with further problems shows “+N”. The badge is chosen by priority: what happens now first, then what failed, then what only warns, then the quiet states. Click the row, or the name, to see all of them.

Badge	Meaning
Stopping…	Someone stopped the backup in the web interface (since 0.4.2). It shows until the node has stopped it. See Stop a backup and pause a queue.
Backing up	A backup is running now. The progress is beside the badge, the tooltip says since when.
Waiting, node not ready	A backup was requested, but its node is disconnected or its queue is paused: nothing starts until it reports or you choose Resume queue. Amber, and counted as a problem.
Waiting for the node	A backup was requested and the node has not started it yet (since 0.3.4). The tooltip says since when (“Requested on …”) and when the node last reported.
Last run failed	The newest run failed. The reason is in the detail panel.
Restore check failed	The restore check of the newest restore point found something wrong (red). The error is in the detail panel.
Could not check	The restore check could not run for two hours, because another run kept the repository’s lock or the check was stopped before it finished (amber, counted as a problem, since 0.4.3). Nothing is known about the restore point yet; it is neither failed nor proven. See Restore checks that could not run.
Restore check postponed	The newest check could not run yet and is tried again in about ten minutes (amber, not yet a problem). The earlier result stands meanwhile.
Incomplete backup	A container backup succeeded with gaps. See Succeeded with gaps.
Succeeded with warnings	The backup was stored, but `vzdump` ended with warnings (amber). See Succeeded with warnings.
Restow server	This guest runs Restow itself (since 0.4.2). It is not backed up until an administrator confirms it, see The Restow server’s own VM.
No backup job	The guest is assigned to no job.
Not backed up yet	In a job, but no backup has succeeded yet.
Cancelled	The last run was stopped on request. It is not a failure and raises no alert; the guest keeps its last backup.
Template	A VM template. Proxmox VE does not back these up through a backup provider.
No longer reported	The node no longer reports the guest: it was deleted or moved to a node without the helper.
Restore check passed	The restore check read the newest restore point back and it was intact. This is the only green badge.
Backed up	The last backup succeeded (plain outline). Nothing has proven the restore point yet.
No state yet	Nothing is known about the guest yet.

Green is proof: only Restore check passed is green. A backup that merely succeeded is not.

The Backup column says how large the first backup of the guest was and what the last follow-up backup added, for example First: 32 GB on Oct 3 · Last: +210 MB. Until a follow-up backup has run, only the first part shows. The tooltip adds what the newest restore point contains. See Sizes.

The detail panel

A click on a row (or on its name) opens a panel beside the table, with the guest in the address, so you can link to it. It shows:

State: every state of the guest as a badge, in priority order, with Privileged for a privileged container and Incremental or Full read (VM was restarted) for how the last backup of a VM read its disks.
Back up now, Stop or Withdraw, Check now (the restore check) and Open guest page.
Excluded from backup (since 0.4.7): under the guest’s job it says that and who excluded it and when. It cannot be changed there; Include again is on the guest’s page and in the guest’s row of the inventory.
Error of the last run and Warnings of the last run: the complete text in a scrollable block, with Copy error and Copy warnings. Error texts no longer show in red under a guest’s row, and warnings no longer only in a tooltip. Since 0.4.6 an error text behind a badge or a cut-off line (the restore check of a guest here, on its page and in the recovery readiness table) also opens on hover or keyboard focus in a card with the whole text and a Copy button.
Restore check: the Result, when it was Checked and what is Next. When a check could not run, Why the check could not run names the reason and what restic reported (who holds the lock), with Copy reason, and Last attempt says when the worker gave up.
Backup: the last backup, what the newest restore point contains and what its run added, the First backup, the average of the Follow-up backups, the Gaps, and a small chart, New data per backup, with one bar for each of the last 30 backups (hover for the date and the size).
Recent runs: the newest runs with their status.

The Backup jobs tab

The jobs of the tenant with their Name, Guests (the scope), Schedule (“Daily at 22:00”, or By hand only), Next run and Current round (Not running, or how far a scheduled round is: “2 of 5 done” and how many failed). Create backup job, Edit and Delete are here. See Backup jobs and protection.

The Nodes tab

One row per node. Node names the node and its cluster. Status is Connected (it reported within the last three minutes) or Disconnected, with the time of its last report (the heartbeat). restow-pve is the version of the helper and, when the server offers a newer release, Update to X.Y.Z beside it (since 0.4.2; since 0.4.3 the server compares the versions and marks a node that is behind). Proxmox VE is the version of Proxmox VE. Guests counts the guests of the node, Queue how many backups wait (Empty, “N waiting” or Queue paused) and Problems what keeps backups from working there (None, or the first problem with “+N”, see Troubleshooting).

The row menu holds Pause queue or Resume queue, Cancel all queued and Revoke. The Fleecing storage is no longer a column: a node without one lists the problem No fleecing storage.

The note that the Proxmox VE host itself is not backed up is one line above the table, with Add the host as a server. Hide this note hides it in your browser. See Connect a node.

Progress of a running backup

Since 0.4.0, a running backup shows a bar and a line under it, in VMs & containers, in the inventory, in the row of Servers & clients → Jobs (for a manual backup) and in the Runs of the guest, for example:

34% · 3.2 GB of 9.4 GB · 85 MB/s

A VM reports the bytes it has read of its disks (the changed blocks only, when the dirty bitmap is reused). The tooltip adds “Uploaded so far”.
A container forwards what restic reports. Restic scans the container first (since restow-pve 0.4.0), so the total is known early. Until it is, the bar pulses and the line says how much was read (“3.2 GB read”).
The helper needs to be restow-pve 0.4.0 or newer. On an older helper, the line says “No progress reported yet” for the whole run. Since 0.4.1 it says what to do instead: “Progress needs restow-pve 0.4.0 on <node> (it runs <version>). Update the node.” See Update and remove nodes.

Sizes

Three numbers describe a guest and its backups. They mean different things:

Disk: the disk size configured in Proxmox VE, what is allocated, not what is in use, written with its unit (“9 GB allocated”). It is on the page of the guest; since 0.4.3 the table of VMs & containers has no column for it. (The column was called Size before 0.3.5.)
Backup, the first line (N in the backup; since 0.4.3 this is in the tooltip of the Backup column of VMs & containers, and the inventory still shows it as a line): everything the newest restore point restores. For a container that is all files restic read, the same figure that Proxmox VE’s task log reports as “Size”. For a VM it is the size of its disks. Every restore point is complete on its own, so this is about the same for each restore point of a guest.
Backup, the second line (+N new in the last run): what the last run added to the repository after deduplication. For a container that is the new data after restic’s deduplication, for a VM the uploaded blocks. The first backup stores nearly everything, later ones only what changed.

The inventory shows the first backup, for example First backup on 8 Oct 2026, 09:14: 9.4 GB stored, and since 0.4.0 what a follow-up backup adds on average (“Average per follow-up backup: +2.5 MB (last 10 backups)”). Since 0.4.7 both are text in the guest’s row, so you can read and copy them, and not only in the tooltip. The average covers the newest 10 restore points after the first backup that recorded what they added. The first backup is the first one the guest ever had, also when retention has removed it since. A guest without a restore point shows No backup yet. The page of the guest says the same average above its restore points.

Since 0.4.3 the Backup column of VMs & containers puts the first and the last on one line instead: First: 32 GB on Oct 3 · Last: +210 MB, with the first backup’s size, its date and what the last follow-up backup added (only the first part until a follow-up has run). The detail panel and the page of the guest show the new data of each of the last 30 backups as small bars.

The page of a guest

The page of a guest has two tables: its Restore points (the newest 200) and its Runs (the newest 50). The line under the title shows the type (VM or Container), the cluster, the node and the disk size (“Disk: 9 GB allocated”). Since 0.4.0 the page also shows the Suspicious badge and a notice when ransomware detection found something in a restore point of the guest, and says that retention of the guest is paused while it is not resolved.

The Restore points table has these columns:

Column	What it shows
Time	When the backup was made, and whether it was started by Restow or started in Proxmox VE.
Type	First backup, Incremental or Full read, and for a container backup with gaps, N items not readable. See below.
Contains	Everything this restore point restores: all files of a container, all disks of a VM. Unchanged data is stored only once.
New in this backup	What this backup added to the repository, after deduplication of unchanged data. A dash when the restore point did not record it.
Restore check	The result of the check: Passed (N blocks), Failed (with the error the check found, since 0.4.2), Could not check: repository locked (or Could not check: check interrupted; a check that a lock kept out, since 0.4.3, see Restore checks that could not run) or Not checked yet, and Check queued while one is asked for (since 0.4.6 it stays until the result is in, and the page refreshes every few seconds meanwhile). Every new restore point is checked within minutes of its backup, see Restore checks.
Boot test	The newest rated boot test of the restore point (since 0.4.0): Booted, Started, no answer or Did not boot, with the time, or Not tested. Skipped tests and tests the node could not carry out stay in the Runs table. See Boot tests.
	Browse files (see Files of a guest), Check now (exactly this restore point, also an older one), Boot test now and Restore as a new guest.

A restore point of an earlier backup chain says Not available, see New backup chain and Reset repository.

The Runs table lists Started, the Type (Backup, Restore, Restore check or Boot test), the Status (Running, Succeeded, Failed, Succeeded with gaps, since 0.4.2 Succeeded with warnings and Cancelled, and for a boot test how it ended, for example Skipped) and the Error. A running backup shows its progress in the Status column.

Restore point types

The Type of a restore point says how it came about:

Type	Meaning
First backup	The first backup the guest ever had, and for a container, since 0.4.6, the first backup of each new backup chain (its repository was missing, or reset), which used to read Incremental. A later restore point is never “the first one” only because retention removed the older ones.
Incremental	A container backup (restic reuses every unchanged file), or a VM backup that read only the changed blocks.
Full read	A VM backup that had to read whole disks again, for example after the VM was stopped and started. Only the blocks whose SHA-256 changed were uploaded.

For a VM, hover over the type to see how each disk was read: Changed blocks only or Whole disk. Every restore point is complete on its own, whatever its type: any of them can be restored or removed without the others.

Succeeded with gaps and incomplete container backups

When restic cannot read some files of a container (its exit code 3), it still writes the snapshot. Restow keeps the restore point instead of failing the backup, and says so:

the run shows Succeeded with gaps (N items could not be read), and its Error column names the first items (“Not read: … and N more”; the tooltip lists them),
the restore point carries N items not readable,
the guest’s state says Last backup incomplete,
in the inventory, the guest counts as Incomplete and the node row shows Incomplete: N.

The restore point misses exactly the items that could not be read. The task log of the whole Proxmox VE backup job names the first 20 of them, and since 0.4.0 (with restow-pve 0.4.0) the run in Restow keeps the same first 20 as well. Proxmox VE’s log of the single guest, the one its notifications show, may not name them. The next successful complete backup clears the state. Since 0.3.5.

Succeeded with warnings

Since 0.4.2, a backup that vzdump ends with warnings (“TASK WARNINGS”) but whose restore point was committed counts as succeeded, not as failed. The run keeps the warning lines (at most ten), and the guest shows Succeeded with warnings in amber: not failed, not green. A backup without a committed restore point still fails.

Before 0.4.2 such backups ended with “TASK WARNINGS: 1” and restow-pve reported them as failed although the restore point was stored. The cause was a note: restow-pve 0.4.2 or newer asks vzdump for no notes any more, and the storage plugin takes a notes update (from a Proxmox VE backup job with a notes template) as a no-op that it logs, instead of an error. Update the nodes to get the fix on the node side; the server already settles an older node’s “failed” result by the run: a committed restore point is succeeded. Protection of a restore point is still refused in Proxmox VE, because Restow holds them.

Restore checks that could not run

Since 0.4.3. A restore check can fail to run at all. For a container it is a restic check, which needs the repository’s lock, and another run (usually the guest’s own backup, whose lock a cancel or an API restart had left behind) can hold it. Before 0.4.3 that ended as a red Restore check failed, although the check never read the restore point. A check that a lock keeps out, or that restic stopped before it finished, is no longer a failed check:

It is postponed. It is tried again ten minutes later, at the back of the queue, and the previous result stands meanwhile. The guest says Restore check postponed, and the restore point on its page Check postponed: repository locked.
After two hours since it was asked for, the restore point reads Could not check: repository locked. It is amber (Attention in Recovery readiness), never red and never green, because nothing is known about the restore point yet. The detail panel names the reason and gives restic’s report of who holds the lock (process ID, host, user and when the lock was created). A check that restic stopped again and again reads Could not check: check interrupted.
It tries again. The weekly check tries the guest again after a day; the next backup’s check, Check now and Check all unverified (which also takes guests that could not be checked) try sooner.
Not a failure. Nothing in Restow counts the guest as failed or red because of it.

What the server does so that it happens rarely:

It removes stale restic locks before a container check and before retention (restic unlock): only locks that no live run refreshes, which means older than 30 minutes or of a process that is gone.
A check waits up to two minutes for a lock that another run holds. Only the first two locked repositories of a pass wait, so a pass stays short.
A guest is not checked while a run of it is going (a backup, a restore, a boot test) or while its node has taken on a backup of it that has not started yet. The check waits for a later pass.
A new restore point is checked two minutes after its commit at the earliest, when the node’s restic has let go of the repository, and restow-pve from 0.4.3 on waits up to 15 minutes for the lock during a container backup.
A failed check keeps restic’s explaining lines, not only its last one.

Restore checks that a lock failed before the update to 0.4.3 stay red until the next check of the guest: choose Check now.

New backup chain and Reset repository

A container’s restore points live in a restic repository of their own under pve-guests/<guest id>/ of the tenant’s primary repository. Since 0.4.2 Restow makes sure of that before a backup gets its credential (once per run), instead of trusting that the repository was created once:

The repository is on the primary: the backup runs as always.
It is only on another repository of the tenant (a retired primary, left behind by “Keep existing backups where they are”): the backup is refused with a clear message that tells you to move the backups with a storage “move” or to reset the repository. Nothing is created. Restores of the container read the repository from whichever target holds it.
It is nowhere: Restow creates a new repository (a new password, restic init, the sealed password file next to it) and a new backup chain begins. The container’s earlier restore points become unavailable: they cannot be restored, browsed or checked any more, readiness and the overviews no longer count them, and retention leaves them alone. The page of the guest says “New backup chain started on” and the date, “the previous repository was not found at” and the place, lists the earlier restore points as Not available, and shows the chain in the guest’s history. The audit log records pve.repository.reinitialized with the run, the repository and how many restore points became unavailable. The first backup of the new chain is called First backup, and since 0.4.6 ransomware detection judges it against the new chain, not against the old one (Ransomware detection).
The storage does not answer: that is not “missing”. The backup fails with a message that the repository is unreachable, and no chain begins.

The case that led to this: after the primary repository was changed with “keep existing backups where they are” (0.4.1 and before), every container with an existing repository failed with repository does not exist (exit code 10), because the server trusted that the repository was on the new primary. A “keep” is refused now while containers have repositories (Replacing the primary repository).

Reset repository is in the Danger zone of the page of a container (containers only), for a repository that is damaged or lies on a repository that is gone. It is for administrators, needs a recent sign-in and the name of the guest typed to confirm, and is audited (pve.repository.reset). Every restore point of the container becomes unavailable at once, and the page says how many. The next backup removes what is left of the old repository on the primary and begins a new chain. A retired repository is never touched.

Readiness, warnings and alerts

Guests count wherever mailboxes and machines count, by one rule. The Status tab, Recovery readiness, GET /status, the provider view, the Warnings page and the statistics all use it, so they agree.

Protected. A guest is protected while it is present on its node, is not a VM template, is not excluded from backup and is in an enabled job: its own, or the job for all guests while it has none. A guest in no enabled job is counted as in no backup job. A guest that leaves its job keeps the rating of its restore points, and it keeps the tenant from green. An excluded guest (since 0.4.7) counts nowhere as unprotected: not in the overviews, the recovery readiness, the warnings, Backup overdue, the statistics, the job counts of the all-tenants view or the provider view, and it never keeps a tenant from green. The guest counts report it as excluded; its restore points stay in the count of restore points and its earlier runs in the history.
Recovery readiness. Every protected guest, and every guest in no job that still has a restore point, is a row of the table on Recovery readiness. The rating is the restore check of the newest restore point and, where one ran, its boot test: Ready, Attention (through a boot test, when the VM started but nothing proved that it works, or, since 0.4.3, through a restore check that could not run, see Restore checks that could not run), Not restorable, Unverified or No backup yet. The row says which check decided. A guest that was never put into a job is listed as in no job, never as “no backup”, because a cluster reports many guests that are not meant to be backed up.
Status tab. The card “N guests in no backup job” with Open VMs & containers, the card Last successful backup with the type VMs and containers, and the counts of protected objects (“including N VMs and containers”).
Ransomware detection. Restore points of containers and VMs are judged like those of machines. A suspicious one gets the Suspicious badge and puts the retention of that guest on hold until an administrator resolves it, see Ransomware detection.
Warnings. Failed guest backups are shown apart on the Warnings page: “N VMs or containers in a backup job have a failed last backup. Failed backups cannot be acknowledged; they stay red until a backup succeeds again.” with Open VMs & containers.
Provider view and API. GET /status reports guests, with the excluded ones apart as guests.excluded (since 0.4.7, contract 1.7.0). The provider view reports guests, guestsWithoutJob and guestsFailed and the hints guest_backup_failed (“The last backup of N guests (VMs or containers) failed.”) and guests_without_job (“N guests (VMs or containers) are in no backup job and are not backed up.”).

The alert Backup overdue

The alert event Backup overdue (backup.overdue, since 0.3.1) covers Proxmox VE guests next to mailboxes, OneDrives, IMAP accounts and machines. It fires once per guest when the guest has had no successful backup for longer than the enabled guest jobs plan: twice the longest planned gap of the most relaxed enabled job, two days when no job has a schedule. It fires again only after a backup has succeeded in between. A rule can set a deadline of its own, from 24 to 720 hours, under Deadline for missing backups. See Notifications and reports.

The event Backup failed is worded for the runs of mailboxes, OneDrives, IMAP accounts, servers and clients. A failed guest backup shows as Last run failed on the guest, in the inventory, on the Warnings page and in the hints above, with the reason. A backup that someone stopped is cancelled: it raises no failure alert and no “Last backup failed”. A failed or unproven boot test raises its own events, Boot test failed and Boot test without proof, see Boot tests.