Backup deletion protection prevents someone from removing recovery data before its required retention period ends. It depends on the permissions assigned to people and applications, the controls enforced by the storage system, and whether another administrative route can defeat those controls. A successful backup job confirms that a copy was created. It does not establish who can erase it.
The account running your backups is a useful place to start. If someone took control of that account, could they delete yesterday’s recovery point? Could they grant themselves more permissions, shorten protection for future backups, or reach a second copy using the same credentials?
Those questions turn a broad claim about protected backups into something a backup administrator can verify. The goal is to identify which recovery copies remain usable after an account is compromised, and what prevents that account from destroying them.
Backup environments have several kinds of authority. A backup operator manages jobs, a storage administrator manages the destination, and an identity administrator controls access. Automated services may have permissions that differ from those held by the people using the console.
Review effective permissions across those roles. An account with no direct delete permission may still be able to change a policy or assume another role that grants it. A second username offers little separation if the same compromised administrator can reset its password or retrieve its credentials.
Use a simple ownership review to expose these relationships:
| Account or role | What to check |
|---|---|
| Backup operator | Can it remove recovery points, stop jobs or change retention? |
| Backup service account | Can it delete stored data or obtain broader permissions? |
| Storage administrator | Can it change protection settings or dismantle the repository? |
| Identity administrator | Can it grant access to both primary and recovery environments? |
| Encryption-key administrator | Can it disable or destroy keys required for restoration? |
| Infrastructure administrator | Can it remove the underlying virtual machine, disks or storage service? |
Treat the table as a set of questions, not a claim that every role has those powers. Record the actual account, its permissions and the system enforcing the restriction. Include emergency and service-provider access because those routes may sit outside the normal backup team’s view.
A backup application and its storage destination maintain different information. Depending on the product, removing an entry from the backup catalog may leave the stored data intact. Conversely, a catalog entry may remain even when the underlying data is missing or inaccessible.
Amazon S3 illustrates another distinction: a delete request can add a delete marker while a locked object version remains stored. A normal view may make the object appear absent. Recovery then depends on locating the retained version and using a supported recovery procedure.
For a deletion test, check both layers. Determine what happened to the application record, then verify the stored recovery data and attempt a restore. An error message in the console alone does not demonstrate that every route to permanent deletion is blocked.
This matters when an incident damages the backup server itself. The team needs a documented way to reconnect or rebuild the recovery environment and discover retained backups. Preserving the data is valuable only if the recovery process can find and use it.
Access permissions determine which requests an account is allowed to make. Immutability adds an enforced restriction on changing or deleting protected data. Both matter, particularly when an attacker acquires credentials belonging to a legitimate administrator.
Consider a hypothetical repository where operators cannot delete backups, but a storage administrator can grant that permission. The restriction helps prevent routine mistakes. It does not, by itself, demonstrate that a compromised storage administrator cannot erase the copies.
The useful test is whether the retention control still blocks deletion when a privileged account requests it. Ask which layer enforces that decision and which exceptions exist. A product label or disabled button does not answer those questions.
In Amazon S3, governance-mode retention permits an authorized bypass when the required permission and request are present. Compliance-mode retention blocks users, including the account root user, from permanently deleting a protected version or shortening its retention before expiry. These are materially different permission boundaries.
For another S3 storage platform, confirm the supported modes and behavior in its documentation. Do not infer every administrative safeguard from API compatibility. The backup application’s integration and the storage configuration both need to match the intended protection.
Object Lock is applied to object versions. A bucket’s capability to support it is not evidence that every backup has the required retention. Inspect the protection actually attached to a representative backup’s objects and confirm that the application’s retention workflow covers the data needed to restore it.
Keep the evidence understandable: which backup was inspected, when its protection expires and which account verified it. This is more useful during an operational review than a screenshot showing that a feature is enabled somewhere in the environment.
Protection of existing copies and protection of future copies need separate checks. An administrator may be unable to erase a currently protected backup while still being able to stop new jobs or change how subsequent backups are retained. That can reduce the available recovery history over time without an immediate deletion event.
Imagine a daily backup job whose protected copies remain intact, but whose schedule has been disabled. The storage control is still doing its job. The organization nevertheless stops receiving fresh recovery points, and the last usable copy becomes progressively older.
Monitor changes to job schedules, destinations and retention settings alongside deletion attempts. Assign someone responsibility for investigating those changes rather than relying on a log that no one reviews. Confirm that a policy adjustment has not created a gap between the application’s retention expectations and storage enforcement.
Expiration also needs an owner. Backups should become eligible for cleanup according to an agreed policy, with capacity planned around that policy. Emergency pressure to reclaim space is a poor time to discover that the team does not understand which copies are still protected.
A repository is part of a larger system. Depending on its deployment, it may rely on virtual infrastructure, administrative interfaces, external key management and shared identity services. A review that stops at the backup console leaves those dependencies unexplored.
For a virtual storage appliance, ask who can remove its virtual disks or delete the appliance. For a managed service, ask who can terminate the service or close the account. For physical infrastructure, establish how administrative and physical access are controlled, and what independent recovery copy survives a site-level loss.
These questions do not mean that every listed action defeats every platform. They identify boundaries that must be checked against the actual architecture. Request a documented explanation of what is protected, from which accounts, and under which failure or compromise conditions.
Encryption introduces a related dependency. Object retention does not preserve access to an external encryption key. Losing that key can leave stored backups unreadable, so key administration and key recovery belong in the same review even though no backup object was deleted.
A second location helps address a site failure, but location alone does not establish administrative separation. If one account controls both repositories, compromise of that account may affect both. Review the destination’s credentials, retention and recovery access independently.
Follow the actual path used to create the copy. Determine which permissions the transfer process needs and whether they also allow destructive changes at the destination. Verify how deletion and retention changes at the source affect the second copy for the replication or backup method in use.
Then consider recovery while the primary environment is unavailable. The team needs access to the destination, necessary keys and the information required to restore. An independent copy should not depend entirely on credentials or configuration stored only inside the failed environment.
Document those dependencies in the recovery procedure. Different administrators should be able to follow it without relying on one person’s memory of how the secondary repository was configured.
Use a disposable backup in an isolated test environment that reflects the relevant production policies. Choose a supported retention period, confirm available space and agree on the expected results before beginning. Avoid experiments on production recovery points or destructive infrastructure tests outside an approved exercise.
Create the test backup through the normal application workflow. Record its retention, the destination and the identities involved. Confirm a successful restore first so that later failures are not confused with a backup that never worked.
Include the metadata and dependencies required by the application. The test should represent a recoverable backup, not merely an arbitrary file uploaded to the same destination. That makes the result relevant to the recovery process the business actually depends on.
Test the ordinary operator and application identities, then the privileged roles within the agreed scope. Attempt the supported deletion and retention-change operations relevant to each role. Record whether the action was blocked, what changed and which control enforced the result.
Check policy-changing authority as well as direct delete permissions. If a role can grant itself an exception, that is part of its effective access. Where an action succeeds, determine whether it removed a catalog record, changed future behavior or permanently removed protected data.
After the exercise, locate the retained backup and restore it using the documented process. Capture the storage evidence, application outcome and audit events together. Note any manual steps needed to make a retained copy visible again.
The resulting record should let another administrator understand the outcome without repeating the entire investigation. Repeat the relevant checks after material changes to identity, retention, storage configuration or the backup integration. A previously verified design can drift as those components change.
Scality’s CORE5 approach covers five layers: API, data, storage, geography and architecture. That provides a useful structure for this review because a backup’s protection depends on more than the request presented to its S3 endpoint. Each layer addresses a different part of the system that stores and exposes the data.
ARTESCA documents support for S3 Object Lock with compliance-mode retention, along with identity controls, encryption and a hardened operating system. Those capabilities establish specific controls to inspect in a deployed backup environment. Their configuration and the backup application’s validated integration still need to be verified.
The practical question for a Scality deployment is therefore specific: which accounts can manage backups, which can administer the platform, and what happens when each tries to remove a protected recovery point? Use the deployment’s documented controls and a restore exercise to answer it. Avoid treating any single feature as evidence that every recovery dependency is protected.
A useful deletion-protection review ends with a clear statement about a particular recovery copy. It identifies who can access it, when its protection expires, what administrative exceptions exist and how it will be restored. It also names the dependencies that could make the copy unavailable without deleting it.
Start with one critical workload and follow its backup through that review. Resolve the unclear permissions and recovery steps before expanding the exercise to other repositories. The result is a defensible answer to the question that matters during an incident: which usable backup remains when the account you normally trust is no longer trustworthy?