# ep0: the whole-guest off-site copies for THIS box - contents, 2026-09-17T00:27:45Z, READ ONLY
# Taken because "the data left the house" is a claim, and a claim needs a look inside.

group   /mnt/pbs-datastore/ns/tester-1/ct/9201
owner   felhom@pbs!tester-1

  2026-09-16T17:27:32Z      catalog.pcat1.didx   4496
                            client.log.blob      1196
                            index.json.blob       688
                            pct.conf.blob         401
                            root.pxar.didx      61056

  2026-09-16T21:59:54Z      catalog.pcat1.didx   5216     <- TONIGHT's copy
                            client.log.blob      1397
                            index.json.blob       687
                            pct.conf.blob         402
                            root.pxar.didx     246616

Both snapshots carry a full set: a manifest (index.json.blob), a file index (root.pxar.didx), a
catalog, the guest config and the client log. Neither is a stub or a half-written directory.

## WHY THE SECOND ONE MATTERS TONIGHT
21:59:54Z is round 6's OFF-SITE leg - the one that started BY ITSELF after I killed the local leg
that could never have fit. Its file index is 246616 bytes against 61056 for the afternoon copy, i.e.
roughly four times the indexed content, which is consistent with a guest that had by then been
seeded with twelve apps. So the whole-guest copy of tonight's box is on ep0, and the data really did
leave the house on the night the local tier could not hold it.

## THE HONEST LIMIT - presence is still not success
This is a LISTING, not a verification. It proves the files exist and are shaped like a real backup.
It does not prove every chunk is readable. A PBS verify job WOULD prove that, and it is deliberately
NOT run: it writes verify state into the datastore, and ep0 is read-only for evidence tonight.
So the correct claim is: the off-site copy is PRESENT and well-formed, and its restorability has
not been tested this session.

## AND THIS IS A DIFFERENT STORE FROM THE ORPHANED ONE
These PBS snapshots (whole-guest vzdump to ep0) are not the same thing as the restic app-backup
repository on the Storage Box, which is orphaned and holds zero readable snapshots. Tonight the box
had a working off-site path for the WHOLE GUEST and a broken one for PER-APP restores, at the same
time. Any sentence that says "off-site backup works" or "off-site backup is broken" without naming
which of the two is meant would be wrong in one direction or the other.

## MY MANIFEST PROBE WAS WORTHLESS, AND ITS SILENCE MUST NOT BE READ AS AN ANSWER
I tried to read a verify state out of index.json.blob and the client log with grep and strings.
Both returned NOTHING - and so did my negative control. That is the whole problem: with a
compressed blob, "no match" and "unreadable" look identical, and I had no POSITIVE control that
would have to appear if the probe worked at all. A probe that cannot fail visibly is not a
measurement, which is the same lesson as the empty-needle grep, the wrong-directory listing and the
invented hostname earlier tonight.
So the verify state of these snapshots is UNKNOWN, not absent. The only claim that stands is the one
already written above: the copies are PRESENT and well-formed, and their restorability was not
tested this session.
