Theoretical Foundation: Configure Snapshots and Soft Delete for Azure Files

1. Initial Intuition

Imagine you work in an office where everyone edits documents in a shared network folder. A colleague accidentally deletes an entire folder with important contracts. Another overwrites a financial report with the wrong version. Without protection, this data is permanently lost.

Snapshots in Azure Files are like photographs of the complete state of the file share at a specific moment. If something goes wrong, you can go back to the photograph and recover what was lost, whether an individual file or the entire share.

Soft Delete in Azure Files is the file share's recycle bin: when a share is deleted, it doesn't disappear immediately. It's preserved for a configurable period, during which it can be completely restored.

While snapshots protect against content modifications and deletions, soft delete protects against deletion of the file share itself.

2. Context

2.1 Position in Azure Files protection strategy

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

2.2 Fundamental difference between Azure Files and Blob Storage

It's important not to confuse the behavior of snapshots and soft delete between the two services, as they have distinct behaviors:

Aspect	Blob Storage	Azure Files
Snapshots	Per individual blob	Per entire file share
Soft Delete	Per blob and per container (separate)	Per file share
Versioning	Automatic per blob	Doesn't exist (snapshots are manual or via Backup)
Content Soft Delete	Yes (individual file)	No (only the share as a whole)

Critical point: In Azure Files, there is no individual file soft delete. If a file within a share is deleted and you don't have a snapshot prior to the deletion, the file is lost.

3. Building the Concepts

A file share snapshot is a read-only and incremental copy of the complete state of the file share at a specific moment.

Incremental means the snapshot doesn't duplicate all data each time. It stores only the differences compared to the previous snapshot (or current state). If you have 100 GB in the share and create a snapshot after adding 1 GB, the snapshot takes approximately 1 GB (plus metadata), not 101 GB.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Snapshot characteristics:

Are read-only: you cannot modify the content of a snapshot
Are independent of the active share: deleting files from the active share doesn't affect snapshots
Can be accessed directly for reading without restoration
Can be used to restore individual files, directories, or the entire share
Remain until explicitly deleted (or until the share is deleted)
Maximum of 200 snapshots per file share

3.2 How to access snapshot content

Azure Files snapshots are accessible in two ways:

Via Windows (Previous Versions): When the share is mounted on a Windows client with AD authentication, the user can right-click on any file or folder and select "Properties" > "Previous Versions" tab. Windows displays all snapshots as navigable previous versions, without administrator intervention.

This is an extremely powerful feature: the user themselves can recover accidentally deleted files without opening support tickets.

Via direct path (Linux and CLI): Snapshots are accessible via special path in the mounted share:

# Linux: navigate in snapshot
ls /mnt/myshare/.snapshot/2025-01-15T10:00:00.0000000Z/

# Windows: via snapshot UNC path
\\myaccount.file.core.windows.net\myshare\{snapshot_datetime}\

When Soft Delete is enabled and a file share is deleted:

The share enters soft-deleted state (not physically removed)
Becomes invisible in normal share listings
All share snapshots are preserved along with the soft-deleted share
Can be restored during the configured retention period (1 to 365 days)
After the period, it's permanently removed

Fundamental point: Soft Delete in Azure Files protects the file share as a whole, including all its content and snapshots. There is no individual file soft delete within the share.

3.4 The relationship between Soft Delete and Snapshots

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Critical behavior: Soft Delete protects the share, not snapshots individually. If you delete a specific snapshot (not the entire share), that snapshot is permanently removed, with no possibility of recovery via soft delete.

4. Structural View

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Practical Operation

5.1 Creating and using snapshots

Before creating a snapshot, understand what it captures:

A file share snapshot captures the state of all files and directories in the share at the moment of creation. It doesn't require the share to be unmounted or clients to disconnect. The operation is consistent at the share level, not at the individual file level.

Flow for recovering a deleted file:

User accidentally deletes final-report.xlsx from the share
Administrator or the user themselves (via Previous Versions in Windows) locates the snapshot prior to deletion
Copies the file from the snapshot back to the active share
File is restored without impacting the rest of the share

5.2 Restoring files via Previous Versions in Windows

This is the most common and most important recovery method for end users:

In Windows Explorer, navigate to the mounted share
Right-click on the folder or file
Select "Properties"
Click on the "Previous Versions" tab
Select the desired snapshot
Click "Open" to view, "Copy" to recover to another location, or "Restore" to overwrite

Requirement for Previous Versions: The share must be mounted with identity-based authentication (Azure AD DS, AD DS, or Azure AD Kerberos). Shares mounted only with access key do not show Previous Versions in Windows Explorer.

Restoring an entire share copies the content from a snapshot over the active share. This overwrites the current share content with the snapshot state. This operation is useful when the share has been corrupted en masse or when many files have been deleted.

There is no native "rollback" operation. Restoring a snapshot to the entire share is done via AzCopy or by copying files from the snapshot to the active share. Azure doesn't have a "restore share to snapshot" operation in a single click (unlike Azure Backup, which offers this).

To restore via AzCopy:

# Copy all files from a snapshot to the active share
azcopy copy \
  'https://myaccount.file.core.windows.net/myshare?sharesnapshot=2025-01-15T08:00:00Z&<SAS-TOKEN>' \
  'https://myaccount.file.core.windows.net/myshare?<SAS-TOKEN>' \
  --recursive

6. Implementation Methods

6.1 Azure Portal

Enabling Soft Delete:

Storage Account > Data Protection > Enable soft delete for file shares

Configure the retention period (1 to 365 days). The configuration is applied immediately.

Creating a manual snapshot:

Storage Account > File shares > [share] > Snapshots > + Add snapshot

Add an optional descriptive message (e.g., "pre-deployment-2025-01-15").

Listing and managing snapshots:

Storage Account > File shares > [share] > Snapshots

The list shows all snapshots with date, time, and incremental size. You can delete individual snapshots or browse content by clicking on a snapshot.

Restoring file from snapshot via portal:

Storage Account > File shares > [share] > Snapshots > [snapshot] > Browse

Navigate through the snapshot's directory structure, select a file, and click "Restore".

Listing and restoring soft-deleted file shares:

Storage Account > File shares > (check "Show deleted shares")

Soft-deleted shares appear with "Deleted" status. Select and click "Undelete".

6.2 Azure CLI

Enabling Soft Delete:

az storage account file-service-properties update \
  --account-name myaccount \
  --resource-group myRG \
  --enable-delete-retention true \
  --delete-retention-days 14

Checking configuration:

az storage account file-service-properties show \
  --account-name myaccount \
  --resource-group myRG \
  --query "shareDeleteRetentionPolicy"

Creating snapshot:

az storage share snapshot \
  --account-name myaccount \
  --name projects \
  --account-key <key>

The command returns the timestamp of the created snapshot.

Listing snapshots:

az storage share list \
  --account-name myaccount \
  --include-snapshot \
  --account-key <key> \
  --output table

Viewing snapshot content:

az storage file list \
  --account-name myaccount \
  --share-name projects \
  --snapshot "2025-01-15T08:00:00.0000000Z" \
  --account-key <key>

Restoring individual file from snapshot:

az storage file copy start \
  --account-name myaccount \
  --source-share projects \
  --source-path "reports/final-report.xlsx" \
  --source-snapshot "2025-01-15T08:00:00.0000000Z" \
  --destination-share projects \
  --destination-path "reports/final-report-restored.xlsx" \
  --account-key <key>

Deleting snapshot:

az storage share delete \
  --account-name myaccount \
  --name projects \
  --snapshot "2025-01-15T08:00:00.0000000Z" \
  --account-key <key>

Listing soft-deleted file shares:

az storage share list \
  --account-name myaccount \
  --include-deleted \
  --account-key <key> \
  --output table

Restoring soft-deleted file share:

az storage share undelete \
  --account-name myaccount \
  --name financial \
  --deleted-version "01D8A3F..." \
  --account-key <key>

The --deleted-version is obtained from the deleted shares listing.

6.3 Azure PowerShell

$ctx = New-AzStorageContext `
  -StorageAccountName "myaccount" `
  -StorageAccountKey "<key>"

# Create snapshot
$snapshot = New-AzStorageShareSnapshot `
  -ShareName "projects" `
  -Context $ctx

# List snapshots
Get-AzStorageShare `
  -ShareName "projects" `
  -Context $ctx `
  -SnapshotTime $snapshot.SnapshotTime

# List soft-deleted shares
Get-AzStorageShare `
  -Context $ctx `
  -IncludeDeleted

# Restore soft-deleted share
Restore-AzStorageShareDeletedShare `
  -Name "financial" `
  -DeletedShareVersion "01D8A3F..." `
  -Context $ctx

6.4 Bicep: configuring Soft Delete

resource fileServiceProperties 'Microsoft.Storage/storageAccounts/fileServices@2023-01-01' = {
  name: '${storageAccount.name}/default'
  properties: {
    shareDeleteRetentionPolicy: {
      enabled: true
      days: 14
    }
  }
}

6.5 Automating snapshots with Azure Backup

The most recommended way to manage snapshots in production is via Azure Backup for Azure Files:

# Enable protection with Azure Backup
az backup protection enable-for-azurefileshare \
  --vault-name myRecoveryVault \
  --resource-group myRG \
  --storage-account myaccount \
  --azure-file-share projects \
  --policy-name DailyFileShareBackup

Azure Backup:

Creates snapshots automatically on scheduled time
Manages retention and deletion of old snapshots
Offers restoration with simplified interface (individual file or complete share)
Maintains backup state outside the Storage Account (additional protection)

7. Control and Security

7.1 Required permissions

To manage snapshots:

Operation	Minimum Role
Create snapshot	Storage Account Contributor
List snapshots	Storage Account Reader
Delete snapshot	Storage Account Contributor
Restore file from snapshot	Storage Account Contributor + share access

To manage Soft Delete:

Operation	Minimum Role
Enable/disable Soft Delete	Storage Account Contributor
List soft-deleted shares	Storage Account Reader
Restore soft-deleted share	Storage Account Contributor

Security observation: Snapshots are not protected by soft delete when deleted individually. A user with Storage Account Contributor permission can permanently delete all snapshots. For additional protection, use Azure Backup, which stores the backup state outside the direct control of the Storage Account.

7.2 Protection against snapshot deletion

Since individually deleted snapshots are permanently removed, consider:

Granular Azure RBAC: Restrict who can delete snapshots to the minimum necessary.
Azure Backup: Backup managed by Azure Backup cannot be deleted directly via storage operations. Requires access to the Recovery Services Vault.
Resource Locks: A CanNotDelete lock on the Storage Account prevents accidental deletion of the account, but doesn't prevent snapshot deletion via storage operations.
Audit Logs: Configure diagnostics to log DeleteShare operations and snapshot operations.

7.3 Soft Delete and Premium file shares

Soft Delete is available for both Standard and Premium file shares. The behavior is identical. The difference is only in cost: Premium shares are charged for provisioned capacity, so a soft-deleted share continues to be charged for the provisioned capacity during the retention period.

8. Decision Making

8.1 Manual snapshots vs Azure Backup

Situation	Best Choice	Reason
Before deployment or critical change	Manual snapshot	Precise control of timing
Continuous production protection	Azure Backup	Automation, managed retention, simplified restoration
Development sharing	Occasional manual snapshot	Low cost, direct control
1-year retention compliance	Azure Backup	Manages long retention automatically
Quick file recovery by user	Previous Versions (Windows)	User recovers without admin intervention
Recovery in Linux environments	Snapshot via CLI + AzCopy	No native Previous Versions support

8.2 Soft Delete retention period

Situation	Recommended Period
Development file shares	7 days
Production file shares	14 to 30 days
Shares with regulatory data	30 days (minimum)
High-cost shares (Premium, large volume)	7 to 14 days (cost vs security balance)

8.3 Snapshots vs Soft Delete: what each one solves

Scenario	Correct tool	Reason
File deleted from within the share	Snapshot prior to deletion	Soft Delete doesn't protect individual files
Entire file share deleted	Soft Delete	Restores the share with content and snapshots
File corrupted by wrong edit	Snapshot prior to edit	Allows recovering previous version
Share corrupted in bulk (ransomware)	Snapshot + Soft Delete	Snapshot recovers content; Soft Delete protects the share
Directory accidentally deleted	Snapshot + manual copy	Restore the directory from snapshot

9. Best Practices

Enable Soft Delete immediately when creating any production file share. The risk of accidental share deletion is real and the enablement cost is minimal.
Configure daily snapshots via Azure Backup for production file shares. Manual snapshots are prone to lapses.
Configure more frequent snapshots (every 4-6 hours) for shares with critical high-volatility data via scheduled scripts or Azure Automation.
Keep snapshots for at least 7 days to cover the period when accidental deletions are usually detected.
Educate users about the Previous Versions feature in Windows. Most users can recover their own files without IT intervention.
Combine snapshots with Soft Delete: Without snapshots, Soft Delete only protects the share structure, not content that was modified. Without Soft Delete, snapshots can be lost if the share is deleted.
Limit the number of snapshots by monitoring consumption and deleting old snapshots via automated lifecycle.
Don't rely only on snapshots for long-term compliance. Use Azure Backup with retention policies for regulatory requirements (LGPD, GDPR, etc.).

10. Common Errors

Error	Why it happens	How to avoid
File deleted without prior snapshot	Snapshot didn't exist or was prior to last important modification	Create snapshots with frequency appropriate to data volatility
Previous Versions doesn't appear in Windows	Share mounted with access key, not with AD identity	Configure identity-based authentication (AD DS, Azure AD DS)
Individual snapshot deleted and irrecoverable	Soft Delete doesn't protect individual snapshots	Restrict who can delete snapshots; use Azure Backup
Soft-deleted share cannot be restored	Retention period expired	Increase period; monitor and act within timeframe
Unexpected cost with soft-deleted share	Premium share continues to be charged for provisioned capacity	Consider this when setting retention period
Confusing Files soft delete with Blob soft delete	They are different services with independent configurations	Configure separately in Data Protection for each service
200 snapshots limit reached	Snapshots created without deletion of old ones	Implement automatic deletion policy for old snapshots
Restoration via AzCopy overwrites more recent data	Copy operation from snapshot over active share	Test in non-production environment; confirm correct snapshot before

11. Operation and Maintenance

11.1 Monitoring snapshots

# Check number of snapshots and size
az storage share list \
  --account-name myaccount \
  --include-snapshot \
  --account-key <key> \
  --query "[?snapshot!=null].{Share:name, Snapshot:snapshot, Quota:properties.quota}" \
  --output table

Configure an alert when the number of snapshots approaches 200:

In Azure Monitor, monitor the FileShareSnapshotCount metric per share.

11.2 Automating deletion of old snapshots

#!/bin/bash
# Delete snapshots older than 30 days
CUTOFF_DATE=$(date -d '30 days ago' +%Y-%m-%dT%H:%M:%SZ)

az storage share list \
  --account-name myaccount \
  --include-snapshot \
  --account-key <key> \
  --query "[?snapshot!=null && snapshot<'$CUTOFF_DATE'].snapshot" \
  --output tsv | while read SNAPSHOT; do
    az storage share delete \
      --account-name myaccount \
      --name myshare \
      --snapshot "$SNAPSHOT" \
      --account-key <key>
    echo "Deleted snapshot: $SNAPSHOT"
done

11.3 Important limits

Aspect	Limit
Maximum snapshots per file share	200
Soft Delete retention period	1 to 365 days
Maximum size of a snapshot	Limited by maximum share size
Premium share snapshots	Supported
NFS share snapshots	Not supported (SMB only)
Soft-deleted share restoration with new name	Not possible; must use original name

Important restriction: NFS snapshots are not supported. If you use Azure Files with NFS protocol, snapshots and share soft delete are not available. Use Azure Backup or another protection strategy.

12. Integration and Automation

12.1 Azure Automation for scheduled snapshots

# PowerShell Runbook for scheduled snapshot
param(
    [string]$StorageAccountName,
    [string]$ShareName,
    [string]$ResourceGroupName
)

# Authenticate via Managed Identity
Connect-AzAccount -Identity

$ctx = New-AzStorageContext `
  -StorageAccountName $StorageAccountName `
  -UseConnectedAccount

# Create snapshot
$snapshot = New-AzStorageShareSnapshot `
  -ShareName $ShareName `
  -Context $ctx `
  -Metadata @{"CreatedBy" = "Automation"; "Purpose" = "DailyBackup"}

Write-Output "Snapshot created: $($snapshot.SnapshotTime)"

# Delete snapshots older than 30 days
$cutoff = (Get-Date).AddDays(-30)
Get-AzStorageShare -ShareName $ShareName -Context $ctx | 
  Where-Object { $_.SnapshotTime -ne $null -and $_.SnapshotTime -lt $cutoff } |
  ForEach-Object {
    Remove-AzStorageShare -Name $ShareName -SnapshotTime $_.SnapshotTime -Context $ctx -Force
    Write-Output "Snapshot deleted: $($_.SnapshotTime)"
  }

12.2 Azure Backup: complete configuration

# 1. Create Recovery Services Vault
az backup vault create \
  --resource-group myRG \
  --name myRecoveryVault \
  --location eastus

# 2. Create backup policy for file shares (daily, 30 days retention)
az backup policy create \
  --resource-group myRG \
  --vault-name myRecoveryVault \
  --name DailyFilePolicy \
  --backup-management-type AzureStorage \
  --policy '{
    "schedulePolicy": {
      "schedulePolicyType": "SimpleSchedulePolicy",
      "scheduleRunFrequency": "Daily",
      "scheduleRunTimes": ["2025-01-01T02:00:00Z"]
    },
    "retentionPolicy": {
      "retentionPolicyType": "LongTermRetentionPolicy",
      "dailySchedule": {
        "retentionTimes": ["2025-01-01T02:00:00Z"],
        "retentionDuration": {
          "count": 30,
          "durationType": "Days"
        }
      }
    }
  }'

# 3. Enable protection for the file share
az backup protection enable-for-azurefileshare \
  --vault-name myRecoveryVault \
  --resource-group myRG \
  --storage-account myaccount \
  --azure-file-share projetos \
  --policy-name DailyFilePolicy

13. Final Summary

Essential concepts:

Snapshots are read-only, incremental copies of the complete state of a file share at a specific point in time. They allow recovering individual files, directories, or the entire share.
File share Soft Delete is a recycle bin for the share as a whole. When a share is deleted, it remains recoverable for the configured retention period, with all its content and snapshots.
In Azure Files, there is no individual file soft delete. Only snapshots protect against deletion of content within the share.

Critical differences:

Snapshot vs Soft Delete: Snapshot protects the share content (files and folders). Soft Delete protects the existence of the share itself. They are complementary.
Deleting snapshot individually vs deleting the share: Deleting a snapshot individually is permanent (no soft delete). Deleting the share with active soft delete preserves the share and all its snapshots.
Azure Files vs Blob Storage: Blob has soft delete per individual file and per container separately. Azure Files has snapshot per share and soft delete only per share (no file level).
Previous Versions in Windows: Only works with identity-based authentication (AD DS, Azure AD DS, Azure AD Kerberos), not with access key.
NFS and snapshots: File shares with NFS protocol do not support snapshots or soft delete.

What needs to be remembered:

Maximum of 200 snapshots per file share.
Soft Delete only protects the share as a whole; files deleted from the share need snapshots to be recovered.
Snapshots are incremental: they store only the differences, not complete copies.
Azure Backup is the recommended way for automatic snapshots in production, as it manages retention and offers simplified restoration.
Soft Delete must be configured before any deletion; it doesn't retroact.
Restoring a soft-deleted share recreates it with the same original name; it's not possible to restore with a different name.
NFS protocol doesn't support snapshots or file share soft delete.

1. Initial Intuition​

2. Context​

2.1 Position in Azure Files protection strategy​

2.2 Fundamental difference between Azure Files and Blob Storage​

3. Building the Concepts​

3.1 File share snapshots​

3.2 How to access snapshot content​

3.3 File share Soft Delete​

3.4 The relationship between Soft Delete and Snapshots​

4. Structural View​

5. Practical Operation​

5.1 Creating and using snapshots​

5.2 Restoring files via Previous Versions in Windows​

5.3 Restoring the entire share from a snapshot​

6. Implementation Methods​

6.1 Azure Portal​

6.2 Azure CLI​

6.3 Azure PowerShell​

6.4 Bicep: configuring Soft Delete​

6.5 Automating snapshots with Azure Backup​

7. Control and Security​

7.1 Required permissions​

7.2 Protection against snapshot deletion​

7.3 Soft Delete and Premium file shares​

8. Decision Making​

8.1 Manual snapshots vs Azure Backup​

8.2 Soft Delete retention period​

8.3 Snapshots vs Soft Delete: what each one solves​

9. Best Practices​

10. Common Errors​

11. Operation and Maintenance​

11.1 Monitoring snapshots​

11.2 Automating deletion of old snapshots​

11.3 Important limits​

12. Integration and Automation​

12.1 Azure Automation for scheduled snapshots​

12.2 Azure Backup: complete configuration​

13. Final Summary​

1. Initial Intuition

2. Context

2.1 Position in Azure Files protection strategy

2.2 Fundamental difference between Azure Files and Blob Storage

3. Building the Concepts

3.1 File share snapshots

3.2 How to access snapshot content

3.3 File share Soft Delete

3.4 The relationship between Soft Delete and Snapshots

4. Structural View

5. Practical Operation

5.1 Creating and using snapshots

5.2 Restoring files via Previous Versions in Windows

5.3 Restoring the entire share from a snapshot

6. Implementation Methods

6.1 Azure Portal

6.2 Azure CLI

6.3 Azure PowerShell

6.4 Bicep: configuring Soft Delete

6.5 Automating snapshots with Azure Backup

7. Control and Security

7.1 Required permissions

7.2 Protection against snapshot deletion

7.3 Soft Delete and Premium file shares

8. Decision Making

8.1 Manual snapshots vs Azure Backup

8.2 Soft Delete retention period

8.3 Snapshots vs Soft Delete: what each one solves

9. Best Practices

10. Common Errors

11. Operation and Maintenance

11.1 Monitoring snapshots

11.2 Automating deletion of old snapshots

11.3 Important limits

12. Integration and Automation

12.1 Azure Automation for scheduled snapshots

12.2 Azure Backup: complete configuration

13. Final Summary