The honest answer, in most environments, is yes. An administrator with the access normally granted to run a backup platform can also destroy what it produced, usually in under an hour and usually without triggering anything that looks like an alarm. This is not a defect in any particular product. It follows from the fact that the person who can configure retention is also the person who can change it.
The question is worth asking because the usual answers avoid it. Immutability is often described as if it settled the matter, and it closes real paths, but not all of them, and the ones it leaves open are those an insider is best placed to use. Separating what is genuinely blocked from what is merely inconvenient is the only way to know which risks have been accepted rather than removed.
The paths that run through the backup software
The most direct path is deletion from the backup console. An administrator selects restore points, or an entire backup chain, and removes them. Well designed platforms record this and may require confirmation, but the operation exists because legitimate cleanup exists, and the record is written to a system the same administrator can usually reach.
The second path is retention. Shortening a retention period deletes nothing immediately. It causes the next retention pass to remove everything now considered expired, through the same routine process that clears old data every night. This is quieter than explicit deletion and produces a log entry describing a policy edit rather than a mass removal.
The third is the repository itself. Removing it from the console, or reformatting the volume beneath it, discards the data without any per object deletion occurring. Where the repository is a general purpose file system or block device presented to the backup server, this is a storage operation rather than a backup operation, and the software may only notice afterward.
The paths that run underneath the backup software
Below the application, the storage layer offers its own routes. If backups land on object storage, the S3 credential used by the backup jobs can also be used directly with a command line client. What that credential can do is defined by policy rather than by the backup software, and a key granted full access can delete objects the console would have refused to remove.
Bucket policy is a further step down. An identity able to edit the policy, or able to change versioning and lock configuration, can alter the rules that protect objects before deleting them. This path goes around the backup application entirely, which means the backup platform's own audit trail will contain nothing about it.
Underneath that sits the infrastructure. A hypervisor administrator can delete the virtual machine that is the repository. Someone with access to the storage array or the appliance's management interface can destroy the underlying volumes or reinitialize a disk group. Physical access closes the list, since hardware removal requires no credentials at all. These layers matter because they are frequently administered by the same small team, which is the practical reason for separating backup administration from general infrastructure administration.
| Deletion path | What it removes | What closes or narrows it |
|---|---|---|
| Console deletion of restore points | Selected backups or a whole chain | Object Lock on the storage side, since the storage refuses the delete regardless of console intent |
| Retention shortened in the backup software | Everything newly considered expired, at the next pass | Retention enforced on the object rather than by the job, so the lock outlives the policy edit |
| Repository removal or volume reformat | The full contents of that repository | A second copy on separate storage under separate credentials |
| Direct use of the storage credential | Objects the policy allows that key to delete | A narrowly scoped key without delete rights and without the right to lift a lock |
| Bucket policy or lock configuration change | The protection over everything in the bucket | Compliance mode locks, plus a separate identity for bucket administration |
| Hypervisor or hardware layer destruction | The platform the repository runs on | Physical separation of one copy, and different administrators at that layer |
Which paths immutability actually closes
Object Lock closes the first two rows cleanly and the fourth partially. An object under a retention period cannot be deleted before that period expires, so console deletion fails at the storage layer and a shortened retention policy in the backup software does not shorten the lock already written to the object. A stolen or misused storage key cannot delete locked objects either, provided the key lacks the rights to change lock settings.
What it does not close is everything that operates on the container rather than the object. Whether a lock can be lifted depends on the mode chosen when the bucket was created, and the difference between the two modes is exactly the difference between an administrator who can reverse a decision and one who cannot, which is the substance of governance mode compared with compliance mode.
It also does not close the layers beneath. A lock is enforced by software running on hardware, and an administrator of that hardware is outside the scope of the lock. This is the boundary where immutability and physical separation stop being interchangeable, a distinction covered in more detail in how an air gap and immutability differ.
What closing a path costs day to day
Every control in the right hand column has an operational price, and pretending otherwise is how controls get removed six months later. Compliance mode means capacity cannot be reclaimed early. Data written under a three year retention occupies storage for three years even if the workload it protected was decommissioned in month four, so sizing has to assume the full period.
Splitting administration costs coordination. If the person who runs backups cannot administer the bucket, then a genuine mistake, a job misconfigured to write a very large volume of data under a long lock, requires a second person to resolve and sometimes cannot be resolved at all. Teams of three or four feel this immediately, since it means a control that depends on two people being available.
A separate copy on separate infrastructure costs money and attention. It is also the only control in the table that survives every path, which is the reason the 3-2-1-1-0 structure keeps one copy outside the main environment rather than relying on a single hardened target.
Where ARTESCA fits
ARTESCA is object storage software used as a backup target, with immutability provided through S3 Object Lock. Retention is enforced on the object by the storage layer, so a deletion issued from the backup console or from a client using the job credential is refused for the duration of the lock. Both governance and compliance behavior are available, and the choice is made per bucket.
Because it presents an S3 API, the credential a backup job uses and the identity that administers the bucket are separate objects with separate policies. Whether they are held by the same person is a local decision, and it is the decision that determines whether the bucket policy path in the table is open or closed.
Deployment is on infrastructure the customer runs, so the hypervisor and hardware layers beneath remain under the customer's administration. Physical location, network boundaries and who holds console access to the underlying platform are set by the operating team, not by the software.
What to decide and record
Write down, for each path in the table, whether it is open or closed in the current environment and who could use it. The exercise takes an afternoon and produces a shorter list than most teams expect, usually two or three names. That list is the accurate answer to the question in the title for one specific environment, and it is more useful than any general statement about immutability.
Decide which paths are worth closing based on that list rather than on principle. Closing the storage credential path by narrowing the key is cheap and rarely regretted. Closing the bucket policy path by splitting administration is worth doing where headcount allows. Closing the hardware path requires a copy somewhere else and is a budget conversation rather than a configuration one.
Review the list when people change roles or leave, since its accuracy depends on knowing who holds which credential today. Record the review date beside it so staleness is visible.