locked
BMR backups failing but system state works RRS feed

  • Question

  • We're seeing an issue doing a BMR backup on several of our servers. I've checked a number of other posts on here, and the resolutions given haven't worked for me.

     

    Backups of the individual drives work fine, as does the System State backup if I configure that on its own. If I then add the BMR backup, both the BMR and Sys State backups initially report as being OK, and then eventually report that they are inconsistent.

     

    WSB is installed and working on the protected server, and on the DPM server I've ramped up the storage allocation to ensure that isn't the issue, so the Replica Volume and Recovery Point Volume on the protected servers System Protection are both set to 100GB. Note, the protected server has 2 volumes configured, the system volume is 40GB with 30GB available, and the data volume is 40GB with 32GB available, so 100GB should realistically be more than enough.

     

    On the DPM server the alert that is generated is :

     

    ---

    Affected area:   Computer\System Protection

    Occurred since: 29/06/2011 10:24:48

    Description:        The replica of System Protection Computer\System Protection on <server name> is inconsistent with the protected data source. All protection activities for data source will fail until the replica is synchronized with consistency check. You can recover data from existing recovery points, but new recovery points cannot be created until the replica is consistent.

     

    For SharePoint farm, recovery points will continue getting created with the databases that are consistent. To backup inconsistent databases, run a consistency check on the farm. (ID 3106)

                    DPM cannot create a backup because Windows Server Backup (WSB) on the protected computer encountered an error (WSB Event ID: 517, WSB Error Code:  0x8078002A). (ID 30229 Details: Internal error code: 0x809909FB)

                    More information

    Recommended action:  For resolution actions and more information on the WSB error, go to http://technet.microsoft.com/en-us/library/cc734488(WS.10).aspx.

                    Synchronize with consistency check.

                    Run a synchronization job with consistency check...

    Resolution:         To dismiss the alert, click below

                    Inactivate alert

    ---

     

    If I run a synchronization job with consistency check the same error comes up again.

     

    On the protection server, the backup attempt shows up in WSB as failed and reports :

     

    VSS settings: VSS Copy Backup

    Status: Failed

                    One of the backup files could not be created.

    Data transferred: 0KB

     

    Within the Errors tab...

    System Reserved: One of the backup files could not be created. Detailed error: The parameter is incorrect

    C: The operation to back up the volume was stopped before the operation started running.

     

    In the event log of the protected server, there are no error events in the System log (there are a number of information events relating to the DPMRA, VSS etc services started and stopping successfully.

     

    In the Application log there is an error :

     

    ---

    Log Name:      Application

    Source:        Microsoft-Windows-Backup

    Date:          29/06/2011 10:25:25

    Event ID:      517

    Task Category: None

    Level:         Error

    Keywords:     

    User:          SYSTEM

    Computer:      <server name>

    Description:

    The backup operation that started at '‎2011‎-‎06‎-‎29T09:25:07.624958100Z' has failed with following error code '2155348010' (One of the backup files could not be created.). Please review the event details for a solution, and then rerun the backup operation once the issue is resolved.

    Event Xml:

    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">

      <System>

        <Provider Name="Microsoft-Windows-Backup" Guid="{1DB28F2E-8F80-4027-8C5A-A11F7F10F62D}" />

        <EventID>517</EventID>

        <Version>0</Version>

        <Level>2</Level>

        <Task>0</Task>

        <Opcode>0</Opcode>

        <Keywords>0x8000000000000000</Keywords>

        <TimeCreated SystemTime="2011-06-29T09:25:25.281547100Z" />

        <EventRecordID>4569</EventRecordID>

        <Correlation />

        <Execution ProcessID="2920" ThreadID="2320" />

        <Channel>Application</Channel>

        <Computer><server name></Computer>

        <Security UserID="S-1-5-18" />

      </System>

      <EventData>

        <Data Name="BackupTime">2011-06-29T09:25:07.624958100Z</Data>

        <Data Name="ErrorCode">2155348010</Data>

        <Data Name="ErrorMessage">%%2155348010</Data>

      </EventData>

    </Event>

    ---

     

    I've seen a suggestion in another thread about checking in the WSB console to see the last attempted backup, get the network location from there and then do a BMR backup from within WSB using that network location as the destination, however unfortunately the network path is too long to be displayed in that window, and I can't find anywhere else that shows that information in its complete form.

     

    We're running DPM 2010 on 2008 R2 Standard, and the servers we're having issues with are all 2008 R2 Enterprise VM's. Strangely, of 5 virtually identical protected servers (the only differences being the allocated memory and storage) we're only seeing this issue on 4 of them. The 5th works fine, but I can't find anything different about that one compared to the others.

     

    Hopefully someone out there has some other suggestions as to what I can try.

    Wednesday, June 29, 2011 2:21 PM

Answers

  • Hello,

    I'd start with testing it out locally.

    wbadmin start backup -allcritical -backupTarget:<any existing drive name>:

    If this fails then DPM never comes into play.  If this works then you can look at the wsb backup logs found in:

    C:\Windows\Logs\WindowsServerBackup

    OR the backup event logs:
    Event Logs\Applications and Services Logs\ Microsoft\Windows\Backup\Operational


    Thanks,
    Shane

    • Proposed as answer by ShaneB. _ Wednesday, January 18, 2012 8:28 PM
    • Marked as answer by Yegor Startsev Tuesday, April 9, 2013 11:06 AM
    Wednesday, July 20, 2011 8:09 PM
  • Thanks for the suggestion Shane, annoyingly it looks like I didn't get a notification for it so never knew about it until it was marked as the answer! :-)

    For reference to anyone else, I did actually try doing the backup using wbadmin and that worked fine. The cause turned out to be the sector size of the drive DPM picked for the backup. I can't remember the exact details (it was a while ago obviously) but our backup server had multiple volumes in use by DPM backups, and they different sector sizes. The issue was either that DPM didn't support one sector size at all (certainly not for system state backups), or it caused issues when either the system state and bare metal backups ended up on one volume while the other backup ended up on a different one.

    We eventually found out about the issue from Microsoft when they confirmed it wasn't a support configuration, while also confirming it wasn't at that time documented.

    The same is still true in 2012, and certainly in DPM 2012 when the backup fails, checking on the protected server in c:\windows\logs\WindowsServerBackup\Backup_Error-<date time>.log shows an error of "The sector size of the physical disk on which the virtual disk resides is not supported".

    • Marked as answer by Yegor Startsev Wednesday, April 10, 2013 6:39 PM
    Wednesday, April 10, 2013 2:14 PM

All replies

  • Are you running Forefront on the protected servers? That could be an issue if so.

    Try to check the following thread : http://blogs.msdn.com/b/exchangeserverfaq/archive/2010/04/06/system-state-backup-using-dpm-2010-fails-on-exchange-servers.aspx

    Tuesday, July 5, 2011 7:48 PM
  • Hello,

    I'd start with testing it out locally.

    wbadmin start backup -allcritical -backupTarget:<any existing drive name>:

    If this fails then DPM never comes into play.  If this works then you can look at the wsb backup logs found in:

    C:\Windows\Logs\WindowsServerBackup

    OR the backup event logs:
    Event Logs\Applications and Services Logs\ Microsoft\Windows\Backup\Operational


    Thanks,
    Shane

    • Proposed as answer by ShaneB. _ Wednesday, January 18, 2012 8:28 PM
    • Marked as answer by Yegor Startsev Tuesday, April 9, 2013 11:06 AM
    Wednesday, July 20, 2011 8:09 PM
  • Hello,

     

       “housekeeping - closing old post.  Open a new post if you still have a need.”


    No respose.


    Shane

    Wednesday, January 18, 2012 8:27 PM
  • Thanks for the suggestion Shane, annoyingly it looks like I didn't get a notification for it so never knew about it until it was marked as the answer! :-)

    For reference to anyone else, I did actually try doing the backup using wbadmin and that worked fine. The cause turned out to be the sector size of the drive DPM picked for the backup. I can't remember the exact details (it was a while ago obviously) but our backup server had multiple volumes in use by DPM backups, and they different sector sizes. The issue was either that DPM didn't support one sector size at all (certainly not for system state backups), or it caused issues when either the system state and bare metal backups ended up on one volume while the other backup ended up on a different one.

    We eventually found out about the issue from Microsoft when they confirmed it wasn't a support configuration, while also confirming it wasn't at that time documented.

    The same is still true in 2012, and certainly in DPM 2012 when the backup fails, checking on the protected server in c:\windows\logs\WindowsServerBackup\Backup_Error-<date time>.log shows an error of "The sector size of the physical disk on which the virtual disk resides is not supported".

    • Marked as answer by Yegor Startsev Wednesday, April 10, 2013 6:39 PM
    Wednesday, April 10, 2013 2:14 PM
  • Thanks for the update Keith.

    My DPM blog ystartsev.wordpress.com

    Wednesday, April 10, 2013 6:39 PM