Zum Inhalt springen
#0952
FilesCron

The off-site copy reads the journal, not the disk

Nightly backups re-read a filesystem to find out what changed. The container already wrote that down.

The file journal is append-only and monotonic by id. A cron entry every ten minutes calls GET /api/v1/journal?after_id=<last>&limit=500. The response is every mutation since the previous run: path, op, before and after hashes, size_after, plus next_after_id and has_more. The script fetches only paths whose after hash it hasn't stored yet, writes them to the off-site bucket, and saves the cursor. Deletes arrive as op: delete, so the mirror tombstones instead of discovering absence.

No full walk, no mtime heuristics, no agent installed on the box. The change feed is a cursor, and the cursor is a query parameter.

Backups used to ask the disk what happened. Now the disk keeps a ledger.