Site Reliability

Enable soft delete and a sufficient retention window for storage

One capability across blobs and containers: make sure that an accidental or malicious delete, or a bad overwrite, can be undone for at least a week, rather than being instant and permanent the moment it happens.

13 min·10 sections·AZURE

Last reviewed 18 June 2026

Soft delete and retention: the basics

What actually happens when someone deletes a blob you needed?

By default, a delete against Azure Blob Storage is immediate and final. A script with a wrong prefix, a lifecycle rule with an off-by-one date, an engineer cleaning up the wrong resource group, or an attacker with a stolen key can remove objects, and unless you have arranged otherwise, there is nothing to undo. Soft delete changes that default. When blob soft delete is enabled, deleting a blob marks it as soft-deleted and keeps it recoverable for a retention period you choose. Container soft delete does the same for an entire container if someone removes it whole. Neither is on unless you turn it on.

There are three settings that make up this one capability, and they protect against different shapes of mistake. Blob soft delete recovers individual objects, snapshots and versions that were deleted or overwritten. Container soft delete recovers a deleted container and everything in it, which a blob-level setting cannot do because once the container is gone the blobs go with it. Blob versioning keeps a previous copy on every overwrite, so a corrupting in-place write is recoverable even though nothing was technically deleted. Microsoft's guidance is to enable all three together, with a retention period of at least seven days, for a complete in-account data-protection posture.

The retention window is the part people get wrong. A one-day window technically satisfies 'soft delete is enabled' but gives you almost no margin: a delete that happens late on a Friday can age out before anyone is back at work to notice. The recoverable period runs from one to 365 days, and the clock starts the moment an object is deleted or overwritten, not when someone discovers the problem. At least seven days is the recommended floor precisely so that a weekend, a holiday or a slow alert does not turn a recoverable incident into a permanent one.

In this lesson you will learn how Azure Blob Storage handles deletes and overwrites by default, why that default turns an ordinary mistake into an outage, and how to enable blob soft delete, container soft delete and versioning with a retention window that actually gives you room to recover. You will see how to find every account that is unprotected, how to set the window safely, and how to enforce it across the estate so new accounts inherit the protection.

Fun fact

The clock starts when you delete, not when you notice

The most counter-intuitive thing about soft delete is the timing. The retention clock starts the moment an object is deleted or overwritten, not the moment a human realises something is wrong. A blob deleted at 6pm on Friday with a one-day window is gone for good by Saturday evening, long before the Monday-morning standup where someone says 'wait, where did that data go?' This is exactly why the recommended floor is seven days rather than one: the window has to outlast not just the mistake, but the time it takes a real team, with weekends and on-call rotations, to spot it and act.

Finding storage accounts with no recovery window

Priya runs the platform team at a SaaS company that just had a near miss: a cleanup script deleted a container of customer documents, and only blind luck, an engineer who happened to be watching, caught it before the data was needed. The container had no soft delete. It was unrecoverable, and the team rebuilt it by hand from a stale export.

Before changing anything, Priya wants the real picture: which accounts have a recovery window at all, and how long that window is. A finding that simply says 'soft delete is enabled' is not enough, because a one-day window is barely protection. She starts by listing the actual retention days on every account.

List the blob soft-delete retention days for every account in a resource group. A blank or single-day value is the real exposure.

$ az storage account blob-service-properties show --account-name appdataprod --resource-group rg-platform --query "{blobSoftDelete:deleteRetentionPolicy.enabled, blobDays:deleteRetentionPolicy.days, containerSoftDelete:containerDeleteRetentionPolicy.enabled, versioning:isVersioningEnabled}" -o table

BlobSoftDelete BlobDays ContainerSoftDelete Versioning

---------------- ---------- --------------------- ------------

False False False

# appdataprod has NO recovery window: a delete here is permanent. Fix first.

An account that holds data a live service depends on, with no soft delete and no versioning, is the highest-value target. One wrong delete here is an outage, not an undelete.

How soft delete, versioning and the retention window actually behavedeep dive

The three settings sit on the blob service of the storage account, not on individual blobs. 'deleteRetentionPolicy' with 'enabled' and 'days' controls blob soft delete; 'containerDeleteRetentionPolicy' with the same shape controls container soft delete; and 'isVersioningEnabled' is the boolean for versioning. Because they live at the account level, turning them on protects everything in the account from that point forward, and the control-plane change takes effect immediately.

What the settings do depends on whether versioning is on alongside soft delete, and this is the part worth understanding. With blob soft delete alone, overwriting a blob automatically creates a soft-deleted snapshot of the blob's state before the write, recoverable for the retention period. With both versioning and soft delete enabled, an overwrite instead creates a new previous version, and that version is not soft-deleted and is not removed when the soft-delete retention period expires. This is why Microsoft recommends running versioning and soft delete together: versioning protects overwrites durably, while soft delete protects outright deletes, and the two cover different failure modes.

The retention window is the single most important parameter and the one most often set too low. It can be one to 365 days, the clock starts at the moment of deletion or overwrite, and when it expires the soft-deleted object is permanently deleted with no further recourse. A one-day window satisfies any check that only asks 'is soft delete enabled', but it gives a real team almost no margin to notice and act. At least seven days is the recommended floor so the window outlasts a weekend, a public holiday or a slow-firing alert. Soft delete and versioning are not a substitute for backup against region loss, but they are the fast, in-account recovery path for the far more common cause of incidents: an accidental or malicious delete or overwrite.

What is the impact of leaving storage with no recovery window?

The direct impact is permanent data loss leading to downtime. Without soft delete, a delete is final the instant it lands, so an accidental delete, a buggy lifecycle policy, a wrong-prefix script or a malicious key holder removes data with no undo. The dependent service does not just lose a file: it goes down, or runs degraded, until the data is reconstructed from somewhere else, and if no other copy exists the loss is total. Accidental and malicious deletes are one of the most common causes of data-driven outages precisely because the default makes them irreversible.

The second-order impact is recovery time, and it dominates the cost. With soft delete and versioning, recovery is an undelete: minutes, self-service, no heroics. Without them, recovery means finding another copy, validating it, and rebuilding state, which can run from hours to days and may involve serving stale or partial data the whole time. The longer the recovery, the larger the outage cost, and the variable that most determines recovery time is whether a recovery window existed at the moment of the delete.

There is a reliability-posture impact too. Azure Advisor surfaces a reliability recommendation, 'Enable Soft Delete to protect your blob data', for accounts that lack it, because Microsoft treats in-account recoverability as part of a sound data-protection strategy. An estate where every data-bearing account has soft delete, versioning and a sufficient window is one where the single most common cause of a data outage has a fast, built-in recovery path rather than an open-ended one.

How do you make storage recoverable safely?

Treat this as one capability rather than three separate toggles, and lead with the accounts whose data a live service depends on. The order matters: protect the data-bearing accounts first, set a window that survives a weekend, then enforce it so new accounts inherit the protection.

1. Inventory the recovery window, not just the toggle

List every account and read the actual retention days for blob and container soft delete, plus whether versioning is on. A value of false or one day is the real exposure. Rank accounts by how much a live service depends on their data, because an account behind a customer-facing feature is a far higher priority than a scratch account.

2. Enable all three together on data-bearing accounts

Turn on blob soft delete, container soft delete and versioning together, as Microsoft recommends, so deletes and overwrites are both recoverable and a removed container can be brought back whole. Each covers a different failure mode, and together they close the common ways data goes missing.

3. Set a window that outlasts a weekend

Use at least seven days as the floor. The clock starts at the moment of deletion, so the window has to survive a Friday-night mistake going unnoticed until Monday. Lengthen it for high-value data where you want more margin; the only cost of a longer window is a little more retained storage.

4. Enforce it so new accounts inherit protection

Use Azure Policy to audit or deny accounts that lack soft delete or a sufficient window, so a new account cannot be created without the safety net. This turns a one-off cleanup into a standing guarantee that every data-bearing account is recoverable by default.

# Make a data-bearing account recoverable: blob + container soft delete + versioning,
# with a seven-day window that survives a weekend. Runs as-is.
RG=rg-platform
ACCT=appdataprod

az storage account blob-service-properties update \
  --account-name "$ACCT" \
  --resource-group "$RG" \
  --enable-delete-retention true \
  --delete-retention-days 7 \
  --enable-container-delete-retention true \
  --container-delete-retention-days 7 \
  --enable-versioning true

# Confirm the recovery window is actually set.
az storage account blob-service-properties show \
  --account-name "$ACCT" --resource-group "$RG" \
  --query "{blobDays:deleteRetentionPolicy.days, containerDays:containerDeleteRetentionPolicy.days, versioning:isVersioningEnabled}" -o table

Quick quiz

Question 1 of 5

By default, what happens when a blob is deleted from an Azure Storage account that has no soft delete configured?

Keep learning

Go deeper on how Azure Blob Storage protects data against accidental and malicious deletes and overwrites, and how the three settings fit together.

You can now treat recoverability as one capability rather than three loose toggles: inventory the actual retention window on every account, enable blob soft delete, container soft delete and versioning together on the data-bearing ones, set a window of at least seven days so a weekend cannot age out a mistake, and enforce it with Azure Policy so new accounts inherit the protection. The single most common cause of a data outage, an accidental or malicious delete, now has a fast, built-in recovery path.

Back to the library

Soft delete and retention: the downtime-cost view

A small, predictable storage charge that caps the cost of a delete-driven outage

This is a control about the cost of downtime, not the cost of a breach. When critical data is deleted from storage with no recovery window, the business does not lose a file, it loses a service: the application that read that data is down until the data is rebuilt or restored from somewhere else, if anywhere else even has it. Soft delete and versioning convert that open-ended outage into a quick undelete. The question for finance is not whether to spend, it is whether to pay a small, predictable storage charge now or an unpredictable outage bill later.

The cost of the control is genuinely modest and easy to forecast. Soft-deleted and previous-version data is billed at the same rate as the corresponding live data for as long as it is retained, so a seven-day window adds a bounded amount of stored capacity proportional to how much your accounts delete and overwrite. There is no per-account fee and no premium tier to buy. On a quiet, mostly-static dataset the overhead is close to nothing; on a high-churn account it is larger but still a small, visible line you can size in advance and lengthen or shorten by changing the retention days.

Set against that is the cost of an outage with no recovery path: the hours or days the dependent service is unavailable, the engineering scramble to rebuild data from logs or backups that may not exist, and the revenue and goodwill lost while customers cannot use the product. The arithmetic is one-sided. A few days of duplicated storage is a cheap insurance premium against an outage whose length you cannot predict and whose cause, an accidental delete, is one of the most common ways cloud services go down.

This lesson is for the finance partner who wants to understand what an unprotected storage account costs when something goes wrong, and how cheap it is to fix. It covers why the control adds only a small, forecastable storage charge, how to size that charge before you commit, and why it is best read as outage insurance rather than a line item to question.

Fun fact

The clock starts when you delete, not when you notice

How a finance partner frames the recovery-window decision

Priya is the finance partner who gets pulled into the post-incident review after the near miss with the customer-document container. The platform lead proposes enabling soft delete, container soft delete and versioning across every production account with a seven-day window, and the instinct is to ask what that does to the storage bill. The honest answer is: a little, and predictably. Retained soft-deleted and previous-version data is charged at the same rate as live data, so the overhead is a function of how much each account churns, and it sits as a small, visible storage line rather than a new fee or a tier upgrade.

Priya asks the team to size it before committing, not after. They estimate the daily delete-and-overwrite volume on the busiest accounts, multiply by the seven-day window, and find the additional capacity is a small fraction of total storage spend, easily within the team's existing budget. Against that they put the cost the company already paid once: a day of an engineer rebuilding a container by hand and a service running on stale data while they did. The finance pack writes itself: 'A small, forecastable storage line buys back an entire class of outage we have already been burned by once. We are paying a known premium to remove an unknown one.'

Why a missing recovery window belongs on the resilience budget

The cost model here is asymmetric, which is what makes it an easy call. The control costs a small, predictable amount: retained soft-deleted and previous-version data billed at the same rate as live data, for the length of the window, with no per-account fee. You can size it in advance from each account's churn and the window length, and tune it by changing the retention days. There is no surprise in the bill.

Leaving the window off, by contrast, creates an unbounded downtime tail. The expected cost of an unprotected account is the probability of a damaging delete multiplied by the cost of the resulting outage, and that outage cost, lost revenue, engineering time to rebuild, customers served stale data or none at all, is open-ended because recovery time is open-ended when there is nothing to undelete. Finance's job is to attach that expected outage cost to each unprotected data-bearing account, compare it with the small known premium of a seven-day window, and recognise that the premium is the cheaper side of the trade by a wide margin.

What finance can do about an unprotected storage estate

Finance cannot toggle a retention policy, but it owns the framing that turns this from a contested cost into an obvious insurance buy. Three levers.

1. Size the premium before the work, not after

Ask the team to estimate the additional retained storage for a seven-day window on the busiest accounts: daily delete-and-overwrite volume multiplied by the window, billed at the live-data rate. This gives a concrete, forecastable line you can put in the budget. On most estates it is a small fraction of storage spend, which removes the 'how much will this cost' objection before it is raised.

2. Price the outage you are insuring against

Put a number on the alternative: the engineering time to rebuild deleted data, the revenue lost while the dependent service is down or degraded, and the goodwill cost of customers seeing stale or missing data. Even a rough figure makes the comparison stark, because the premium is small and bounded while the outage cost is large and open-ended. The expected-cost arithmetic favours the window every time.

3. Prioritise by service dependency, not by account count

Not every account deserves the same window. An account whose data a customer-facing service reads is a high-impact item to protect today; a scratch or staging account is low priority and can take a shorter window or none. Ask the team to rank by how badly a delete would hurt a live service, so the spend lands where the downtime risk is, rather than spreading a flat window across everything regardless of value.

Quick quiz

Question 1 of 5

The platform team proposes a seven-day soft-delete and versioning window across production accounts. As the finance partner, what is the right starting assumption about its cost?

Keep learning

Go deeper on how Azure Blob Storage protects data against accidental and malicious deletes and overwrites, and how the three settings fit together.

You have finished the finance view of storage recoverability. You know the cost model is one-sided: the control adds a small, forecastable storage premium that you can size in advance, and it insures against an outage whose length, and therefore cost, is open-ended. Next time a recoverability proposal lands, you will size the premium on the busiest accounts, price the outage it prevents, prioritise the window where a live service depends on the data, and treat it as the cheap insurance buy it is.

Back to the library

Soft delete and retention: the headline

Whether one wrong delete can take a service down with no way back

Outages do not only come from attackers or hardware failures. A large share come from someone, or something, deleting or overwriting data that a live service depends on. Without soft delete, that delete is permanent the instant it lands, and the service stays down until the data can be reconstructed, if it can be reconstructed at all. With soft delete and a sensible retention window, the same incident becomes a short, recoverable blip.

The leadership question is simple: if a script or an engineer deletes the wrong data tomorrow, is that a five-minute undelete or a multi-day incident? The defensible end state is that every account holding data a service depends on has soft delete on, versioning on, and a retention window long enough to survive a weekend, so accidental and malicious deletes are recoverable by default rather than by luck.

This is a resilience decision with a small, predictable price tag, not a budget battle. The spend is a modest amount of duplicated storage for a few days. What it buys is the difference between a delete being a routine recovery and a delete being an outage you have to explain afterwards.

A short read for the leader who needs to know why an accidental delete is one of the most common causes of an outage, why protecting against it is a small and predictable cost, and what a defensible, recoverable-by-default end state looks like across the estate.

Fun fact

The clock starts when you delete, not when you notice

What it looks like when a delete is recoverable by default, not by luck

After the near miss, the CEO asked the only question that mattered: if that engineer had not happened to be watching, how long would we have been down, and could we have got the data back at all? The honest answer was uncomfortable: the container had no recovery window, so the answer was 'we would have rebuilt what we could from a stale export, and the service would have run degraded for as long as that took.' The save was luck, not design.

The team's response was to stop treating recovery as a per-incident scramble and start treating it as a default. They enabled blob soft delete, container soft delete and versioning on every account holding service-critical data, set a seven-day window so a weekend could not age out a recoverable mistake, and then set an Azure Policy so any new account inherits the same protection. The next time the question came up, the answer had changed from 'we got lucky' to 'a delete like that is now a few-minute undelete, and the policy means no new account can be created without the same safety net.' That shift, from relying on someone noticing in time to making recovery the default, is the confidence this capability delivers, for a small and predictable storage cost.

Why this is a resilience decision for the board

Most discussion of cloud risk focuses on breaches, but a large share of real outages come from something more mundane: data that a service depended on was deleted or overwritten by accident or by a malicious actor. Soft delete with a sufficient retention window is the capability that turns that event from a multi-day recovery into a quick undelete. It is reliability engineering, not security spend.

The trade is one leadership should be quick to approve: the cost of action is a small, predictable amount of duplicated storage, and the cost of inaction is an outage of unpredictable length whenever the most common kind of mistake happens. Asking the team to confirm that every service-critical account is recoverable by default, with a window that survives a weekend, is asking them to remove one of the most common single points of failure in the estate for a price you can write down in advance.

The leadership move on storage recoverability

The executive handle is not to approve each account individually; it is to require that every service-critical store is recoverable by default and that the protection is enforced so it cannot quietly lapse on new accounts.

1. Set a deadline to reach recoverable-by-default

Ask for a date by which every account holding service-critical data has blob and container soft delete and versioning on, with a window of at least seven days, and Azure Policy auditing or denying any new account that lacks it. A standing policy is the difference between 'we fixed the accounts we knew about' and 'no new account can be created without a recovery window.'

2. Ask for the recovery time, not the toggle state

The proof is not 'soft delete is enabled.' It is a clear answer to 'if the wrong data is deleted tomorrow, how long until the service is whole again, and could a weekend delete age out before we notice?' A seven-day-plus window with versioning makes that answer 'minutes, self-service, and no, a weekend cannot age it out.' Ask for that answer, not the checkbox.

3. Treat shorter windows as named, owned exceptions

Some accounts genuinely do not need a long window, or any: pure scratch, fully reproducible caches. That is fine, but it should be a deliberate, documented decision with an owner, not an oversight. The goal is not a uniform window everywhere; it is zero service-critical accounts that are accidentally unrecoverable.

Quick quiz

Question 1 of 5

At a review after a near miss, you ask whether a wrong delete tomorrow would be an outage or a quick recovery. What end state should you be looking for?

Keep learning

Go deeper on how Azure Blob Storage protects data against accidental and malicious deletes and overwrites, and how the three settings fit together.

Two takeaways. An accidental or malicious delete is one of the most common ways a data-driven service goes down, and soft delete with a sufficient window turns that from a multi-day recovery into a quick undelete for a small, predictable cost, so it is a resilience trade you should be quick to approve. And the defensible end state is not 'we checked and soft delete is on'; it is every service-critical account recoverable by default with a window that survives a weekend, enforced by Azure Policy so no new account can lapse, with the rare throwaway exceptions documented and owned.

Back to the library

Part of the learning path Build in Azure resilience

Enable soft delete and a sufficient retention window for storage

Soft delete and retention: the basics

The clock starts when you delete, not when you notice

Finding storage accounts with no recovery window

How soft delete, versioning and the retention window actually behavedeep dive

What is the impact of leaving storage with no recovery window?

How do you make storage recoverable safely?

1. Inventory the recovery window, not just the toggle

2. Enable all three together on data-bearing accounts

3. Set a window that outlasts a weekend

4. Enforce it so new accounts inherit protection

Quick quiz

Keep learning

Soft delete and retention: the downtime-cost view

The clock starts when you delete, not when you notice

How a finance partner frames the recovery-window decision

Why a missing recovery window belongs on the resilience budget

What finance can do about an unprotected storage estate

1. Size the premium before the work, not after

2. Price the outage you are insuring against

3. Prioritise by service dependency, not by account count

Quick quiz

Keep learning

Soft delete and retention: the headline

The clock starts when you delete, not when you notice

What it looks like when a delete is recoverable by default, not by luck

Why this is a resilience decision for the board

The leadership move on storage recoverability

1. Set a deadline to reach recoverable-by-default

2. Ask for the recovery time, not the toggle state

3. Treat shorter windows as named, owned exceptions

Quick quiz

Keep learning

Related site reliability lessons