Skip to content

docs(operations): make the recovery cleanup safe to run after the snapshot volume - #142

Merged
Fl0p merged 1 commit into
mainfrom
flo-973-recovery-leftovers
Oct 11, 2026
Merged

Fl0p merged 1 commit into
mainfrom
flo-973-recovery-leftovers

Conversation

@Fl0p

@Fl0p Fl0p commented Oct 11, 2026 •

Copy link
Copy Markdown
Contributor

The What a recovery leaves behind section of the DuckDB recovery page predates the timed Parquet snapshots. That feature added a fourth cotel* volume on the host which is not a recovery leftover and is the only restore point there, but the page's cleanup table never mentions it. An operator following this page to delete leftovers therefore meets the backup with no guidance, and docker volume prune looks like a reasonable shortcut.

What changed:

  • cotel-snapshots is now a row in the table, marked never-delete.
  • Spells out what docker volume prune actually destroys in each direction: with the deploy up it takes the irreplaceable forensic original, with the deploy down it also takes the snapshots.
  • The page no longer implies the step-2 ...-backup-... copy is already deleted. That deletion is one write on a host whose read-write access may belong to someone else, so it can sit undone. The page now tells you to classify a listed leftover by hash instead of inferring anything from its name.

Verified: npm run build in docs/ passes (VitePress fails the build on dead links). The documented classification loop was run read-only against the four live cotel* volumes: the two damaged twins return the same hash, the snapshots volume returns no database file, production's hash is unique. Production's /data mount was confirmed with docker inspect rather than assumed from the volume name.

🤖 Generated with Claude Code

@coderabbitai

coderabbitai Bot commented Oct 11, 2026

Copy link
Copy Markdown

Review in Change Stack →

Note

Currently processing new changes in this PR. This may take a few minutes, please wait...

⚙️ Run configuration
  • Configuration used: defaults
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 4ed22e0b-a10c-4d2c-9bca-3ce642e24e5e

📥 Commits

Reviewing files that changed from the base of the PR and between c0c36c5 and 06a0dcc.


📒 Files selected for processing (1)
  • docs/operations/duckdb-recovery.md

 ______________________________________________________________________
< I see you chose the 'dynamic typing' difficulty setting. On purpose. >
 ----------------------------------------------------------------------
  \
   \   \
        \ /\
        ( )
      .( o ).
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Commit to this branch
  • Create a new PR

  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

…pshot volume

The "what a recovery leaves behind" section was written when a recovery left
three volumes. The timed Parquet snapshots added a fourth that shows up in the
same `docker volume ls`, is not a leftover, and is the only restore point on the
host - so a reader following this page to clean up met the backup with no guidance
about it. Adds it to the table as never-delete, and spells out what
`docker volume prune` actually destroys in each direction.

Also stops the page from implying the step-2 copy is already gone. The deletion is
one write on a host whose read-write access may belong to someone else, so it can
sit undone; the page now says to classify a listed leftover by hash rather than
infer anything from its name. Verified the classification command against the four
live cotel volumes: the two damaged twins share one hash, the snapshots volume
reports no database file.

Co-Authored-By: Daedalus <daedalus@agents.flopbut.local>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@Fl0p
Fl0p force-pushed the flo-973-recovery-leftovers branch from 06a0dcc to a7ac397 Compare October 11, 2026 18:09
@Fl0p
Fl0p merged commit 97e57cd into main Oct 11, 2026
7 checks passed
@Fl0p
Fl0p deleted the flo-973-recovery-leftovers branch October 11, 2026 18:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant