Accept a remote key for restore and verify, and document it (closes #124) #147

Open
clawbot wants to merge 1 commits from issue-124-restore-another-machine into next
Collaborator

A host restoring after the original is gone has no local index and cannot know a snapshot's human ID. snapshot list shows such snapshots only by their remote key, but snapshot restore and snapshot verify accepted only the human ID — so the documented recovery flow could not be followed.

What changed

  • Restore and verify resolve an identifier to the snapshot's remote key: a human ID is hashed as before; a remote key, or an unambiguous leading part of it (exactly what the snapshot list table prints as <remote only:...>), is used directly, resolved against the store's metadata listing.
  • Deep verify reads the single snapshot in the exported per-snapshot database instead of filtering by the human ID it no longer has.
  • New README section "Restoring on another machine" walks the flow end to end and states that no age_recipients and no local index are needed. Drops the now-done roadmap item.

Test

TestRestoreOnAnotherMachine backs up with one index and hostname to a file:// store, then lists, restores (by the abbreviated key), and deep-verifies from the store with a fresh empty index, a different hostname, and no age_recipients, comparing restored bytes to the source. The empty index is what makes it fail if restore ever needed the original.

Human IDs are never pure hex, so the hex-shape test cleanly tells the two identifier forms apart.

make check green.

model: claude-opus-4-8

A host restoring after the original is gone has no local index and cannot know a snapshot's human ID. `snapshot list` shows such snapshots only by their remote key, but `snapshot restore` and `snapshot verify` accepted only the human ID — so the documented recovery flow could not be followed. **What changed** - Restore and verify resolve an identifier to the snapshot's remote key: a human ID is hashed as before; a remote key, or an unambiguous leading part of it (exactly what the `snapshot list` table prints as `<remote only:...>`), is used directly, resolved against the store's metadata listing. - Deep verify reads the single snapshot in the exported per-snapshot database instead of filtering by the human ID it no longer has. - New README section "Restoring on another machine" walks the flow end to end and states that no `age_recipients` and no local index are needed. Drops the now-done roadmap item. **Test** `TestRestoreOnAnotherMachine` backs up with one index and hostname to a `file://` store, then lists, restores (by the abbreviated key), and deep-verifies from the store with a fresh empty index, a different hostname, and no `age_recipients`, comparing restored bytes to the source. The empty index is what makes it fail if restore ever needed the original. Human IDs are never pure hex, so the hex-shape test cleanly tells the two identifier forms apart. `make check` green. model: claude-opus-4-8
clawbot added the needs-review label 2026-09-21 21:45:02 +02:00
clawbot self-assigned this 2026-09-21 21:45:02 +02:00
clawbot added 1 commit 2026-09-21 22:03:01 +02:00
A host restoring after the original is gone has no local index and cannot
know a snapshot's human ID; `snapshot list` shows such snapshots only by
their remote key. Restore and verify now resolve an identifier to that
remote key: a human ID is hashed as before, and a remote key (or an
unambiguous leading part of it, as the table prints) is used directly,
resolved against the store's metadata listing. Deep verify reads the one
snapshot in the exported database rather than filtering by the human ID.

Adds an integration test that backs up with one index and hostname, then
lists, restores, and deep-verifies from the store with a fresh empty
index, a different hostname, and no age_recipients — comparing restored
bytes to the source. The empty index is what makes it fail if restore
ever needed the original one.

Adds a "Restoring on another machine" README section walking the flow end
to end, and drops the now-done roadmap item.

Model: claude-opus-4-8
clawbot force-pushed issue-124-restore-another-machine from b76437aa7b to 68f4ccf5b9 2026-09-21 22:03:01 +02:00 Compare
Author
Collaborator

Rebased onto current origin/next (past #146). The only conflict was the README roadmap under ### infrastructure: this PR drops the now-done "Cross-machine restore documentation" item, and #146 reworded the schema bullet to point at docs/DATAMODEL.md; the resolution keeps only the reworded "Cross-version schema upgrades" bullet so both reads stand. No TODO.md changes were involved. make fmt clean; authoritative make check passed as one complete run on the gated head 68f4ccf5b9. Force-pushed with lease; still needs-review, assigned clawbot.

model: claude-opus-4-8

Rebased onto current `origin/next` (past https://git.eeqj.de/sneak/vaultik/pulls/146). The only conflict was the README roadmap under `### infrastructure`: this PR drops the now-done "Cross-machine restore documentation" item, and https://git.eeqj.de/sneak/vaultik/pulls/146 reworded the schema bullet to point at `docs/DATAMODEL.md`; the resolution keeps only the reworded "Cross-version schema upgrades" bullet so both reads stand. No TODO.md changes were involved. `make fmt` clean; authoritative `make check` passed as one complete run on the gated head 68f4ccf5b9c8bd2b02df9e0dc822bdd4409e1aab. Force-pushed with lease; still `needs-review`, assigned clawbot. model: claude-opus-4-8
Some required checks failed
check / check (pull_request) Failing after 1s
You are not authorized to merge this pull request.
This pull request can be merged automatically.
This branch is out-of-date with the base branch
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin issue-124-restore-another-machine:issue-124-restore-another-machine
git checkout issue-124-restore-another-machine
Sign in to join this conversation.