Backup deletion approval is a control that requires a second person to confirm before backup data is removed. It is often called the four-eyes principle: two people have to see and agree to a destructive action before it takes effect. The control exists because deleting restore points is a legitimate, routine operation that also happens to be exactly what an attacker or a disgruntled administrator would do. A single account, however well protected, should not be enough to erase an organization's recovery copies.
This post explains how four-eyes approval works for backup deletion, which actions it should cover and how it fits with immutability.
The problem it addresses
Backup administrators need the ability to delete. Old jobs are retired, test backups are cleaned up, repositories are decommissioned. Any account with that ability is also a single point of failure. If its credentials are stolen, or its owner makes a mistake at the end of a long day, the same rights that allow housekeeping allow the removal of every restore point. Multi-factor authentication makes theft harder. It does not help against a hijacked session, an error or an insider.
Four-eyes approval separates the request from the authorization. One person asks for the deletion and a different person, using a different account, approves it. Neither can complete the action alone.
Actions worth placing under approval
| Action | Why it matters | Approval recommended |
|---|---|---|
| Deleting backups or restore points | Direct loss of recovery data | Yes |
| Removing a repository or bucket from the configuration | Can orphan or erase its contents | Yes |
| Shortening retention or immutability periods | Causes data to expire sooner than intended | Yes |
| Disabling or deleting backup jobs | Stops new restore points being created | Yes, or alert at minimum |
| Adding or changing administrator accounts | Could be used to create a second approver under one person's control | Yes |
| Changing approval settings themselves | Would disable the control | Yes |
| Running restores | Does not remove data | No, though it should be logged |
The principle is to cover every action that removes recovery capability, including the indirect routes. Shortening retention to one day achieves the same result as deleting, a day later.
How the workflow runs
In products that implement it, the flow is simple. An administrator initiates a protected action. Instead of executing, the system records a pending request and notifies the designated approvers. A second administrator reviews what is being asked and approves or rejects it within a set time, after which an unanswered request expires. Only on approval does the action run, and both identities are written to the audit log.
Where the backup software has no built-in feature, the same effect can be approximated with process: deletions are raised as change tickets, approved by a second person and carried out using a privileged account whose password is released only against an approved ticket. This is weaker, since it relies on procedure, but it still removes the single-account path.
The approvers must be independent
The control is only as strong as the separation between the two parties. If both accounts authenticate against the same directory and an attacker controls that directory, the attacker can act as both. If one administrator knows the password of the other, or the second account is a shared mailbox, there is in effect one person. Approver accounts should be named, individually held, protected by their own multi-factor authentication and, ideally, not dependent on the production domain. Separating backup admin accounts covers how to structure those identities.
In very small teams, the second approver may sensibly sit outside IT operations: a security officer, an IT manager or a trusted service provider. What matters is that a compromise of the day-to-day administrators does not automatically include the approver.
Friction and how to keep it low
A control that blocks routine work gets switched off. Two measures keep four-eyes approval tolerable. Scope it to the destructive actions in the table and leave everything else alone. And make sure there are at least three eligible approvers, so that holidays and illness do not leave a request waiting for days. An expiry time on pending requests prevents old approvals from being used later out of context.
Genuine emergencies are rare for deletion. There is almost never a reason why backup data must be removed within the hour, which makes deletion a good candidate for a deliberate pause.
Approval and immutability together
Four-eyes approval and storage-level immutability address the same risk from different sides. Approval governs what administrators can do through the backup software. Immutability governs what anyone can do to the stored data, through any path, for a fixed period. Approval is flexible: it allows a justified deletion to go ahead. Immutability in compliance mode is absolute: nothing is removed until the lock expires. Object Lock governance and compliance modes explains the degrees in between.
Used together they cover each other's gaps. Immutability protects recent restore points even if both approvers are compromised. Approval protects the configuration, longer-term data outside the lock period and the settings that determine what future backups look like. Insider threat and backup deletion goes through the scenarios each one stops.
Where ARTESCA fits
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. Immutability is provided by S3 Object Lock on each object, and in compliance mode no account, including ARTESCA administrators, can remove a lock before it expires. That holds regardless of what is approved or requested in the backup software, which makes it the backstop beneath a four-eyes process.
The repository has its own administrative accounts, separate from the backup server and the production directory. ARTESCA grows within the same deployment from roughly 50 TB to 8.5 PB and is used as a target for Veeam and other backup software.
Testing that it works
The control should be tested like any other. Once or twice a year, an administrator attempts a protected action without approval and confirms it is held. The approver list is reviewed for leavers. The audit log is checked for any deletion with a single identity attached. If each test passes, the organization can state with evidence that no one person is able to erase its backups.