Share via

Backing up FSLogix Containers

MichaelB-2136 250 Reputation points
2026-04-17T09:53:32.9166667+00:00

Hi, I have a vault standard Azure backup job that backups up my FS Logix profiles.

I deliberately set them up to run outside of business hours to avoid any chance of profile corruption and they take 6-7 hours.

My business wants to reduce our downtime hours meaning they may be logged in during the 6-7 hour process.

Am I right in thinking that as long as no one is logged in during the initial snapshot that occurs at start of the backup then there is no risk of profile corruption? The snapshot completes instantly and the rest of the time is the data being moved in to the vault I believe.

E.g.

12PM Backup starts, snapshot is taken

5AM User logs in

7AM FSLogix backup finishes

Is this ok?

Azure Backup
Azure Backup

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

Answer accepted by question author

  1. Suchitra Suregaunkar 13,785 Reputation points Microsoft External Staff Moderator
    2026-04-17T10:31:02.9733333+00:00

    Hello MichaelB-2136

    Thank you for posting your query on Microsoft Q&A platform.

    Yes, your understanding is correct, and the scenario you described is supported when using Azure Backup for FSLogix containers stored on Azure Files.

    When you protect an Azure File Share using Azure Backup (Vault‑Standard), the backup process works as follows:

    • Azure Backup takes a storage‑level snapshot at the start of the backup job
    • After the snapshot is completed, Azure Backup uses that snapshot to create the recovery point in the vault
    • The long backup duration (several hours) is due to snapshot processing and data replication, not because the live file share or VHDX files are locked

    Impact to FSLogix profiles:

    FSLogix profile containers are stored as VHD/VHDX files on the file share. The key point is when the snapshot is taken:

    • If no user is logged in (container not mounted) at the moment the snapshot is taken, the snapshot represents a clean, consistent point‑in‑time copy.
    • Users can log in after the snapshot completes and continue working normally while Azure Backup finishes processing the snapshot.
    • Azure Backup does not interact with the live, mounted VHDX after the snapshot.

    Microsoft does not state any requirement that users must stay logged off for the entire backup window, nor does it document Azure Backup snapshots as a cause of FSLogix profile corruption.

    Your example scenario:

    12:00 AM – Backup starts, snapshot is taken
05:00 AM – User logs in
07:00 AM – Backup job finishes

    This scenario is supported and acceptable, because the snapshot was already completed before the user logged in. All subsequent backup activity works only against the snapshot, not the live FSLogix profile.

    Reference:

    Best practice is to schedule backups when users are unlikely to be logged in, but from a product‑support standpoint, users logging in after the snapshot is taken does not invalidate the backup or introduce a documented corruption risk.

    So, Azure Backup for FSLogix containers is snapshot‑based. As long as the FSLogix container is not mounted when the snapshot is taken, users logging in afterward do not affect the backup or introduce a documented risk of profile corruption.

    Thanks,
    Suchitra.

    1 person found this answer helpful.

Answer accepted by question author

  1. Q&A Assist
    2026-04-17T09:53:51.3366667+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    For Azure Backup of FSLogix containers stored on Azure Files or Azure NetApp Files, the backup process is snapshot-based. The snapshot is taken on the storage side and then used to create a recovery point in the vault. The long backup duration is primarily the time needed to process and replicate data, not the time during which the live share is frozen.

    From the documented behavior:

    • Azure Backup uses storage snapshots and then copies data (for vaulted backups, object replication is used) to the Backup vault.
    • Recovery points are created after the snapshot and replication complete, but the source remains online and accessible during this process.

    The risk of FSLogix profile corruption is primarily related to:

    • Anti-virus or other processes interfering with I/O to the VHD/VHDX while it is mounted and in use.
    • Storage or I/O issues (for example, corruption in the underlying storage subsystem).

    The documentation does not state that Azure Backup snapshots themselves cause FSLogix container corruption when users are logged in. It also does not require that no users be logged on during the entire backup window. Instead, it treats backup as a standard protection mechanism for FSLogix profiles stored on Azure Files or Azure NetApp Files.

    Given the documented model:

    • The snapshot is taken at the start of the backup.
    • After the snapshot, Azure Backup works from that snapshot to create the recovery point.
    • Users can continue to access their profiles on the live share while the backup job completes.

    Therefore, the described timeline is consistent with supported behavior:

    • 12 AM: Backup starts, snapshot taken.
    • 5 AM: Users log in and use FSLogix profiles on the live share.
    • 7 AM: Backup job finishes processing the snapshot and creating the recovery point.

    This pattern aligns with how Azure Backup is designed to protect file shares and storage accounts and does not, by itself, introduce a documented risk of FSLogix profile corruption.

    To improve overall resilience of FSLogix profiles and user data:

    • Use Azure Backup for Azure Files or Azure NetApp Files where FSLogix profiles are stored.
    • Consider a no-profile recovery strategy or Cloud Cache plus backup, and redirect critical user data to OneDrive or SharePoint so that profile loss or corruption has less impact.

    References:

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

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.