Troubleshooting Lab: Configure snapshots and soft delete for Azure Files
Diagnostic Scenarios
Scenario 1 — Root Cause
An administration team receives a complaint: files deleted two days ago from an Azure Files share don't appear as recoverable in the Azure portal. The team confirms that the soft delete functionality was configured on the storage account three weeks ago, with a retention period of 30 days.
The administrator accesses the portal, navigates to the dados-financeiros share and finds no items in soft delete state. He checks the storage account and gets the following output:
az storage account show \
--name stgfinprod \
--resource-group rg-financeiro \
--query "properties.largeFileSharesState"
"Enabled"
Next, he checks the soft delete state at the file service level:
az storage account file-service-properties show \
--account-name stgfinprod \
--resource-group rg-financeiro \
--query "shareDeleteRetentionPolicy"
{
"days": 30,
"enabled": false
}
The storage account is in the East US region, was created six months ago and uses LRS redundancy. The share was mounted via SMB on Windows servers. NFS protocol is not in use.
What is the root cause of the absence of recoverable items?
A. Files were deleted via SMB, and soft delete only protects deletions performed via REST API.
B. The soft delete policy is configured with enabled: false, which means the feature was not active at the time of deletion.
C. The 30-day retention period has not been reached yet, but the portal requires a manual refresh of the view to display the items.
D. The largeFileSharesState feature configured as Enabled automatically disables soft delete on LRS accounts.
Scenario 2 — Diagnostic Sequence
An administrator receives the following report: "I mounted the Azure Files share on Windows and want to access a snapshot created yesterday, but I can't find it anywhere."
The administrator needs to diagnose if the snapshot exists and why it's not visible. Below are five investigation steps available:
- Check if there are snapshots listed via CLI with
az storage share list --include-snapshots - Guide the user to access Properties > Previous Versions in the mounted folder
- Confirm that the share is mounted correctly with active drive letter
- Verify if the client operating system is Windows and supports the previous versions feature via SMB
- Check if the snapshot was created successfully by querying its date and time in the Azure portal
Which diagnostic sequence represents the correct order of investigation?
A. 3 → 1 → 5 → 4 → 2
B. 1 → 5 → 3 → 2 → 4
C. 5 → 1 → 3 → 4 → 2
D. 3 → 4 → 1 → 5 → 2
Scenario 3 — Root Cause
An administrator created daily snapshots of an Azure Files share for 30 consecutive days. When checking the storage cost at the end of the month, he notices that the amount charged for snapshots is approximately equal to the cost of the main share, even though the share data is rarely modified.
The logs-app share has 500 GB of data. Files are written once and never changed. The administrator runs the following command to investigate:
az storage share list \
--account-name stglogsprod \
--include-snapshots \
--query "[].{Name:name, Snapshot:snapshot, Quota:properties.quota, Usage:properties.shareUsageBytes}" \
--output table
Name Snapshot Quota Usage
--------- -------------------------- ------- -----------
logs-app (null) 5120 536870912000
logs-app 2024-11-01T02:00:00.000Z 5120 536870912000
logs-app 2024-11-02T02:00:00.000Z 5120 536870912000
...
logs-app 2024-11-30T02:00:00.000Z 5120 536870912000
The Usage field in each snapshot returns the same value as the active share. The storage account uses GPv2 with Standard LRS SKU. The development team confirms that no files were deleted or modified since the beginning of the period.
The administrator concludes that snapshots are consuming 30 times the size of the share. What is the root cause of the behavior observed in the command output?
A. Snapshots in Azure Files consume storage equal to the total size of the share, regardless of changes to the data.
B. The shareUsageBytes parameter returned by the command for snapshots reflects the accumulated size of the share at the time of the snapshot, not the incremental delta stored; the actual cost is based only on the different blocks.
C. The GPv2 account with Standard SKU does not support incremental snapshots; this behavior is exclusive to Premium accounts.
D. Log files continue to be written in the background by an operating system agent, causing real differences between snapshots.
Scenario 4 — Action Decision
The cause has been identified: soft delete for an Azure Files share was disabled when critical files were deleted. The files are not recoverable through soft delete. The administrator has already confirmed that there is an Azure backup configured for the share, with the last recovery point from 18 hours ago, and that there are manual snapshots created 6 hours ago and 24 hours ago.
The environment is production. The deleted files were last modified 10 hours ago. The allowed maintenance window is 30 minutes. Restoring the complete Azure backup takes an average of 45 minutes and replaces all files in the share. Restoring from a snapshot takes less than 5 minutes and allows individual file recovery.
What is the correct action to take at this time?
A. Restore the complete Azure backup, as it represents the most recent recovery point and ensures greater data integrity.
B. Restore files individually from the snapshot created 6 hours ago, as it is the recovery point closest to the time of deletion and respects the available maintenance window.
C. Enable soft delete immediately and wait for the system to automatically recover the deleted files.
D. Restore from the snapshot created 24 hours ago, as it is prior to the modification window and ensures that files are in a consistent state.
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The command output explicitly reveals "enabled": false in the shareDeleteRetentionPolicy policy. This means that at the time the files were deleted, soft delete was inactive, regardless of any other account configuration. Files deleted while the feature is disabled are not retained and cannot be recovered.
The decisive clue is in the output of the second command, not the first. The largeFileSharesState: Enabled field is irrelevant information for the diagnosis: it only controls support for large shares (above 5 TB) and has no relation to soft delete behavior. Including it in the scenario simulates the real noise an administrator encounters in production.
Alternative A is factually incorrect: soft delete covers deletions via SMB. Alternative C invents a manual refresh behavior that doesn't exist. Alternative D describes a causal relationship that doesn't exist between largeFileSharesState and soft delete.
The most dangerous distractor is D: an administrator who confuses capacity settings with data protection settings might spend time investigating the account SKU while the real cause is visible in the command output.
Answer Key — Scenario 2
Answer: A
The correct sequence is 3 → 1 → 5 → 4 → 2, which follows the logic of progressive diagnosis from simplest to most specific.
The reasoning is: before investigating the snapshot itself, it's necessary to confirm that the share is mounted and accessible (step 3). Next, verify via CLI if snapshots actually exist (step 1). If they exist, confirm which one was created and when (step 5). Then, verify if the client operating system supports access via Previous Versions (step 4). Only after all these validations does it make sense to guide the user on how to access the snapshot correctly (step 2).
Starting with step 2, as suggested by alternatives B and D, is a common mistake: guiding the user to look for previous versions before confirming that the snapshot exists is diagnosing before validating. Alternative C starts with step 5 without first confirming the snapshot's existence via CLI, which reverses the order from objective to interpretive verification.
Answer Key — Scenario 3
Answer: B
The shareUsageBytes field returned by the az storage share list command for snapshots represents the total size of the share at the time the snapshot was created, not the differential size of stored blocks. This is a known characteristic of the listing API: the displayed value is the logical size of the point in time, not the actual cost of incremental storage.
Since files were never modified or deleted after the creation of the first snapshot, subsequent snapshots don't store any new blocks. The actual storage cost of the 29 additional snapshots is close to zero, because snapshots are incremental and capture only differences. The command output cannot be used directly to calculate the storage cost of snapshots.
Alternative A represents the most common and most dangerous misconception: concluding that snapshots cost the same as the share just because the usage field displays the same value. Alternative C is factually incorrect: incremental snapshots work on Standard GPv2 accounts. Alternative D is the irrelevant information purposely included: the scenario mentions that files are written once and never changed, which should eliminate this hypothesis, but the distractor reintroduces it as a cause.
Answer Key — Scenario 4
Answer: B
The critical constraint in the scenario is the 30-minute maintenance window. Restoring the complete backup takes 45 minutes, which violates this constraint. The snapshot created 6 hours ago is the recovery point closest to the deletion that can be used within the available window, and allows individual file recovery without replacing the entire share.
Alternative A would be technically correct in a context without time constraints, but explicitly ignores the constraint stated in the scenario. Choosing this alternative represents the classic mistake of applying the right solution in the wrong context.
Alternative C demonstrates lack of knowledge about soft delete behavior: enabling the feature after deletion does not recover files already lost; it only protects future deletions.
Alternative D is the most sophisticated distractor: the 24-hour snapshot is prior to the modifications of the last 10 hours, which means restoring from it would result in loss of recent work data, being worse than the 6-hour snapshot.
Troubleshooting Tree: Configure snapshots and soft delete for Azure Files
Color Legend:
| Color | Node Type |
|---|---|
| Dark Blue | Initial symptom (entry point) |
| Blue | Diagnostic question (binary decision or observable) |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Validation or intermediate verification |
To use this tree when facing a real problem, always start with the root node, which represents the observed symptom. At each blue node, answer the question based on what you can verify directly in the environment, whether through the portal, CLI, or client behavior. Follow the path corresponding to your answer until you reach a red node, which identifies the cause, or a green node, which indicates the action to execute. Orange nodes indicate that an intermediate verification is necessary before concluding the diagnosis.