Backups
An invoice dispute may be resolved months before the machine holding its records fails. Restoring the final amount alone would lose the corrections and supporting documents that explain the outcome. The rules used to make the decision also belong to that record. Recovery needs to keep that knowledge together.
Because definitions are part of the dataset, backups can protect their history alongside the facts they describe. Referenced documents and other files belong in that recovery too. A restored invoice can retain its relationship to the evidence someone reviewed. Each application avoids having to coordinate separate recovery plans for those parts of its data.
Multiple targets
A nearby backup can make recovery convenient, while a copy elsewhere protects against losing the machine and its local storage together. Multiple targets let the same dataset have both. Local folders and S3-compatible storage offer choices about location and cost. The useful combination depends on which failures the application needs to survive.
Recovery also needs agreement about the history being recovered. An older copy may simply lack recent work, but copies with conflicting changes require a decision about which history to retain. Choosing by timestamp could discard valid work. Stardust refuses conflicting histories rather than choosing one automatically.
Compression and encryption
Compression can reduce the storage and transfer costs of backed-up transaction history. Encryption protects the contents of backup copies, including their referenced files, when those copies are stored elsewhere. Each target can have its own compression and encryption settings. A local copy and a remote copy can therefore have different settings, and encrypted copies require their key for recovery.
Acceptable loss
The latest committed change may not yet have reached a backup target. That delay matters differently for a dataset that can be rebuilt and one holding records that cannot be replaced. Lag limits express how much work can remain unprotected at each target. When a target exceeds its limit, further data writes are held until its lag is within the limit.
The number of targets, their locations, compression, encryption and acceptable lag are choices along a sliding scale. Keeping less recent work unprotected can mean pausing writes sooner during an outage. More copies require more storage and transfer work.