DCSIMG
Restoring a Computer From Windows Home Server Backup - All Your Base Are Belong To Us

All Your Base Are Belong To Us

Mostly .NET internals and other kinds of gory details

Restoring a Computer From Windows Home Server Backup

The other day I had the immensely fun experience of restoring my Alienware m15x laptop from backup. It’s the second time I’ve restored a computer from backup since I have my trusty Acer easyStore Windows Home Server system. It just sits quietly in the corner, gathering dust and backing up my documents, work, and memories, claiming no reward but an additional 2TB hard drive every six months.

The general restore process is very simple:

  1. Burn a copy of the Windows Home Server Computer Restore CD
  2. Boot the faulty machine from the CD
  3. Let it find your home server over the network
  4. Choose which machine to restore and which backup to use
  5. Wait a few hours and you have a restored machine

The only potential pitfall in this process is that you need the restore CD environment to recognize your hardware. At the very least, it must be able to recognize the hard drive and the Ethernet network card, or it won’t be able to download the backup from your Home Server and restore the system from it.

With every backup, Windows Home Server captures the set of critical drivers required for the restore. Before restoring the system, you can get these drivers from the Home Server backup—they will be in a folder called Windows Home Server Drivers for Restore on your system drive when you view the Home Server backup from the Windows Home Server console. These drivers will work great in the recovery environment if you are restoring a 32-bit system—the recovery environment is 32-bit.

Unfortunately, if you are restoring a 64-bit system, you will need to find 32-bit drivers for the hard drive and network card manually. This can be a rather tedious process. You can usually find drivers on the hardware manufacturer’s website.

When restoring my Alienware m15x, the only hardware device with a missing driver was the Intel Ethernet NIC. You’ll need the Windows Vista 32-bit drivers, as that’s what the recovery environment is based on. Download them from here and you’ll be good to go!

Oh, and by the way—backups are important, but they are worthless if you never try restoring from backup. You’d think it should only take an hour and then spend a whole weekend sorting out driver problems, like I did :-)

I am posting short updates and links on Twitter as well as on this blog. You can follow me: @goldshtn
Posted: Apr 14 2012, 12:44 PM by Sasha Goldshtein | with 2 comment(s)
תגים:

Comments

Josh said:

Is there complete feature parity in accessing WinRT from C# / C++ / Javascript ?

Is there a COM marshaling overhead in calling the WinRT API from C# ?

If only a small subset of .NET Framework is available on WOA, is there any point (besides productivity, GC) in leveraging C# for a metro app ?

Which language do you recommend for developing Metro apps?

# April 24, 2012 9:06 AM

Sasha Goldshtein said:

@Josh, have you accidentally commented on the wrong post? :-)

To answer your questions:

1.

There is almost complete feature parity for the various languages. One limitation that comes to mind is real-time connectivity apps (lock-screen apps) -- some functionality is not supported from JavaScript.

2.

There is no cross-apartment marshaling unless you cause it (if that's what you're asking). There is a standard IL stub that performs the interop transition, otherwise.

3.

Productivity and GC are big enough reasons for me :-)

4.

I really can't answer that as it depends on your previous background and specific scenario.

# April 28, 2012 2:55 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 


Enter the numbers above: