locked
Preferred method to rebuild data after system disk replacement RRS feed

  • Question

  • My server is humming along 24/7 without any major glitches since beta now. I feel it is time to do some preventive maintenance and replace the system drive which is a vanilla desktop version with something more reliable in the long run.

    I've read through the FAQ regarding that topic and there seem to be generally two possibilities:
    • replace drive and do a server reinstallation which will rebuild all the thombstones
    • disconnect all drives, replace system drive, do a reinstall, add a first empty drive for storage and then reconnect the drives one by one (not added to the pool) and copy back the data manually as decribed in "How To: Recover data after Server Failure"
    Obviously the preferred method should be the first one. But the perspective to be waiting for days until the thombstones of my ~6TB and gazillions of files are rebuilt without any real good feedback except a more or less moving progress bar is not one I am looking forward to.
    For me it seems more effective to actively copy the data back to the shares as described in the second option and actually have control of the process, maybe even decide what to copy over first and be able to use the server in the meantime.

    So my question really is if there are any drawbacks in the second option except the actual manual process and some planning that has to be done...

    Thanks for your thoughts on this!
    Thursday, February 4, 2010 1:51 PM

Answers

  • The second method is a manual version of the first. It will only be faster than the first if you have a gigantic backup database, because the first method will (usually) preserve that, while the second method won't. Otherwise, the additional time required to manage your drives and data will probably dwarf the automated rebuilding of the system disk.

    There's a third option: you can clone your system drive.

    Of the three options, server reinstallation/recovery is the supported method. The second method isn't supported, is slow, and after you've done it once you will never want to do it again. The third is relatively quick, though it's probably the riskiest of the three options (and obviously is also not supported). However, there's no need to replace your system drive if it's not having issues, so leave well enough alone for now. :)

    I'm not on the WHS team, I just post a lot. :)
    • Marked as answer by jdifool Thursday, February 4, 2010 3:55 PM
    Thursday, February 4, 2010 3:23 PM
    Moderator

All replies

  • The second method is a manual version of the first. It will only be faster than the first if you have a gigantic backup database, because the first method will (usually) preserve that, while the second method won't. Otherwise, the additional time required to manage your drives and data will probably dwarf the automated rebuilding of the system disk.

    There's a third option: you can clone your system drive.

    Of the three options, server reinstallation/recovery is the supported method. The second method isn't supported, is slow, and after you've done it once you will never want to do it again. The third is relatively quick, though it's probably the riskiest of the three options (and obviously is also not supported). However, there's no need to replace your system drive if it's not having issues, so leave well enough alone for now. :)

    I'm not on the WHS team, I just post a lot. :)
    • Marked as answer by jdifool Thursday, February 4, 2010 3:55 PM
    Thursday, February 4, 2010 3:23 PM
    Moderator
  • Wow, you're fast, thanks...

    The cloning option looks more like the manual to defuse an alien dark matter bomb, so I'll skip.

    Are there any rules of thumb concerning the duration of the rebuild depending on storage size or number of files?
    Thursday, February 4, 2010 3:55 PM
  • Rules of thumb: Terabytes can take days. Which you already knew. :) Consider what it needs to do: go through every file on every disk in the storage pool, making sure that each file in a folder that's duplicated is on two disks and is identical, recreate reparse points on the system drive, etc. 

    If you have a home-built server, and you're using additional storage controllers or your motherboard needs drivers loaded for the onboard storage controllers, I strongly recommend trying out the server recovery scenario before your server suffers a drive or other failure and you really need it to work. This is because of the possibility of problems finding drivers that can be used, loading them at the correct time(s), etc. I usually recommend you try it without a large data load, but with several drives connected to your various controllers and included in the storage pool, so you can get the full experience.

    I'm not on the WHS team, I just post a lot. :)
    Thursday, February 4, 2010 4:50 PM
    Moderator
  • If you do opt for the manual copy, get RichCopy from Technet. It supports multiple concurrent copies and is especially useful for USB and eSata attached drives. The manual option takes longer because you have to do the copy from every drive that was in your pool, there were 2 copies of the data. Using RichCopy means you only copy the data once,

    The problem I had was that adding a blank drive did not offer me the Recover Data option. I had to do a 'fresh install', then on the second reload I got the option to recover my existing data. I believe this is an error in the process that MS should fix, I can't imagine the average person dealing too well with this situation.

    Gerrit
    Friday, February 5, 2010 4:14 AM
  • For me the major issue is that the server will not be available for several days in case of a system drive issue and that I will obviously not be able to choose the time of this non-availability. Also I have experimented a lot with the setup while the server slowly evolved into the 6TB stage. So there is a lot of clutter in the system which actually would justify a reinstall by itself.

    So now I have come up with this:
    • buy server grade hard disk as the new system drive
    • wait for wife and daughter to be gone over the weekend
    • copy the crucial folders to an external hard-drive (those are the ones that I need to be available again as soon as possible, shouldn't be more than 1TB)
    • detach all drives (4 internal SATA, 6 external USB)
    • install new system drive (as drive 0)
    • install clean WHS
    • recreate shares, users and client connections
    • add one storage drive to the pool to have folder duplication available
    • copy the crucial data from the external drive to the corresponding shares, from here on I am fully operational again and it shouldn't have taken more than a day
    • as I have time and motivation attach one drive after the other back to the server (non pooled) copy the data from the hidden folders to the shares and reintegrate the drive into the pool. I do not backup any clients on my WHS so I do not have to worry about the backup database.
    Advantages
    • minimized downtime
    • ability to schedule the whole ordeal
    • I am actively in control of the progress
    • if for whatever reason the clean install doesn't work I can drop in the old system drive and pretend nothing ever happened
    Disadvantages
    • not the supported method ;-)
    • disk jugglery
    I might actually do this within the next couple of weeks unless someone can post a killer argument against the process.
    Will post back either a happy or a broken man ...
    Friday, February 5, 2010 12:07 PM
  • Very clear and valid approach. This is essentially how I rebuilt by 5TB system.

    Turning off duplication while adding all that data back in would also help as Demigrator won't be running in parallel.
    When you install, ensure that all updates are installed before starting the data reload.

    Gerrit
    Friday, February 5, 2010 1:13 PM
  • Gerrit makes a valid point, that the added overhead of duplication will slow things down. I still think that at the end of the process, you're going to swear "never again" until you're blue in the face, because you have to do the work, rather than letting Windows Home Server handle it for you. :)
    I'm not on the WHS team, I just post a lot. :)
    Friday, February 5, 2010 3:58 PM
    Moderator