Microsoft Azure Backup Server issue

Hi @Linfeng Wen (dadminlw) Thank you for contacting Microsoft Support regarding Microsoft Azure Backup Server. I have reviewed both reported symptoms and can confirm they are two distinct faults requiring separate remediation. Neither is a product limitation; both have documented resolutions.

Issue (ID 3188) - this one has a specific documented cause:

ID 3188 is documented as: "Windows Azure Backup Agent was unable to create a snapshot of the selected volume (ID: 100034)", and the official remediation is:

This can occur if the DPMWriter service isn't running. Set the DPMWriter service to Automatic and make sure that the service is started." — DPM error codes

1. On the MABS server run services.msc → find DPMWriter → set Startup type = Automatic → Start. Verify: sc query DPMWriter shows RUNNING.
2. Also confirm OBEngine ("Microsoft Azure Recovery Services") is running - net start OBEngine. Verify: service state Running.
3. Right‑click the datasource → Create recovery point → select Online protection. Verify: the job completes and an online recovery point appears.

Important: increasing retention can never enable online protection. Retention only controls how long recovery points are kept. If the Online protection page is missing from the protection group, right‑click the group → Add Online Protection, and make sure the server is ticked on Specify online protection data. Note that online protection also requires "I want short-term protection using: Disk" to be selected.

Issue (ID 3106 + ID 910) — the important code here is 910, not 3106:

• 3106 just means the replica is inconsistent and all protection activity will fail until a consistency check runs.
• 910 means "The DPM service terminated unexpectedly during completion of the job. The termination may have been caused by a system restart." — that is what broke the replica. Fixing the crash matters more than repeatedly running consistency checks.

1. Check the System event log for unexpected shutdown/restart (Event 6008) and the Application log for MSDPM/DPMRA crashes at the failure time. ✔ Verify: you can pinpoint the crash timestamp.
2. Install the latest MABS Update Rollup and update the MARS agent — a Microsoft‑accepted answer explicitly recommends this as step 1.
3. In Monitoring, create a custom filter showing only synchronization and recovery point jobs. Per XinGuo‑MSFT's accepted answer, "a replica can only become inconsistent if a synchronization or express-full job fails" — this finds the real originating failure.
4. Restart DPMRA on both the protected server and the MABS server (net stop dpmra / net start dpmra).
5. Check free space: storage pool, replica volume, recovery-point volume, and 5–10 % free on the scratch volume. Confirm AV exclusions for MABS.
6. Run Perform consistency check, then Resynchronize. ✔ Verify: datasource returns to OK.
7. Create a disk recovery point first, and only then an online one — MABS builds online recovery points from the local replica, so this ordering matters.

If it still fails, please share the full error text not just the ID.

If you have further questions regarding this answer, feel free to click "Comment". If you find the answer helpful, please click "upvote" and accept it. This helps the community by allowing others with similar queries to easily find the solution.

These failures are related, but extending retention does not enable online protection. IDs 3106/910 mean MABS considers the local replica inconsistent, so cloud recovery-point creation can fail until the disk replica is healthy.

Update MABS and the MARS agent. Confirm SQL Agent, Volume Shadow Copy, Microsoft Azure Recovery Services, and OBEngine are running. Verify outbound Azure connectivity, antivirus exclusions, and free space in the MABS storage pool, replica/recovery-point volumes, and scratch location. In the MABS console, select the affected data source and run Synchronize with consistency check. When it succeeds, create a disk recovery point, then retry an online recovery point.

For ID3188, also confirm registration to the intended Recovery Services vault and validate the encryption passphrase and scratch path. If either job still fails, collect the detailed job error plus MABS/MARS logs and open a Microsoft Support case; the numeric ID alone does not identify the failed component.