mirror of
https://github.com/kevinveenbirkenbach/docker-volume-backup.git
synced 2026-08-12 09:24:40 +00:00
Kevin Veen-Birkenbach
cd21f1fa67
Each volume is copied twice into the same destination: once hot with the container running, once cold after it is stopped (backup/app.py:127-131). rsync ran with -b, so --delete did not remove a file the source had dropped between the passes - it renamed it. Stopping a container is exactly what makes the source drop files: a graceful shutdown flushes, and the format rolls its commit point. For an opaque payload the twin is stale bytes nobody reads. For a format that enumerates its own directory it is corruption. Lucene resolves the current commit by parsing every file starting with segments as a radix-36 generation, so a restored segments_3~ raises NumberFormatException, the shard store cannot be read, and the primary is left NO_VALID_SHARD_COPY. With .security-7 unallocatable the reserved elastic user has no password hash, every probe gets HTTP 401, and the container never turns healthy. Seen in infinito-nexus-core CI run 30963648828: the restore drill waited 1200s on elasticsearch while all 29 other containers came back healthy; the generation held segments_3~ next to segments_4 in all three index directories. A run two days earlier passed the same drill because that stack was idle and nothing rolled between the passes - which is why this reads as flaky rather than broken. Reproduced with real rsync in all three shapes: two passes into the same destination with -b leave segments_3~ beside segments_4, without -b only segments_4 survives, and a single pass keeps segments_3. Measured on the same fixtures, dropping -b leaves the predecessor generation byte-identical and keeps the --link-dest hardlinks intact, so the incremental scheme is unaffected; generations get smaller, never larger. --link-dest already provides the cheap incrementals. -b contributed nothing on top of it but the twins, and no caller reads them: the restore path is an unfiltered rsync -avv --delete into the live volume (restore/files.py:35). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>