A job is configured to keep fourteen restore points and the object storage repository is configured with a thirty day immutability period. Neither number, on its own, describes how long the data will actually be locked or how much capacity the repository will end up holding. The lock that arrives on a given object is produced by several settings interacting, and the result is almost always longer than the largest figure typed into any one of them.
The tempting reading is that the settings are independent. Retention governs how many restore points exist, immutability governs how long an object resists deletion. That holds for a single object considered alone. It fails once a chain is involved, since the software will not release a restore point whose blocks are still referenced, and the storage will not accept a delete for an object whose retain until date has not passed.
Both constraints apply at once and they do not apply to the same unit. Retention is counted in restore points, a logical construct assembled from many objects. The lock is counted in days and applies to each object version. Whether to use an Object Lock bucket at all is a separate question with its own tradeoffs; what follows assumes that decision is settled.
What the immutability period applies to
The period is configured once on the object storage repository and then applied at write time, object by object. When a block lands in the bucket, the backup software calculates a retain until date and sets it on that object version. From that moment the storage enforces the date and the backup software has no further say in it.
So the repository has no single unlock moment. Objects written on Monday and on Friday carry dates four days apart and become deletable four days apart. Nor is the period measured from the start of the chain: an incremental written today receives the full period counted from today, even though the full it depends on is weeks older.
How job retention and the lock period compound
When job retention is shorter than the immutability period, the job reaches the point where it wants to remove the oldest restore point and cannot. The point is marked for removal, the delete fails against locked objects, and the data stays at full size until the dates pass. Capacity is then governed by the lock, not by the retention count.
When retention is longer than the period, the opposite holds. Objects come out of lock while the chain still depends on them, so retention governs capacity and the lock is a floor under the youngest portion of the repository. That is easier to forecast and weaker to rely on, since older points sit in the bucket unprotected.
Neither arrangement is visible from one screen. The retention figure lives in the job, the period lives in the repository configuration, and the dates live on the objects. Reading all three is the only way to know which constraint binds, and it is the same reconciliation that matters when locks start lapsing.
Block generation and the longest lock in the chain
A strict per object lock would break a chain. If a full written on day one expired while incrementals written on day thirty still pointed at its blocks, the chain would be one successful delete away from being unrestorable. Veeam extends immutability on blocks still part of an active chain, grouping writes into generations and refreshing the lock while a generation remains in use.
The lock on a long lived block is therefore not the configured period. It is that period plus however much of the current generation was still running, and the extension applies to the generation rather than to one object. Generation length and the exact mechanism vary between versions and configurations, so the figure that matters is observable locally: the spread between write timestamp and retain until date on a sample of objects.
GFS restore points sit on top of this. A weekly, monthly or yearly point is kept far past the operational chain, and its immutability derives from that longer retention rather than from the repository period. The oldest locked object in most repositories belongs to a GFS full, not to the daily chain.
| Setting | What it controls | What it does not control |
|---|---|---|
| Restore points kept by the job | How many points the software maintains and when it asks for a delete | Whether that delete succeeds, or when capacity returns |
| Immutability period on the repository | The minimum lock written onto each object at upload | How long the chain still needs those objects present |
| Block generation handling | Extension of the lock on blocks a live chain still references | The retention count configured in the job |
| GFS weekly, monthly and yearly points | Which points survive past the operational chain, and for how long | The repository period, which no longer governs them |
| Backup mode, forward incremental or periodic full | How long a single block stays referenced by a live point | Dates already stamped on objects written earlier |
Predicting the capacity that follows
Capacity here is not the restore point count multiplied by an average point size. It is the sum of three populations. The first is the active chain, which grows with change rate and shrinks as points age out. The second is the set of points the software has finished with but cannot delete. The third is the GFS set, which grows in steps and shrinks rarely.
The second population breaks forecasts. Its size is roughly the data written during the interval by which the effective lock exceeds the moment the job wanted to delete, which means it scales with daily change rate rather than with total protected data. Two environments of identical size and identical settings can hold very different amounts of held over data if one churns harder.
A first pass model is built from change rate, the gap between retention and effective lock, and the GFS schedule, in that order. Those inputs feed the same arithmetic used for sizing a repository from change rate and retention, with the held over population kept as a separate line rather than folded into an average.
Where ARTESCA fits
ARTESCA is object storage software used as a backup target, presented over an S3 compatible API, with immutability provided through S3 Object Lock. The division of responsibility is clean: the backup software computes a retain until date and sets it at upload, and the storage enforces that date regardless of what is later changed in the job or the repository configuration.
Because enforcement lives at the bucket, the questions split cleanly too. Which restore points should exist, how long a generation runs and how GFS points are scheduled are answered in the backup software. Whether a delete will be refused today is answered by inspecting the object version and its retain until date. Versioning underpins Object Lock, so noncurrent versions consume capacity until they are expired in their own right.
The system runs on infrastructure the customer operates, so retained data, keys and operational access stay inside the customer's own boundaries. Capacity held longer than expected is held on hardware the team owns and can measure directly.
What to write down before changing a retention number
Before any retention value is edited, four figures belong in the same note: the restore point count in each job, the immutability period on the repository, the GFS schedule, and the oldest retain until date currently present in the bucket. The fourth is the only one that reflects what is in force, and the only one that cannot be read from a configuration screen.
Changes are best made one at a time, since two simultaneous edits make the result unattributable. The meaningful observation window afterwards is not a week. It is at least one full generation plus the longest GFS interval expected to turn over, because nothing about the held over population is visible until objects written under the old settings have finished leaving.
A short record kept with the job configuration is enough: what changed, on what date, the oldest retain until date beforehand, and capacity on that day. Six months later it answers whether the repository grew because the environment changed or because a number was adjusted whose consequences ran longer than expected.