How to recover MABS from existing DPMDB backup

Hello Shubham Prajapati,

Greetings! Thanks for raising this question in the Q&A forum.

The "DPMDB already exists" error happens because a fresh MABS install already creates its own DPMDB database, so when you try to restore your old backup on top of it DpmSync sees a conflicting database and refuses to overwrite it. There are two supported ways to recover here, and the Add External MABS method is the one Microsoft recommends over manual DpmSync restore because it avoids exactly this class of error.

1. Preferred method: recover using Add External MABS This is the documented disaster recovery path and does not require manually wrestling with DpmSync.

• Build a new server, install MABS on it, and make sure it matches the exact same MABS version and Update Rollup level as the original corrupted server. A mismatch here is the most common reason recovery fails, since DPMDB schema is version specific.
• Register this new MABS server to the same Recovery Services vault your old server was using.
• In the MABS Administrator Console, go to Recovery, then select Add External MABS.
• Provide the vault credentials downloaded from the Recovery Services vault. Note these credentials are only valid for 2 days, so generate a fresh set if yours have expired.
• In Select External MABS for Recovery, choose the original (corrupted) MABS server identity, enter the encryption passphrase you set when the vault was originally configured, and select OK.
• Select the recovery point you want to restore from the list of available points, then complete the recovery. This pulls the DPMDB backup down from Azure and restores it into the new server's own DPMDB without a database collision.

1. If you must restore manually with DpmSync Only use this path if you are restoring onto the same server after OS reinstall and cannot use Add External MABS.

• Uninstall MABS from the server first, and when prompted choose Retain Data so the disk based recovery points and storage pool are not wiped.
• Use SQL Server Management Studio to connect to the local SQL instance and delete the existing DPMDB database completely so there is no name collision.
• Reinstall MABS at the exact same version and Update Rollup as when the backup was taken.
• Run the restore:

DpmSync -RestoreDb -DbLoc <path to DPMDB.bak> -InstanceName <server\instance>

• After the restore completes, synchronize the database:

DpmSync -Sync

• If any replicas show as missing after sync, reallocate them:

DpmSync -ReallocateReplica

1. On your broader question about disaster recovery planning for MABS Since MABS is a single centralized server, most organizations mitigate that single point of failure by doing one or both of the following, backing up the MABS server's own DPMDB to Azure Backup (which is exactly the Add External MABS scenario above, this is the primary purpose of that feature) and keeping a documented, tested runbook with the exact MABS version and Update Rollup recorded, since version mismatch is the top cause of failed recovery. Some environments also run a secondary standby MABS server pre-registered to the same vault so Add External MABS can be performed immediately without waiting to provision new hardware.

If recovery still fails after matching the version and using Add External MABS, that points to a corrupted or incomplete DPMDB backup itself rather than a procedural issue, and at that point opening an Azure Backup support case with the vault name, MABS server name, and the exact error text is the right next step, since diagnosing a bad backup chain requires access to vault side telemetry.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.