Six fixes since v1.7.2, all in the check that tells you which backups a container has not got. No breaking changes, no config or schema changes — upgrading is a straight swap of the exe.
Four of the six made that check under-report: a backup declared present when it was not, or a container declared current when it was hours behind. A short list reads as an all-clear, which is the worst direction for it to be wrong in.
The whole history is read, with no cap anywhere
The instance's backup history was read as "the newest 500" — and not even that. The limit was applied after joining the table that holds one row per backup file, so it counted files rather than backups: a four-way striped setup got a quarter of what the number promised. The cut could also land inside a backup set, leaving an entry holding some of its stripes — which a RESTORE cannot use, and which this check reported as missing files that were neither missing nor beyond the limit.
Every caller feeds something a short answer quietly breaks: the restore chain, the CLI's inventory, and the missing-backups check itself. So there is no cap on any of them now. A database on a one-minute log schedule takes 1,440 backups a day; the old limit covered about eight hours, against containers routinely further behind than that.
Copied backups land where the app can find them
The check names the backups that never reached the container and writes you a script to copy them in. That script uploaded each file under its bare name, which puts it at the root of the container.
Nothing about the upload fails. But a blob's database and server are read back out of its path, by the container's own layout — so a file at the root belongs to no database, every question the app asks steps over it, and pressing "rescan and check again" reported none of them arrived after a copy in which every byte transferred.
The destination now follows the container's own pattern, worked out from what the instance recorded about each backup. The file keeps its name; only where it lands changes.
A backup is only "present" on evidence that it is
Matching is by LSN where both sides have one. Otherwise it falls back to type and timestamp within a few seconds — which is the ordinary path, because a container set only carries an LSN once it has been audited.
That tolerance assumed the timestamp came from the file name, where it is the backup's own start time. When the name cannot be parsed, the only time available is when the blob finished uploading — a different event, on a clock that can be hours out of position. Comparing the two as though they were the same kind of thing could match a backup against an unrelated one that happened to upload nearby, and report it as safely in the container when it was not.
An upload time now vouches for nothing. Auditing a container reads each backup's own header and settles it exactly; where that has not happened, the panel says how many sets it could not identify instead of quietly guessing.
"This container is N behind" can no longer disappear
The same reading was used to measure the gap, and the same two problems applied — with a worse outcome. An upload time always makes the container look more current than it is, and a UTC reading west of UTC runs ahead of the server's own clock. Both shrink the measured gap, and a gap that did not come out positive was not reported at all.
So a single such set could suppress the warning entirely, on a container genuinely hours behind. It is measured only from real backup times now, and where there are none it quotes no figure rather than a wrong one.
The button works
"Check its history" stayed disabled after choosing an instance, and the only way to wake it was to leave the screen and come back. It read a value nothing ever announced had changed, so the control kept the answer it was given while the list was still empty. It also greys out while a check is running now, so a second press cannot land on one already in flight.
Under the hood
2,291 tests. Every fix above was confirmed to fail against the unfixed code before the fix went in.