Summary

  • Scaleway says a bucket’s default retention applies to new objects and runs from each object’s creation. One duration does not create one common expiry date for an evolving estate.
  • An explicit retain-until date and an independent legal hold affect different constraints. Retention expiry alone does not demonstrate that a hold has been removed or a version deleted.
  • Enabling object lock cannot be undone at bucket level, and versioning cannot then be suspended. Buyers need to distinguish that commitment from visibility, recovery and the separately documented account-lifecycle boundary.

One duration, more than one promise

Consider a hypothetical archive that keeps receiving new material under the same default retention duration. Earlier and later objects do not start their clocks together. The policy can look uniform while the dates at which particular commitments mature remain different. No customer inventory is being measured here; the point follows from how Scaleway describes the start of its default retention period.

The provider’s object-lock guide, reviewed on May 21, 2026, says a default applies to every new object added to the bucket and that the period begins at each object’s creation. It also distinguishes a duration expressed in days or years from an object’s absolute retain-until timestamp. A buyer who treats the bucket’s settings as an estate-wide deadline has confused the rule that admits new commitments with a schedule of commitments already present.

That difference matters commercially because retention protection is also a restriction on later choice. The service can prevent an operator from removing a protected version even when a project wants to change its housekeeping plan. The value purchased is not merely stored capacity. It includes a defined inability to alter the protected record under particular conditions.

Bucket permanence and object expiry are different

Scaleway requires versioning for object lock. Once object lock is enabled on a bucket, the guide says it cannot be disabled and versioning cannot be suspended. This is a lasting choice about the bucket’s operating regime. It does not say that every object must consequently remain forever, or that every object has the same retention settings.

The guide describes two modes. Compliance prevents deletion or overwrite during the specified retention period even by owners and administrators; the mode cannot be changed and the period cannot be shortened. Governance allows appropriately authorised users to modify retention and delete targeted objects. These are different allocations of future control, not two interchangeable labels for the same administrative convenience.

Object-level retention can override a bucket default for the specific object, according to the same guide. The explicit retain-until field is an absolute timestamp. A default configuration therefore cannot, by itself, establish the protection state of every item. Nor does the statement that defaults apply to new objects establish retroactive protection for everything already present. Existing versions require their own evidence; this analysis does not infer an undocumented reset of their clocks when an object is read or renamed.

The irreversibility at bucket level and the non-shortenable compliance period operate at different scales. One concerns whether the bucket can leave its lock-enabled regime. The other concerns what can happen to a particular protected version before its date. Combining them into a single claim of “permanent retention” would obscure both.

A legal hold is not another way to express the same date

Scaleway describes legal hold as an independent on-or-off protection with no expiry date, explicitly removed by a user with the necessary permission. Retention and legal hold can coexist. The disappearance of one time constraint does not establish that the other protection has ended.

For a procurement decision, this means a duration is not the whole commitment. An archive can include items whose retention periods have expired but whose holds remain active. Conversely, removing a hold does not demonstrate that a separate retention restriction has expired or been permissibly altered. These are logical distinctions in the documented controls, not claims about a real customer’s backlog.

The name “legal hold” should not be mistaken for a legal recommendation in this article. The documents describe a product mechanism. They do not establish which law requires a particular organisation to retain a particular record for a particular period. Choosing an illustrative duration from a vendor example would not answer that separate question.

An item can disappear from view without disappearing from storage

The provider’s deletion troubleshooting guide, reviewed in July 2025, explains another source of mistaken completion. A deletion request in a versioned bucket without a version identifier creates a delete marker while the targeted objects continue to exist. Its governance discussion separately identifies a bypass request and version identifier. This is a description of documented boundaries, not an instruction to alter customer data.

The backup guide also explains that versioning can create new versions under the same name. A name or an ordinary listing is consequently not a complete representation of retained history. The visible state, the existence of a particular version and the permissions affecting that version must not be treated as one thing.

A procurement report built only from what is currently visible could therefore misunderstand the remaining commitment. That is a possible measurement error, not evidence that Scaleway has lost protected bytes or charged a particular customer incorrectly. A delete marker is not proof of physical erasure; equally, proof that bytes remain is not proof that an application can reconstruct a useful service from them.

Preservation is not a recovery result

Scaleway’s storage shared-responsibility document assigns infrastructure operation to the provider while leaving lifecycle choices, version management, continuity measures and integrity work with the customer. It describes traces made available on request and customer responsibilities for retaining relevant records and checking successful operations. None of those statements is a measured recovery result for a particular archive.

Object lock can protect a version from a defined change. It does not, on that evidence alone, demonstrate that every necessary application component was captured consistently or that a replacement environment has been validated. The distinction is important when “retained” becomes shorthand for “recoverable.” A stronger restriction on deletion and a successful restoration are different benefits requiring different evidence.

There is also a wider boundary in the public wording. Scaleway’s concepts page and its April 2026 backup guide mention deletion of the entire account as an exception alongside retention expiry. The February 2026 account-closure guide describes permanent deletion of resources and backups while console access remains, and distinguishes closure from personal-data erasure. The documents do not settle here the precise handling of a presently locked version during that procedure.

That boundary needs clarification rather than a sweeping conclusion. This research did not close an account, invoke a bypass or test a retained object. It does not establish a working vulnerability, a failure of the object-level promise or indefinite custody across every account-lifecycle action. The current detailed guide’s owner-and-administrator restriction should be read in its documented control scope, not expanded into an untested guarantee about every other process.

The buyer’s unit of commitment is smaller than the bucket

The practical economic question is which future decisions have been constrained, for which records and until when. A single default may be appropriate, but it is an input to that answer rather than the answer itself. An evolving archive, explicit object settings and independent holds can make a uniform policy generate a non-uniform set of outstanding obligations.

The selected sources provide no figure for the resulting bill, savings, recovery success or incident exposure. They support a narrower proposition: the attractive simplicity of a bucket setting does not eliminate the need to understand individual commitments. Purchasing stronger protection means being precise about what cannot later be changed, without mistaking visibility or an expired clock for a completed release.

Sources