DPM Rollup Update Installation Fails - Failed to execute SQL string, error: BACKUP DATABASE is terminating abnormally

Recently we decided to deploy Update Rollup 5 for Data Protection Manager 2019, but were running into issues getting the update to install.

In the installation log we spotted lots of:

MSI (s) (BC!10) [14:34:02:258]: Transforming table Error.

But most importantly we saw:

ExecuteSqlStrings:  Error 0x80040e14: failed to execute SQL string, error: BACKUP DATABASE is terminating abnormally., SQL key: KB5024231_BackupDpmDb.sql.97DDF5B3_3770_4C3E_8673_52BD081E1EFD SQL string: BACKUP DATABASE DPMDB_SERVERNAME080fe81c_748b_403a_b6ca_fa1d3a042da9 TO DISK = 'QFEDPMDB_SERVERNAME080fe81c_748b_403a_b6ca_fa1d3a042da9.bak' WITH COPY_ONLY, INIT

Well why would that be an issue - it usually works...

The answer is annoyingly simple:

If you delete the file:

QFEDPMDB_SERVERNAME080fe81c_748b_403a_b6ca_fa1d3a042da9.bak

(which will be located in your normal backup directory for SQL Databases and named with the guid and machine/database name you actually have rather than the above)

It will work. But why does it care, the file usually exists from the last update rollup.

The answer is in the command - if you run that in SSMS you'll see this error appear:

System.Data.SqlClient.SqlError: Cannot use the backup file because it was originally formatted with sector size 4096 and is now on a device with sector size 512. (Microsoft.SqlServer.Smo)

Ah ha! Indeed - the last update rollup we installed we were indeed using a disk with 4096 sector size, and the new ones are back to 512 for the system volume (long story for another day!)

Deleting the old backup is the easiest fix.

DPM 2010 - "Replica is Inconsistent" on 2008 Servers for Statem State

It would be fair to say DPM is proving to be far better than Backup Exec on most things, but occasionally there are some short sighted decisions or stupid issues that could have been better handled.

One small example is where you find System State and Bare Metal Recovery Replicas keep becoming inconsistent on a Windows 2008 system that's being backed up with DPM 2010.

The fix is pretty simple. On the 2008 server you're backing up, go to "Server Manager", load features, choose "Add Feature" and ensure "Windows Server Backup" is an allowed feature (this won't need a reboot).

Given DPM seems to check loads of other pre-requisites you'd expect it would either alert you to this at install time, or just enable it as part of the install (even if there was an option which said "If Windows Server Backup features are not enabled on the source for protection, enable it automatically" or something.

A silly oversight and one that just takes a tiny bit of the sparkle of clueful implementation away I think.

Microsoft DPM - A breath of Fresh Air (almost!)

Having finally reached the end of our patience with Backup Exec and its never ending failures to simple requests, the terrible performance issues it suffers and all the other problems we hear about and witness every day, we decided to give Microsoft's Data Protection Manager a whirl.

There are a few important things to think about though if you are looking to switch, since Microsoft DPM is really only about Windows, SQL, Exchange and Sharepoint. If that's what you're running, and you're on 2003 SP-2 or 2008 and above, you should be fine. If you need other platforms and apps which Backup Exec supports you're probably out of luck using this.

Microsoft DPM is a very different product. One of the key differences is that it is truely snapshot based. Backup Exec still does far too much by using file by file methods - this has terrible scaling consequences.

It is mostly about Disk backup, whereas Backup Exec has a wider range of support for traditional tape backup. DPM can do it (it calls this "Long Term" Storage, and uses Disk for "Short Term" (you define what short/long term is...)

So in a nutshell (kind of) here's the story so far:

1) Installation of DPM failed because the install folder was "C:\!Software\DPM2010" whereas the installer ignored the existance of ! and tried to load "C:\Software\DPM2010" and couldn't find its own files. So we just put up with that and put DPM2010 in the c:\ folder root so we could get started.

2) Installation takes a while as it also rolls out SQL 2008 (you can get it to use an existing Database but we opted not to - and this is the recommended approach).

3) Take time to read the pre-req's and understand how DPM works. For example, make sure you have a huge volume on each DPM server (the best scenario) you have left unformatted so it can claim this for itself.

With those basics covered, the initial installation was completely succesful and our first DPM server appeared.