Most of these are good products for a different failure

Survives a dropped table or bad deploy

The failure everyone plans for. Every option here handles it.

Copy sits outside the account holding the data

Cloud-native services can write cross-account and cross-region, which is configuration you have to get right. Snapshots are held by the provider that runs the resource.

Survives compromise of the cloud account

Follows directly from the row above: if the copy answers to the same control plane, it shares the blast radius.

Works across providers and on-premise

Cloud-native services are scoped to their own provider's resources by design.

Encrypted with a key the vendor never holds

Provider-managed and customer-managed keys both live in the provider's KMS. We hold public keys only, so we cannot decrypt in any configuration.

Hold cannot be shortened by whoever holds the account

Vault Lock and Object Lock enforce this at the storage layer. Ours is enforced in our code: it stops the account holder and our own sweep, and not someone holding our bucket credentials. Weaker than a storage-layer lock, and we would rather say so.

Verifiable history of every run

A script writing to a bucket leaves a directory listing, which cannot tell you about a run that never happened.

Restorable without the vendor's tooling

Snapshots and vault-format backups generally restore through the provider's own API. Our artifacts are standard compression and standard encryption.

Backs up things with no connector

Anything you can produce a file from, via a script source or a push.