Share via

recovery point creation failed

David Horvath 0 Reputation points
2026-03-25T19:55:57.1566667+00:00

In MABS we get creation point creation failure on the c: drive and system state. We run a consistency check and it fails. I deleted both c: and system state from the backup set and then re-added them. It initially seems to work well, but then the creation point creation failure returns. There are no errors in the event viewer and I cannot find any error logs.

Azure Backup
Azure Backup

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

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Suchitra Suregaunkar 11,150 Reputation points Microsoft External Staff Moderator
    2026-03-26T19:27:19.03+00:00

    Hello David Horvath

    Thanks for sharing the details. Based on the behavior you’re seeing, this issue is most likely related to how System State backups are created and staged in Microsoft Azure Backup Server (MABS) rather than a problem with the protection group itself.

    When MABS protects the C: drive and System State, it relies on Windows Server Backup and the MARS agent to first create a local System State image on a staging location. If that local staging step is interrupted or becomes unstable (for example, due to insufficient free space, disk availability issues, or interference from security software), the recovery point creation can fail. Once that happens, the replica can become inconsistent, which is why the Consistency Check also fails and deleting/re‑adding the data source only provides temporary relief.

    A few checks I recommend focusing on:

    • Verify that the System State staging drive configured on the protected server is local, online, and consistently has sufficient free space. MABS requires adequate scratch space for System State operations.
    • Ensure the Microsoft Azure Recovery Services (MARS) Agent is up to date and that the Microsoft Azure Recovery Services service is running. Restarting the service after validating the staging location can help.
    • Review antivirus or endpoint protection exclusions. Real‑time scanning of MABS, DPM, or MARS folders can interfere with snapshot finalization and cause silent backup failures.
    • Check the MABS and MARS log locations (not just Event Viewer), as System State backup failures are often logged only in the agent logs.

    Once the underlying System State staging issue is corrected, you’ll need to rebuild the replica (by re‑adding the data source) so that future recovery points can be created successfully and remain consistent. Thanks,

    Suchitra.

  2. Q&A Assist
    2026-03-25T19:56:14.0533333+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    For recurring recovery point creation failures on C: and System State in MABS, focus on the underlying System State backup and its prerequisites, since MABS relies on Windows Server Backup and the MARS agent for these jobs.

    Use these steps:

    1. Perform basic MARS/System State checks on the protected server
      1. Verify the Microsoft Azure Recovery Services (MARS) agent is current.
      2. Confirm the Microsoft Azure Recovery Services service is running; restart it and retry a consistency check.
      3. Ensure at least 5–10% free space is available on the scratch/cache volume used by the MARS agent.
      4. Confirm there is stable network connectivity from the server to Azure.
      5. Make sure the OS is fully patched and .NET Framework is at least 4.6.2.
      6. Verify that unsupported drives or files with unsupported attributes are excluded from backup as per the MARS support matrix.
      7. Check that the system clock/time zone are correct.
      These are the recommended baseline validations before deeper troubleshooting of System State backup issues.
    2. Check the System State backup workflow and staging drive MABS uses Windows Server Backup to create a System State backup and stages it on a local drive before transferring it:
      • On the protected server, open: C:\Program Files\Microsoft Data Protection Manager\MABS\Datasources
      • Edit the relevant PSDataSourceConfig.xml and verify the <FilesToProtect> drive letter used for System State staging:
        • Ensure this drive is local, online, and has sufficient free space.
        • If the server is a cluster node, make sure the configured drive is not a cluster disk that can move to another node. If it is, change it to a local drive.
      • After changes, save the file.
      • In MABS, run a consistency check for the protection group. If an alert is raised, use Modify protection group from the alert, complete the wizard, and then run another consistency check.
    3. Inspect the WindowsImageBackup folder behavior During System State backup, Windows Server Backup creates WindowsImageBackup at the root of the configured restore/staging folder. Note:
      • This folder and contents are not cleaned up after each backup; space is reserved for the next job.
      • Verify that the staging drive has enough free space to accommodate this folder over time; if it fills up, subsequent recovery point creation can fail even if MABS only reports a generic failure.
    4. If failures persist with no clear error
      • Re-run a System State backup directly with Windows Server Backup on the protected server using the same target drive configured in PSDataSourceConfig.xml. If that fails, collect its error details; MABS will not be able to succeed until the underlying Windows Server Backup job is healthy.
      • After fixing any Windows Server Backup issues, run another MABS consistency check.

    These steps align with how MABS orchestrates System State backups and address the common causes of recurring recovery point creation failures when no obvious event log errors are present.

    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.