They answer different questions
Versioning asks who changed what, when, and what the previous content was. Backup asks whether data can be recovered after the source device or site disappears. Both concern the past, but their failure hypotheses differ.
A live vault, mirror, and bare repository on one computer all disappear under one disk failure. Ten thousand commits still provide zero independent copies. An offsite copy without history may survive disaster but offer little help finding yesterday's one-line mistake.
Durability belongs to its existing chain
A bounded product recognizes the durability chain already in place instead of inventing another. Independent devices, network storage, and encrypted offsite copies can protect both source and ledger while Vestige contributes version history.
Adding another Git remote is not automatically safer. Soul memory is sensitive plaintext; a provider, credential, and exposure surface arrive with it. The existence of a backup need does not authorize one product to expand the trust boundary.
UI vocabulary is an invariant
If users can read Versioned as Backed Up, the status is dishonest. Show last commit and last durable backup as separate facts, or omit a backup badge when the product cannot observe durability.
The distinction changes incident response. Corrupt history is rebuilt from live truth, device loss is restored by the backup owner, and an accidental edit uses a historical blob in a forward write. Combining the words causes three runbooks to collide.
Build the failure table
List accidental edit, history corruption, disk loss, site loss, and credential theft. Mark which copies survive each row. Designs that confuse versioning with backup usually pass only the first two rows because all copies share a failure domain. Encryption and restore rehearsal are required before a durability claim is complete.