Share via

File Share Succeeded on 1st Backup, failing each time since. Error Code 850000

MichaelB-2136 150 Reputation points
2026-03-09T09:31:24.31+00:00

Hi, I have a FSLogix Profiles File Share that is 500 GB that I set up a vault-standard backup for on Friday night. The first backup succeeded and took 8 hours.

The subsequent next 3 have failed at the transferring to Vault stage.

The 1st failed after 4 Hrs 15 Mins, 2nd after 2 Hrs 9 Mins & 3rd after 5 Hrs 36 Mins.

The Take Snapshot sub task succeeded on every job. Error Code 850000

Given the first one succeeded it surely cannot be a firewall or config issue but just to confirm I have checked that my storage account does have allow access to special Azure services ticked.

The file share file count is 90-130 depending on users logged in so nowhere near the half a mil limit. All 4 backups were attempted outside of work hours so no data in the file share being changed at the time.

I have another file share that is 100 GB on the same backup policy that has never failed, even though the file count metric is 140k.

Given that nothing has changed since the 1st backup I have no idea why all the others have failed.

The file share is a premium tier, 470GB used 700GB provisioned.

Azure Backup
Azure Backup

An Azure backup service that provides built-in management at scale.

Answer accepted by question author
  1. Bharath Y P 7,080 Reputation points Microsoft External Staff Moderator
    2026-03-09T11:42:11.0333333+00:00

    Hello MichaelB-2136, You are experiencing a partial success in the Azure Backup workflow. The "Snapshot" phase works: This means the Backup Service has the correct permissions to talk to the Azure Files API and trigger a point-in-time copy. The "Transfer to Vault" phase fails: This is the data-heavy movement where the snapshot is cataloged and moved to the Recovery Services Vault (RSV) storage.

    Error 850000: This is a "Data Mover" timeout or connectivity interruption. Because it fails at different time intervals, it suggests a throttling or a network handshake drop rather than a flat permission deny.

    The most likely reason is a Metadata Timeout or Storage Throughput Exhaustion.

    Even though your file count is low, FSLogix .vhdx files are "sparse" and dynamic. When Azure Backup transfers data to a "Vault-Standard" tier, it doesn't just copy blocks; it performs a consistency check and metadata synchronization.

    • IOPS/Throughput: Premium shares have fixed ingress/egress limits based on provisioned size. If FSLogix "compaction" or background disk activity occurs during the backup transfer, you may be hitting the egress limit of the Premium share, causing the Backup Data Mover to lose its connection.
    • The "Large File" Penalty: Because the 500 GB share is 5x larger than your working 100 GB share, the "Transfer to Vault" stage stays open much longer, making it more susceptible to transient network blips or "Lease" conflicts on the VHDX files.

    The first backup was a "Full Seed." Subsequent backups are Incremental.

    • The Delta Calculation: For FSLogix profiles (.vhdx), even if users aren't logged in, the metadata within the VHDX can change significantly due to OS background tasks.
    • The "Data Mover" Timeout: Error 850000 is often a generic "Data Mover" failure. If the service takes too long to enumerate the "changes" in a large 500 GB file, the session between the Storage Account and the Vault times out.
    • Throttling: Premium shares have a fixed egress rate. The 500 GB share has a larger "metadata footprint" than the 100 GB share. If the backup service hits the storage account's egress limit while trying to read the VHDX blocks, it will drop the connection.

    Pull Full Job Details and Error Text

    • Go to Recovery Services Vault > Backup Jobs > Failed Job > Error Details is the first step.
    • The “DataTransfer” or “DataMover” section can reveal specific causes (throttling, network timeouts, authentication issues, file locks, etc.).
    • This is crucial because Error 850000 is generic; the subtask details provide the real root cause.

    Check Storage Account Networking & SAS Token Lifetime

    • “Allow trusted Microsoft services” is necessary but not sufficient if: Private Endpoints or firewall rules exist and The vault’s service tag AzureBackup is not allowed.
    • SAS tokens used by Backup are autogenerated and short-lived. If the storage account rotates keys or has an SAS policy that invalidates tokens mid-transfer, the backup can fail at the transfer stage.

    Run Built-in AFS Backup Diagnostics

    In Recovery Services Vault > Backup Instances > Run Diagnostics.

    This runs AzureBackupAFSBackupScenarioHelper, which validates:

    • Configuration
    • Network connectivity
    • Authentication / SAS token issues

    This can pinpoint subtle misconfigurations before retrying backup.

    If you still encounter an error, this need help from backend team to verify the file share backup failure and this need backend clean up before retrying the next backup.

    References:

    Troubleshoot Azure Files backup - Azure Backup | Microsoft Learn

    Restore Azure Files - Azure Backup | Microsoft Learn

    Hope this helps. and please feel free to reach out if you have any further questions. Thanks

    0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2026-03-09T09:31:44.75+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    Based on the symptoms (snapshot always succeeds, failure occurs only during “Transfer data to vault”, other file share on same policy works), focus on backup/restore service limits, throttling, and storage account configuration rather than basic connectivity.

    Key checks and actions:

    1. Check the backup job error code and failure file list
      • Open the failed backup job in the Recovery Services vault and look for a specific error code/message.
      • If the error is one of the throttling or “all files failed” types, use the guidance below:
        • FileshareBackupFailedWithAzureRpRequestThrottling – indicates storage service throttling.
        • DataTransferServiceAllFilesFailedToRecover / DataTransferServiceCoFLimitReached – similar patterns exist on restore; for backup, the same throttling and per‑file issues can apply.
      • If a failure file list or log path is provided, review it to see if specific files are repeatedly failing (locked, in use, or path/name issues).
    2. Check for storage service throttling
      • The context explicitly calls out throttling errors:
        • FileshareBackupFailedWithAzureRpRequestThrottling – “File share backup or restore operation failed due to storage service throttling. This may be because the storage service is busy processing other requests for the given storage account. Try the backup/restore operation at a later time.”
      • Even off‑hours, other workloads (FSLogix I/O, diagnostics, other services) can cause bursts that trigger throttling.
      • Actions:
        • Confirm in the job details whether throttling is the reported cause.
        • If yes, reschedule the backup to a different time window and ensure no heavy operations (large copy/migration jobs, scans, etc.) run against that storage account then.
    3. Verify storage account network routing and special services setting
      • For Azure Files backup, the storage account must use Microsoft network routing, not Internet routing:
        • Error UserErrorStorageAccountInternetRoutingNotSupported: “Storage accounts with Internet routing configuration are not supported by Azure Backup. Ensure that the routing preference set for the storage account hosting backed-up file share is Microsoft network routing.”
      • Confirm:
        • In the storage account → Networking → Network routing, ensure “Microsoft network routing” is selected.
        • “Allow access from Microsoft services” is already enabled, which is required.
    4. Confirm no account locks or policy conflicts
      • If the storage account is locked, backup jobs can fail:
        • UserErrorStorageAccountIsLocked: “Backup or restore jobs failed due to storage account being in locked state. Remove the lock on the Storage Account or use delete lock instead of read lock and retry the backup or restore operation.”
      • Also ensure no concurrent operations conflict with backup configuration:
        • BMSUserErrorConflictingProtectionOperation / BMSUserErrorObjectLocked – wait for any in‑progress configure/modify operations to complete before the scheduled backup.
    5. Validate that the file share and snapshots remain intact
      • Although the first backup succeeded, later failures can occur if snapshots or the share state change:
        • Ensure the file share is not in soft‑deleted state and has not been deleted/recreated.
        • For restore scenarios, errors like UserErrorAFSSourceSnapshotNotFound and soft‑delete errors appear if snapshots or the share are deleted; similar issues can affect incremental backup chains if snapshots are removed.
      • For FSLogix, ensure no external process is cleaning up snapshots or manipulating the share in a way that interferes with incremental backups.
    6. Re‑run backup after addressing configuration and throttling
      • After confirming:
        • Microsoft network routing is enabled.
        • No storage account locks are present.
        • No conflicting backup/modify operations are running.
        • Backup window avoids other heavy workloads.
      • Trigger an on‑demand backup of the problematic 500‑GB share and monitor the job details for:
        • Stage at which it fails.
        • Exact error code and message.
    7. When to escalate
      • If:
        • Network routing is correct,
        • No locks or soft‑delete issues exist,
        • No throttling error is reported, and
        • The job still fails at “Transfer to vault” while a similar share on the same account and policy succeeds,
      • Collect the job error code, time, and correlation IDs from the job details and open a support case, as this may indicate a service‑side issue specific to that share or vault.

    References:

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.