none
Failed consistency check against file servers RRS feed

  • Question

  • Hello,

    When backing up our file servers, if something "tanks", it forces us into doing a sync w/ consistency check.  It's a long process but for the most part, we get through it.  However, once in a while, we get this funky error when running the consistency check:  "An unexpected error occurred during job execution. (ID 104 Details: Catastrophic failure (0x8000FFFF))".  The fix in the past was always one of the following:

    • Make sure the latest builds (software and/or agents) are applied;
    • Restart the host DPM server or restart the DPMRA agents on the target servers;
    • Drop the Protection Group and re-seed;
    • Or just keep trying until it works.

    We've seen in the past that eventually one of the above would work and normal synchs and recovery points could resume.  However, this time, none of the above are working for 2 file servers.  Has anyone else seen this?  Info on our setup is below:

    DPM server:  Physical server running DPM 2007 (version 2.0.8851.0) on Windows 2008 SP2 (64-bit).

    2 Problem File servers:  VMWare ESX4 guests running DPM agents (version 2.0.8851.0) on Windows 2008 SP2 (64-bit).  All 12 of our file servers host shares, run DFSR and Shadow Copies.  Just 2 are having problems now.

    We do have the bandwidth throttled to 25% during the day and 85% at night.  No, these file servers do not have a private VLAN for DPM traffic.  The total data is about 190GB on one server and about 1TB on the other server.  The backup set is not for tape-based; just disk-based.  Lastly, YES, we have disabled McAfee on the 2 file servers as a test and still the problem persists. Help!

    Tuesday, September 7, 2010 1:56 PM

Answers

  • Hi

    Your running DPM2007 with SP1 and the hotfix KB970868 installed. There is a fix with the KB article number KB979970. Apply this and verify if your DPM server / agent can sort out the error.

    In the latest version of DPM 2007 the developers implemented a function call "skip" (or someathing like that) that will skip the file that DPM 2007 is trying to backup if it can't be released from it's process used.

    Apply the hotfix and get back with an answer.

    BR

    Robert Hedblom


    Check out my DPM blog @ http://robertanddpm.blogspot.com
    • Marked as answer by Dave-LVP Wednesday, September 8, 2010 1:27 PM
    Tuesday, September 7, 2010 8:37 PM
    Moderator

All replies

  • Hi

    Your running DPM2007 with SP1 and the hotfix KB970868 installed. There is a fix with the KB article number KB979970. Apply this and verify if your DPM server / agent can sort out the error.

    In the latest version of DPM 2007 the developers implemented a function call "skip" (or someathing like that) that will skip the file that DPM 2007 is trying to backup if it can't be released from it's process used.

    Apply the hotfix and get back with an answer.

    BR

    Robert Hedblom


    Check out my DPM blog @ http://robertanddpm.blogspot.com
    • Marked as answer by Dave-LVP Wednesday, September 8, 2010 1:27 PM
    Tuesday, September 7, 2010 8:37 PM
    Moderator
  • Robert:

    Thank you for the information.  I updated our server and am in the process of updating the agents now.  We've seen the errors anywhere between 5 mins after re-running the job and sometimes up to 24 hours after re-running the job.  I'll re-run them tonight and will post back results either tomorrow or the day after (whenever the consistency checks complete).  Thank you for your quick answer.

    Regards,

    -Dave

    Tuesday, September 7, 2010 9:12 PM
  • Dave

    Great, I will look at this thread tomorrow to see if you have put in an answer.

    BR

    Robert Hedblom


    Check out my DPM blog @ http://robertanddpm.blogspot.com
    • Marked as answer by Dave-LVP Wednesday, September 8, 2010 1:27 PM
    • Unmarked as answer by Dave-LVP Wednesday, September 8, 2010 1:28 PM
    Tuesday, September 7, 2010 9:17 PM
    Moderator
  • Yo.... Mr Hedblom,

    Thank you.  The server with the smaller data set (~190GB) completed the synch within 30 minutes.  The second one with ~1TB is still running but has not errored out so things look good.

    Thank you.

    Regards,

    -Dave

    Wednesday, September 8, 2010 1:27 PM