locked
WHS Restore CD Questions RRS feed

  • Question

  • I'm a few weeks into my WHS project and after getting comfortable with WHS backup, getting remote access (via certificate-based SSH) working, and automating various client PC maintenance tasks with server-side scripts, my attention is now focused on understanding and working with the restore mechanism. File-based mounting and recovery works fine, so I'm now on to bare-metal restores, but I have a few questions. Keep in mind that my background in restoring PC images has been with image-based methods like Acronis True Image, which are capable of doing a bare-metal restore to a blank, unformatted hard disk. The WHS restore method seems to be a file-based restoration that requires an existing, formatted partition as a target, correct? Here are a few questions:

    1. When booted to the PE-based restore CD, I don't see a way to get to a command prompt. Is there a way?

    2. I see that Windows Disk Management console is available in the restore environment. Which version of Disk Management is used in the restore environment; Vista or XP?

    3. If you use the Disk Management console to create partitions are they created with the newer Vista/Win7 offset of 2048-sectors, or with the older XP offset of 63-sectors?

    4. If the Disk Management console is the Vista version, will it work with 63-sector offset partitions that were created by XP or other partitioning software?

    I will of course experiment with this, but if anyone knows the answers or where to find them you could save me a lot of time and trouble.

    So far, I've had no problems booting the restore environment on various PCs. I've copied the ISO image file to a USB flash drive and boot the ISO directly with Grub4Dos, and it loads faster than using a CD, it finds the correct drivers for the host PC, and it finds the server and the restoration database on the network. Now it is time to do some test restores.
    Friday, August 7, 2009 9:38 PM

Answers

  • After a few hours of experimenting, I think I can answer these questions for the benefit of anyone who comes across this thread. The WHS restore mechanism is cluster-based. I confirmed this by backing up a partition with 16k cluster size and restoring to a partition that was formatted with 4k clusters. After restoration, the cluster size is again 16k.

    1. I couldn't find any way to get to a command prompt, so if one needs to do anything with chkdsk , bcdedit , bootsect , bootrec , or other low-level tools then you need to do this from something other than the WHS restore environment.

    2. Disk Management is from build 6000, so it's from Vista.

    3. Partitions are created with the Vista offset of 2048 sectors. All of the features of Vista Disk Management are present, including the ability to grow or shrink partitions. Along with this are all of the limitations of Vista Disk Management, like the inability to move partitions and the fixed algorithm that will not create a logical partition until after you have created three primary partitions. If advanced partition operations are required, one needs third-party partitioning software.

    4. It is probably best to avoid mixing partition tools that use different rules for creating partitions. If restoring to a disk on an XP machine that has 63-sector partition offsets, I would not use Vista Disk Management on the WHS recovery CD. It's safer to use the older partition tools like XP disk management or third-party partition tools that use the 63-sector offset standard. Of course if you are just restoring over top of an existing partition on an XP machine then this does not apply.

    Some further observations:

    A) Restoration was fast at 2.7 GB/min on my hardware.
    B) I was unable to restore an existing backup to a partition that is smaller than the source partition, even if the used space on the partition was adequate. For example if you back up a 50 GB partition that has 10 GB of used space then you cannot restore this backup to a partition that is smaller than 50 GB, not even to a 49 GB partition. This is an annoying limitation not present in most commercial imaging software.** Edited 9/5/2009 to correct ** Further testing has shown this to not be true. I'm not sure what I did wrong in the original test, but in today's tests I was able to restore to a smaller partition provided that the end result was a partition with 15% free space or more.
    C) All in all, the restoration process is pretty decent for restoring to existing partitions. It lacks flexibility, so better keep a copy of Acronis True Image around for doing anything beyond just restoring over top of an existing partition.
    • Marked as answer by Mark Wharton Saturday, August 8, 2009 8:25 PM
    • Edited by Mark Wharton Saturday, September 5, 2009 7:05 PM To correct further observation B)
    Saturday, August 8, 2009 8:24 PM

All replies

  • After a few hours of experimenting, I think I can answer these questions for the benefit of anyone who comes across this thread. The WHS restore mechanism is cluster-based. I confirmed this by backing up a partition with 16k cluster size and restoring to a partition that was formatted with 4k clusters. After restoration, the cluster size is again 16k.

    1. I couldn't find any way to get to a command prompt, so if one needs to do anything with chkdsk , bcdedit , bootsect , bootrec , or other low-level tools then you need to do this from something other than the WHS restore environment.

    2. Disk Management is from build 6000, so it's from Vista.

    3. Partitions are created with the Vista offset of 2048 sectors. All of the features of Vista Disk Management are present, including the ability to grow or shrink partitions. Along with this are all of the limitations of Vista Disk Management, like the inability to move partitions and the fixed algorithm that will not create a logical partition until after you have created three primary partitions. If advanced partition operations are required, one needs third-party partitioning software.

    4. It is probably best to avoid mixing partition tools that use different rules for creating partitions. If restoring to a disk on an XP machine that has 63-sector partition offsets, I would not use Vista Disk Management on the WHS recovery CD. It's safer to use the older partition tools like XP disk management or third-party partition tools that use the 63-sector offset standard. Of course if you are just restoring over top of an existing partition on an XP machine then this does not apply.

    Some further observations:

    A) Restoration was fast at 2.7 GB/min on my hardware.
    B) I was unable to restore an existing backup to a partition that is smaller than the source partition, even if the used space on the partition was adequate. For example if you back up a 50 GB partition that has 10 GB of used space then you cannot restore this backup to a partition that is smaller than 50 GB, not even to a 49 GB partition. This is an annoying limitation not present in most commercial imaging software.** Edited 9/5/2009 to correct ** Further testing has shown this to not be true. I'm not sure what I did wrong in the original test, but in today's tests I was able to restore to a smaller partition provided that the end result was a partition with 15% free space or more.
    C) All in all, the restoration process is pretty decent for restoring to existing partitions. It lacks flexibility, so better keep a copy of Acronis True Image around for doing anything beyond just restoring over top of an existing partition.
    • Marked as answer by Mark Wharton Saturday, August 8, 2009 8:25 PM
    • Edited by Mark Wharton Saturday, September 5, 2009 7:05 PM To correct further observation B)
    Saturday, August 8, 2009 8:24 PM
  • C) All in all, the restoration process is pretty decent for restoring to existing partitions. It lacks flexibility, so better keep a copy of Acronis True Image around for doing anything beyond just restoring over top of an existing partition.

    Thanks for sharing this Mark!
    Just one caution on using 3th party tool like Acronis True Image, Ghost and a like: I would not recommended using such tools for general use as there have been reported issues in the past with WHS backups.

    - Theo.


    No home server like Home Server
    Thursday, August 13, 2009 10:31 AM
    Moderator
  • Just one caution on using 3th party tool like Acronis True Image, Ghost and a like: I would not recommended using such tools for general use as there have been reported issues in the past with WHS backups.

    - Theo.
    Theo:

    I have not run into any yet. My tests were done by using both the WHS restore mechanism and Acronis True Image (ATI) to restore the same test PC. Both solutions restored the PC properly and I've had no issues since. Additionally, the other PCs on the network that are being backed up by WHS have all been restored with ATI at one time or another in the past, and WHS backups are running flawlessly on them. I've researched some of your prior posts about ATI but couldn't find anything specific about issues that it would cause with WHS backups, but I'd be very interested knowing more.

    I have more faith in ATI since I've used it on a lot of different hardware for the past 5 years and have a fairly deep understanding of its strengths and weaknesses, but I'm gaining confidence in the WHS backup mechanism the more that I work with it. My approach at the moment is to let WHS do its thing automatically because that's its core strength. The backup database with automatic daily incremental backups and the de-duplication feature result in the most efficient and compact backup set that I've ever seen with any backup solution. The concerns that I have with it are related to reliability and lack of redundancy, so second and third-level backups are important to me.

    My second layer of backup then is to save a monthly ATI image of each PC to a share on the WHS. This is also automated so I don't have to remember to do it. The final layer of reduncancy is a manual copy one of the ATI images to an external USB disk quarterly, and to store the disk offsite.
    Thursday, August 13, 2009 12:57 PM
  • B) I was unable to restore an existing backup to a partition that is smaller than the source partition, even if the used space on the partition was adequate. For example if you back up a 50 GB partition that has 10 GB of used space then you cannot restore this backup to a partition that is smaller than 50 GB, not even to a 49 GB partition. This is an annoying limitation not present in most commercial imaging software.

    what ?
    my XP pc is on a single HDD of 250GB with no extra partitions, i have only used 50GB of system files. This means that in order to restore my pc in case of a HDD failure i must have a new HDD that its 250GB minimum ????

    Thursday, August 13, 2009 1:14 PM
  • The assumption is that you will be replacing your hard drive with a similar or better one if it fails. Why wouldn't you?
    I'm not on the WHS team, I just post a lot. :)
    Thursday, August 13, 2009 4:03 PM
    Moderator
  • not really.
    This would be the case if your HDD was smaller but 250GB or 500GB that PCs now have its too much for my needs since i only need the system files so yes if my HDD fails i would first try to find a really cheap one even below 100GB since thats what i need only...You can see the problem here...if i had started with 80GB of HDD then there is no problem but now that someone starts with HDD of 250 or 500GB this is a potential problem...

    But i understand your argument and maybe i'm overreacting on this
    Thursday, August 13, 2009 4:27 PM
  • This seems to be an unwarranted assumption on the part of the designers. Let's say that, in the preceeding example, the 250 GB disk fails and I do replace it with another 250 GB disk. But I wise up and decide that I should have kept the operating system and my user files on separate partitions, so I want to restore the OS to, say, a 100 GB partition and leave the rest of the disk free for creation of a user data partition. WHS doesn't appear to allow that. Other imaging software does. With ATI, for example, you can alter the size of the partition dynamically when you restore it, making the restored partition larger or smaller than the original partition size.
    Thursday, August 13, 2009 4:45 PM
  • Mark, if you want to resize partitions, there are tools that are designed for that purpose, e.g. Acronis Disk Director. Windows Home Server is not one of them.

    Windows Home Server backup and restore is intended to make it easy to restore a computer to it's "last good" state after a hard drive failure. When you do a "bare metal" restore it will need a large enough partition to hold the disk that was originally backed up. This is in keeping with the "keep it simple" design philosophy (which a lot of people here in the forums seem to have trouble with).

    Windows Home Server isn't designed to replace Acronis True Image or Acronis Disk Director for someone who's comfortable with the latter tools. It's designed to perform the essential function of ATI for someone who can't figure ATI itself out, or who tihnks it's too complicated.




    I'm not on the WHS team, I just post a lot. :)
    Thursday, August 13, 2009 6:21 PM
    Moderator
  • Windows Home Server isn't designed to replace Acronis True Image or Acronis Disk Director for someone who's comfortable with the latter tools. It's designed to perform the essential function of ATI for someone who can't figure ATI itself out, or who tihnks it's too complicated..
    I completely understand, Ken. I wasn't arguing that WHS should allow dynamic resizing of partitions or that it should replace imaging or partitioning software.

    When you do a "bare metal" restore it will need a large enough partition to hold the disk that was originally backed up.
    The statement quoted above is at the heart of the issue.

    A "bare metal" restore should only need a target partition large enough to hold the used space in the partition that was originally backed up. Allowing this does nothing to violate the "keep it simple" design philosophy. If a backup of a 250 GB partition would fit in a 20 GB destination partition, then this should be allowed. The restoration routine already lets you restore to a larger target partition. IMHO it should also allow restoration to a smaller target partition, provided that it will fit.
    Thursday, August 13, 2009 7:31 PM
  • A "bare metal" restore should only need a target partition large enough to hold the used space in the partition that was originally backed up. Allowing this does nothing to violate the "keep it simple" design philosophy. If a backup of a 250 GB partition would fit in a 20 GB destination partition, then this should be allowed.

    Hi Mark,

    I agree with you on this if (?) the above statement is true. That said I beleave that if there was a "simple" way to allow current WHS to restore to a smaller partition, the WHS Team would have implemented this or will do so in the near future ;-)

    BTW: If I had a choice for a simple (but somewhat limitted) restoring implementation or a more complex (read: more difficult to garantee and maintain the stability of the code) implementation, for WHS I would choose the first.

    - Theo.
    No home server like Home Server
    Thursday, August 13, 2009 8:08 PM
    Moderator
  • I have not run into any yet. My tests were done by using both the WHS restore mechanism and Acronis True Image (ATI) to restore the same test PC. [....

    Thanks Mark! This is good to know. May I ask what version of ATI have you been using?

    -Theo.
    No home server like Home Server
    Thursday, August 13, 2009 8:29 PM
    Moderator
  • ... May I ask what version of ATI have you been using?
    The gold standard, Version 10 build 4942. I believe it was the high point in this product's evolution, and it's been downhill ever since.
    Thursday, August 13, 2009 8:35 PM
  • ...if my HDD fails i would first try to find a really cheap one even below 100GB since thats what i need only...

    May be. But the way the costs, specs and size of harddisks have developing in the past years, I do not think replacing a new disk with one of a smaller size then the original does seems the best choice (generally speeking)?

    Personally If WHS would allow me to restore to a smaller partition I would only use this as a "tool" to resize the original partition. But WHS was not designed for this. Unfortunally ;-)

    - Theo.
    No home server like Home Server
    Thursday, August 13, 2009 8:40 PM
    Moderator
  • ...B) I was unable to restore an existing backup to a partition that is smaller than the source partition, even if the used space on the partition was adequate. For example if you back up a 50 GB partition that has 10 GB of used space then you cannot restore this backup to a partition that is smaller than 50 GB, not even to a 49 GB partition. This is an annoying limitation not present in most commercial imaging software.


    I wanted to test the system restore feature of WHS so I made a server backup of a fresh XP Home SP3 installation on a 75GB partiton.

    Using the 'Home Computer Restore CD', I resized the 75GB partiton down to 65GB, hit 'Next' and watched as it finished the retore without a hitch. I then booted to the desktop and while I didn't spend a lot of time testing this and that, the system seemed as responsive as any fresh install would.

    So, why did that work? I have to tell you, I was very surprised since I'm aware that this is generally reported as something that cannot be done, or should not be done be because it could cause untold problems down the road.

    What gives?

    Saturday, August 22, 2009 6:35 PM
  • I would be very interested in knowing why that worked. I couldn't get the restore CD to allow selection of a destination partition smaller than the size of the source partition, but then again I only tested on one machine.

    From the description of your test, the target partition was the same as the source partition except that you resized the target smaller before restoring. If you resized from the right, the starting sector did not change and thus the target partition would have the same GUID as the source partition. Perhaps that's something that the restore software is looking at -- if it sees that you are attempting a restore to a partition with the same GUID then perhaps it assumes that it is the same identical partition.

    Just a guess.

    In my test I first deleted all of the partitions and then rearranged things before attempting a restore. The target partition was not in the same location on the disk after rearrangement, so it would not have had the same GUID as the source partition.
    Sunday, August 23, 2009 3:45 AM
  • I see what you're saying. You had done the resizing in a manner different from what I had done.


    What I actually did was to use Disk Management to Shrink the partition from 75GB to 65GB, during the beginning stages of the restore process using the 'Home Computer Restore CD'.

    The shrunken partition needed no formatting, nor did was it necessary to mark it as "Active" since it already was. In other words, I did nothing to the partition, except shrink it. FYI, I do remember that the end of the partition, or 'right' as you called it, was the section shrunken.

    As to the idea about the GUID, I'd be interested to know if it was part of the problem you experienced, and if so, would that mean that 'shrinking' does not change a GUID. Also, if GUID is at the heart of this, are there any tools out there for duplicating a GUID?

    *But here's the big question. Since I was able to do that, what are the chances of some kind of problem occurring down the road? As I said, it went off without a hitch and things seems normal when I booted to desktop. So I'm left wondering, this seems ok to do, but is it really?
    Sunday, August 23, 2009 11:14 AM
  • antialex01:

    I'm probably using the wrong terminology to describe the way that Windows identifies partitions. In the registry key HKLM\System\MountedDevices there is a list of drive letter reservations for known partitions. Each drive letter is paired with a binary identifier which is formed by concatenating the DiskID (found in sector 0) with the starting sector of the partition. I'm not sure what this identifier is called, but probably not a GUID.

    Yes, if you used Disk Management on the restore CD to shrink the partition then it would have been shrunk "from the right", so the ending sector was modified but the starting sector remained the same. If the starting sector was not changed then the ID of the partition in the registry would not have changed either.

    Remember that this is all just a wild guess - it may not have anything to do with why you were able to restore to a smaller partition.

    I can't answer your "big question" except to speculate that you will be fine. You could run chkdsk on the partition to see if Windows thinks that there is anything wrong, but I doubt that there is.

    Right before I install Windows 7 on my main desktop PC I will experiment with this further to see if I can duplicate your results.
    Sunday, August 23, 2009 12:05 PM
  • Thanks for that clarification on hard drive ID's.  And good point about running chkdsk.  I meant to, then got distracted. 

    I've since changed the partition back to its original size and ran restore once more, since I wasn't confident that there'd be no future problems. But now that we've hashed this over a bit, I'm going to try that same resizing experiment on an older laptop, just to see how it holds up over time. And this time, I'll run chkdsk right off.

    *fwiw - My WHS is a frankenbuild ( Athlon 2700+ / 1G RAM / 80GB + 250GB pata hard drives / gigabit LAN ) with a 120-day evaluation copy of WHS I've gotten directly from MS.  So far, I have to say that I really like WHS's backup/restore solution.  Very straightforward and simple.  I'm in the process of determining whether I miss out on anything by not buying a pre-packaged solution such as an HP MediaSmart server.  My main concern with an HP solution is a question of performance, but the much more lightweight rig I'm using now seems to be putting that to rest.
    Sunday, August 23, 2009 1:28 PM
  • @Mark Wharton

    I did another backup test, and was once again able to successfully perform a complete restore using a WHS backup to a partition smaller than the one backed up.  This time, I used an Acer laptop configured as follows:

    C: = 37.4GB XP Professional
    D: = 37.4GB Windows 7 RC1

    XP is the original installation of this dual boot system, with Windows 7 added a little over a month ago.

    What I did:   First off, I backed up only the Windows 7 installation located on drive D:\.  I then booted with the 'Home Computer Restore CD', went into Disk Management, and shrank the same D:\ partition by 5GB down to 32.4GB.  I then stepped through the rest of the process and initiated the restore.  After 55 minutes or so, it was done.  I rebooted, got a prompt to insert my Windows installation CD in order to repair some boot files, and after another couple minutes and a reboot, I was looking at my desktop.  Again, as in the previous test, everything looked fine.  Chkdsk came up clean. Dual boot menu still appears and works as before.

    Once again, I am impressed with WHS's flexible backup/restore solution.  This is looking very good to me.

    In the past, I've used simple imaging solutions such as 'Western Digital Data Lifeguard'.  Then I found Runtime.org's 'DriveImage XML', which was great because it could compress images.  While neither of these solutions ever failed me, they could never restore to a partition smaller than the original.  WHS restore apparently can.

    *As an aside, since DriveImage XML supports Server 2003, I think I may have found a backup solution for WHS.

    Friday, August 28, 2009 12:32 AM
  • antialex01:

    Was your original disk partitioning done by XP and then you installed Windows 7 to the D partition? If so, that would explain the need for the boot repair. If D: was originally created by WinXP Disk Management then it would have had 63-sector offset (the older, established partitioning standard). When you resized the partition with the Home Computer Restore CD, the Vista Disk Manager was used, so it probably realigned the partition to the Vista/Win 7 standard offset of 2048 sectors. Moving a partition's starting sector invalidates the BCD pointers and requires a boot repair. Normally, if the partition was originally created by Vista or Windows 7 and you resized it with Vista Disk Management console then it should not have been necessary to do any boot repair.

    Thanks for posting your results; they are encouraging. I am a couple of weeks away from being able to experiment on my main desktop PC, so I will repeat my original test and try to duplicate your results.

    *As an aside, since DriveImage XML supports Server 2003, I think I may have found a backup solution for WHS.
    I'll let Ken Warren or one of the regulars caution you against trying this. Even though DriveImage XML may support Server 2003, the usual advice on here is to avoid using imaging software on WHS because of the Drive Extender (DE) technology and the way that the server handles additional disks. I suspect that imaging may work on a single-disk system but not if you have multiple disks.
    Friday, August 28, 2009 1:44 AM
  • @Mark Wharton

    You are correct about the original disk partitioning being done in XP, then modified with Home Computer Restore CD.  Interesting info.  I'm just glad a 2 minute repair easily solved it.  I suppose I could repeat the experiment, shrinking the partition another 5 GB just to see what happens.


    --- edited 5:28 am 8-28-09 --->

    *After thinking about this, I think I understand your caution regarding DE technology thwarting any imaging attempt. DriveImage XML would have no idea of how to reapply an image to a set of hard drives acting as a single partition. It only understands the idea of working with a single physical hard drive and a selected partition on that hard drive. And looking at the hard drives that represent the Data drive in a WHS system, instead of seeing one big partition, it would see multiple ones, or perhaps nothing at all as it may not be able to interpret a DE partition. Is that what you were saying? Is that close? (I'll have to boot into BartPE to see what this looks like.)

    So, do you see any problem with imaging the system partition only?
    • Edited by dvn1 Friday, August 28, 2009 9:29 AM
    Friday, August 28, 2009 2:14 AM
  • Regarding backing up and restoring the system partition: the problem users typically run into is that the system partition contains a mix of operational data, some of which Windows Home Server will recreate if it's entirely absent, but which it will happily use if it's present, even if it's horribly outdated. So the recommendation is to live with the limitations of server reinstallation, becuase that guarantees that all this data will be recreated (in a reinstallaiton to a previously used system disk, the C: partition is formatted and of course everything on it is lost). If you insist on avoiding server reinstallation, you will have to back up your system disk every single time you make a configuration change of any sort to your server (anything that involves the WHS console for sure, and possibly other stuff).

    Regarding restoring to a smaller partition: the reason the other poster was successful is tied to the way Windows Home Server backs up a disk. It backs up clusters of used data, not files per se . And it restores in the same fashion. So as a result, it requires a disk that's large enough to accept the last used cluster in the same location . The disk size limitation (can't restore to a smaller disk) is a result of the way NTFS allocates clusters of data across a disk. If you were to take a 100 GB disk and install Windows XP on it, then immediately back it up, you could restore to a significantly smaller disk than 100 GB, probably around 60 GB or so and maybe even smaller. Try it and see. :) This is mostly of academic interest; in the real world the "last used cluster" very rapidly becomes the last cluster on the partition.

    That Windows Home Server only backs up clusters of data is also why it's not recommended that you convert a disk from FAT to NTFS. Converted FAT disks have clusters of a different size than virgin NTFS (by default, 512 bytes if I recall correctly) and you wind up with a separate segment of the backup database for the different cluster size, with no sharing of clusters between the two. This is why some users see ".512", ".2048". ".4096" and other files in their backup database...

    Edit: I should mention that I worked with Windows and NTFS at a pretty deep level for a couple of years. What I describe above is partially a result of my research at that time, partially from published documentation (mostly on MSDN and TechNet) on NTFS, and partially the result of experimentation with Windows Home Server, which produced results that were consistent with my expectations (for the most part :) ).

    I'm not on the WHS team, I just post a lot. :)
    Friday, August 28, 2009 6:53 PM
    Moderator
  • antialex01:

    After experimenting some more with WHS restore, I was able to duplicate your results. I restored a backup of a 50 GB Vista partition that had 34.2 GB of used space, to a new partition of 40 GB, and it worked. I tried several different target partition sizes and found that as long as the end result was a partition with 15% free space, the restore would be allowed and would succeed.

    Additionally, in a further experiment I deleted the boot and Vista partitions from the disk and created two new partitions for them in completely different locations on the disk, allowing two other data partitions to remain as-is. After restoration I expected that I would need to fix the pointers in the BCD and the drive letter assignments in the registry, since both partitions were relocated. So after WHS restoration and before booting Vista for the first time, I booted into VistaPE to check the BCD, expecting the pointers to the Boot and Vista partitions to be listed as unknown, since the partitions were now in different locations. Much to my surprise the BCD pointers were correct! But surely the two drive letter reservations for the partitions would be wrong in the Vista registry (HKLM\System\MountedDevices), so I mounted the system registry file in the Vista partition to have a look and again to my surprise there were drive letter reservations for C (Vista) and F (Boot) in the registry and they were correct, and different from the values in the registry file in the backup! So WHS restore must be Vista-aware and obviously knows how to fix these issues. A reboot into Vista was a complete success.

    Most other imaging software cannot properly fix issues like this - it usually requires manual BCD and registry editing or other measures. I am really impressed, and my hat's off to the WHS developers.
    Saturday, September 5, 2009 7:28 PM
  • Mark and Ken, thanks for your feedback. This is good stuff, demonstrating yet another aspect of WHS flexibility.

    "...hat's off to the WHS developers." Indeed.
    Saturday, September 5, 2009 11:05 PM
  • I had to replace my 320HD in my mediacenter and since i har my WHS now I did not need all the space so I got a 120HD instead but when I wanted to restore the backup it came op and with the could on restore to a smaller drive or HD so I used "Acronis Disk Director suite" on "Hiren bootcd 9.9" to resize the 320HD to 98GB restarted the computer and made a new backup with WHS and then put in the 120HD and restored from the new backup.

    so so simple so simple

    I think it was a nice work around and it did not take that long maby 1 to 1.5 hour total

    reg.
    HomeGyro
    Tuesday, September 8, 2009 7:03 PM
  • The assumption is that you will be replacing your hard drive with a similar or better one if it fails. Why wouldn't you?
    This is a flawed assumption in my particular case. Well, maybe not; because, granted, I tried to replace my old drive with a BETTER one but..

    Check this out:

    I have a Dell Mini 9 (DM9). I replaced the primary drive (SSD via PCIe) with a Runcore Pro 64GB SSD . For various reasons, I decided to do a clean install about a month ago. So, I actually took the time to do a clean install of Windows 7 Enterprise RTM (Win7). Immediately after I installed Win7 and applied the appropriate updates, I backed up my DM9 to my Windows Home Server (WHS). Then, I proceeded to install my various applications - all the while incrementally backing up my DM9 to my WHS after each application I would install. I even did another backup after I activated all the software as the last step. I even experimented a few times deleting, reformatting, restoring everything in less than 15 minutes - what an awesome way to create clean "images" of a machine (I used to use imagex to do this - even though it's not suppose to be used like this.) that gets stored on the WHS! Alas... here's my issue...

    My Runcore Pro died on me. Not a problem. Data's already backed up on WHS. I have an "image" of a clean install on my WHS, right? Well, I ordered me a new Runcore - but this time, I got the even faster Runcore Pro IV 64GB SSD (you need to scroll down on the link and check out the 4Kb write speeds!). I just got the drive today and I began the restoration process using the latest WHS Client Restore image on my bootable UFD. Well, ____ me off! My old SSD was 61134 MB. This new SSD is 61055 MB. A difference of 79 MB!!!!!!!!!! Trust me, even after loading everything onto my SSD, It wasn't even at 50% capacity... So here I am, stuck with a NEWER, BETTER drive - but it's 79 MB smaller in size...

    The first thing that popped into my mind is to jury-rig some way of making my external USB drive as the primary drive on my DM9 - restoring to it; resizing the partition; backing it up; and then restoring that newer backup onto the new SSD.

    Bah, I may have to just bite the bullet and spend the time doing ANOTHER clean install - this time, I'm going to actually create my GOLD image using imagex and then backing THAT up on the WHS - just in case!

    Still, I'm open to any other suggestions... Help?
    Tuesday, December 8, 2009 6:44 AM
  • ...The first thing that popped into my mind is to jury-rig some way of making my external USB drive as the primary drive on my DM9 - restoring to it; resizing the partition; backing it up; and then restoring that newer backup onto the new SSD...Still, I'm open to any other suggestions... Help?
    Don't bother with the USB experiment - Windows cannot boot from USB disks. However, do you have any other disk that can be connected internally to your Mini 9? If so, create a partition (or 2 if you have the separate Win 7 boot partition) on it that's large enough to hold your existing WHS image, restore the image, and then resize the partition smaller like you were suggesting. Then back this up and restore it to your new SSD. I think this should work.
    Tuesday, December 8, 2009 1:15 PM
  • Don't bother with the USB experiment - Windows cannot boot from USB disks. However, do you have any other disk that can be connected internally to your Mini 9? If so, create a partition (or 2 if you have the separate Win 7 boot partition) on it that's large enough to hold your existing WHS image, restore the image, and then resize the partition smaller like you were suggesting. Then back this up and restore it to your new SSD. I think this should work.
    Well, I did bother with the USB experiment. I had to - the reason being is that I don't have very many drives with a PCIe interface, which the Dell Mini 9 requires.

    I took an empty external USB drive and plugged it in before the restoration process. On the screen after I logon to the server, pick which computer to restore and then which backup date I want to restore, I'm presented with the Choose Volumes to Restore screen. Interestingly, at this juncture, because I have my USB drive plugged in, I'm presented with an additional Source Volume and Destination Volume option (example picture - just know that the RED X for mine was on top due to the "79 MB smaller destination" problem). I selected None for the top one and selected that the backup image be written to my external USB drive. I finished the restore process in about 20 minutes and now I had an external USB drive that contained the image of what I was trying to restore.

    I plugged that USB drive into my other computer where I could run an elevated command prompt and captured that drive using imagex.exe (e.g., "imagex /capture g: c:\Mini9.wim "Gold - everything is installed" /check /verify").  After about 30 minutes, I had a 5GB WIM. I copied this WIM file over to a USB drive and plugged that into my Mini 9, along with a bootable UFD that had WinPE and imagex on it. I then applied that WIM to my newer-but-smaller-by-79MB Runcore (e.g., "imagex /apply g:\Mini9.wim 1 c: /check /verify"). After another 30 minutes or so, it stated that the image was applied successfully!

    Well, I tried booting the Mini9 to the new SSD and immediately get a black screen error: "Windows failed to start. A recent hardware or software change might be the cause." I pop in my Windows 7 installation UFD and select Repair your computer . After letting it do what it's suppose to do, I reboot.

    Viola! A working Mini 9 with the new Runcore Pro IV!

    Now to go make a backup of it... :D

    Tuesday, December 8, 2009 10:36 PM
  • Nice job figuring that out.
    Wednesday, December 9, 2009 12:29 AM