Re: Disaster recovery restore options
From: Jeff Middleton [SBS-MVP] (jeff_at_cfisolutions.com)
Date: 08/04/04
- Next message: Gary V.: "Do I need dual Xeons?"
- Previous message: R: "Re: Send as option when sending email"
- In reply to: Sean McLeod: "Re: Disaster recovery restore options"
- Next in thread: Sean McLeod: "Re: Disaster recovery restore options"
- Reply: Sean McLeod: "Re: Disaster recovery restore options"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 4 Aug 2004 13:17:53 -0500
<comment> your original post made reference to a commitment for response,
which may well be the case of you signed up for Technet or a similar
value-add program that provides support from MS employees, but there is not
a program that promises or expects response time from MVPs. MVPs are not MS
employees, don't have a contractual relationship to participate here by any
stretch. Therefore, if you get an answer from an MVP, it's simply that they
took the time to address the question. If you are expecting response time
and not getting, see MS with your concern.</comment>
The newsgroup tends to give the obvious answer to the obvious questions, and
that's not always going to be the complete answer to the complete question.
Depending upon you combination of skill, time allows, sense of value
associated with hardware purchase vs consuming more time, skill, and
downtime, you really have many options. The general assumption in answering
this question is that people are looking for the least skill, least cost,
least downtime answers. However, that theory doesn't scale up well.
The suggestion that you have a drive image and identical hardware is just an
oversimplification of a potentially complicated discussion. That's because a
drive image assures that you have an identical drive content, and identical
hardware assures that the drivers that are preinstalled in the OS are going
to find the expected hardware to boot from.
By contrast, you can take a drive image from on server and transfer it to
radically different hardware (servers, drive controllers, NICs, video,
whatever) and get backup running with full transparency, but you have to
know a bit more about what you are doing, and how to make it happen. If you
know what you are doing, you can often get it doen in about the same amount
of time as the "optimal" case of identical hardware, and typically within
about 1-2 hrs max if not lucky.
There are only a couple of scenarios that truly can't be resolves as far a
server replacement is concerned, and that's basically if the original server
was not using an ACPI HAL and the new one is, or vice-versa. This is the
only case you really will hit a wall with a lift from one server to another.
Essentially it means that you will probably find another alternative method
to be preferred.
What it comes down to when you are trucking an installed OS from one machine
to another is that the new machine will require a minimum of critical
hardware drivers to already be present and installed in the OS prior to the
transfer. Think of the hard disk as just being a way to move the files
intact, but what's required is for the OS to be able to identify the new
hardware's driver needs and have a certain group of drivers already
available.....not available to install.....rather already installed.
The critical pieces are the HAL, boot controller, and video. Video tends to
be less of an issue these days, most video controllers support a default VGA
mode now so there's at least some common option there.
This leaves you with HAL and boot controller. Now, if you really want a
faster recovery option, you do one of two things.
1. You use a boot drive controller that is PCI based so that you can move
it, and for emergency concerns, you consider making sure you have an extra
one in case the original is the damaged part. We aren't talking a whole
computer for spare, just a drive controller that is typically less than $500
2. Your alternative is to be a little bit smarter. You buy a boot controller
that is PCI based, together with a disk drive to match with it. You take a
weekend sometime with a couple of hours free. You install your PCI card in
your original server, boot the machine from the production drives, install
the required drivers for this controller. With that done, you use drive
imaging to make an image of the production server's system partition on this
"recovery drive". You are welcome to make an image of more than the system
partition, but it's the main thing you care about.
Now that you have a preinstalled driver, a portable PCI boot controller and
a matching drive (or in case 1, you just assume a matching drive is readily
available) and you can now do a little testing. Make yourself a boot floppy,
you know, the thing with a boot.ini file.
In the production server, you take the production drives offline, and you
leave only your PCI card and recovery drive connected. You try booting your
system from the hard drive, and chances are you will be pleasantly surprised
that you can boot from the imaged drive without problems, even if it's a
different kind or controller. This typically works even if the production
set is a SCSI RAID and the recovery set is an EIDE. If it works, you know
that the installation OS is properly configured to work as a replacement in
the same box. That's great. Now you have a replacement drive set in the same
box. Next you figure out if you can boot this in a different box. Before you
shutdown, you inspect Device Manager to see what the HAL is. (Computer type)
Go to your alternate computer running Windows 2000, XP, 2003....workstation
or server versions obviously, doesn't matter. Look at the HAL there. If they
are the same, then you have no work. If they are different, then before you
shutdown the recovery drive set, you first reset the HAL type before
shutdown. This is like replacing a driver in Device Manager, but in this
case it doesn't take affect until the next boot. Once you shutdown, do NOT
restart in that same computer. Move the recovery set to the alternate
computer.
Chances are, you will find that the system in fact boots normally. This
typically is true if the two computers are both less than 4 yrs old because
that's when ACPI standards became pretty well uniformly adopted.
If the boot doesn't work, now you have to figure out if it's because the
boot.ini isn't right or not. If you are getting a Boot Menu then getting
bad/missing System, you have a boot.ini problem. If instead you get a 7b
Stop error, this means the driver required isn't installed, and that's odd
because you actually moved the drive controller over, right? You normally
get that only if the controller had never been working in the OS
installation before. However, it's possible that this means that the
motherboard actually has some chipset action or BIOS related issue that is
making the drive controller not appear in the same ARC path location, or
possibly that the controller isn't activating in the same way as on the
other computer.
At this point, there are various ways you can go about resolving this, but
you have one option that is pretty much a no-brainer to address. Run an
in-place upgrade of this OS on the new machine. That's not a repair, you can
try that, but it probably won't fix this issue. Normally you might have to
say you want to skip the first repair screen, tell it you are installing
new, but then take the second option to in-place repair. After the repair
is complete, you should find that you can boot the machine normally, even if
there are issues with the OS configuration at this point. Don't worry about
that. You now use a restore from a normal full system backup by moving your
tape drive over, or even by doing a backup to disk on another drive, or even
on this drive before you move it from the old machine. After you do a system
state restore, you should have everything but the NICs properly configured.
That you can repair according to KBs.
You will reach a point where you have successfully moved the installation to
another box. Now you have a choice, you can either keep the experience of
now knowing how you will do this next time from scratch, or you can keep
this drive and controller on the shelf as your starting point for a disaster
recovery to this same machine as your alternative hardware if the server
dies. You could assume that in the future, even if this drive isn't updated
over time, you can always use your nightly backup/restore media to update
this drive in the alternate server.
The result is that your plan now requires you only to do a restore to a
previously configured alternate machine, or you repeat that process if you
feel that's a better answer for yourself.
The same thing I've described is not much different than the KB MS has on
how to move a Domain Controller to different hardware:
How to perform a disaster recovery restoration of Active Directory on a
computer with a different hardware configuration
http://support.microsoft.com/default.aspx?scid=kb;en-us;263532&Product=win2000
Note that the KB above says to do a clean install, and I said to overwrite a
drive image. The reason I suggest that you do that is that with all Windows
OS versions prior to Win2003, the Short Filenames will be broken when you do
a restore from tape. Win2003 is the only Windows OS since Win3.11 that
doesn't have this problem. Therefore, you could do as the KB says with a
clean install if you prefer, but only with Win2003 as the server OS.
You will find several useful references in that KB as well.
"Sean McLeod" <sean@no-spam.seanmcleod.com.no-spam> wrote in message
news:uZrbeJieEHA.332@TK2MSFTNGP09.phx.gbl...
> Hi
>
> > Consider TrueImageServer www.acronis.com
>
> Thanks, but again that will tie us into having to have the exact same
> hardware for the recovery machine since TrueImage Server appears to make
> disk snapshots.
>
> > Get a second identical basic set of HW initially and use it as a
> workstation
> > or utility machine until needed in an emergency. Or just mothball it
> offsite
> > for after the big one.
>
> The client already has a complete set of client PCs, and is a fairly small
> company so they can't afford the luxury of buying a 2nd server machine
just
> in case.
>
> Is it really not possible to restore at a minimum user accounts, client pc
> accounts and the Exchange data store without using the same motherboard
> chipset? If so this seems like a real issue for lots of people.
>
> Thanks
>
>
- Next message: Gary V.: "Do I need dual Xeons?"
- Previous message: R: "Re: Send as option when sending email"
- In reply to: Sean McLeod: "Re: Disaster recovery restore options"
- Next in thread: Sean McLeod: "Re: Disaster recovery restore options"
- Reply: Sean McLeod: "Re: Disaster recovery restore options"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
