The backup operation ... has failed to start, error code '2155348040' and BMRBackup.cmd questions RRS feed

  • Question

  • I have a single DPM Server and a few Windows 2008 servers. A couple of days ago I upgraded DPM from 2007 to 2010. All of the existing servers SystemState backups passed consistency checks.

    I was also setting up a new Windows 2008 R2 server which I designated as both SystemState and BareMetal. DPM reported acutal size at 20 GB and I set the two volume sizes at 50 gigs. The alert reported that the size was exceeded. Volume sizes were increased to 85 gb with no success.. On protected the above error message.

    I did a manual SystemState backup, and changed the xml file to make that happen on Production\d:. Clearly that part was possible. Then I found a post at on May 19 that suggested using BMRBackup.cmd \\server_name\Share_name and that worked without a hitch. The only problem is that the backup is 137 gb. No wonder it did not work.

    I removed the BareMetal option and SystemState has now successfully completed. So much for my plan to do BareMetal backups for all the servers. I have some headroom on the DPM server, but not that much. However, I do still have the just retired server that is kind of yesterday hardware, but has a few hundred gigs of now spare disk drive. It is where I put the bmrbackup test.

    This morning I set up some shares on retired and on three of the servers set up a task to do a daily backup. They all ran and now I can add a couple more servers, possibly all as not all are as large as the first one was. But I am wondering about this backup, will each iteration replace the previous, or will the DPM block level updates transpire? If the former, maybe I will only do these weekly or possibly even less frequently. If the updates are only changed blocks, perhaps I can do daily backups without undue strain on the network.

    Also, I started 7zip to work on one of those file sets and over the first 10 gigs or so it appeared to compress down to maybe 30% of original size. I killed it at that point as it was taking a long time. But that is a significant savings, and I am wondering if there are any obvious downsides to compressing the drive? Its only function would be to hold these backups.



    Thursday, June 3, 2010 6:08 AM


  • Baremetal backup is at block level and incremental backup needs only the space for the changed blocks. Its optimized for disk space requirement for incremental backups, so might need more(as much as the protected data size) disk space in replica volume but recovery point needs the space only to accommodate the changed blocks in each backup version. Coming to incremental backup schedule, doing incremental more freequently don't require more disk, for example if 7 blocks are changed in a week time(one block in a day), storing 7 incrementals for each reaquires only 7 blocks of storage at the same time to storage one backup at the end of the week also needs 7 blocks. So Doing BMR backup weekly instead daily don't save much on disk space, but you should consider the protected computer recoverability requirements and choose the right schedule. One advantage in doing weekly backup is the recoverability range can be longer. For example assume that you have sufficiently large disk space to hold BMR recovery points, Doing weekly backup gives larger recovery range compared to daily backups as the number of backups that can be stored using VSS shadowCopy is limited.

    If you are compressing the Replica volume on DPM side that is just going break the entire logic and design of using the VSS shadowcopy to store incremental backups. So I wouldn't suggest compressing the recovery point volume on DPM replica side. Otherwise it can indeed work in reverse and also can cause recovery point volume also to consume more disk space.

    Hope this helps you understand the BMR feature better.

    Thanks, Praveen D [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, June 4, 2010 6:44 AM