‘Backed Up’ and ‘Actually There’ Aren’t the Same Thing

A dry-run backup is a rehearsal pass that simulates the full write operation and reports what would be committed — without touching production data — so truncation, record loss, or scope errors surface before they become permanent.

What the dry-run actually caught

On 2026-08-13, a dry-run pass on ai_news_latest.json reported a BLOCKED_TRUNCATION event: the file would have written at 2,089 bytes against a 28,779-byte source — a 93% reduction. A HEAD comparison against 39 records confirmed zero surviving records in the current file. All 39 had moved to archive. The “nowhere” count was zero: no records were lost to the void, but none were present in the live file either.

After repair, a live run produced COMMITTED status, residue zero, git status clean.

The gap the dry-run crossed is between write confirmation and data integrity. COMMITTED tells you a write occurred. It says nothing about the ratio of what survived.

Why COMMITTED status is not a safety signal

Backup tools report on the operation they were asked to perform, not on the relationship between what existed and what remained. A 93% truncation commits cleanly if the tool’s task was “write this output to disk” and the output happened to be 2,089 bytes. No error. No flag. No diff.

The pattern has a structural cause. Backup pipelines are typically validated at build time against small fixtures and checked at runtime against exit codes. Neither catches a case where a filter, a scope parameter, or a HEAD offset quietly changes what feeds the write. The write succeeds. The data shrinks.

This is where the dry-run earns its place as a verification layer rather than a convenience flag. It forces the pipeline to compute its output before committing it, which is the only moment when a size or record-count anomaly is still reversible.

The three conditions that make silent truncation possible

Silent truncation requires three things to align — and all three were present in the measured incident:

1. A bounded source: the pipeline reads from a defined HEAD or record window, not the full dataset. Shifting that window by one parameter silently changes scope.
2. A write-only confirmation signal: the downstream system reports success on the act of writing, with no comparison to the prior state or expected cardinality.
3. No record-count gate: nothing in the pipeline checks whether records-in matches records-out within an acceptable tolerance before the write is allowed to commit.

Remove any one of these and the truncation either fails loudly or never occurs. The dry-run substitutes for removing condition three: it surfaces the cardinality mismatch before the commit window opens.

What this means for pipelines that ingest live data

Coding agents now carry memory layers — tools like funes, announced September 3, 2026, index agent session traces locally and can push to a Hugging Face dataset the operator owns. The same structural risk applies to any pipeline where a memory or knowledge store is written by an automated process: if the write confirmation is the only check, a scope change that truncates the store commits silently.

The AWS benchmarking work on OpenAI models on Amazon Bedrock makes a parallel point from a different angle: price-per-token is the number on every pricing page, but production workloads buy outcomes — resolved tickets, correct summaries — and the multipliers between the sticker price and the outcome are what the spreadsheet misses. Backup pipelines have the same accounting problem. Exit-code success is the sticker metric. Record survival rate is the outcome metric. The dry-run is what measures the gap.

The three-condition checklist before any live backup write

The measured incident points to three concrete gates, each targeting one of the structural conditions above:

• Size ratio check: compare output bytes to source bytes. A drop beyond a defined threshold (the incident showed 93%) blocks the write and requires explicit override.
• Record-count parity check: compare records-in to records-out. Zero surviving records against a 39-record source is an unambiguous signal; a tolerance band of ±5% catches partial truncations.
• Dry-run as mandatory pre-flight: run --dry before every scheduled write, not only during development. Log the dry-run output alongside the live-run output so anomalies are diffable over time.

None of these gates require new infrastructure. They require treating the dry-run output as evidence rather than a development convenience.

The non-obvious principle

The 93% figure is not the interesting finding. The interesting finding is that the COMMITTED status that followed repair was indistinguishable, to any downstream consumer, from the COMMITTED status that would have followed truncation. Both look the same from outside the pipeline. The dry-run is the only instrument positioned between those two outcomes — and it is optional by default in most backup tooling.

Looking for more on ai & digital income? Visit SAVYX

Frequently Asked Questions

What does a dry-run backup flag actually do?

It simulates the full write operation and reports what would be committed — size, record count, scope — without touching production data. Any truncation or record loss is visible before it becomes permanent.

Can a backup show COMMITTED status even if most data was lost?

Yes. COMMITTED confirms a write occurred, not that the written data matches the source in size or record count. The measured incident produced a 93% size reduction that would have committed cleanly without the dry-run gate.

How large a truncation is worth blocking?

The appropriate threshold depends on how much your pipeline’s output legitimately varies run-to-run. A record-count parity check with a ±5% tolerance catches most silent truncations; a size-ratio check set at, for example, 20% drop triggers on anything beyond normal variance.

Does this risk apply to agent memory layers like funes?

Yes. Any pipeline where an automated process writes to a knowledge or memory store carries the same structural risk: if write confirmation is the only check, a scope change that truncates the store commits without a signal.

Is a dry-run enough on its own?

It closes the most dangerous gap — making the truncation visible before commit. Pairing it with a size-ratio check and a record-count parity gate removes all three structural conditions that allow silent truncation.

Disclosure: As an affiliate, this post may earn a commission from qualifying purchases at no extra cost to you.