What This Trilio Document Confirms About Incremental Backup

snapshot A

snapshot B

compare via rbd diff

extract changed blocks

store only deltas

The key detail shows up again: the size of an incremental backup is exactly the size of the data that changed.

It says more than how one product is implemented. Backup systems are optimized for moving data efficiently. They are not built to guarantee that a system can be reconstructed correctly.

Put precisely, the document shows that backup logic is a mathematical comparison of storage states. You take snapshot1 vs snapshot2, compute the diff, get the changed blocks, and back those up.

As in the first document, and now beyond doubt, there is zero concept of what the application means. The whole system reduces to one question: "what bytes changed".

This confirms the earlier point that "backup saves blocks". Both documents show identical behavior, so it can now be said with confidence: backup is block-level delta tracking.

Go one level deeper and the uncomfortable part appears. When you restore, you:

reconstruct the snapshot

rebuild the volume

attach it to the VM

A restore does not do any of the following:

reconstruct application state

validate dependencies

ensure the system executes correctly

Missing orchestration is only part of it. The larger gap is a mismatch between what the backup captures and what people expect a restore to give them.

The cleanest version of the message has a headline, a core claim, and a gap.

Headline

Your backup is mathematically correct, but the system you restore from it might not be.

Core claim

Backup tools track exact data changes at the block level. They are precise, efficient, and scalable.

The gap

They cannot tell whether the restored system will actually work.

The strongest one-liner: "Your backup is accurate. Your recovery is uncertain."

A sharper version: "You restore the data perfectly. You don't restore the outcome."

The argument now covers:

an architecture gap

an ownership gap

a recovery gap

a reconstruction gap

and proof at the data level

Each one arrives at the same conclusion from a different angle.

Backup answers "what changed?" Recovery needs an answer to "what should work together?" The space between those two questions is the category.

The analysis already spans top-level architecture and bottom-level mechanics, which is full coverage. The question to use in real conversations is this: "Even if your backup is perfect, how do you know your system will work after restore?"