locked
Please help me diagnose and fix a WHS drive issue (re: system crashing, incorrect DATA array size, etc.) RRS feed

  • Question

  • Long story short:

    HP Mediasmart EX-485 with 3TB of storage.  It worked perfectly and provided daily backups (for a single PC running Vista-64) for around a year and it had no problems serving up movies and music to my HTPC.  In April of this year it started freezing up every time it tried to run the nightly backup of the PC.  It fails at 12% of the way through the backup process at the "Rearranging Data on the Server" stage.

    I used the "Repair..." function to try to repair the backup database (seemed to get through just fine), although the "Clean backups" seems to hang at the start and never gets anywhere; I left it for 12 hours yesterday and it made no progress.

    I have 3 screenshots of some other odd things going on with the drives.

    First, here's a picture of the server storage as seen by the console: http://www.franzen-online.com/pete/console.png

    Here's what shows up when I RD into the server (note how there is more free space than the total size of the array, according to this): http://www.franzen-online.com/pete/rd.png

    And here's a closeup of the DATA array with some really odd stuff going on in the 'Used Space' section: http://www.franzen-online.com/pete/rd2.png

     

    How do I go about troubleshooting this?  I just did a Server Recovery and reinstalled the OS but that didn't fix anything.  There is clearly something going on with the drives but there don't seem to be any chkdsk errors in the event logs.  Help!

    Friday, June 18, 2010 7:16 PM

Answers

  • Problem solved.

    I shut down the server, removed each drive one by one, and ran 'chkdsk /f /r' on each drive on my primary PC.  One of the drives had some errors that chkdsk was able to fix, and as soon as the drives were reinstalled in the server it began working perfectly.

    I was under the impression that WHS ran chkdsk regularly, so I'm not sure why it wasn't able to find and fix these errors on its own.  Regardless, I'm glad the issue was a relatively simple one.

    • Marked as answer by CUclimber Tuesday, June 22, 2010 8:52 PM
    Tuesday, June 22, 2010 8:52 PM

All replies

  • Hi,

    your screenshots show nothing uncommon.

    The larger free size of drive D: is a cosmetic bug, which was introduced to fix another issue not allowing to copy more than the free amount of space on the real D: drive to a shared folder at once.

    You may wish to check the event log on the server. Are there any ntfs or disk related errors? Did you try the FAQ How to check all the drives in your server for errors?

    Are there errors in the event log on the client PC giving more details about the backup failure? Did you try to run chkdsk /r on each disk on the client PC?
    Do you have only one PC or more? If more, are the other clients backed up successfully?

    If not you might try to delete the entire Backup database and start from the scratch (this would loose you all current backups, but since you did not succeed since April the loss cannot be that big):

    On the server open a command prompt.
    Enter following commands:
    net stop pdl
    net stop whsbackup
    d:
    cd  \folders\{00008086-058D-4C89-AB57-A7F909A47AB4}
    del *.*


    (You can also perform the deletion of all files in that folder from Windows Explorer after stopping the mentioned services, if you are not so sure about the command prompt.)
    After completing the deletion (ensure that no files did remain in the folder) restart either the services or the server.

    Best greetings from Germany
    Olaf

    Friday, June 18, 2010 8:59 PM
    Moderator
  • Problem solved.

    I shut down the server, removed each drive one by one, and ran 'chkdsk /f /r' on each drive on my primary PC.  One of the drives had some errors that chkdsk was able to fix, and as soon as the drives were reinstalled in the server it began working perfectly.

    I was under the impression that WHS ran chkdsk regularly, so I'm not sure why it wasn't able to find and fix these errors on its own.  Regardless, I'm glad the issue was a relatively simple one.

    • Marked as answer by CUclimber Tuesday, June 22, 2010 8:52 PM
    Tuesday, June 22, 2010 8:52 PM