Protect recovery points from deletion

Deletion protection stops anyone from deleting or overwriting a recovery point for a set number of days after it is written. Azure enforces it, so it holds even against an account with full control of the subscription.

How deletion protection works#

Recovery points are stored under an Azure immutability policy that the deployment locks. While it is locked, Azure refuses to delete or overwrite a file until its window has passed, for everyone: you, a subscription Owner and Vambris. The window can be raised but never lowered or removed.

Every deployment starts with a 1-day window, so the permanent choice is never made for you at installation. An Admin can raise it from the dashboard; updating EIDGuard never lowers it. Each file's window counts from when it was written, at the length in force then, so a report added to a recovery point later gets its own window, and files written before a raise keep at least their shorter one.

Deletion protection is separate from retention. Retention decides when EIDGuard deletes a recovery point; deletion protection decides how long nobody can. Retention cannot be shorter than the window: the minimum retention is the larger of the 30-day soft-delete period and the deletion protection window. See Back up tenants.

The current window appears under Configuration > Protection > Deletion protection, under Configuration > Deployment > Immutable window, and in the Deletion protection field on each recovery point's page.

Status on a recovery point#

A recovery point's page shows the policy in its Deletion protection field:

Shown	Meaning
Locked policy · N days	Files written while this locked policy was in force cannot be deleted for N days after they were written.
Window ended	The recovery point's files are older than today's window and no longer protected. Retention and Azure permissions decide when they are deleted.
Not locked	A deployment did not finish locking the policy. Azure still refuses deletes today, but anyone with full access to the subscription can shorten or remove the policy. To complete the lock, redeploy EIDGuard over the existing deployment (Update EIDGuard).
Not immutable	There is no policy. Azure permissions alone govern deletion.
Not confirmed	The policy could not be read, so no protection is claimed. Reload the page to check again.

When the policy is not locked, Configuration > Protection also shows "Deletion protection isn't locked — redeploy to lock it." When there is no policy, the Deletion protection section is not shown.

Raise the window#

Warning

A raise is permanent. Nobody can lower or remove it afterwards: not you, not Vambris, not a subscription Owner. Azure also allows a locked window to be extended only a limited number of times, ever, so choose the window you want to keep rather than stepping up to it. A longer window also means a longer wait before EIDGuard can be removed.

Requirements#

You need the Admin role. Viewers and Operators see the window read-only.
The new window must be a whole number of days, more than the current window and at most 3650 (ten years).
At most one raise every 24 hours.
Every retention must already be at least the new window, or 0 (keep forever): the default under Configuration > Protection > Retention, and each tenant's own on the Tenants page (Per-tenant protection). Otherwise the raise is refused and the message names each retention to change.
With private networking, start the raise while the worker VM is powered on (around scheduled backups), or power it on first.

Steps#

Go to Manage > Configuration > Protection.
In the Deletion protection section, enter the new number of days. The text beside the field shows the current window.
Select Apply. The button stays disabled until the value meets the requirements above.
In the Raise deletion protection dialog, read the warning, type the number of days again in Type <N> again to confirm, and select Raise to N days.

What happens during a raise#

The raise runs as a job, shown on Jobs as Raise deletion protection, and the section shows "Raising deletion protection — watch the job." until it ends with one of these results:

Raised: "Recovery points are now locked for N days." The new window applies from now on, and Azure may also hold existing recovery points longer.
Refused: "Not raised — nothing was changed." followed by the reason, with a link to the job. Fix what the reason names and try again.
Ended another way: "The raise job ended … — the window shown above is what Azure enforces now." The job failed or was stopped; the window shown is the one Azure reports.

What a longer window costs#

Recovery points kept longer use more storage. The dashboard estimates about $0.02 per GB a month, and a typical tenant recovery point is well under a megabyte. For current prices, see Azure Blob Storage pricing.

Deletion protection and removing EIDGuard#

Removing EIDGuard means deleting its resource group. Azure will not delete the storage account while it holds a recovery point inside its window, so removal waits until the newest recovery point is older than the window. To keep recovery points beyond the deployment, export them first. For the procedure, see Remove EIDGuard; if the resource group delete stops on the storage account, see Deleting the resource group fails with AccountProtectedFromDeletion.

Troubleshoot a raise#

Before the dialog opens, a message under the field says what to correct, for example "Enter more than N — it can only go up." or "Default retention is N days — raise it to at least M first."

A refused raise reports one of these reasons. Nothing was changed in any of these cases.

Reason (beginning of the message)	What to do
"Retention must be at least N days (or 0, keep forever) before recovery points can be locked that long …"	Raise each retention the message names (Configuration > Protection, or Tenants > Settings), then raise again.
"The storage lifecycle policy still deletes recovery points sooner than N days …"	Save retention again in the dashboard, then raise again.
"Deletion protection was already raised in the last 24 hours …"	Wait until the time the message gives.
"Another deletion-protection raise is already running."	Wait for that job to finish.
"Deletion protection is not locked, so it cannot be raised from the dashboard."	Redeploy EIDGuard over the existing deployment to complete the lock (Update EIDGuard).
"Azure refused the raise: this locked policy has already been extended as many times as Azure allows …"	The window cannot be raised again.
"The deletion protection policy changed while this job was applying it …"	Another raise or an update changed it first. Reload the page to see the current window.
"WorkerOffline: … a raise started now would queue and never run."	With private networking, raise while the worker VM is on, or power it on first.
A message saying something "could not be read"	Try again shortly.

If a raise fails with AuthorizationFailed shortly after you update EIDGuard, wait a few minutes and raise again: permissions an update adds can take a few minutes to apply.

If the job fails with "Recovery points are now locked for N day(s), but retention changed while the raise was applied …", the raise succeeded but someone saved a shorter retention meanwhile. Raise it to at least the new window (or 0).

Microsoft documents locked time-based retention, including its limit on extensions, in Time-based retention policies for immutable blob data.