General discussion


Bare Metal Disaster Recovery Technology

By parasailingdiva ·
I am interested in obtaining information regarding Bare Metal Disaster Recovery Technology and/or Disaster Recovery Technology which will allow me to do the following:

Restore any W2K Server on my network in the quickest time possible without having to reinstall the OS, but more importantly being able to restore the server to any or almost any dissimular hardware I may have available (i.e., being able to restore a Compaq DL360 or Compaq XEON server to a Compaq EVO D510 PC with the right size harddrive of course.

I currently restore my data from tape media (ArcServe/Brightstor) however, when trying to do a complete restore of a server I incur major problems because of the System State (hardware differences - which make the OS loop on startup because of hardware changes). So, I am trying to find an alternative method which will allow me to get this server to it's original state on dissimular hardware. I have tried Brightstor's Disaster Recovery Option plug in, but this only allows you to restore the server to hardware that is exactly the same. Also, I want to be able to restore the server in a non-production environment if possible.

Please advise.


This conversation is currently closed to new comments.

14 total posts (Page 1 of 2)   01 | 02   Next
| Thread display: Collapse - | Expand +

All Comments

Collapse -

by parasailingdiva In reply to Bare Metal Disaster Recov ...

I should add that the dissimular hardware would also include a change in drive configuration and Raid configuration. So, I would need to also have the ablility to completely restore the server from a mirrored Raid 5 configuration to a single basic and/or dynamic disk configuration Raid 1. Possible or not?

Collapse -

by CG IT In reply to Bare Metal Disaster Recov ...

I don't think you can do what you want to do. Simply put, the system state & full system backup includes "everything" and restoring that means restoring "everything". Dissimilar hardware on a system state backup will preclude restore and functionality.

keeps people of swiping backup tapes and trying to install it on their computer.

Collapse -

by CG IT In reply to

As TheChas has mentioned the HAL Hardware would have to be striped.

Final word on this is NO you can't within the context that you want.

Collapse -

by TheChas In reply to Bare Metal Disaster Recov ...

To even have a chance of an any hardware restoration, the backup would need to have the HAL Hardware layer stripped from it.

If your RAID array uses any form of striping, that would be another major obstacle.

I also know of no way to work around the obstacles in your scenario.

I think you would be better off looking into redundancy.


Collapse -

by erikdr In reply to Bare Metal Disaster Recov ...

Agree with previous posters. In the way you state it, simply impossible.
Redundancy (with frequent replication of all critical data) is one way out.
Another one is in provisioning technology combined with good DATA backup. If you have a way to quickly install new Windows bare metal servers, including specifying their identity, then after the install you can restore the essential data on them. This quick install can be done with free MS tools like RIS and Windows 2003 ADS, or with paid tooling from e.g. Altiris or LANDesk. Make sure the essential data is not linked to the SID identity of the server. E.g. databases and home directories are fine, but moving roaming profiles from one server to another could be a problem. Some level of redundancy for those SID-related info would be needed anyhow.


<Erik> - The Netherlands

Collapse -

by wlbowers In reply to Bare Metal Disaster Recov ...

What you are attempting to do would require that you build a startup driver configuration much as the windows install cd use. But your problem is that most of them are shotgun or generic.

If you are wanting a disaster recovery plan that involves minimum downtime build you a disaster/crash kit of exact hardware. Keep this hardware in an anvil case in a safe location.

I have built these for clients and they usually consist of the following.

Motherboard with cpu/fan and memory installed
video card
nic {if not included in the mb}
scsi controller {if not included in the mb}
hard drive with the base system installed ready to restore applications and data to.

A lot of business owners think this crazy until I show them what his operating loss is per hour due to his server being down.

Good Luck Lee

Collapse -

by Jose Mir In reply to Bare Metal Disaster Recov ...

CLUSTERING is the solution to your needs!!!

You still need to keep doing backups, but clustering will give you non-delayed failure recovery.



Collapse -

by dwaneporter In reply to Bare Metal Disaster Recov ...

As a BCP/DRP planner what you are requesting is impossible. But there is hope.

The most you can hope for is to do one of the following;

Design your system to have a cluster (local) for high availability. (optional)

Second - replicate your data to a secondary system using something like vertias replication. This will allow you to replicate to a second server. This does not have to be identical hardware - just space requirements have to be equal or better.

Now heres the caveot: the primary system is configured xyz.....the seconday system will have to be configured xyz.....they do not have to be the same config - just configed for that hardware/application you are using.

The only bare metal restore that could work is same to = same. Word of caution - that can me down to the nth degree for some systems (bios, controllers etc....)

Collapse -

by s.spike In reply to Bare Metal Disaster Recov ...

This is possible.
The first step is to install two instances of WIN2k onto your new (different hardware) server into C:\WINNT & C:\DRWINNT
Now make sure both have the same service pack revision as the server to be recovered.
Whilst running from the instance in the C:\winnt folder install backup software and restore everything (all drives and system state).
Once this is done you can try and reboot onto the restored OS. This may fail though. In which case bot into the second instance in C:\DRWINNT and run regedt32.

Under HKEY_LOCAL_MACHINE/ SYSTEM, select (highlight) Mounted Devices Save the Mounted Devices key

Next under HKEY_LOCAL_MACHINE/ SYSTEM, expand the CurrentControlSet sub hive

Next highlight ENUM from the tool bar select Registry then save key and save the ENUM key

Next under HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control, select the Class key and save it.

Next under HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control, select the CriticalDevicedatabase key and save it.

Next under HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services, save the following key:

Cpqcissm (dependent on disk controller)

This can vary dependent on hardware - you have to know what mass storage controller has been used.

First highlight HKEY_LOCAL_MACHINE from the toolbar select Registry then Load Hive.
Browse to c:\winnt\system32\config and select SYSTEM (no ext) click OK then name it HIVE2.

Collapse -

by s.spike In reply to Bare Metal Disaster Recov ...


IMPORTANT NOTE: keys MUST be restored to ControlSet001 otherwise the procedure will fail. Note: You can check under the select key as displayed above to see which controlset is current it will be ControlSet001 99% of the time.

Next Highlight HIVE2 then ControlSet001/enum and from the toolbar select security then permissions and add and give Administrators full control.

Next expand HIVE2 and restore the saved keys to controlset001 in the original locations in the HIVE2 registry that was restored and loaded.

Reboot and select the original c:\winnt instance, all should be ok. You may have to uninstall device drivers from Device Manager and 'scan for hardware changes', especially for the NIC and VGA to work correctly

Back to Security Forum
14 total posts (Page 1 of 2)   01 | 02   Next

Related Discussions

Related Forums