locked
"Backup Service is not running" errors on a new WHS install RRS feed

  • Question

  • I purchased and setup an HP MSS EX470 a few weeks ago. I didn't install any add-ins nor do anything else to WHS except to install the HP 1.3 update and to schedule backups of my two client PCs. Backups worked fine for about a week.

    Soon after that, the WHS Console greeted me with the annoying "Backup Service is not running - Backup Service is not running on server" error. Rebooting the server didn't resolve the problem; nor did performing any of the Troubleshooting Methods listed in "How to troubleshoot the “Backup service is not running” error message in Windows Home Server" (http://support.microsoft.com/kb/946339). I performed Method 5--Reset the backup database (i.e., simply delete all client PC backups). Upon doing that and rebooting, the Backup Service started OK.

    The next morning, I got the same "Backup Service is not running" error. Rebooting the server didn't resolve the problem.

    At the time of both Backup Service failures (and at the time of the subsequent reboots, which didn't resolve the problem, either), the following two errors appeared in the HomeServer event log:

    Event Type: Error
    Event Source: HomeServer
    Event Category: Backup
    Event ID: 272
    User: N/A
    Description:
    Unexpected error 0x45d from ReadFile on D:\folders\{00008086-058D-4C89-AB57-A7F909A47AB4}\Index.4096.dat: The request could not be performed because of an I/O device error.

    Event Type: Error
    Event Source: HomeServer
    Event Category: Backup
    Event ID: 267
    User: N/A
    Description:
    Client Backup server failed at d:\qhsv1_rtm_qfe\qhs\src\backup\util\diskfile.cpp(372)

    At first glance, it appeared that there was a problem with one of my drives. (I have a 500 GB drive and three 1 TB drives.) However, the Server Storage button indicated that all of the drives are Healthy. To that point, page 19 of Microsoft's 'Technical Brief for WHS Drive Extender' states:

    Unhealthy and Missing Hard Drives
    Windows Home Server runs CHKDSK every 12 hours on all of the hard drives on the home server to look for potential issues. At the end of a CHKDSK pass, a hard drive can be marked as Unhealthy in the home server console. If you select an unhealthy hard drive and then click Repair, the Repair a Hard Drive Wizard starts. It attempts to fix errors by doing the following:
    - Scanning the hard drive by using the CHKDSK utility to verify the integrity of the hard drive. If the primary hard drive is marked Unhealthy, the user is asked to reboot the home server.
    - Correcting hard drive errors, if possible.
    - Rebuilding shared folder duplications, if necessary.

    So it would appear that my hard drives are OK. Many CHKDSKs are being performed yet all of the drives are still marked as Healthy. That being the case, it's a mystery to me why the Backup Service keeps failing upon the first backup of my client PCs.

     

    Hoping that it might improve the situation, I installed PP1. It didn't help. The Backup Service is still failing. In addition, I thereafter received 'There are file conflicts' warnings. The Details button on the Network Critical button indicates that there are four files in conflict (all within the same directory) with the conflict message for each stating: "The request could not be performed because of an I/O device error".

    I went to the Settings > Backup form and pressed the Repair button. After a minute or so, I was rudely logged out of the WHS Console. I logged back in and pressed the Repair button; after a few minutes, I was again rudely logged out of the WHS Console. I re-started WHS, but the Backup Service still failed...and the warning about the four file conflicts remains.

    Ugh. Any suggestions?

    Wednesday, August 6, 2008 1:56 AM

Answers

  • cgwaters,

     

    It's by design per PP1. Chris Gray has published an excellent article on the new data migration strategy of PP1 on his blog: A brief description of the balancing algorithms used for disk balancing in Home Servers PP1 Drive Extender

     

    During PP1 beta there was some 'discussion' (read this thread) on the why's and how's and if this could be an issue for the release of PP1. The conclusion was that there is no problem except for some special situations (like adding a disk when the system disk is full). Microsoft is aware of this problem and will probably address it at some time in the feature.

    For the meanwhile I have written a little tool that enables you to work around the problem when it hits you. I named it LZreallocator (you can download it from my Home Server here).

    At this time the download link was hit over 100+ times, so apparently some people have used it. Until today I have had nog negative feedback at all so I assume it is doing what it was designed for without problems.

     

    A I mentioned in my earlier post, in your case I do not think you need the tool (although you could use it to free up some space on the system disk) as the 30% free space on your system disk should be enough for normal circumstances.

     

    Theo.

    • Marked as answer by cgwaters Tuesday, September 16, 2008 9:28 PM
    Saturday, August 30, 2008 10:07 PM
    Moderator
  •  cgwaters wrote:

    Hi, Lara. I filed a bug on Connect (ID 361010) and used the WHS Toolkit to collect and upload the CAB files. The bug report also includes the CAB Number that was provided by the WHS Toolkit.

     

    Please let me know if there is anything else that I can do to help resolve this issue. Thanks.

     

    Hi!

     

    I've found it in the database. I'm going out to get the CABs now and then we'll get this to the developers.

     

    Thanks!

    Lara

    Friday, August 8, 2008 4:39 PM
    Moderator
  •  kariya21 wrote:

    That's because they are not drive letters.  You need to provide the entire path.  So in your example, it would be "chkdsk c:\fs\g /r" (without the quotes).  It will ask you if you want to force a dismount.  You should select no.  Then it will ask you if you want the chkdsk to run the next time the server is rebooted.  You should select yes to that, then reboot the server.

    Thanks! I never would have guessed that.

     

    CHKDSK C: /r said that it would execute at the next system restart.

     

    CHKDSK C:\fs\G /r ran right away, without any dismount or reboot messages. After about 20 minutes, it reported the following:

    The type of the file system is NTFS.
    Volume label is DATA.

    CHKDSK is verifying files (stage 1 of 5)...
    27120 file records processed.
    File verification completed.
    0 large file records processed.
    0 bad file records processed.
    0 EA records processed.
    0 reparse records processed.
    CHKDSK is verifying indexes (stage 2 of 5)...
    109261 index entries processed.
    Index verification completed.
    5 unindexed files processed.
    CHKDSK is verifying security descriptors (stage 3 of 5)...
    27120 security descriptors processed.
    Security descriptor verification completed.
    2524 data files processed.
    CHKDSK is verifying file data (stage 4 of 5)...
    27104 files processed.
    File data verification completed.
    CHKDSK is verifying free space (stage 5 of 5)...
    84067273 free clusters processed.
    Free space verification is complete.

     976751968 KB total disk space.
     640346816 KB in 24514 files.
         13168 KB in 2526 indexes.
             0 KB in bad sectors.
        122892 KB in use by the system.
         65536 KB occupied by the log file.
     336269092 KB available on disk.

          4096 bytes in each allocation unit.
     244187992 total allocation units on disk.
      84067273 allocation units available on disk.

    Other than the five unindexed files being processed, the drive appears to be fine.

     

    CHKDSK C:\fs\H /r ran right away, without any dismount or reboot messages. After about 20 minutes, it reported the following:

    The type of the file system is NTFS.
    Volume label is DATA.

    CHKDSK is verifying files (stage 1 of 5)...
    29760 file records processed.
    File verification completed.
    0 large file records processed.
    0 bad file records processed.
    0 EA records processed.
    0 reparse records processed.
    CHKDSK is verifying indexes (stage 2 of 5)...
    119310 index entries processed.
    Index verification completed.
    5 unindexed files processed.
    CHKDSK is verifying security descriptors (stage 3 of 5)..
    29760 security descriptors processed.
    Security descriptor verification completed.
    2871 data files processed.
    CHKDSK is verifying file data (stage 4 of 5)...
    29744 files processed.
    File data verification completed.
    CHKDSK is verifying free space (stage 5 of 5)...
    83857884 free clusters processed.
    Free space verification is complete.

     976751968 KB total disk space.
     641180520 KB in 26771 files.
         14380 KB in 2873 indexes.
             0 KB in bad sectors.
        125532 KB in use by the system.
         65536 KB occupied by the log file.
     335431536 KB available on disk.

          4096 bytes in each allocation unit.
     244187992 total allocation units on disk.
      83857884 allocation units available on disk.

    Again, other than the five unindexed files being processed, the drive appears to be fine.

     

    CHKDSK C:\fs\I /r ran right away, without any dismount or reboot messages. This took many hours to run, but eventually reported the following:

    The type of the file system is NTFS.
    Volume label is DATA.

    CHKDSK is verifying files (stage 1 of 5)...
    55104 file records processed.
    File verification completed.
    1560 large file records processed.
    0 bad file records processed.
    0 EA records processed.
    0 reparse records processed.
    CHKDSK is verifying indexes (stage 2 of 5)...
    218741 index entries processed.
    Index verification completed.
    5 unindexed files processed.
    CHKDSK is verifying security descriptors (stage 3 of 5)...
    55104 security descriptors processed.
    Security descriptor verification completed.
    3052 data files processed.
    CHKDSK is verifying file data (stage 4 of 5)...
    18 percent complete. (20000 of 55088 files processed)
    Windows replaced bad clusters in file 23055
    of name \DE\folders\{00008~1\BA388C~1.DAT.
    Windows replaced bad clusters in file 23111
    of name \DE\folders\{00008~1\INDEX4~1.DAT.
    Windows replaced bad clusters in file 23971
    of name \DE\folders\{00008~1\DATA40~3.DAT.
    Windows replaced bad clusters in file 24118
    of name \DE\folders\{00008~1\DATA40~4.DAT.
    18 percent complete. (50000 of 55088 files processed)
    Windows replaced bad clusters in file 52230
    of name \DE\shares\Videos\Misc\21LAND~1.AVI.
    Windows replaced bad clusters in file 52233
    of name \DE\shares\Videos\Misc\23LAND~1.AVI.
    Windows replaced bad clusters in file 54713
    of name \DE\shares\Videos\Misc\25LAND~1.AVI.
    Windows replaced bad clusters in file 54836
    of name \DE\shares\Videos\Misc\15LAND~1.AVI.
    55088 files processed.
    File data verification completed.
    CHKDSK is verifying free space (stage 5 of 5)...
    9390102 free clusters processed.
    Free space verification is complete.
    Adding 700 bad clusters to the Bad Clusters File.
    Correcting errors in the master file table's (MFT) BITMAP attribute.
    Correcting errors in the Volume Bitmap.
    Windows has made corrections to the file system.

     976751968 KB total disk space.
     939012864 KB in 50393 files.
         24888 KB in 3054 indexes.
          2800 KB in bad sectors.
        151012 KB in use by the system.
         65536 KB occupied by the log file.
      37560404 KB available on disk.

          4096 bytes in each allocation unit.
     244187992 total allocation units on disk.
       9390101 allocation units available on disk.

    Ah, Drive I: appears to have been the problem! Again, five unindexed files were processed. Bad clusters were replaced in four \DE\folders\..\*.DAT files; I wonder if this is the reason the Backup Service wouldn't remain running? Bad clusters were also replaced in four \DE\shares\..\..\*.AVI files; these seem to correspond to the four files that were originally reported as being in conflict 'because of an I/O device error'. (BTW, the WHS Console no longer listed these four files as being in conflict; however, it did list many more files in conflict with a conflict message of 'Access is denied'. Could this perhaps be a consequence of the lengthy CHKDSK jobs?

     

    Next, I rebooted the server--causing the "CHKDSK C: /r" job to run. I couldn't see the results, but the server came back quickly and there were no errors in any of the event logs.

     

    Now that the drive(s) have been repaired and the server has been rebooted, the Backup Service is no longer crashing. The file conflct messages have gone away, too. I'll check on the integrity of the original four files that were in conflict. I'll also await the results of tonight's (and future) backups.

     

    Questions: 2800 KB in bad sectors on the I: drive isn't very much space, but should I be concerned about the integrity of the rest of the drive? All three 1 TB drives ( G:, H:, and I: ) are brand new; should I expect there to be no errors? When the drives were added to WHS, no errors were found; of course, my CHKDSK /R commands are perhaps the first time that these drives have ever been thoroughly scanned. I'm still within the return policy for the drives; should I return the I: drive? Thanks!

Monday, August 11, 2008 4:04 PM
  • Thanks for the additional information, Theo!

    FYI to All: The replacement 1 TB drive is up to 10% full.

    Client PC backups are proceeeding without a problem. Storage balancing is occurring periodically, as expected.

    I consider this thread to be answered and closed.
    • Marked as answer by cgwaters Tuesday, September 16, 2008 9:28 PM
    Tuesday, September 16, 2008 9:28 PM
  • All replies

    • The many chkdsk runs notwithstanding, the most likely reason for your error is a problem with one of your hard drives. You should run "chkdsk /r" on each or your drives.
      Wednesday, August 6, 2008 3:41 AM
      Moderator
    • I'm having the same exact issue.  4 healthy drives.  Backup service is not running.  I Can't even delete all my backups because the settings are not there in backup.  The Toolkit will not allow me to reset my database either.  I get some cryptic message when I try that.  And, when I try to do a repair in the console, it stalls and logs me out of it everytime.  MS dropped the ball on this one.  Oh, and I have power pack 1 by the way.  As of now, I have no way to reset my database so I'm stucked with gigs of data that cannot be backed up with my 2.5 TB home server.

      Wednesday, August 6, 2008 8:23 AM
    •  

      I have a friends WHS where it ran the backup service once after messing with it. Now with PP1 installed I go to do a repair on the backup database and the WHS console closes me out as well. Try installing the WHS Toolkit. I then got an error when it tried to reset the backup database but still didnt fix it. I can't even remove the computers using the console due to the backup service not running.
      Wednesday, August 6, 2008 2:39 PM
    • Not wanting to say these fixes are universal, but two people with the same problem did find fixes. Worth looking into.
      http://forum.wegotserved.co.uk/index.php?showtopic=2693

      Ben
      Wednesday, August 6, 2008 3:45 PM
    •  lix2k3 wrote:

      I'm having the same exact issue.  4 healthy drives.  Backup service is not running.  I Can't even delete all my backups because the settings are not there in backup.  The Toolkit will not allow me to reset my database either.  I get some cryptic message when I try that.  And, when I try to do a repair in the console, it stalls and logs me out of it everytime.  MS dropped the ball on this one.  Oh, and I have power pack 1 by the way.  As of now, I have no way to reset my database so I'm stucked with gigs of data that cannot be backed up with my 2.5 TB home server.

       

      Hello,

      Could you submit a bug on Connect for this issue? If possible, please use the toolkit to collect CAB files and if it’s not, please collect them from the following locations:

      XP machine:
      %SystemDrive%\Documents and Settings\All Users\Application Data\Microsoft\Windows Home Server\logs

       

      Vista machine:
      %SystemDrive%\ProgramData\Microsoft\Windows Home Server\logs

       

      Server logs:         
      %SystemDrive%\Documents and Settings\All Users\Application Data\Microsoft\Windows Home Server\logs

       

      Can you also attach a screenshot of the error you’re receiving when you attempt to reset the database?

       

      Thank you

      Lara Jones [MS]

      Windows Home Server Team

      Wednesday, August 6, 2008 4:43 PM
      Moderator
    •  skinner6695 wrote:

       

      I have a friends WHS where it ran the backup service once after messing with it. Now with PP1 installed I go to do a repair on the backup database and the WHS console closes me out as well. Try installing the WHS Toolkit. I then got an error when it tried to reset the backup database but still didnt fix it. I can't even remove the computers using the console due to the backup service not running.

       

      Hi Skinner6695,

       

      I asked lix2k3 to file a bug on Connect. Would it be possible for you to do the same thing?  As I mentioned above, please use the toolkit to collect CAB files. If for some reason this is not possible, please collect them manually from the locations below:

       

      XP machine:
      %SystemDrive%\Documents and Settings\All Users\Application Data\Microsoft\Windows Home Server\logs

      Vista machine:
      %SystemDrive%\ProgramData\Microsoft\Windows Home Server\logs

       

      Server logs:         
      %SystemDrive%\Documents and Settings\All Users\Application Data\Microsoft\Windows Home Server\logs

       

      Thank you

      Lara Jones [MS]

      Windows Home Server Team

      Wednesday, August 6, 2008 5:09 PM
      Moderator
    •  Ken Warren wrote:
      The many chkdsk runs notwithstanding, the most likely reason for your error is a problem with one of your hard drives. You should run "chkdsk /r" on each or your drives.

      Hey! I go away on business for one day and I find my thread to be hijacked!  Smile

       

      Seriously, though, thanks everyone for the comments.

       

      Ken, pardon my ignorance, but how do I run a CHKDSK /R command on the drives? From an RDP session on the WHS, the only drive letters are C: and D:. How do I check the individual drives?

      Thursday, August 7, 2008 8:46 PM
    •  Lara Jones [MS] wrote:

      ...file a bug on Connect....please use the toolkit to collect CAB files.

       

      Thank you

      Lara Jones [MS]

      Windows Home Server Team

      Hi, Lara. I filed a bug on Connect (ID 361010) and used the WHS Toolkit to collect and upload the CAB files. The bug report also includes the CAB Number that was provided by the WHS Toolkit.

       

      Please let me know if there is anything else that I can do to help resolve this issue. Thanks.

      Thursday, August 7, 2008 9:24 PM
    •  cgwaters wrote:

       Ken Warren wrote:
      The many chkdsk runs notwithstanding, the most likely reason for your error is a problem with one of your hard drives. You should run "chkdsk /r" on each or your drives.

      Hey! I go away on business for one day and I find my thread to be hijacked! 

       

      Seriously, though, thanks everyone for the comments.

       

      Ken, pardon my ignorance, but how do I run a CHKDSK /R command on the drives? From an RDP session on the WHS, the only drive letters are C: and D:. How do I check the individual drives?

       

      You can find the secondary drives in C:\fs.  Those are volume mount points.

      Friday, August 8, 2008 1:10 AM
      Moderator
    •  kariya21 wrote:
       cgwaters wrote:

       Ken Warren wrote:
      The many chkdsk runs notwithstanding, the most likely reason for your error is a problem with one of your hard drives. You should run "chkdsk /r" on each or your drives.

      Hey! I go away on business for one day and I find my thread to be hijacked! 

       

      Seriously, though, thanks everyone for the comments.

       

      Ken, pardon my ignorance, but how do I run a CHKDSK /R command on the drives? From an RDP session on the WHS, the only drive letters are C: and D:. How do I check the individual drives?

       

      You can find the secondary drives in C:\fs.  Those are volume mount points.

      Thanks. My C:\fs folder contains three JUNCTION entries: G, H, and I. It's still not clear to me, however, how to perform a CHKDSK on these drives.

       

      When I attempt to run "CHKDSK G:" (or H or I, with or without "/R") from a command prompt, "Cannot open volume for direct access" is returned.

       

      With the C: drive, I can at least run CHKDSK without any parameters (no errors were found, BTW). If I add the "/R" option, however, it says that the C: volume is in use (obviously) and that it can be scheduled to run upon the next reboot. Considering that this hardware is 'head-less', however, I'm not sure if that is how I should proceed--since I won't be able to monitor the results.

       

      What do you think? How can I perform an effective CHKDSK on all four drives?

      Friday, August 8, 2008 3:27 PM
    •  cgwaters wrote:

      Hi, Lara. I filed a bug on Connect (ID 361010) and used the WHS Toolkit to collect and upload the CAB files. The bug report also includes the CAB Number that was provided by the WHS Toolkit.

       

      Please let me know if there is anything else that I can do to help resolve this issue. Thanks.

       

      Hi!

       

      I've found it in the database. I'm going out to get the CABs now and then we'll get this to the developers.

       

      Thanks!

      Lara

      Friday, August 8, 2008 4:39 PM
      Moderator
    •  cgwaters wrote:
      Thanks. My C:\fs folder contains three JUNCTION entries: G, H, and I. It's still not clear to me, however, how to perform a CHKDSK on these drives.

       

      When I attempt to run "CHKDSK G:" (or H or I, with or without "/R") from a command prompt, "Cannot open volume for direct access" is returned.

       

      That's because they are not drive letters.  You need to provide the entire path.  So in your example, it would be "chkdsk c:\fs\g /r" (without the quotes).  It will ask you if you want to force a dismount.  You should select no.  Then it will ask you if you want the chkdsk to run the next time the server is rebooted.  You should select yes to that, then reboot the server.

       

       cgwaters wrote:
      With the C: drive, I can at least run CHKDSK without any parameters (no errors were found, BTW). If I add the "/R" option, however, it says that the C: volume is in use (obviously) and that it can be scheduled to run upon the next reboot. Considering that this hardware is 'head-less', however, I'm not sure if that is how I should proceed--since I won't be able to monitor the results.


      I would still run it on all of the drives, even if you can't see the results.  If it comes across any errors, it will fix them.

       

       cgwaters wrote:
      What do you think? How can I perform an effective CHKDSK on all four drives?

      Saturday, August 9, 2008 4:30 AM
      Moderator
    •  kariya21 wrote:

      That's because they are not drive letters.  You need to provide the entire path.  So in your example, it would be "chkdsk c:\fs\g /r" (without the quotes).  It will ask you if you want to force a dismount.  You should select no.  Then it will ask you if you want the chkdsk to run the next time the server is rebooted.  You should select yes to that, then reboot the server.

      Thanks! I never would have guessed that.

       

      CHKDSK C: /r said that it would execute at the next system restart.

       

      CHKDSK C:\fs\G /r ran right away, without any dismount or reboot messages. After about 20 minutes, it reported the following:

      The type of the file system is NTFS.
      Volume label is DATA.

      CHKDSK is verifying files (stage 1 of 5)...
      27120 file records processed.
      File verification completed.
      0 large file records processed.
      0 bad file records processed.
      0 EA records processed.
      0 reparse records processed.
      CHKDSK is verifying indexes (stage 2 of 5)...
      109261 index entries processed.
      Index verification completed.
      5 unindexed files processed.
      CHKDSK is verifying security descriptors (stage 3 of 5)...
      27120 security descriptors processed.
      Security descriptor verification completed.
      2524 data files processed.
      CHKDSK is verifying file data (stage 4 of 5)...
      27104 files processed.
      File data verification completed.
      CHKDSK is verifying free space (stage 5 of 5)...
      84067273 free clusters processed.
      Free space verification is complete.

       976751968 KB total disk space.
       640346816 KB in 24514 files.
           13168 KB in 2526 indexes.
               0 KB in bad sectors.
          122892 KB in use by the system.
           65536 KB occupied by the log file.
       336269092 KB available on disk.

            4096 bytes in each allocation unit.
       244187992 total allocation units on disk.
        84067273 allocation units available on disk.

      Other than the five unindexed files being processed, the drive appears to be fine.

       

      CHKDSK C:\fs\H /r ran right away, without any dismount or reboot messages. After about 20 minutes, it reported the following:

      The type of the file system is NTFS.
      Volume label is DATA.

      CHKDSK is verifying files (stage 1 of 5)...
      29760 file records processed.
      File verification completed.
      0 large file records processed.
      0 bad file records processed.
      0 EA records processed.
      0 reparse records processed.
      CHKDSK is verifying indexes (stage 2 of 5)...
      119310 index entries processed.
      Index verification completed.
      5 unindexed files processed.
      CHKDSK is verifying security descriptors (stage 3 of 5)..
      29760 security descriptors processed.
      Security descriptor verification completed.
      2871 data files processed.
      CHKDSK is verifying file data (stage 4 of 5)...
      29744 files processed.
      File data verification completed.
      CHKDSK is verifying free space (stage 5 of 5)...
      83857884 free clusters processed.
      Free space verification is complete.

       976751968 KB total disk space.
       641180520 KB in 26771 files.
           14380 KB in 2873 indexes.
               0 KB in bad sectors.
          125532 KB in use by the system.
           65536 KB occupied by the log file.
       335431536 KB available on disk.

            4096 bytes in each allocation unit.
       244187992 total allocation units on disk.
        83857884 allocation units available on disk.

      Again, other than the five unindexed files being processed, the drive appears to be fine.

       

      CHKDSK C:\fs\I /r ran right away, without any dismount or reboot messages. This took many hours to run, but eventually reported the following:

      The type of the file system is NTFS.
      Volume label is DATA.

      CHKDSK is verifying files (stage 1 of 5)...
      55104 file records processed.
      File verification completed.
      1560 large file records processed.
      0 bad file records processed.
      0 EA records processed.
      0 reparse records processed.
      CHKDSK is verifying indexes (stage 2 of 5)...
      218741 index entries processed.
      Index verification completed.
      5 unindexed files processed.
      CHKDSK is verifying security descriptors (stage 3 of 5)...
      55104 security descriptors processed.
      Security descriptor verification completed.
      3052 data files processed.
      CHKDSK is verifying file data (stage 4 of 5)...
      18 percent complete. (20000 of 55088 files processed)
      Windows replaced bad clusters in file 23055
      of name \DE\folders\{00008~1\BA388C~1.DAT.
      Windows replaced bad clusters in file 23111
      of name \DE\folders\{00008~1\INDEX4~1.DAT.
      Windows replaced bad clusters in file 23971
      of name \DE\folders\{00008~1\DATA40~3.DAT.
      Windows replaced bad clusters in file 24118
      of name \DE\folders\{00008~1\DATA40~4.DAT.
      18 percent complete. (50000 of 55088 files processed)
      Windows replaced bad clusters in file 52230
      of name \DE\shares\Videos\Misc\21LAND~1.AVI.
      Windows replaced bad clusters in file 52233
      of name \DE\shares\Videos\Misc\23LAND~1.AVI.
      Windows replaced bad clusters in file 54713
      of name \DE\shares\Videos\Misc\25LAND~1.AVI.
      Windows replaced bad clusters in file 54836
      of name \DE\shares\Videos\Misc\15LAND~1.AVI.
      55088 files processed.
      File data verification completed.
      CHKDSK is verifying free space (stage 5 of 5)...
      9390102 free clusters processed.
      Free space verification is complete.
      Adding 700 bad clusters to the Bad Clusters File.
      Correcting errors in the master file table's (MFT) BITMAP attribute.
      Correcting errors in the Volume Bitmap.
      Windows has made corrections to the file system.

       976751968 KB total disk space.
       939012864 KB in 50393 files.
           24888 KB in 3054 indexes.
            2800 KB in bad sectors.
          151012 KB in use by the system.
           65536 KB occupied by the log file.
        37560404 KB available on disk.

            4096 bytes in each allocation unit.
       244187992 total allocation units on disk.
         9390101 allocation units available on disk.

      Ah, Drive I: appears to have been the problem! Again, five unindexed files were processed. Bad clusters were replaced in four \DE\folders\..\*.DAT files; I wonder if this is the reason the Backup Service wouldn't remain running? Bad clusters were also replaced in four \DE\shares\..\..\*.AVI files; these seem to correspond to the four files that were originally reported as being in conflict 'because of an I/O device error'. (BTW, the WHS Console no longer listed these four files as being in conflict; however, it did list many more files in conflict with a conflict message of 'Access is denied'. Could this perhaps be a consequence of the lengthy CHKDSK jobs?

       

      Next, I rebooted the server--causing the "CHKDSK C: /r" job to run. I couldn't see the results, but the server came back quickly and there were no errors in any of the event logs.

       

      Now that the drive(s) have been repaired and the server has been rebooted, the Backup Service is no longer crashing. The file conflct messages have gone away, too. I'll check on the integrity of the original four files that were in conflict. I'll also await the results of tonight's (and future) backups.

       

      Questions: 2800 KB in bad sectors on the I: drive isn't very much space, but should I be concerned about the integrity of the rest of the drive? All three 1 TB drives ( G:, H:, and I: ) are brand new; should I expect there to be no errors? When the drives were added to WHS, no errors were found; of course, my CHKDSK /R commands are perhaps the first time that these drives have ever been thoroughly scanned. I'm still within the return policy for the drives; should I return the I: drive? Thanks!

    Monday, August 11, 2008 4:04 PM
  •  cgwaters wrote:
    Thanks! I never would have guessed that.

     

    <snipped chkdsk logs>

     

    Ah, Drive I: appears to have been the problem! Again, five unindexed files were processed. Bad clusters were replaced in four \DE\folders\..\*.DAT files; I wonder if this is the reason the Backup Service wouldn't remain running? Bad clusters were also replaced in four \DE\shares\..\..\*.AVI files; these seem to correspond to the four files that were originally reported as being in conflict 'because of an I/O device error'. (BTW, the WHS Console no longer listed these four files as being in conflict; however, it did list many more files in conflict with a conflict message of 'Access is denied'. Could this perhaps be a consequence of the lengthy CHKDSK jobs?

     

    Next, I rebooted the server--causing the "CHKDSK C: /r" job to run. I couldn't see the results, but the server came back quickly and there were no errors in any of the event logs.

     

    Now that the drive(s) have been repaired and the server has been rebooted, the Backup Service is no longer crashing. The file conflct messages have gone away, too. I'll check on the integrity of the original four files that were in conflict. I'll also await the results of tonight's (and future) backups.

     

    Questions: 2800 KB in bad sectors on the I: drive isn't very much space, but should I be concerned about the integrity of the rest of the drive?

     

    I would be.

     

     cgwaters wrote:
    All three 1 TB drives ( G:, H:, and I: ) are brand new; should I expect there to be no errors?

     

    Absolutely.

     

     cgwaters wrote:
    When the drives were added to WHS, no errors were found; of course, my CHKDSK /R commands are perhaps the first time that these drives have ever been thoroughly scanned. I'm still within the return policy for the drives; should I return the I: drive?

     

    Yes, yes, a thousand times yes. Smile

     

     cgwaters wrote:
    Thanks!

    Tuesday, August 12, 2008 1:05 AM
    Moderator
  • Thanks, again.

     

    OK, I have an RMA for the faulty drive. I need to use the WHS Console's Server Storage tab to remove that drive, right? All three drives appear as Healthy and with the same ID and capacity. How can I know for certain which of the three 1 TB drives to select for removal? Since the I: drive is the third drive in the alphabetical list of known drives ( G: , H:, and I: ), would the I: drive correspond to the third 1 TB drive in the Server Storage list? And once the drive is removed from WHS, how will I know which physical drive to remove from the chasis?

     

    While I await the replacement drive, I have a spare (!) 1 TB drive to install in the faulty drive's place. Short of installing the drive and waiting for it to fail, is there a recommended way to thoroughly test it in advance? Should I install the drive and then simply perform a CHKDSK on the path again (i.e., "chkdsk c:\fs\i /r")? If so, should I wait for storage balancing to complete?

    Tuesday, August 12, 2008 4:04 PM
  • Hi,

    If you kept a note of the drive reference numbers, the Drive Management Add-In will identify each drive to assist in removal. If you didn't, the easiest way is to power down the server, remove one drive and power back up. The server will complain about a missing drive and give you the drive info. Powering down again re-inserting the drive and powering up again, will clear the error messages. (It won't do any harm to your data).

    The disk manufacturer will make tools to check the drive, which in most cases, includes some form of surface checking. There is also HdTach which will do a drive read/write test.

     

    FYI, all drives, even when new, will have some faulty sectors. However, the manufacturer always includes some extra sectors not included in the official specs, to allow for situations like yours. However, to have so many on a nearly new drive, doesn't bode well for the longevity of it.

     

    Colin 

     

    Tuesday, August 12, 2008 4:57 PM
  •  ColinwH wrote:

    Hi,

    If you kept a note of the drive reference numbers, the Drive Management Add-In will identify each drive to assist in removal. If you didn't, the easiest way is to power down the server, remove one drive and power back up. The server will complain about a missing drive and give you the drive info. Powering down again re-inserting the drive and powering up again, will clear the error messages. (It won't do any harm to your data).

    The disk manufacturer will make tools to check the drive, which in most cases, includes some form of surface checking. There is also HdTach which will do a drive read/write test.

     

    FYI, all drives, even when new, will have some faulty sectors. However, the manufacturer always includes some extra sectors not included in the official specs, to allow for situations like yours. However, to have so many on a nearly new drive, doesn't bode well for the longevity of it.

     

    Colin 

     

    Thanks, Colin! I had the Drive Management Add-In on my old, home-built WHS, but I don't have it installed on my HP MediaSmart server with PP1. Is this add-in compatible with PP1?

     

    I didn't note the drive reference numbers when I installed the drives, but I could certainly power down the server and take note of them.

     

    But how do I know which drive translates to the one that CHKDSK C:\fs\I /r determined was in need of repair? The CHKDSK command didn't provide any identifiers.

     

    BTW, I own a copy of SpinRite--a robust drive checking tool. It runs as a bootable CD; since my WHS is 'head-less', I wouldn't be able to use it to check the new/replacement drive unless I somehow hooked up the drive to my desktop PC and ran SpinRite from there, instead. I believe the SpinRite folks recommending doing this periodically with all drives--old and new.

    Tuesday, August 12, 2008 7:26 PM
  • Hi,

    From all accounts, SpinRite has a very good reputation, so should be well worth running.

    There is a recent version of the Disk management Add-In which works with PP1, so it's worth upgrading.

    Identifying the individual drive(s) really is one of WHS's biggest bug-bears. There isn't any way, apart from pulling a drive, any drive, and noting which one the server tells you is missing - this is where the Management add-in pays for itself. I ended up doing this for a couple of pre-built servers before I decided to add a disk at at time when building, and identifying each as I went along.

     

    Colin

     

    Tuesday, August 12, 2008 7:39 PM
  • Thanks. I'll download and install the latest version of the Drive Management add-in.

     

    I'm still not sure how I'll know whether I pulled the faulty drive. The HP MediaSmart EX470 comes with four drive bays, stacked horizontally, with the bottom-most bay containing a 500 GB drive. The HP documentation states that each additional drive should be installed in the lowest empty tray. So in theory, my first 1 TB drive (which was installed in the tray right above the 500 GB drive) is my G: drive, my second 1 TB drive (which was installed right above the first 1 TB drive) is my H: drive, and my third 1 TB drive (which was installed right above the second 1 TB drive...and which CHKDSK repaired but which still should be replaced) is my I: drive.

     

    So it would seem that I want to pull the top-most drive. I guess I won't know for sure until I remove that drive, boot the server, and then examine the junction entries in the C:\FS directory. Hopefully, only the G: and H: drives will be listed....and hopefully they will still correspond to the original G: and H: junctions as well to the two 1 TB drives that CHKDSK said were fine.

     

    Of course, after that I should probably re-insert the physical drive, instruct WHS to remove it (perhaps with the Drive Management add-in tool's assistance to identify the drive), and then physically remove the drive again.

    Tuesday, August 12, 2008 7:58 PM
  • If for no other reason than to help other poor souls who stumble upon this thread, I'll continue to document my experience.  Smile

     

    I used the Disk Management add-in to document the serial numbers of all three 1 TB drives. Then I powered WHS down and removed the top-most physical 1 TB drive--hoping that it would correspond to the C:\FS\I device that CHKDSK repaired. (As a review: Since these are all new drives, it was suggested that this drive be returned; I already received an RMA for the drive.) Upon booting, the network was flagged as critical with the following message: "WDC WD10 EACS-00D6B0 SCSI Disk Device has failed. Ensure it is connected. If this problem continues, add a new hard drive and then remove the failed hard drive from your server storage using the console." There were also four "There are file conflicts" warnings--corresponding to four of the shares on the server. All four warnings listed 20 files--no more, no less; making me wonder if the interface only lists the first 20 files! For two of the shares, all 20 files had a conflict message of "The system cannot find the drive specified"; for the other two shares, 19 files had that same conflict message and one of the files had a conflict message of "A device attached to the system is not functioning". I was able to open the files with the former conflict message, but could not open the two files with the latter conflict message. When I attempted to copy these two files, I received "The device is not connected" errors; this concerns me, since the files should be available on one of the remaining two drives.

     

    All three junctions were still present in C:\FS. Using a command prompt on the WHS, I was able to change to the C:\FS\G and C:\FS\I directories; my attempts to change to the C:\FS\H directory, however, resulted in "The system cannot find the path specified." That suggested that the drive that I removed was *not* the I: drive, but was the H: drive! The WHS Console's Server Storage tab listed the *second* 1 TB drive as "Missing"--even though the drive that I removed was the third physical drive (as confirmed by matching the serial number on the drive case with the Disk Management add-in's serial number for the third physical drive).

     

    Next, I re-inserted the top-most physical drive and booted WHS. Then, I powered WHS down and removed the middle physical 1 TB drive. Upon booting, the same "SCSI Disk Device has failed" error appeared. In addition, the Backup Service crashed. Again, there were four "There are file conflicts" warnings with 20 files listed for each; however, all 80 files had the conflict message of "The system cannot find the drive specified".

     

    All three junctions were still present in C:\FS. I was able to change to the C:\FS\G and C:\FS\H directories, but my attempts to change to the C:\FS\I directory resulted in "The system cannot find the path specified." That suggested that the drive that I removed *was* the I: drive! It was logical for me to believe that this was the faulty drive, since the backup database appears to be on this drive and since the failure of the backup service was the problem that caused me to create this thread in the first place! The Server Storage tab listed the *first* 1 TB drive as "Missing"--even though the drive that I removed was the second physical drive (as confirmed by matching the serial number of the drive case with the Disk Management add-in's serial number for the second physical drive).


    Lastly, I re-inserted the middle physical drive and booted WHS. Then, I powered WHS down and removed the bottom physical 1 TB drive. Upon booting, the same "SCSI Disk Device has failed" error appeared. This time, there was only one "There are file conflicts" warning with 20 files listed; all 20 files had the conflict message of "The system cannot find the drive specified".

     

    All three junctions were still present in C:\FS. I was able to change to the C:\FS\H and C:\FS\I directories, but my attempts to change to the C:\FS\G directory resulted in "The system cannot find the path specified." That suggested that the drive that I removed was the G: drive! The Server Storage tab listed the *third* 1 TB drive as "Missing"--even though the drive that I removed was the first physical drive (as confirmed by matching the serial number of the drive case with the Disk Management add-in's serial number for the first physical drive).

     

    Whew! WIth the above out of the way, I re-inserted the bottom physical drive and booted WHS. Then I used WHS to remove the drive that corresponded to the middle physical 1 TB drive--the drive that appears to correspond to the I: drive. The removal process has been running for a few hours and looks as though it will run for at least another few hours. Once that task is complete, I'll return the drive to the dealer, power WHS down, install the replacement drive, boot WHS, wait for drive balancing to complete, and then perform CHKDSK /R commands on all of the drives again. I'll also watch for file conflict messages and wait to see if the Backup Service continues to run.
    Thursday, August 14, 2008 4:31 AM
  •  cgwaters wrote:

    If for no other reason than to help other poor souls who stumble upon this thread, I'll continue to document my experience. 

     

    I used the Disk Management add-in to document the serial numbers of all three 1 TB drives. Then I powered WHS down and removed the top-most physical 1 TB drive--hoping that it would correspond to the C:\FS\I device that CHKDSK repaired. (As a review: Since these are all new drives, it was suggested that this drive be returned; I already received an RMA for the drive.) Upon booting, the network was flagged as critical with the following message: "WDC WD10 EACS-00D6B0 SCSI Disk Device has failed. Ensure it is connected. If this problem continues, add a new hard drive and then remove the failed hard drive from your server storage using the console." There were also four "There are file conflicts" warnings--corresponding to four of the shares on the server. All four warnings listed 20 files--no more, no less; making me wonder if the interface only lists the first 20 files! For two of the shares, all 20 files had a conflict message of "The system cannot find the drive specified"; for the other two shares, 19 files had that same conflict message and one of the files had a conflict message of "A device attached to the system is not functioning". I was able to open the files with the former conflict message, but could not open the two files with the latter conflict message. When I attempted to copy these two files, I received "The device is not connected" errors; this concerns me, since the files should be available on one of the remaining two drives.

     

    All three junctions were still present in C:\FS. Using a command prompt on the WHS, I was able to change to the C:\FS\G and C:\FS\I directories; my attempts to change to the C:\FS\H directory, however, resulted in "The system cannot find the path specified." That suggested that the drive that I removed was *not* the I: drive, but was the H: drive! The WHS Console's Server Storage tab listed the *second* 1 TB drive as "Missing"--even though the drive that I removed was the third physical drive (as confirmed by matching the serial number on the drive case with the Disk Management add-in's serial number for the third physical drive).

     

    Next, I re-inserted the top-most physical drive and booted WHS. Then, I powered WHS down and removed the middle physical 1 TB drive. Upon booting, the same "SCSI Disk Device has failed" error appeared. In addition, the Backup Service crashed. Again, there were four "There are file conflicts" warnings with 20 files listed for each; however, all 80 files had the conflict message of "The system cannot find the drive specified".

     

    All three junctions were still present in C:\FS. I was able to change to the C:\FS\G and C:\FS\H directories, but my attempts to change to the C:\FS\I directory resulted in "The system cannot find the path specified." That suggested that the drive that I removed *was* the I: drive! It was logical for me to believe that this was the faulty drive, since the backup database appears to be on this drive and since the failure of the backup service was the problem that caused me to create this thread in the first place! The Server Storage tab listed the *first* 1 TB drive as "Missing"--even though the drive that I removed was the second physical drive (as confirmed by matching the serial number of the drive case with the Disk Management add-in's serial number for the second physical drive).


    Lastly, I re-inserted the middle physical drive and booted WHS. Then, I powered WHS down and removed the bottom physical 1 TB drive. Upon booting, the same "SCSI Disk Device has failed" error appeared. This time, there was only one "There are file conflicts" warning with 20 files listed; all 20 files had the conflict message of "The system cannot find the drive specified".

     

    All three junctions were still present in C:\FS. I was able to change to the C:\FS\H and C:\FS\I directories, but my attempts to change to the C:\FS\G directory resulted in "The system cannot find the path specified." That suggested that the drive that I removed was the G: drive! The Server Storage tab listed the *third* 1 TB drive as "Missing"--even though the drive that I removed was the first physical drive (as confirmed by matching the serial number of the drive case with the Disk Management add-in's serial number for the first physical drive).

     

    Whew! WIth the above out of the way, I re-inserted the bottom physical drive and booted WHS. Then I used WHS to remove the drive that corresponded to the middle physical 1 TB drive--the drive that appears to correspond to the I: drive. The removal process has been running for a few hours and looks as though it will run for at least another few hours. Once that task is complete, I'll return the drive to the dealer, power WHS down, install the replacement drive, boot WHS, wait for drive balancing to complete, and then perform CHKDSK /R commands on all of the drives again. I'll also watch for file conflict messages and wait to see if the Backup Service continues to run.

     

    And all of that is precisely why the Disk Management add-in is now (and will forever be) one of the very few add-ins I have on my server. Wink

    Thursday, August 14, 2008 4:38 AM
    Moderator
  • Agreed; however, I *did* see a few anomalies with the Disk Management add-in.

     

    When I removed the first drive (Disk 3), powered up WHS, and then went to the Disk Managment tab on the WHS Console, the entire WHS Console interface locked up and then crashed. It did not do this when I removed the other two drives, in turn.

     

    Also, no matter which drive I physically removed, the add-in always listed Disk 0, Disk 1, and Disk 2 in the Storage Pool section...and the removed disk in the Attention Required section. It wasn't until I used the WHS Console to actually remove the second disk that the add-in properly listed Disk 0, Disk 1, and Disk 3 in the Storage Pool section...and Disk 2 in the Attention Required section (with a status of "Not Added").

     

    Now that WHS has successfully removed the faulty drive, I'm going to install it on my desktop PC and let SpinRite have a look at it. I'll also have SpinRite wipe the data from the drive prior to my returning it to the supplier. I'll also have SpinRite examine my extra 1 TB drive before I install it in my WHS. That would seem to be better than installing the replacement drive only to learn that that drive is faulty, too.

    Thursday, August 14, 2008 5:17 PM
  • Glad you documented your progress.

    I would guess that it depends on how HP has wired the back-plane to the motherboard which would determine which drive is which.

    It might be worthwhile going to the Disk Management Add-In forum on We Got served, and let Terry know about the glitches.

     

     

    Colin 

     

    Thursday, August 14, 2008 5:28 PM
    Moderator
  • I couldn't get SpinRite to detect the drive; something to do with the BIOS's inability to correctly provide the necessary parameters for such a large drive (1 TB).

     

    I downloaded Western Digital's Data LifeGuard Diagnostics for Windows tool and am currently performing an extended test of the faulty drive. The test says that it will take upwards of three hours to complete--perhaps longer as it stumbles over the bad sectors.

     

    Prior to running the test, I used the WD LifeGuard tool to display the drive's S.M.A.R.T. statistics. I'm not exactly sure what I was looking at, but almost all of the attribute error counts seemed higher than the threshold amounts. Sounds like a bad drive to me! Of course, having said that, I wonder how my remaining 1 TB drives in my WHS would report? It will be interesting to see what the replacement drive reports.  

    Thursday, August 14, 2008 7:44 PM
  • Shows how little I know about S.M.A.R.T. statistics! According to the help file that accompanies the WD LifeGuard tool:

     

    Attribute Values range from 1 to 253 with 1 being worst case, 253 being best case, and 100 being nominal....An impending degrading or faulty condition is indicated when the calculated Attribute Value becomes less than or equal to its corresponding Attribute Threshold value.

     

    So the high attribute values I was seeing for the fautly drive were not (by itself) indicative of a problem.

     

    In any case, the faulty drive failed the "QUICK TEST". I ran the "EXTENDED TEST" but canceled it when it seemed to be stuck on one particular sector for more than two hours. By that point, the 'estimated time to completion' had risen to over one week.

     

    Next, I tested my spare 1 TB drive. It passed both the "QUICK TEST" and the "EXTENDED TEST", so I'm going to proceed to use it to replace the faulty drive in my WHS.

    Friday, August 15, 2008 1:22 PM
  • I installed the replacement 1 TB drive three days ago. The status of all four drives (the native 500 GB system drive and the three 1 TB drives, including the replacement drive) is "Healthy". Storage balancing has been occurring from time to time, most recently just a few minutes ago. Client PC backups are proceeding normally. There have been no new file conflict messages.

     

    The thing that's strange (to me, anyway) is that the original two 1 TB drives are 98% full, but the new drive is 0% full. So the replacement drive doesn't appear as though it's being used--even three days later! The 500 GB system drive is 70% full--which seems high to me. It would be interesting to see where the Client PC backups are being stored.

     

    When I originally removed the faulty 1 TB drive, the other two 1 TB drives went from about 50% full to about 97% full. But now that the replacement/empty 1 TB drive has been added to the mix, why isn't it being used? Free space is listed as 1.1 TB, so the replacement/empty drive is definitely being seen.

     

    With only 40 GB of drive space still available on the original two 1 TB drives (2% of 1 TB times two drives) and perhaps 150 GB of drive space still available on the system drive, something has to "give" soon!

    Monday, August 18, 2008 2:41 PM
  •  cgwaters wrote:
    I installed the replacement 1 TB drive three days ago. The status of all four drives (the native 500 GB system drive and the three 1 TB drives, including the replacement drive) is "Healthy". Storage balancing has been occurring from time to time, most recently just a few minutes ago. Client PC backups are proceeding normally. There have been no new file conflict messages.

     

    The thing that's strange (to me, anyway) is that the original two 1 TB drives are 98% full, but the new drive is 0% full. So the replacement drive doesn't appear as though it's being used--even three days later! The 500 GB system drive is 70% full--which seems high to me. It would be interesting to see where the Client PC backups are being stored.

     

    When I originally removed the faulty 1 TB drive, the other two 1 TB drives went from about 50% full to about 97% full. But now that the replacement/empty 1 TB drive has been added to the mix, why isn't it being used? Free space is listed as 1.1 TB, so the replacement/empty drive is definitely being seen.

     

    With only 40 GB of drive space still available on the original two 1 TB drives (2% of 1 TB times two drives) and perhaps 150 GB of drive space still available on the system drive, something has to "give" soon!

     

    That's normal.  The algorithm WHS uses is basically "use the drive with the least free space first."  You can read a more detailed explanation in the Technical Brief for Windows Home Server Drive Extender.

    Tuesday, August 19, 2008 4:11 AM
    Moderator
  • Thanks. Still no change in the percentage used for any of the drives--at least, not within the Disk Management add-in. Although the replacement/empty drive still shows 0% full, the add-in's Details button reveals that 4 GB is actually in use. So it appears that WHS is writing *something* to the drive.

    • Proposed as answer by Dan J B Saturday, January 8, 2011 6:43 AM
    Saturday, August 23, 2008 4:11 AM
  •  cgwaters wrote:

    Thanks. Still no change in the percentage used for any of the drives--at least, not within the Disk Management add-in. Although the replacement/empty drive still shows 0% full, the add-in's Details button reveals that 4 GB is actually in use. So it appears that WHS is writing *something* to the drive.

     

    As Kariya indecated in a previous post, your server is operating within its speciafications as of PP1.

    It is not likely WHS will move any data to the replacement/empty drive until you start adding new data to the storage pool or maybe change the duplication setting of one of the shares.

     

    Theo.

     

    PS - Your system drive has 'only' 150GB free (70% full, which also happens to be the free space reported on a share). This should not be a problem unless you

    1. Are running a Vista client PC
    2. Try to copy more then 150GB of data at ones to one of the WHS shares.

    The reason for this is that when copying files Vista will check the amount free space available on the target directory/share before copying files (and refuse the copy if not enough space is reported on the target). Just in case this 70% 'limitation' becomes a problem I have a work arround available that will force some data of the primairy drive.

     

    Saturday, August 23, 2008 9:43 PM
    Moderator
  • The replacement 1 TB drive shows 6% full; the other two 1 TB drives show 94% full and 96% full--so data is trickling from the original two 1 TB drives to the replacement 1 TB drive.

     

    Theo: Concerning your P.S.: I am running Vista on two of my client PCs. With my original, home-built WHS, I would frequently get 'not enough drive space' when copying data from my Vista PCs to that WHS. I haven't experienced that yet with my new WHS. What is causing the system drive to remain at 70% full? Is this a known issue that not even PP1 resolves?

    Saturday, August 30, 2008 7:08 PM
  • cgwaters,

     

    It's by design per PP1. Chris Gray has published an excellent article on the new data migration strategy of PP1 on his blog: A brief description of the balancing algorithms used for disk balancing in Home Servers PP1 Drive Extender

     

    During PP1 beta there was some 'discussion' (read this thread) on the why's and how's and if this could be an issue for the release of PP1. The conclusion was that there is no problem except for some special situations (like adding a disk when the system disk is full). Microsoft is aware of this problem and will probably address it at some time in the feature.

    For the meanwhile I have written a little tool that enables you to work around the problem when it hits you. I named it LZreallocator (you can download it from my Home Server here).

    At this time the download link was hit over 100+ times, so apparently some people have used it. Until today I have had nog negative feedback at all so I assume it is doing what it was designed for without problems.

     

    A I mentioned in my earlier post, in your case I do not think you need the tool (although you could use it to free up some space on the system disk) as the 30% free space on your system disk should be enough for normal circumstances.

     

    Theo.

    • Marked as answer by cgwaters Tuesday, September 16, 2008 9:28 PM
    Saturday, August 30, 2008 10:07 PM
    Moderator
  • Thanks for the additional information, Theo!

    FYI to All: The replacement 1 TB drive is up to 10% full.

    Client PC backups are proceeeding without a problem. Storage balancing is occurring periodically, as expected.

    I consider this thread to be answered and closed.
    • Marked as answer by cgwaters Tuesday, September 16, 2008 9:28 PM
    Tuesday, September 16, 2008 9:28 PM
  • Great,
    Thanks for sharing this!
    No home server like Home Server
    Wednesday, September 17, 2008 5:56 PM
    Moderator