A green backup is not a restore result
A newer archive should not inherit an older restore test. Hostwatch keeps those records separate so an operator can see what exists, what was actually restored and what still needs checking.
Published 26 October 2026. Hostwatch engineering review; implementation limits are stated below.
Three records describe three different facts
The newest archive record answers which backup the installed profile most recently produced and checked. Independent restore evidence answers which exact archive was opened and verified in an isolated environment. Availability answers whether the referenced archive can still be found under the approved storage and identity checks. These records are related, but their timestamps and file identities may differ. Combining them into a single green badge loses the information needed for the next recovery decision. The current Hostwatch behavior described here was reviewed for publication on 26 October; the edition slot is not a feature-release date.
Consider a hypothetical sequence. Monday’s archive passes an independent restore. Tuesday’s archive is created and passes its archive checks, but its full restore has not run. The accurate display is a Tuesday latest archive and a Monday last successful restore, with the relevant availability for each. It is inaccurate to attach Monday’s green restore result to Tuesday’s new bytes. This example is a model, not a reported customer timeline. Its value is that it makes the identity error easy to recognize before a real recovery depends on the dashboard.
A restore result needs a reproducible identity
Hostwatch’s backup contract associates successful verification with the archive identity, a SHA-256 where available, a verification timestamp and the installed driver’s integrity, schema and table-digest results. The driver’s protocol is specific to the configured application. A generic controller cannot infer whether copying an arbitrary database file produced a transactionally valid backup. The operator must install the snapshot and restore procedure that understands that database and its writers. The interface should show a missing or incomplete result explicitly rather than upgrading a plausible filename into proof.
A historical success remains a historical fact even if the corresponding archive later expires or moves. Current availability must therefore remain a separate property. If the named file is missing or its known identity conflicts, the history can still explain that a check once succeeded, while clearly saying that this copy is not currently available through the approved storage. This avoids two opposite mistakes: erasing useful verification history, or presenting an unavailable historical archive as an immediately usable recovery point. Both identity and present access matter.
Independent verification must leave the source alone
The installed verification workflow creates a new private scratch directory and restores there. It checks the restored result without choosing the production database as its destination. This separation is essential: checking whether a backup works must not overwrite the service being protected. The driver also needs an application-appropriate consistency procedure. For a multi-writer service, identifying every writer and its data relationship is part of that installation work. A complete-looking inventory does not replace the database-specific snapshot contract or prove that external effects can be replayed safely.
Keep verification distinct from a service migration. A restore test can establish properties of an archived copy while public traffic continues to use the source. Moving the active service additionally requires runtime compatibility, dependency bindings, write authority, destination health, routing and a recovery protocol. Hostwatch uses separate governed operations for those purposes. An operator choosing another server as a possible destination has not approved a data move merely by inspecting capacity. The correct interface keeps the job’s objective visible throughout the operation so a successful restore is not celebrated as a completed cutover.
A small archive can require a large verification window
The compressed archive size is only one input to capacity planning. A full verification may require decompressed data, temporary working files, archive staging and a reserve that remains available to the operating system and live application. Memory, host load, I/O and execution time also matter. These demands vary by installed driver and database. A free-disk number that exceeds the compressed file size is therefore insufficient to declare readiness. The read-only preflight must describe the actual operation and preserve unknown requirements instead of silently treating them as zero.
Hostwatch checks workspace, reserve, load, memory headroom and active or unresolved jobs before the configured action. Some approved expiry adapters can account for eligible retained copies while preserving the last verified recovery point; preview itself does not remove them. There is still an implementation limit: a unified planner for backup retention together with isolated restore capacity remains follow-up work. The current checks and driver contract should not be advertised as a universal capacity guarantee. When the installed preflight blocks a verification, the honest next step is to resolve that specific resource or evidence gap.
Desired policy needs an effective-settings readback
A saved schedule is not proof that a server is running it. Hostwatch’s configured profiles let an owner review the schedule and timezone, retention in days, approved storage, free-space reserve and resource budgets. The controller reads back the dedicated systemd timer, executor and limits, and blocks operations when their effective state drifts from the reviewed configuration. This makes configuration status an observation about the selected server. A successful form submission alone cannot establish that the timer will fire with the intended arguments and budget.
The boundary is intentionally narrow. Source paths, destinations, keys, executable arguments and unit bindings belong to the installed operator profile. The app and MCP select that profile and its reviewed settings; they do not accept a general shell command or a new private key as a backup parameter. Writes require the existing owner and scope checks. A newly enrolled server can therefore show that backups are unconfigured without implying a product failure. Installing an agent supplies an authenticated operating channel; the application-specific recovery procedure still has to be prepared.
A lost response must keep the original operation identity
A backup or restore can continue after the phone loses its connection. Hostwatch uses a durable job and a stable UUID for the action so the same request can be retried without inventing a second operation. If the outcome cannot be established from the installed worker and its receipt, the job remains unknown and fences further work. That state is inconvenient, but it is more accurate than interpreting an HTTP timeout as proof that nothing happened. Starting another full restore with a new key can consume the very headroom needed to inspect the first one.
Follow the existing job, inspect its authoritative result and preserve any unresolved scratch identity for the installed recovery procedure. Do not reset a fence merely to make the Run button available. In the interface, queued and running remain intermediate states; accepted work becomes successful only after the matching result. A useful error explains which operation needs inspection and which server owns it. It should not expose driver output, customer table contents or credentials. Operational clarity comes from structured identity and state, rather than copying a privileged worker’s entire log into a mobile screen.
Review the recovery chain, not the badge count
A routine review should identify the newest archive, the last independently verified restore, whether that exact recovery material is available, and the age of both observations. Then inspect effective policy and the readiness of the next scheduled operation. If a new archive has not been fully restored, say so. If an old successful check refers to an expired file, keep its history but do not count it as available recovery coverage. These are small distinctions in the data model with large consequences when an operator needs a dependable answer under pressure.
The design goal is a recovery conversation that another person can continue without guessing. They should know which copy was checked, what the check established, where the evidence ends and what operation is safe to inspect next. The published contract documents the current boundaries and unresolved outcomes. Hostwatch can make those facts easier to follow across web, iPhone and MCP; it cannot turn an untested application procedure into a recovery guarantee. A green result is useful when its identity and meaning survive the drilldown.
Attach restore evidence to an exact archive and keep that proof separate from the newest backup. Check current availability and resource preflight before starting another verification; a historical success is not permission to proceed.