Backup chain design is usually settled during installation, in a dialog offering forward incremental, reverse incremental, or forever forward with synthetic fulls. It looks like a storage question, since the visible difference is how much space each option consumes. It is actually a recovery question. The chain shape decides what a restore has to read, how long that reading takes, and how much of the history a single damaged file can take with it.
The storage framing is not wrong, it is just incomplete. Space is the cost that shows up on a capacity graph every day, so it wins the argument by being visible. The recovery cost shows up once, during an incident, and nobody is measuring it at that moment.
Four shapes cover almost every deployment, and they differ in three ways that matter: how many files a restore has to open, what one corrupt or missing file destroys, and how much work the backup server does on an ordinary night.
A restore is a reconstruction. The product assembles the requested point in time from whatever files hold the blocks that make it up, and the number of files it has to touch is set entirely by the chain shape.
With a forward incremental chain, the newest restore point is the most expensive one. Reconstructing it means reading the full backup at the head of the chain and then applying every increment written since, in order. A chain that has run for three weeks without a new full means twenty one files opened in sequence. With a reverse incremental chain the arrangement is inverted: the most recent point is always a complete full, so restoring yesterday reads one file, while restoring three weeks back means reading that full and then walking backward through reverse increments.
Forever forward with synthetic fulls sits between the two. Increments are written each night, and periodically the product builds a new full by merging existing data on the repository rather than reading from production. The chain length between fulls is therefore bounded, which bounds the worst case restore, without ever reading the source machines again.
Chain shape also decides the blast radius of a single bad file. This is where the difference stops being about minutes and starts being about whether a recovery point exists at all.
| Chain shape | What restoring the newest point reads | What one damaged file costs |
|---|---|---|
| Active full plus forward increments | The full, then every increment since it | A damaged full ends that chain; a damaged increment ends everything after it |
| Forever forward with synthetic fulls | The most recent synthetic full, then increments since it | Same as above, but the exposure window is bounded by the synthetic interval |
| Reverse incremental | One file, the current full | A damaged full costs every point, since all reverse increments depend on it |
| Active full every run | One file | One restore point, and nothing else |
| Forward increments with no full refresh | The original full, then a chain with no bound | Any single file can orphan every point after it, indefinitely |
The last row is a configuration nobody chooses deliberately. It appears when an active full schedule is disabled to save space or to fit a backup window, and it is worth checking rather than assuming, since the chain length in the console is the only place it shows.
Daily processing cost runs in almost the opposite direction to restore cost, which is why the decision is a trade and not an optimization.
Forward increments are the cheapest nightly operation. Changed blocks are read from production and written once. Active fulls are the most expensive, since the entire machine is read from production storage and written again, which is both a load on the production array and the main reason backup windows overrun. Reverse increments are cheaper on production than an active full but expensive on the repository, because every run injects new blocks into the full and writes the displaced blocks out as a reverse increment, turning one logical write into a read, a write and another write.
Synthetic fulls move that work onto the repository entirely. Production is read once for the increment, and the full is assembled from data already stored. That is attractive until the repository is asked to do it, since a synthetic operation on a device with poor random read behavior can take longer than the active full it replaced. This is the single most common surprise when a chain design is carried over to new storage unchanged, and it is usually the slowest step rather than the obvious one that sets the elapsed time.
Object storage does not hold backup files the way a filesystem does. Products that write natively to an object repository break the data into many small immutable objects, group them into generations, and track which objects a given restore point depends on in metadata. There is no file to overwrite, because objects are written once and only ever deleted.
That changes the calculus in three places. Reverse incremental, which depends on rewriting a full in place, generally does not apply to a native object repository at all. Synthetic full creation becomes a metadata operation over existing objects rather than a large read and rewrite, which removes most of its cost. And retention no longer deletes a file, it deletes the objects no remaining point depends on, which is why capacity does not fall in the steps people expect. The mechanics of how chains are represented on an object repository are worth reading before a chain design is ported.
Immutability interacts with this directly. When objects carry a retention lock, nothing in the chain can be rewritten or removed early, so a design that relied on in place modification has to be replaced rather than tuned. Long chains also extend the period during which older objects stay referenced, which moves capacity in ways a simple retention count does not predict and belongs in the sizing allowance for growth and churn.
ARTESCA is object storage software used as a backup target, with an S3 compatible API and immutability through S3 Object Lock. Backup software writing to it uses its own chain representation, so the shape of the chain is decided in the backup product and the repository stores the resulting objects.
The practical consequence for chain design is that the repository is write once. Objects are added and later deleted, never modified, so any shape that assumes a file can be updated in place belongs on a different tier. Object Lock reinforces that, since a locked object cannot be removed before its retain until date regardless of what the chain would prefer.
Because ARTESCA runs on infrastructure the customer operates, the requests generated by synthetic full creation and by retention processing stay inside the customer's own network rather than crossing a link to an external provider. Whether a particular product performs synthetic operations server side or by reading data back is a question for the version in use.
Two figures make the trade visible. The first is the worst case chain depth for each job, meaning how many files or object generations a restore of the oldest retained point would have to traverse. The second is the elapsed time of an actual restore from that oldest point, measured rather than estimated, since the depth only matters through what it does to the clock.
Both belong in a review that happens on a schedule, not once at install. Chains lengthen quietly when a full is rescheduled, a job is edited, or a repository change makes synthetic operations slow enough that someone turns them off. Reviewing the chain depth alongside reported space savings also keeps reduction ratios in perspective, because a longer chain flatters them while making recovery worse.
Write down the reason for the shape that was chosen, in one line, next to the job. When the design is revisited under pressure, the argument that saved it last time is the thing nobody can reconstruct.