|
SecuriData Online Backup - Server Bare Metal Back & Restore (BMR)
To be
able to perform BMR, you must protect the target computer with a single backup
set that contains:
·
System
State and Services Database
·
Operating System Volume
NOTE: Some applications can be installed and can store data across multiple
volumes. You must include all of those volumes in this online backup set if you
want to be able to restore those applications.
Depending on the applications running on the target computer, you may need to
stop them for the initial backup, in order to facilitate a smooth BMR. To
protect those services after the initial backup and when they are running (i.e.
in “hot” mode), you must create separate backups with the corresponding special
backup sets (e.g. "MS SQL Server Database Backups").
Details
The
reason you must perform at least one online backup of the target computer with
the service applications stopped is to ensure that any locked files used by
those applications are backed up at least once. Otherwise, those services will
not start after you perform the BMR.
In
order to restore from the special backup sets (e.g. MS SQL Server), SecuriData’s
Online Backup Service needs to connect to a running service. If the service
cannot start, you must repair that service installation with the corresponding
Installation Package.
In
general, the steps for BMR of a Windows computer running MS SQL Server are:
1. Assemble the replacement hardware for the target BMR computer.
2.
Re-install the same Windows Operating System (you do not need to apply any
Service Packs).
3. If
the Hardware is different from the original computer, you must install the
corresponding hardware drivers.
4.
Restore from the target computer’s backup set (including Operating System
Volume, System State and Services Database).
5.
Restart the MS SQL Server (if applicable).
6.
Restore the latest version of MS SQL Server from the separate special backup set
(if applicable).
Bare Metal Restore of Windows 2003
Summary
Bare Metal Restore is a restore process when the whole machine is being
restored. Usually this type of restore is performed after a complete hardware
failure or hardware upgrade.
You must have backed up the machine’s System State and Services Database.
Microsoft recommends using the same hardware for the destination machine.
·
You
can restore Windows 2000/2003 machines to different hardware.
·
Restoring a Windows NT4 machine to different hardware is not possible (unless
some initial preparations are made). However, if the differences are minor (e.g.
different SCSI controller, NIC) the restore may be successful.
Switching between different computer types (ACPI to standard computer type and
vise versa) is not allowed. For more information you can check Microsoft’s
knowledge base article number 237556.
1. Determine your computer type:
Before starting the restore you can check your computer type. Here is how you
can determine your computer type.
Click Start, point to
Settings, click
Control Panel, and then double click
System.
Click the Hardware tab, and then
click Device Manager to view
what is listed under the computer branch.
Here are the descriptions of the computer types and the associated hal.dll:
·
ACPI Multiprocessor PC – halmacpi.dll
·
ACPI Uniprocessor PC – halaacpi.dll
·
Advanced Configuration and Power Interface (ACPI) PC – halacpi.dll
·
MPS
Multiprocessor PC – halmps.dll
·
MPS
Uniprocessor PC – halapic.dll
·
Standard PC – hal.dll
·
Compaq SystemPro Multiprocessor or 100% Compatible – halsp.dll
There are other types available but that would require Hardware vendor specific
installation (involving customized hal.dll).
2. Restoring from one computer type to another:
In
some cases it is necessary to perform bare metal restore to a machine of
different type. In this case after successful restore, after the reboot you will
not be able to start your machine. Regardless what backup software you are using
the result would be the same – your computer would not start properly or at all.
SecuriData has a solution for this problem:
·
In
the last screen of the restore wizard, DS-Client will ask you if you want it to
save some files in order to preserve them. If you answered yes, they will be
saved with an extra extension called asigra-date-time. The files are –
hal.dll, ntoskrnl.exe, ntkrnlpa.exe,
kernel32.dll, ntdll.dll, win32k.sys, winsrv.dll, setup.log (in
\WINNT\repair directory), and boot.ini.
·
After the restore is finished, you are prompted to reboot the target computer.
Do so.
·
If
your computer boots normally, no intervention is required. If your computer does
not boot, or crashes, you have to follow the steps outlined below:
·
Reboot the computer from the Windows 2000 installation CD, and start a repair
process using the recovery console.
·
Once you have the command prompt, change to the system32 directory (by typing
cd system32), and type
dir *.*.asigra*
·
You
should see the 7 saved files. Copy each one of them to their original name. For
example if you have
hal.dll.asigra-022403-0800, you should type
copy hal.dll.asigra-022403-0800 hal.dll.
Confirm the overwrite and continue with the rest of the files.
·
Type cd dllcache. Type dir
*.*.asigra*. You may see 2 more files. Copy them to their original
names.
·
Change to the root of C:\ drive by typing cd
\
·
Type dir *.*.asigra*. You will see one file. Copy it to the
original name (boot.ini).
·
Change to C:\WINNT\repair by typing cd
\winnt\repair. If your %SystemRoot% is located on a different drive
or has a different name, change to the proper location.
·
Type dir *.*.asigra*. You will see one file. Copy it to the
original name (setup.log). You will need this file in case you need to perform
repair.
·
After successfully copying all the files type
exit, which would reboot the
machine. Boot normally, and your machine should be up and running.
There would be a rebuild of the plug and play database, and you may be prompted
to provide drivers for the new hardware found. Follow the instructions on the
screen. When prompted to reboot, select NO and finish installing all drivers.
Set the TCP/IP details for your network adapter(s).
Now you have to fix your computer type. If you did not check the computer type
of the destination machine (the one that you are restoring to), you can find out
the type by checking the properties of the
hal.dll. Open your Windows explorer and go to
%SystemRoot%\system32 (%SystemRoot% is usually located in C:\WINNT). Locate the
file hal.dll with the extra
asigra extension. It could be
something like hal.dll.asigra-022403-0800.
Right click on it and select properties. Click on the "Version" tab, and from
"Item name" select "Internal name". In the "Value" field you would see the
original file name. In step 1 above there is a description for each computer
type and its corresponding hal.dll.
Now you have to change your computer type to the right one (if it is not already
so). Click Start, point to
Settings, click
Control Panel, and then double click
System. Click the
Hardware tab, and then click
Device Manager to view what is
listed under the computer branch. Right click on the computer type, select
Properties, and select "Driver" tab. Click on "Update driver" button. Click on
"Display a list of the known drivers for this device so that I can choose a
specific driver" radio button and click "Next". Select the right model for your
computer (the one that you discovered by checking the original hal.dll
properties) and click "Next". Finish and when prompted to reboot do so.
3. Restoring Active Directory in a multiple server tree.
Active directory is part of the System State
and can be restored only as a System State
restore. System State would
restore the registry as well. You can perform 2 types of AD restore – normal and
authoritative. The AD objects restored through normal restore, would be
overwritten by the AD replication. The restored objects would have their
original "update sequence number". These USNs are used by the replication
process to detect and propagate AD changes among the servers in the tree.
Because of this the restored data would look old to the AD replication and the
data would never get replicated. In fact the replication process would overwrite
it. When is the normal (nonauthoritative) restore useful? It is good for single
server trees, or when you want to restore the registry, but not to overwrite the
Active Directory.
However in case you need to restore an older version of the Active Directory
(but not older than 60 days), you have to perform an authoritative restore.
Below is a description of each restore type:
Authoritative restore - Select "Authoritative restore" in the last screen of the
Restore Wizard. This will perform authoritative restore of both AD and FRS.
The
following list of requirements must be met before you perform an authoritative
FRS restore:
a)
The FRS service must be disabled on all downstream partners (direct and
transitive).
b)
Events 13553 and 13516 have been logged in the FRS event log.
c)
The computer that is configured for the authoritative restore is configured to
be authoritative for all the data.
d)
All other partners in the replica set must be reinitialized with a
non-authoritative restore.
To
reinitialize the partners with a non-authoritative restore, stop the FRS
service, configure the BurFlags registry key, and then restart the FRS service.
To do so:
·
Click Start, and then click Run.
·
In
the Open box, type cmd and then press ENTER.
·
In
the Command box, type net stop ntfrs.
·
Click Start, and then click Run.
·
In
the Open box, type regedt32 and then press ENTER.
·
Locate the following subkey in the registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process
at Startup
·
In
the right pane, double click BurFlags.
·
In
the Edit DWORD Value dialog box, type D2 and then click OK.
·
Quit Registry Editor.
·
Perform this on every partner.
After rebooting the machine you just restored, start the FRS service on all the
partners by typing "net start ntfrs" in the command box. They will synchronize
from the restored machine.
Normal restore - default - "Authoritative restore" is NOT selected. This will
perform non-authoritative restore for both Active Directory and NTFRS.
You can still perform Non-authoritative restore with DS-Client and then manually
run ntdsutil. However this would not work if you are performing bare metal
restore where the destination for restore doesn't have AD. If this is the case,
let DS-Client perform authoritative restore. DS-Client is running several
activities that you can not perform when running manually ntdsutil.
Note: After successful restore you should reboot the machine. Once the machine
is restarted the plug and play database is reinitialized and most probably you
will be prompted for a reboot. Please do not reboot immediately, wait and make
sure the Active directory and FRS are synchronized.
Please note that replication may take some time before the restored data would
be propagated. If you are testing authoritative restore – please note that
objects added to the AD after the backup, would not be removed from AD after the
authoritative restore. For more information see Microsoft’s knowledge base
article 216243.
4. Restoring Active Directory on a server that is not the PDC when the PDC is
missing.
There are some scenarios when you have to restore AD on a domain controller when
the PDC is missing. In this case there are several steps that should be
performed in order to get the AD in 100% running condition.
If
the destination machine is a domain controller already, you have to boot into
Directory Services Restore Mode. If the destination machine is a stand-alone
Windows 2000/2003 computer you can start the restore immediately.
Select "Authoritative restore" in the last screen of the Restore Wizard. This
will perform authoritative restore of both AD and FRS.
After successful restore of the System State reboot the computer when prompted.
Please note that you may have to perform the steps outlined above in case you
are restoring to different computer type.
There are a few articles from Microsoft describing the whole process:
216498 - HOW TO: Remove Data in Active Directory After an Unsuccessful Domain
Controller Demotion
248410 - Error Message: The Account-Identifier Allocator Failed to Initialize
Properly
234790 - HOW TO: Find Servers That Hold Flexible Single Master Operations Roles
223787 - Flexible Single Master Operation Transfer and Seizure Process
Outlined below is the whole process described step by step.
4.1. Login to the restored machine (after the normal reboot) and start a command
prompt. Start ntdsutil:
Type "domain management"
Type "connections"
Type "connect to server ServerName"
(where ServerName is your current computer name)
Type "quit"
Type "select operation target"
Type "list roles for connected server"
You
should get information about what roles where associated with the server.
Type "list sites" and note the
number for the site you are dealing with
Type "select site #" (where # is
your site number. e.g. 0, 1, ...)
Type "list domains in site" and
note the domain number
Type "select domain #" (where #
is your domain number. e.g. 0, 1, ...)
Type "list servers in site" and
note the number for the missing PDC
Type "select server #" (where #
is your server number. e.g. 0, 1, ...)
Type "list naming contexts" and
note the number for the CN=Configuration
Type "select naming context #"
(where # is your naming context number. e.g. 0, 1, ...)
Type "quit"
Type "quit"
Type "roles" and you will be at
the "fsmo maintenance:" prompt.
Now you must "seize" all 5 rows. ntdsutil
will attempt to "safe transfer" the roles, but the transfer will fail since the
PDC is missing. Just ignore the errors, because seizure will succeed:
Type "seize domain naming master"
Click "Yes" at the pop up message
Type "seize infrastructure master"
Click "Yes" at the pop up message
Type "seize PDC"
Click "Yes" at the pop up message
Type "seize RID master"
Click "Yes" at message prompting you to synchronize and "Yes' to confirm the
operation
Type "seize schema master"
Type "quit"
Type "quit" to exit
ntdsutil
4.2. Now you have to delete all references to the missing server. This could be
accomplished using "ADSI edit".
This utility is free and is located on the Windows 2000 Server installation CD.
It is in \support\tools. Just
install the tools.
Start ADSI Edit. If you launch
ADSI edit immediately after logon, you may receive an error that the domain does
not exist. Wait a minute or so and try again.
In
"Domain NC..." folder, expand until you reach "OU=Domain Controllers". Locate
the missing server and delete it. Redo the delete if you get an error or partial
delete.
In
"Configuration Container...", expand until you reach CN=Sites, CN=SiteName -
CN=Servers. Locate the missing server and delete it.
The
last step is to set the Global catalog. In "Active
Directory Sites and Services" expand the site all the way down until
you reached NTDS settings for the server that you restored. Right click on "NTDS
Settings" select "Properties", check "Global Catalog", click "Apply", and close
this dialog box.
4.3. Now you are ready to reboot. Reboot the server.
4.4. Examine all the logs for any errors. You should not have any errors. If
this is not the case you may have incompatible hardware or device drivers.
Usually the error would give you an indication what the problem is and you must
be able to solve them.
4.5. Your server is now ready.
Note: If there are no other domain controllers to synchronize with, you will
have problems. For an explanation of how to fix this, refer to the next
paragraph 5 (Restoring Active Directory from a multi server to a single server
environment, or when the rest of the domain controllers are missing).
5. Restoring Active Directory from a multi server to a single server
environment, or when the rest of the domain controllers are missing:
You
will have SAM errors if other domain controllers are missing. If you do not plan
to ever start the other controllers, then you should remove them from Active
Directory. Use ADSI Edit as explained in step 4 above.
From "Active Directory Sites and Services" delete "Connection" from NTDS
Settings.
After Service Pack 3, the FSMO role holder would not assume its FSMO role unless
it had successfully completed at least one sync.
Microsoft changed this in order to avoid multiple FSMO owners in a domain, and
to prevent the Domain Controller from issuing duplicate RIDs.
As described in the previous steps if you seize the RID Master role it will not
become authoritative until it synchronizes with another DC.
During disaster recovery where you restore only one domain controller from
backup, or when you remove domain controllers from AD, you may get "The
account-identifier allocator failed to initialize properly..." errors in the
System log. The error would be from source SAM and Event ID 16650. Dcdiag may
report problems with RID Manager or corrupted data.
There are 2 solutions:
a)
You can restore another domain controller, or
b)
You can delete the replication links
In
case you want to keep only one domain controller, you have to delete the
replication links, otherwise the domain controller is not fully operational.
Here are the instructions for deleting the replication links:
1.
You need to use the repadmin tool. It is part of the "Windows 2003 Support
tools". The installation of the tools is located in \SUPPORT\TOOLS on the
Windows 2003 CD.
2.
Open a command prompt and type "repadmin /showreps /v"
3.
You need to find out the "guid-based-dns-name of replica partner", which is
displayed after "Address:" of the deleted partner.
4.
Here is an extract from repadmin:
------------------------------------
C:\>repadmin /showreps /v
Default-First-Site-Name\SPEEDYNT4
DSA
Options : IS_GC
objectGuid : a089478f-cffb-409f-b74b-addb83a6e93e
invocationID: a089478f-cffb-409f-b74b-addb83a6e93e
==== INBOUND NEIGHBORS ======================================
CN=Schema,CN=Configuration,DC=spdnt4,DC=local
Default-First-Site-Name\TR1
DEL:b91cd853-6af0-4c3a-9586-b5dcc8f489f7 (deleted DSA) via RPC
objectGuid: a48650dc-8ed0-4363-8c25-b41553f9248d
Address: a48650dc-8ed0-4363-8c25-b41553f9248d._msdcs.spdnt4.local
ntdsDsa invocationId: 8994f8c1-f71e-454c-ad3a-17b119621381
WRITEABLE SYNC_ON_STARTUP DO_SCHEDULED_SYNCS
USNs: 3518/OU, 3518/PU
------------------------------------
5.
In the example above, the FQDN is spdnt4.local and the "guid-based-dns-name of
replica partner" is "a48650dc-8ed0-4363-8c25-b41553f9248d._msdcs.spdnt4.local"
6.
The restored server is called SPEEDYNT4 and the deleted partner - TR1.
7.
Now you can delete the replicas. The syntax is:
repadmin /delete <naming context> <restored server name> <guid-based-dns-name of
replica partner> /localonly
8.
<naming context> would be for the Schema, Configuration and Domain.
10.
In our example to delete the links for the schema we would type:
repadmin /delete CN=Schema,CN=Configuration,DC=spdnt4,DC=local
speedynt4.spdnt4.local a48650dc-8ed0-4363-8c25-b41553f9248d._msdcs.spdnt4.local
/localonly
11.
To delete the links for Configuration we would type:
repadmin /delete CN=Configuration,DC=spdnt4,DC=local speedynt4.spdnt4.local
a48650dc-8ed0-4363-8c25-b41553f9248d._msdcs.spdnt4.local /localonly
12.
To delete the links for Domain we would type:
repadmin /delete DC=spdnt4,DC=local speedynt4.spdnt4.local
a48650dc-8ed0-4363-8c25-b41553f9248d._msdcs.spdnt4.local /localonly
13.
You must reboot the server after deleting all the replication links.
14.
Check the System Log after the reboot to make sure there are no errors from
source SAM.
6. Common mistakes:
-
Slow clients logins
-
Misconfigured DNS, DHCP
-
If the missing server is your PDC, and also your main DNS and DHCP server,
your client computers may experience slow logins or errors when trying to
login to the domain. If you are using fixed IP addresses, make sure the
clients DNS settings are correct. Check your DHCP server for proper
settings.
|
