Hpe Data Protector Disaster Recovery Guide

HPE Data Protector
Software Version: 9.07
Disaster Recovery Guide
Document Release Date: June 2016
Software Release Date: June 2016

Legal Notices
Warranty
The only warranties for Hewlett Packard Enterprise Development LP products and services are set forth in
the express warranty statements accompanying such products and services. Nothing herein should be
construed as constituting an additional warranty. HPE shall not be liable for technical or editorial errors or
omissions contained herein.
The information contained herein is subject to change without notice.
Restricted Rights Legend
Confidential computer software. Valid license from HPE required for possession, use or copying. Consistent
with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and
Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard
commercial license.
Copyright Notice
© Copyright 2016 Hewlett Packard Enterprise Development LP
Trademark Notices
Adobe™ is a trademark of Adobe Systems Incorporated.
Microsoft® and Windows® are U.S. registered trademarks of Microsoft Corporation.
UNIX® is a registered trademark of The Open Group.
This product includes an interface of the 'zlib' general purpose compression library, which is Copyright ©
1995-2002 Jean-loup Gailly and Mark Adler.
Documentation Updates
The title page of this document contains the following identifying information:
l Software Version number, which indicates the software version.
l Document Release Date, which changes each time the document is updated.
l Software Release Date, which indicates the release date of this version of the software.
To check for recent updates or to verify that you are using the most recent edition of a document, go to:
https://softwaresupport.hp.com
This site requires that you register for an HPE Passport and sign in. To register for an HPE Passport ID, go
to: https://hpp12.passport.hp.com/hppcf/createuser.do
Or click the Register link at the top of the HPE Software Support page.
You will also receive updated or new editions if you subscribe to the appropriate product support service.
Contact your HPE sales representative for details.
Support
Visit the HPE Software Support Online web site at: https://softwaresupport.hp.com
This web site provides contact information and details about the products, services, and support that HPE
Software offers.
HPE Software online support provides customer self-solve capabilities. It provides a fast and efficient way to
access interactive technical support tools needed to manage your business. As a valued support customer,
you can benefit by using the support web site to:
HPE Data Protector (9.07) Page 2 of 138

l Search for knowledge documents of interest
l Submit and track support cases and enhancement requests
l Download software patches
l Manage support contracts
l Look up HPE support contacts
l Review information about available services
l Enter into discussions with other software customers
l Research and register for software training
Most of the support areas require that you register as an HPE Passport user and sign in. Many also require a
support contract. To register for an HPE Passport ID, go to:
https://hpp12.passport.hp.com/hppcf/createuser.do
To find more information about access levels, go to:
https://softwaresupport.hp.com/web/softwaresupport/access-levels
HPE Software Solutions Now accesses the HPESW Solution and Integration Portal Web site. This site
enables you to explore HPE Product Solutions to meet your business needs, includes a full list of
Integrations between HPE Products, as well as a listing of ITIL Processes. The URL for this Web site is
http://h20230.www2.hp.com/sc/solutions/index.jsp

Contents
Chapter 1: Introduction 11
Data Protector disaster recovery overview 11
Disaster recovery phasesprocess 13
Disaster Recovery Methods 13
Manual disaster recovery method 15
Disaster recovery using disk delivery 15
Enhanced Automated Disaster Recovery (EADR) 16
One Button Disaster Recovery (OBDR) 16
Data Protector integrations and disaster recovery 17
Chapter 2: How to Prepare for Disaster Recovery 18
Planning 18
Consistent and relevant backups 19
Creating a consistent and relevant backup 20
Encrypted backups 20
Updating and Editing the System Recovery Data 21
Chapter 3: Disaster recovery on Windows systems 22
Assisted Manual Disaster Recovery (AMDR) 22
Overview 22
Requirements 22
Steps 23
Preparation for Assisted Manual Disaster Recovery (Windows Systems) 23
General preparations 23
Updating the recovery diskettes using the CLI 25
Limitations 26
Example of the Disaster Recovery Preparation Table for Windows 26
Updating the SRD File (Windows Clients) 27
Updating the SRD file using the Data Protector Disaster Recovery Wizard on Windows
systems 28
Steps 28
Updating the SRD file using the omnisrdupdate command 28
Steps 28
Updating the SRD file using a post-exec script 28
Example of Editing the SRD File 29
Changing the MA client 29
Changing the backup device 29
Installing and Configuring a Windows System Manually 30
Steps 30

Phase 1 30
Phase 2 31
Phase 3 32
Restoring the Data Protector Cell Manager specifics 32
Restoring System Data Manually (Windows Systems) 32
Restoring the Windows system 33
Steps 33
Phase 2 33
Phase 3 33
Restoring the Data Protector Cell Manager specifics 34
Restoring Vendor-Specific Partitions (Windows systems) 34
Disclaimer 34
Preparation for the Disaster Recovery 34
Steps 34
Restoring an Eisa Utility Partition 35
Steps 35
Overview 35
Prerequisites 36
Preparation for Enhanced Automated Disaster Recovery (Windows and Linux) 37
Prerequisites 37
Limitations 39
Additional preparations for the Cell Manager 42
Saving a Recovery Set to the Cell Manager 43
Saving the recovery set file to the Cell Manager for all clients in the backup
specification 43
Steps 43
Saving the recovery set file to the Cell Manager for a particular client in the backup
specification 44
Preparing the Encryption Keys 45
Preparing a DR OS image 45
Steps 45
Recovering Windows Systems Using Enhanced Automated Disaster Recovery 47
Steps 47
Phase 1 47
Phase 2 51
Phase 3 52
Overview 53
Requirements 54
Limitations 55
Preparation for One Button Disaster Recovery (Windows and Unix) 55
Preparatory steps 56
Creating the Backup Specification for One Button Disaster Recovery 57
Prerequisites 57

Limitations 57
Creating a backup specification for OBDR 57
Steps 57
Modifying an OBDR backup specification to use disk image backup 59
Steps 59
Recovering Windows Systems Using One Button Disaster Recovery 60
Prerequisites 60
Steps 60
Phase 1 60
Phase 2 64
Phase 3 65
Advanced tasks 66
Disaster Recovery of Microsoft Cluster Server 66
About Disaster Recovery of a Microsoft Cluster Server 66
Possible scenarios 66
Preparation for Microsoft Cluster Server Disaster Recovery Specifics 66
EADR specifics 67
OBDR specifics 67
Recovering a Microsoft Cluster Server 67
At least one of the nodes is up and running 67
Prerequisites 67
All nodes in the cluster have experienced a disaster 68
Prerequisites 68
Steps 68
Merging P1S Files for Microsoft Cluster Server 69
Windows 69
UNIX 69
Steps 70
Restoring Original Hard Disk Signatures on Windows Systems 70
Restoring original hard disk signatures on Windows 70
Obtaining original hard disk signatures 71
Example of Hard Disk Signatures in the SRD File 71
Restoring the [%=DP.DP_BriefProductName%] Cell Manager specifics 71
Making IDB consistent (all recovery methods) 71
Enhanced Automated Disaster Recovery specifics 72
Restoring Internet Information Server Specifics 72
Requirements 72
Steps 73
Editing the kb.cfg File 73
Editing the SRD Files 73
AMDR 74
Steps 74
EADR/OBDR 75
Steps 75
Windows systems 75

Linux systems 76
Example of Editing the SRD File 76
Changing the MA client 76
Changing the backup device 77
Windows BitLocker Drive Encryption 77
Limitation 78
Steps 78
Recovery to Dissimilar Hardware 78
When dissimilar hardware restore might be needed 79
Overview 79
Requirements 80
Limitations 80
Recommendations 81
Drivers 81
Preparation 82
Recovery procedure 82
Steps 82
Restoring and preparing the OS 83
Correcting network mappings 83
Steps 83
After the OS is successfully restored 84
Recovery of a physical system to a virtual machine (P2V) 84
Prerequisites 84
Procedure 84
Recovery of a virtual machine to a physical system (V2P) 85
Chapter 4: Disaster recovery on UNIX systems 86
Manual Disaster Recovery (MDR) 86
Overview 86
Preparation for Manual Disaster Recovery (HP-UX Cell Manager) 87
One-time preparation 87
HP-UX systems 87
Backing up the system 87
Installing and Configuring HP-UX Systems Manually (Cell Manager) 88
Steps 88
Phase 1 88
Restoring System Data Manually (HP-UX Cell Manager) 88
Prerequisites 88
Steps 88
Phase 2 88
Phase 3 89
Preparation for Manual Disaster Recovery (HP-UX Client) 89
Using custom installation medium (Golden Image) 89
Creating a Golden Image 89
Recovering an HP-UX Client 91

Recovery using a Golden Image 91
On the client 91
Steps 91
On the Ignite-UX Server 92
Steps 92
Recovery from the bootable backup tape 92
Steps 92
Recovery from the network 92
Using system recovery tools (make_tape_recovery, make_net_recovery) 93
Prerequisites 93
Creating an archive using make_tape_recovery 94
Creating an archive using make_net_recovery 94
Disk Delivery Disaster Recovery (DDDR) 94
Overview 94
Limitations 95
Preparation for Disk Delivery Disaster Recovery of UNIX Clients 95
One-time preparation 96
HP-UX Example 96
Solaris Example 96
AIX 96
Preparing the auxiliary disk 97
Backing up the system 97
Creating the Backup Specification for Disaster Recovery of a UNIX Client 97
Steps 97
Installing and Configuring a UNIX Client Using DDDR 98
Prerequisites 98
Steps 98
Restoring System Data Using DDDR (UNIX Client) 99
Prerequisites 99
Steps 99
Phase 2 99
Phase 3 99
Overview 100
Requirements 101
Limitations 101
Disk and partition configuration 103
Preparation for Enhanced Automated Disaster Recovery 103
Additional preparations for the Cell Manager 103
Saving a Recovery Set to the Cell Manager 104
Saving the recovery set to the Cell Manager for all clients in the backup
specification 104
Steps 104
Saving the recovery set to the Cell Manager for a particular client in the backup
specification 105

Preparing a DR OS image 106
Steps 106
Recovering Linux Systems Using EADR 107
Prerequisites 107
Steps 108
Phase 1 108
Phase 2 109
Phase 3 110
Overview 110
Requirements 111
Limitations 111
Disk and partition configuration 112
Preparation for One Button Disaster Recovery 112
Preparatory steps 112
Creating the Backup Specification for One Button Disaster Recovery 113
Prerequisites 113
Limitations 113
Creating a backup specification for OBDR 114
Steps 114
Recovering Linux Systems Using OBDR 115
Prerequisites 115
Steps 115
Phase 1 115
Phase 2 117
Phase 3 117
Chapter 5: Troubleshooting disaster recovery 118
Before you begin 118
Troubleshooting Automatic Disaster Recovery 118
The AUTODR.log file 118
Debugging disaster recovery sessions 119
Windows 119
Linux systems 121
Setting omnirc options during disaster recovery 122
Windows systems 122
Linux systems 122
The drm.cfg file on Windows 122
Disabling the automatic collection of EADR or OBDR 123
Common Problems (All Methods) 123
You cannot perform a disaster recovery from a media copy or an object copy 123
You cannot log on after disaster recovery finishes 124

Disaster recovery fails due to inappropriate network settings 124
File system of type BTRFS has limited support 125
Troubleshooting Assisted Manual Disaster Recovery 125
"Cannot copy file" 125
Troubleshooting Enhanced Automated Disaster Recovery and One Button Disaster
Recovery 126
Automatic DR information could not be collected 126
Some non-critical errors were detected 127
Restore session fails if the device is created from StoreOnce/DDBoost device with
planned gateway 127
Network is not available during restore 128
Network is not available due to missing network drivers 128
EADR and OBDR online recovery fails when the Cell Manager and a client are in the
different domains 129
When encrypted control communication is enabled, Cell Manager does not respond
during an online recovery of a client 129
Auto logon does not work 129
Computer stops responding during EADR 130
Cannot create a CD ISO image for EADR of Microsoft Cluster Server 130
Creating a CD ISO image on a Microsoft Cluster Server client fails 130
Creating an ISO image fails when antivirus software is installed on media creation host 131
Volume is not re-mounted during phase 1 131
After a failed or aborted disaster recovery, Boot Descriptors are left 132
A wrong or no boot disk is selected on an Intel Itanium system 132
Disaster recovery fails with "There is not enough space" message 132
Disaster recovery of a Windows 8.1 client fails with "Cannot write: ([13] The data is
invalid. ) => not restored." message 133
Minor errors or warnings are displayed during a client backup 133
Cell Manager and RMA hosts are not responding 134
Troubleshooting Disaster Recovery of Internet Information Server 135
IIS dependent services do not start automatically 135
Appendix A: Example Preparation Tasks 136
Example of Moving Kill Links on HP-UX 11.x 136
Example of the Disaster Recovery Preparation Table for Windows 136
Send Documentation Feedback 138

Chapter 1: Introduction
Data Protector disaster recovery overview
This chapter provides a general overview of the disaster recovery process, explains the basic terms used in
the Disaster Recovery guide and provides an overview of disaster recovery methods.
A computer disaster refers to any event that renders a computer system unbootable, whether due to a
human error, hardware failure, or natural disaster. In these cases, it is most likely that the boot partition or
system partition of the computer is not available and the environment needs to be recovered before the normal
restore operation can begin. The disaster recovery includes repartitioning and/or reformatting the boot partition
and recovery of the operating system with all the configuration information that defines the environment. This
step must be completed in order to recover other user data.
For detailed information on disaster recovery, see the HPE Data Protector Disaster Recovery Guide.
Original system refers to the system configuration backed up by Data Protector before a computer disaster
hit the system.
Target system refers to the system after the computer disaster has occurred. The target system is typically
in a non-bootable state and the goal of Data Protector disaster recovery is to restore this system to the
original system configuration. The difference between the affected and the target system is that the target
system has all faulty hardware replaced.
A boot disk/partition/volume refers to the disk/partition/volume that contains the files required for the initial
step of the boot process, whereas the system disk/partition/volume refers to the disk/partition/volume that
contains the operating system files.
Note: Microsoft defines the boot partition as the partition that contains the operating system files and the
system partition as one that contains the files required for the initial step of the boot process.
Hosting system is a working Data Protector client used for Disk Delivery Disaster Recovery with Disk
Agent installed.
Auxiliary disk is a bootable disk that has a minimal operating system with networking and Data Protector
Disk Agent installed. It can be carried around and used to boot the target system in Phase 1 of Disk Delivery
Disaster Recovery of UNIX clients.
Disaster recovery operating system (DR OS) is the operating system environment where the process of
disaster recovery is running. It provides Data Protector a basic runtime environment (disk, network, tape and
filesystem access). It has to be installed and configured before the Data Protector disaster recovery can be
performed.
DR OS can be either temporary or active. Temporary DR OS is used exclusively as a host environment for
some other operating system restore along with the target operating system configuration data. It is deleted
after the target system is restored to the original system configuration. Active DR OS not only hosts the Data
Protector disaster recovery process but is also a part of the restored system because it replaces its own
configuration data with the original configuration data.
Critical volumes are the volumes required to boot the system and Data Protector volumes. Regardless of
the operating system, these include:

l Boot volume
l System volume
l the volume with Data Protector executables
l the volume where the IDB is located (for Cell Managers)
Note: If the IDB is located on more than one volume then all volumes where the IDB resides are
treated as critical.
Apart from the critical volumes stated above, CONFIGURATION is also a part of the critical volumes
set for Windows and Linux systems. On Windows systems, services are backed up as a part of the
CONFIGURATION backup.
On Windows systems, some items included in the CONFIGURATION object can be located on
volumes other than system, boot, Data Protector, or IDB volumes. In this case these volumes are also
a part of the critical volumes set:
l User profiles volume
l Certificate Server database volume on Windows Server systems
l Active Directory Service volume on domain controller on Windows Sever
l Quorum volume on Microsoft Cluster Server
On Linux systems, the CONFIGURATION object contains only data relevant for the automated
disaster recovery methods, such as volumes, mount points, network settings, and similar.
Online recovery is performed when Cell Manager is accessible. In this case most of Data Protector
functionalities are available (Cell Manager runs the session, restore sessions are logged in the IDB,
you can monitor the restore progress using the GUI, and so on).
Offline recovery is performed if the Cell Manager is not accessible (for example, due to network
problems, Cell Manager has experienced a disaster, online recovery has failed, and so on). Only
standalone, SCSI Library, File Library and Backup to Disk (B2D) devices can be used for offline
recovery. The Cell Manager can only be recovered offline.
Remote recovery is performed if all Media Agent systems specified in SRD file are accessible. If any
of them fails, disaster recovery process fails over to local mode. This means that the target system is
searched for locally attached devices. If only one device is found, it is automatically used. Otherwise
Data Protector prompts you to select the device which will be used for restore. Note that offline OBDR
is always local.
Disaster is a severe event, however, the following factors can exacerbate the situation:
l The system has to be returned to online status as quickly and efficiently as possible.
l Disaster recovery is not a common event and administrators may not be familiar with the required
steps.
l The available personnel to perform the recovery may only have fundamental system knowledge.
Disaster recovery is not provided as an already-defined, easy-to-use solution. It is a complex process
that involves extensive planning and preparation before execution. You have to thoroughly define a
step-by-step process to be prepared for swift recovery from disastrous situations.

Disaster recovery phasesprocess
The process of disaster recovery is split into four consecutive phases, regardless of the recovery
method:
1. Phase 0
2. Phase 1
3. Phase 2
4. Phase 3
1. Phase 0 (preparation) is the prerequisite for a successful disaster recovery. The planning and
preparation must be done before a disaster occurs.
2. In Phase 1, DR OS is installed and configured, which usually includes repartitioning and
reformatting of the boot partition, since the boot or system partition of the system are not always
available and the environment needs to be recovered before normal restore operations can
resume.
3. The operating system with all the configuration information that defines the environment with Data
Protector (as it was) is restored in Phase 2.
4. Only after this step is completed, is the restore of applications and user data possible (Phase 3).
A well-defined, step-by-step process has to be followed to ensure fast and efficient restore.
Disaster Recovery Methods
This section provides a general overview of disaster recovery methods. For lists of disaster recovery
methods that are supported on different operating systems, see the latest support matrices at
http://support.openview.hp.com/selfsolve/manuals.
Note: Each disaster recovery method has limitations you should consider before implementation.
"Overview of disaster recovery methods" below provides an overview of the Data Protector disaster
recovery methods.
Overview of disaster recovery methods
Phase 0 Phase 1 Phase 2 Phase 3
Manual Disaster Recovery
Full filesystem backup
of the entire system,
Internal Database
backup (Cell Manager
only). Update the SRD
file (Windows systems
only). Collect
Install DR OS with
network support.
Repartition the disk
and re-establish the
original storage
structure.
Execute the drstart
command to
automatically recover
critical
volumes.Additional
steps are required to
perform advanced
Restore user and
application data using
the standard Data
Protector restore
procedure.

information on the
original system to
enable installation and
configuration of the DR
OS.
recovery tasks.
See "Assisted Manual Disaster Recovery (AMDR) " on page 22 or "Manual Disaster Recovery
(MDR) " on page 86.
Disk Delivery Disaster Recovery (DDDR) (UNIX systems only)
internal Database
only), create the
auxiliary disk.
Connect the auxiliary
disk to the target
system.
Repartition the
replacement disk and
re-establish the original
storage structure.
Restore the boot disk
of the original system
onto the replacement
disk, remove the
auxiliary boot disk.
Restart the system.
Additional steps are
required to perform
advanced recovery
tasks.
Restore user and
the standard Data
Protector restore
procedure.
See "Disk Delivery Disaster Recovery (DDDR) " on page 94.
Enhanced Automated Disaster Recovery (EADR)
Internal Database
only). Prepare and
update the SRD file.
Prepare the DR OS
image.
Boot the system from
the disaster recovery
CD, USB flash drive,
or network and select
the scope of recovery.
Automatic restore of
critical volumes.
Additional steps are
required to perform
advanced recovery
tasks.
Restore user and
the standard Data
Protector restore
procedure.
See "Enhanced Automated Disaster Recovery (EADR) " on page 35 or "Enhanced Automated
Disaster Recovery (EADR) " on page 100.
One Button Disaster Recovery (OBDR)
of the entire system
using the OBDR
wizard.Prepare and
update the SRD file.
Boot the target system
from the OBDR tape
and select scope of
recovery.
Automatic restore of
critical volumes.
Restore user and
the standard Data
Protector restore
procedure.
See "One Button Disaster Recovery (OBDR) " on page 53 or "One Button Disaster Recovery
(OBDR) " on page 110.
The following has to be completed before you can proceed to the next phase:

l Phase 0:
A full client backup and the IDB backup (on Cell Manager only) must be performed, and enough
information must be collected by the administrator from the original system to enable installation and
configuration of the DR OS. An auxiliary boot disk should be created for Disk Delivery Disaster
Recovery of UNIX systems.
l Phase 1:
DR OS must be installed and configured and the original storage structure must be re-established
(all volumes are ready to be restored). The replacement disk for Disk Delivery Disaster Recovery on
UNIX must be made bootable.
l Phase 2:
Critical volumes are restored. Additional steps to perform advanced recovery tasks are required.
See the section “Advanced recovery tasks”.
l Phase 3:
Check if application data is restored correctly (for example, databases are consistent).
Manual disaster recovery method
This is a basic disaster recovery method that involves recovering the target system to the original
system configuration.
First, you have to install and configure the DR OS. Then use Data Protector to restore data (including
the operating system files) replacing the operating system files with the restored operating system
files.
With manual recovery, it is important to collect the information regarding the storage structure, which is
not kept in flat files (such as partition information, disk mirroring, and striping).
Disaster recovery using disk delivery
The Disk Delivery Disaster Recovery method (DDDR) is supported on UNIX clients. For details on
supported operating systems, see the HPE Data Protector Product Announcements, Software Notes,
and References.
This method works without an additional client and requires a bootable auxiliary disk (which can be
carried around) with a minimal operating system, networking, and a Data Protector Disk Agent
installed. You need to collect enough information before the disaster to be able to correctly format and
partition the disk.
This is a fast and simple method to recover clients.
Tip: This method is especially useful with hot swap hard disk drives, because you can disconnect
a hard disk drive from a system and connect a new one while the power is still on and the system is
operating.
See "Disk Delivery Disaster Recovery (DDDR) " on page 94.

Enhanced Automated Disaster Recovery (EADR)
Data Protector offers an enhanced disaster recovery procedure for Windows and Linux Data Protector
clients and Cell Managers where user intervention is reduced to a minimum.
The EADR procedure collects all relevant environment data automatically at backup time. During a
configuration backup, data required for temporary DR OS setup and configuration is packed in a single
large DR image (recovery set) file is stored on the backup tape (and optionally on the Cell Manager)
for each backed-up client in the cell.
In addition to this image file, a Phase 1 startup information (stored in the P1S file), required for correct
formatting and partitioning of the disk is stored on the Cell Manager. When a disaster occurs, you can
use the EADR wizard to restore the DR OS image from the backup medium (if it has not been saved on
the Cell Manager during the full backup). You can either convert it to a disaster recovery CD ISO
image, save it on a bootable USB drive, or create a bootable network image. You can then record the
CD ISO image on a CD using any CD recording tool.
When you boot the target system from the CD, USB drive, or over the network, Data Protector
automatically installs and configures the DR OS, formats and partitions the disks, and finally recovers
the original system with Data Protector as it was at the time of backup.
The recovered volumes are:
l The boot volume
l The system volume
l The volume containing the Data Protector installation and configuration
Any remaining volumes can be recovered using the standard Data Protector restore procedure.
One Button Disaster Recovery (OBDR) is an automated Data Protector disaster recovery method for
Windows and Linux Data Protector clients, where user intervention is reduced to minimum. It is based
on the concept of using an OBDR device and copying an image file onto a tape. For details on
supported operating systems, see the HPE Data Protector Product Announcements, Software Notes,
and References.
During OBDR backup, data required for the temporary DR OS installation and configuration is packed
in a single large OBDR image file and stored on the backup tape. When a disaster occurs, the OBDR
device is used to boot the target system directly from the tape which contains the OBDR image file
with disaster recovery information. Data Protector then installs and configures the DR OS, formats and
partitions the disks and finally restores the original operating system with Data Protector as it was at
the time of backup.
The automatically-recovered volumes are:
l The boot volume
l The system volume
l The volume containing the Data Protector installation and configuration
The remaining volumes can be recovered using the standard Data Protector restore procedure.

You need to prepare a new OBDR boot tape locally on the client after each hardware, software or
configuration change. This also applies to any network configuration changes, such as change of IP
address or DNS server.
HPE recommends to restrict access to backup media, DR images, SRD files and disaster recovery
CDs and USB drives storing DR OS data
Data Protector integrations and disaster
recovery
Disaster recovery is a very complex process that involves products from several vendors. As such,
successful disaster recovery depends on all the vendors involved. Use the information provided here
only as a guideline.
Check the instructions of the database/application vendor on how to prepare for disaster recovery.
This is a general procedure on how to recover an application:
1. Perform Disaster Recovery.
2. Install, configure, and initialize the database/application so that data on Data Protector media can
be loaded back to the system. Consult database/application vendor documentation for a detailed
procedure and steps needed to prepare the database.
3. Ensure that the database/application server has the required Data Protector client software
installed and is configured for the database/application. Follow the procedures in the appropriate
HPE Data Protector Integration Guide.
4. Start the restore. When the restore is complete, follow the instructions of the database/application
vendor for any additional steps required to bring the database back online.

Chapter 2: How to Prepare for Disaster
Recovery
Carefully follow the instructions below to prepare for disaster recovery and ensure a fast and efficient restore.
The preparation procedure does not depend on the disaster recovery method, and includes developing a
detailed disaster recovery plan, performing consistent and relevant backups, and updating the SRD file on
Windows.
This chapter contains the general preparation procedure for disaster recovery for all disaster recovery
methods. Additional preparation is required for each particular disaster recovery method. For additional
preparation steps, see the corresponding topics.
Remember that preparing the Cell Manager for disaster recovery is critical and requires more attention.
Prepare for disaster recovery before a disaster occurs.
Planning
Developing a detailed disaster recovery plan has a major impact on the success of a disaster recovery. To
deploy disaster recovery in a large environment with many different systems, proceed as follows:
1. Plan
Planning must be prepared by IT administration and should include the following steps:
l Make a list of the most important systems that should be recovered first. Critical systems are
systems required for a network to function properly (DNS servers, domain controllers, gateways, and
so on), Cell Managers, and Media Agent clients. They should be recovered prior to all other systems.
l Select the disaster recovery methods that are appropriate for your systems. Based on these
methods, consider which preparation steps are required for each system.
l Determine a method to obtain the required information at recovery time, such as the media that stores
the IDB, the location of the updated SRD file, and the location and labels of the Cell Manager backup
media. Define the location of software libraries to enable the performance of new installations.
l Create a step-by-step detailed checklist to guide you through the process.
l Create and execute a test plan to confirm that the recovery will actually work.
2. Prepare for recovery
Perform the following preparation steps before running the backup to guarantee environmental
consistency during the backup:
All systems:

l Perform regular and consistent backups.
l You need to understand volume groups and partition concepts. On UNIX systems, you should
know where the information about the storage environment structure resides.
UNIX systems:
l Create pre-exec scripts, which collect the storage structure, and perform other client-specific
preparations.
l Create tools, such as the auxiliary disk with the minimum operating system, network
resources, and the Data Protector Disk Agent installed.
Windows systems:
l Ensure that you have a valid CONFIGURATION backup at your disposal.
l Update the SRD file and store it in a safe place. You should restrict access to SRD files due to
security considerations.
3. Perform recovery procedures
Follow the procedures and checklists you have tested to recover the affected system.
Caution: Do not change the default Inet listen port on systems that are prepared for disaster
recovery. In the opposite case, if such systems are struck by a disaster, the disaster recovery
process may fail.
Consistent and relevant backups
In case of a disaster, the target system should be returned to the original system configuration.
Additionally, the system is expected to operate and function as it did just before the last valid backup
was performed.
Note: On UNIX systems, some daemons or processes are active as soon as the system finishes
booting, for various reasons (the run-level 2). Such processes may even read data into memory and
write a “dirty flag” into some file while it runs. A backup taken at the standard operating stage (the
standard run-level 4) cannot be expected to yield a problem-free restart of such an application. To
follow the example, the license server, if started after such a pseudo recovery, will realize that the
data read from the file is inconsistent and will refuse to run the service as expected.
On Windows systems, while the system is up and running, many system files cannot be replaced
because the system keeps them locked. For example, the user profiles that are currently being
used cannot be restored. Either the login account must be changed or the relevant service must be
stopped.
Depending on what is active on the system when the backup runs, the data consistency of an
application can be violated, causing re-start and execution issues after the recovery.
Chapter 2: How to Prepare for Disaster Recovery

Creating a consistent and relevant backup
l Ideally, you would perform a backup with the relevant partition(s) set offline, which is often not
possible.
l Examine the activity on the system during the backup. Only operating system-related processes
and database services which are backed up online can remain active during the backup execution.
l Ensure minimal system activity. For example, only the core operating system, basic networking,
and backup should be active. None of the low-level application services should be running. This can
be achieved using an appropriate pre-exec script.
Disaster recovery uses data from the btrfs sub volumes and volumes backed up through the root of the
file system (cross file system boundary) to create a Disaster Recovery ISO image, and perform
recovery and restore. This implies that all system, profile, and relevant user data must be included in
the backup of the / (root) file system object. All separately backed up data (one using the OB2_
SHOW_BTRFS_MOUNTS) can be used only for the regular Disk Agent file system restore operations and
not for the recovery process. This applies to the Linux operating system only.
Note: Data Protector includes data from the manually created btrfs snapshots.
What should be included in the consistent and relevant backup depends on the disaster recovery
method you plan to use and other system specifics (for example, disaster recovery of Microsoft Cluster
Server). See the topics pertaining to preparation for particular disaster recovery methods.
Encrypted backups
If your backups are encrypted, you must ensure that the encryption keys are safely stored and
available when you start a disaster recovery. Without the access to the appropriate encryption key, the
disaster recovery procedure aborts. Different disaster recovery methods have additional requirements.
The encryption keys are stored centralized on the Cell Manager; thus the disaster recovery client must
be connected to the Cell Manager to get the encryption key. For details on encryption concepts, see the
HPE Data Protector Help index: "encryption".
Two disaster recovery scenarios are possible:
l Recovery of a client where you can establish a connection to the Cell Manager. No additional
encryption related preparations are needed for such a scenario, as Data Protector automatically
obtains the encryption keys.
l Disaster recovery of a Cell Manager or standalone client recovery, where you cannot establish a
connection the Cell Manager.
You must provide the encryption keys on removable media (for example a diskette) when prompted.
The keys are not part of the disaster recovery OS image and are exported to the key file (DR-
ClientName-keys.csv). You must manually store the keys to a separate removable media, such as
a diskette or USB flash drive. Ensure that you have always an appropriate copy of the keys for each
backup that is prepared for disaster recovery. If the encryption key is not available, disaster recovery
is not possible.

Updating and Editing the System Recovery
Data
The System Recovery Data (SRD) is a text file in the Unicode (UTF-16) format that contains
information required to configure the target system. The SRD file is generated when a
CONFIGURATION backup is performed on a Windows client and then stored on the Cell Manager into
the directory:
Windows systems: Data_Protector_program_dataConfigServerDRSRD
UNIX systems: /etc/opt/omni/server/dr/srd.
When IDB is not available, information about objects and media is stored only in the SRD file.
The SRD filename on the Cell Manager is identical to the hostname of the computer on which it was
generated (for example, computer.company.com).
After the CONFIGURATION backup, the SRD file contains only system information required for
installation of the DR OS. In order to perform a disaster recovery, additional information about backup
objects and corresponding media must be added to the SRD. The SRD can be updated only on a
Windows or Linux client. The name of the updated SRD file is recovery.srd.
There are three different methods possible for updating the SRD file:
l Update SRD File wizard (from Windows systems only)
l omnisrdupdate command as a standalone utility
l omnisrdupdate command as a backup session post-exec script
When you update the SRD file for Cell Manager, specify an IDB backup session which is newer than
the filesystem backup session so that you can browse the file system backup sessions and data after
a recovery.
For a detailed procedure on how to update the SRD file, see "Updating the SRD File (Windows Clients)
" on page 27.

Chapter 3: Disaster recovery on Windows
systems
Assisted Manual Disaster Recovery (AMDR)
While being recovered, Windows requires an installation of disaster recovery operating system (DR OS). The
procedure of recovering the original operating system is automated by the omnidr command.
Windows systems provide additional possibilities for recovering a system before deciding for a disaster
recovery. This can be done by booting the system in the Safe mode or from the recovery floppy disks and
trying to resolve the problems.
Overview
Ensure that you have performed all the general preparation steps that are mentioned in the preparation
chapter.The general procedure for Assisted Manual Disaster Recovery of a Windows system is:
1. Phase 1
a. Replace the faulty hardware.
b. Reinstall the operating system (create and format the necessary volumes).
c. Reinstall service packs.
d. Manually re-partition the disk and re-establish the storage structure with original drive letter
assignments.
Tip: You can combine Phase 1 of Manual Disaster Recovery with automated deployment tools.
2. Phase 2
a. Execute the Data Protector drstart command that will install the DR OS and start the restore of
critical volumes.
b. The system must be restarted after the drstart command finishes.
c. Additional steps are required if you are recovering a Cell Manager or performing advanced recovery
tasks. For more information, see “Advanced tasks” (page 72).
3. Phase 3
a. Use the Data Protector standard restore procedure to restore user and application data.
Requirements
l The partitions must be the same size or bigger than the partitions on the failed disk. This way the
information stored on the crashed disk can be restored to the new one. Also, the type of the filesystem
(FAT, NTFS) and compression attributes of the new volumes must match.

l The hardware configuration of the target system must be the same as of the original system. This
includes SCSI BIOS settings (sector remapping).
l All hardware has to be the same.
Steps
1. "Preparation for Assisted Manual Disaster Recovery (Windows Systems) " below.
2. "Installing and Configuring a Windows System Manually " on page 30.
3. "Restoring System Data Manually (Windows Systems) " on page 32.
4. "Restoring Vendor-Specific Partitions (Windows systems) " on page 34.
5. Restore user data.
Preparation for Assisted Manual Disaster Recovery
(Windows Systems)
To prepare for a successful disaster recovery, follow the instructions related to the general preparation
procedure for disaster recovery before performing the steps listed in this topic. Prepare in advance in
order to perform a disaster recovery fast and efficiently. You should pay special attention to disaster
recovery preparation for the Cell Manager.
General preparations
Before completing the steps listed in this section, see also "Planning" on page 18 for the general
preparation procedure for all disaster recovery methods. To recover from a disaster quickly and
efficiently, consider the following steps and prepare your environment accordingly:
1. You need a Windows bootable installation CD-ROM to enable your system to start from the CD-
ROM. You can also use the Windows diskettes if you do not have a bootable CD-ROM drive.
2. Ensure that you have the drivers for the system that you want to recover. You may need to install
some drivers, such as HBA and SCSI drivers, during Windows Setup.
3. To recover the affected system, you need the following information about the system before the
disaster:
l If DHCP was not used before the disaster, the TCP/IP properties (IP address, default gateway,
subnet mask and DNS order (IPv4), subnet prefix length, preferred and alternate DNS server
(IPv6))
l Client properties (hostname, domain)
4. Ensure that the following is true:
Chapter 3: Disaster recovery on Windows systems

l You should have a valid full client backup image (including valid CONFIGURATION backup
data). See the HPE Data Protector Help index: “backup, Windows specific” and “backup,
configuration”.
l You should have an SRD file, updated with information about the objects from the backup
sessions that you plan to use for the recovery.
l For recovery of the Cell Manager, you should have a valid Internal Database backup image,
created after the client backup image. For more information on how to configure and perform an
IDB backup, see the HPE Data Protector Help index: “IDB, configuration”.
l In case of Microsoft Cluster Server, consistent backup also includes (in the same backup
session)
o all nodes
o administrative virtual server (defined by the administrator)
o if Data Protector is configured as a cluster-aware application, also Cell Manager virtual
server and IDB.
For details, see "About Disaster Recovery of a Microsoft Cluster Server " on page 66.
l The disk with the boot partition requires free disk space for the Data Protector disaster
recovery installation (15 MB) and an DR OS installation. Additionally, you need as much free
disk space as required for the restore of the original system.
5. Copy the drsetup images (“drsetup diskettes”) onto a USB flash drive or floppy disks. The number
of diskettes depends on the platform and the version of the Windows operating system. The
images are located in:
l 32-bit Windows systems:
Windows Vista and later releases: Data_Protector_program_dataDepotDRSetupX86
Windows XP, Windows Server 2003: Data_Protector_homeDepotDRSetupX86
Data Protector installation medium: i386toolsDRSetupX86
l 64-bit Windows systems on the AMD64/Intel EM64T platform:
Windows Vista and later releases: Data_Protector_program_dataDepotDRSetupX64
Windows XP, Windows Server 2003: Data_Protector_homeDepotDRSetupX64
Data Protector installation medium: i386toolsDRSetupX64
l 64-bit Windows systems on the Itanium platform:
Windows Vista and later releases: Data_Protector_program_dataDepotDRSetupIA64
Windows XP, Windows Server 2003: Data_Protector_homeDepotDRSetupIA64
Data Protector installation medium: i386toolsDRSetupIA64
In case of a disaster, save the updated SRD file of the affected system to the first floppy disk
(disk 1). Only one set of floppy disks is required per site for all Windows systems, but you must
always copy the updated SRD file of the affected client onto the first floppy disk. If multiple SRD
files are found, Data Protector will ask you to select the appropriate version.
6. In order to re-create disk partitions as they existed before the disaster, record the following

information for each partition (it will be needed during the recovery process):
l partition length and order
l drive letter assigned to the partition
l partition filesystem type
This information is stored in the SRD file. The -type option in the diskinfo section of the SRD file
shows the volume filesystem type for a particular volume:
How to determine the filesystem type from the SRD File
Type number Filesystem
1 Fat12
4 and 6 Fat32
5 and 15 Extended partition
7 NTFS
11 and 12 Fat32
18 EISA
66 LDM partition
The table on the next page is an example of the preparation for the disaster recovery. Note that data in
the table belongs to a specific system and cannot be used on any other system. For an empty template
which can be used when preparing for the Assisted Manual Disaster Recovery, see "Example of the
Disaster Recovery Preparation Table for Windows " on page 136.
Updating the recovery diskettes using the CLI
Data Protector does not offer a command to automatically create recovery images (diskettes).
However, you can manually update the contents of the first diskette in the recovery set by executing
the omnisrdupdate command. Insert the first diskette from the recovery set in to the floppy disk drive
and specify a: as the location, for example:
Data Protector client system:
omnisrdupdate -session 10/04/2011-1 -host clientsys.company.com -location a: -asr
Data Protector Cell Manager:
omnisrdupdate -session 10/04/2011-1 10/04/2011-2 -host cmsys.company.com -location
a: -asr
To manually create a recovery diskette, you also need to copy the DRDiskNumber.cab files from Data_
Protector_program_dataDepotDRSetupDiskDiskNumber folders to the appropriate recovery
diskette.

Limitations
l The Internet Information Server database, Terminal Services database and Certificate Server
database are not restored automatically during Phase 2. They can be restored on the target system
using the standard Data Protector restore procedure.
l Using resumed object backups for recovery is not supported since the consistency of such backups
cannot be guaranteed.
Example of the Disaster Recovery Preparation Table for
Windows
Client properties Computer name ANAPURNA
Hostname anapurna.company.com
Drivers tatpi.sys, aic78xx.sys
Windows Service Pack Windows Vista
TCP/IP properties for IPv4 IP address 10.17.2.61
Default gateway 10.17.250.250
Subnet mask 255.255.0.0
DNS order 10.17.3.108, 10.17.100.100
TCP/IP properties for IPv6 IP address td10:1234:5678:abba::6:1600
Subnet prefix length 64
Default gateway td10:1234:5678:abba::6:1603
Preferred DNS server td10:1234:5678:abba::6:1603
Alternate DNS server td10:1234:5678:abba::6:1604
Medium label/barcode number "anapurna - disaster recovery" /
[000577]

Partition information and
order
1st disk label
1st partition length 31 MB
1st drive letter
1st filesystem EISA
2nd disk label BOOT
2nd partition length 1419 MB
2nd drive letter C:
2nd filesystem NTFS/HPFS
3rd disk label
3rd partition length
3rd drive letter
3rd filesystem
Updating the SRD File (Windows Clients)
After the CONFIGURATION backup the SRD file contains only system information required for
installation of the DR OS. It is located on the Cell Manager:
Windows systems: Data_Protector_program_dataConfigServerDRSRD
UNIX systems: /etc/opt/omni/server/dr/srd
In order to perform a disaster recovery, additional information about backup objects and corresponding
media must be added to the SRD. The SRD can be updated only on a Windows client. The SRD
filename on the Cell Manager is identical to the hostname of the computer where it was generated - for
example computer.company.com. The name of the updated SRD file is recovery.srd.
It is possible, that the information about backup devices or media stored in the SRD file is out of date at
the time disaster recovery is being performed. In this case, edit the SRD file to replace the incorrect
information with the relevant information before performing the disaster recovery.
Store the Cell Manager SRD file in a safe place (not on the Cell Manager). It is recommended to restrict
access to the SRD files.

Updating the SRD file using the Data Protector Disaster
Recovery Wizard on Windows systems
Steps
1. In the Data Protector Context List, click Restore.
2. In the Scoping Pane, click Task, and then click Disaster Recovery to open the Disaster
Recovery Wizard.
3. In the Host drop-down list, select the system for which you want to update the SRD file.
4. In the Disaster Recovery Method list, select SRD file update. Click Next.
Data Protector first searches the Cell Manager for the SRD file. If it is not found, Data Protector
restores it from the last backup.
5. Select the objects and versions needed to restore the logical volumes and the system
configuration. Click Next for each object.
6. Specify the destination for the SRD file. Click Finish.
Updating the SRD file using the omnisrdupdate command
You can use omnisrdupdate as a standalone command.
To update the SRD file, either modify an existing backup specification or create a new one with a
specified post-exec script.
Steps
1. In the Data Protector Context List, click Backup.
2. In the Scoping Pane, expand Backup Specifications and then Filesystem. All saved backup
specifications are displayed.
3. Click the backup specification that you want to modify.
4. In the Options property page, under the Backup Specification Options, click Advanced.
5. In the Backup Options window, type omnisrdupdate in the Post-exec text box.
6. In the On client drop-down list, select the client on which this post-exec script will be executed,
then click OK.
7. Click Apply to save the change and exit the wizard.
Updating the SRD file using a post-exec script
Another method to update the SRD is using the omnisrdupdate command as a backup post-exec
script. To do so, either modify an existing backup specification or create a new one. Perform the
following steps to modify a backup specification so that the SRD file is updated with information about
backed up objects when the backup session stops:

1. In the Backup context, expand the Backup Specifications item and then Filesystem.
2. Select the backup specification that you would like to modify (it must include all backup objects
marked as critical in the SRD file, otherwise the update will fail. It is recommended to perform the
client backup with disk discovery) and click Options in the Results Area.
3. Click the Advanced button under the Backup Specification Options.
4. Type omnisrdupdate in the post-exec text box.
5. In the On client drop down list, select the client on which this post-exec script will be executed and
confirm with OK. This should be the client that was marked for backup on the source page.
When the omnisrdupdate command is executed as a post-exec utility, the session IDs are obtained
automatically, without needing to be specified.
All other options can be specified the same way as with the standalone utility (-location Path, -
host ClientName).
You cannot use omnisrdupdate in a post-exec script to update the SRD for a Cell Manager because the
IDB is backed up in a separate session.
Example of Editing the SRD File
If the information in the SRD file is not up to date anymore (for example, you changed a backup device),
modify the updated SRD file (recovery.srd) before performing Phase 2 of disaster recovery to
update the wrong information and thus enable a successful recovery.
You can display some of the device configuration information using the devbra -dev command.
Changing the MA client
You performed a backup for disaster recovery purposes using a backup device connected to the client
old_mahost.company.com. At the time of disaster recovery, the same backup device is connected to
the client new_mahost.company.com with the same SCSI address. To perform a disaster recovery,
replace the -mahost old_mahost.company.com string in the updated SRD file with -mahost new_
mahost.company.com before performing the Phase 2 of disaster recovery.
If the backup device has a different SCSI address on the new MA client, modify also the value of the -
devaddr option in the updated SRD file accordingly.
After you have edited the file, save it in Unicode (UTF-16) format to the original location.
Changing the backup device
To perform disaster recovery using another device than the one which was used for the backup, modify
the following option values in the updated SRD file:
-dev, -devaddr, -devtype, -devpolicy, -devioctl, and -physloc
Where:
-dev specifies the logical name of the backup device or drive (library) to be used for the
backup,

-devaddr specifies its SCSI address,
-devtype specifies the Data Protector device type,
-devpolicy specifies the device policy, which can be defined as 1 (Standalone), 3 (Stacker), 5
(Jukebox), 6 (external control), 8 (Grau DAS exchanger library), 9 (STK Silo medium
library) or 10 (SCSI-II Library),
-devioctl specifies the robotics SCSI address.
-physloc specifies the library slot
-storname specifies the logical library name
For example, you performed a backup for disaster recovery purposes using an HPE Ultrium standalone
device with the device name Ultrium_dagnja, connected to the MA host dagnja (Windows systems).
However, for the disaster recovery you would like to use an HPE Ultrium robotics library with the
logical library name Autoldr_kerala with drive Ultrium_kerala connected to the MA client kerala
(Linux systems).
First, run the devbra -dev command on kerala to display the list of configured devices and their
configuration information. You will need this information to replace the following option values in the
updated SRD file:
-dev "Ultrium_dagnja" -devaddr Tape4:1:0:1C -devtype 13 -devpolicy 1 -mahost
dagnja.company.com
with something like:
-dev "Ultrium_kerala" -devaddr /dev/nst0 -devtype 13 -devpolicy 10 -devioctl
/dev/sg1 -physloc " 2 -1" -storname "AutoLdr_kerala" -mahost kerala.company.com.
Installing and Configuring a Windows System Manually
After a disaster happens, you should first install and configure the operating system. After installing the
operating system, you can proceed with the system data recovery.
Steps
Phase 1
1. Install the Windows system from the CD-ROM and install additional drivers if needed. The
Windows operating system has to be installed on the same partition that it was installed on before
the disaster. Do not install the Internet Information Server (IIS) during the installation of the
system.
If the Windows operating system has been installed using the unattended setup, use the same
script now to re-install Windows to make sure that both the %SystemRoot% and
%SystemDrive%Documents and Settings folders are installed to the same location.

2. When the Windows Partition Setup screen appears, proceed as follows:
l If an EISA Utility Partition (EUP) existed on the system before the disaster, create (if it does not
exist due to the disaster) and format a “dummy” FAT partition using the EUP information stored
in the SRD file. The EUP will later on be recovered to the space occupied by the “dummy”
partition. Create and format a temporary boot partition immediately after the “dummy” partition.
l If an EUP did not exist on the system before the disaster, create (if the boot partition does not
exist due to the disaster) and format the boot partition as it existed on the disk before the
disaster.
When the Windows Setup prompts you for the Windows installation directory, specify a new
directory on the boot partition equal to the directory where the original Windows installation
resided.
Note: During the installation, do not add the system to a Windows domain where it had
previously resided, but to a workgroup. If you are restoring a Primary Domain Controller
(PDC), ensure that the target restore system is not located in the domain that had been
controlled by the affected PDC.
3. Install the TCP/IP protocol. If DHCP was not used before the disaster, configure the TCP/IP
protocol as it was before the disaster by providing the following information: the hostname of the
affected client, its IP address, default gateway, subnet mask and DNS server. This information
can be obtained from the SRD file. Make sure that the field labeled Primary DNS suffix of this
computer contains your domain name.
Note: By default, Windows install the Dynamic Host Configuration Protocol (DHCP) during
the Windows setup.
4. Create a new temporary disaster recovery account in the Windows Administrators group (for
example, DRAdmin) and add it to the Data Protector Admin group on the Cell Manager. See the
HPE Data Protector Help index: “adding Data Protector users”.
The user account must not have existed on the system before the disaster. The temporary
Windows user account will be removed later on during this procedure.
5. Log off and log on to the system using the newly created account.
6. Create and format all unformatted partitions (including the “dummy” EISA Utility Partition, if used),
as they existed on the disk before the disaster. Use the vendor specific procedure for creating
utility partitions. The “dummy” EISA Utility Partition has to be formatted as a FAT filesystem.
Assign drive letters as they were assigned before the disaster.
Phase 2
1. If the information in the SRD file is not up to date (for example, because you changed the backup
device after the disaster) and you are performing an offline recovery, edit the SRD file before
continuing with this procedure.
2. Run drstart from the Data_Protector_homeDepotdrsetupdisk1 (Cell Manager) or
i386toolsdrsetupdisk1 (Data Protector installation medium) directory.
If you have prepared the drsetup diskettes, you can also run drstart from the first diskette.
3. drstart first scans the current working directory, floppy disk drive, and CD-ROM drive for the

location of disaster recovery setup files (dr1.cab and omnicab.ini). If the required files are
found, the drstart utility installs the disaster recovery files in the
%SystemRoot%system32OB2DR directory. If these files are not found, browse for them or enter
their path in the DR Installation Source text box.
4. If the SRD file (recovery.srd) is found in the same directory as dr1.cab and omnicab.ini,
drstart copies recovery.srd to the %SystemRoot%system32OB2DRbin directory and the
omnidr utility is started automatically. Otherwise, you can enter the location of the SRD file
(recovery.srd) in the SRD Path text box or browse for the file. Click Next.
If multiple SRD files are found on the floppy disk, Data Protector will ask you to select an
appropriate version of the SRD file.
After omnidr successfully finishes, all critical objects required for a proper boot of the system are
restored.
5. Remove the temporary Data Protector user account (added during the Phase 1) from the Data
Protector Admin group on the Cell Manager, unless it existed on the Cell Manager before the
disaster recovery.
6. Restart the system, log on and verify that the restored applications are running.
Phase 3
6. Additional steps are required if you are recovering a Cell Manager or performing advanced
recovery tasks (such as restoring MSCS or IIS, editing the kb.cfg and SRD files). For more
information, see "Restoring the [%=DP.DP_BriefProductName%] Cell Manager specifics" on
page 71 and the “Advanced recovery tasks” section.
7. Restore user and application data using the standard Data Protector restore procedure.
The temporary DR OS will be deleted after the first login, except in the following cases:
l You interrupt the Disaster Recovery Wizard during the 10 second pause (after it has found the DR
installation and the SRD file on the backup medium) and select the Debugs option.
l You manually execute the omnidr command with the -no_reset or -debug option.
l Disaster recovery fails.
Restoring the Data Protector Cell Manager specifics
After you have performed the general Manual Disaster Recovery procedure of a Windows system,
perform additional steps to restore the Cell Manager using Data Protector.
To make the IDB recovery consistent, you restore the information about the backed up objects that
was not restored during the disaster recovery. To do this, update the IDB by importing the media with
the Cell Manager full client backup used for the disaster recovery.
Restoring System Data Manually (Windows Systems)
After you have installed and configured the operating system (Phase 1), you can use Data Protector to
recover the Data Protector client or Cell Manager. Disaster recovery of the Cell Manager and Internet
Information Server (IIS) requires additional steps.

Restoring the Windows system
Steps
Phase 2
2. Run drstart from the Data_Protector_homeDepotdrsetupdisk1 (Cell Manager) or
i386toolsdrsetupdisk1 (Data Protector installation medium) directory.
If you have prepared the drsetup diskettes, you can also run drstart from the first diskette.
3. drstart first scans the current working directory, floppy disk drive, and CD-ROM drive for the
location of disaster recovery setup files (dr1.cab and omnicab.ini). If the required files are
found, the drstart utility installs the disaster recovery files in the
%SystemRoot%system32OB2DR directory. If these files are not found, browse for them or enter
their path in the DR Installation Source text box.
4. If the SRD file (recovery.srd) is found in the same directory as dr1.cab and omnicab.ini,
drstart copies recovery.srd to the %SystemRoot%system32OB2DRbin directory and the
omnidr utility is started automatically. Otherwise, you can enter the location of the SRD file
(recovery.srd) in the SRD Path text box or browse for the file. Click Next.
If multiple SRD files are found on the floppy disk, Data Protector will ask you to select an
appropriate version of the SRD file.
After omnidr successfully finishes, all critical objects required for a proper boot of the system are
restored.
5. Remove the temporary Data Protector user account (added during the Phase 1) from the Data
Protector Admin group on the Cell Manager, unless it existed on the Cell Manager before the
disaster recovery.
6. Restart the system, log on and verify that the restored applications are running.
Phase 3
recovery tasks (such as restoring MSCS or IIS, editing the kb.cfg and SRD files). For more
information, see "Restoring the [%=DP.DP_BriefProductName%] Cell Manager specifics" on
page 71 and the “Advanced recovery tasks” section.
The temporary DR OS will be deleted after the first login, except in the following cases:
l You interrupt the Disaster Recovery Wizard during the 10 second pause (after it has found the DR
installation and the SRD file on the backup medium) and select the Debugs option.

Restoring the Data Protector Cell Manager specifics
After you have performed the general Manual Disaster Recovery procedure of a Windows system,
perform additional steps to restore the Cell Manager using Data Protector.
To make the IDB recovery consistent, you restore the information about the backed up objects that
was not restored during the disaster recovery. To do this, update the IDB by importing the media with
the Cell Manager full client backup used for the disaster recovery.
Restoring Vendor-Specific Partitions (Windows
systems)
If needed, conclude the general Manual Disaster Recovery procedure with the recovery of vendor-
specific partitions (VSP).
Disclaimer
Recovering a VSP may be a complex procedure, requiring advanced skills and knowledge of the
Windows operating system. The information provided here is meant for your convenience only. You
should use this information at your own risk. If the partition order has changed after the restore of a
VSP, the boot.ini file will need to be modified. A wrong boot.ini file results in the system not being
bootable.
Preparation for the Disaster Recovery
This information applies only for Assisted Manual Disaster Recovery (AMDR), because Enhanced
Automated Disaster Recovery (EADR) and One Button Disaster Recovery (OBDR) will automatically
recover the VSP and are therefore the recommended methods to be used to recover VSPs.
When performing AMDR, you will have to manually recreate the previous storage structure (including
the VSP).
ASR will recreate the previous storage structure automatically and preserve unallocated space on disk
for VSP. Then you will have to recreate the VSP on the unallocated disk space using vendor-specific
tools and procedures.
In order to enable Data Protector access to the VSP, you will have to map it in Windows using the Data
Protector omnipm utility.
Steps
1. Run Data_Protector_homebinutilnsomnipmto start the Data Protector Partition Mapper.
2. In the Partition Mapper window, select the partition identified with vendor-specific ID under the
Type column.
3. Click Map to assign a drive letter to the selected partition. In the dialog window, specify a drive
letter and click OK.

4. Use the standard Data Protector restore procedure to restore the backed up data on the mapped
EISA utility partition.
5. Unmap the partition you have mapped in step 3.
Caution: Do not overwrite the operating system files (usually *.sys files) in the root of the VSP
during the recovery, because this could cause the system to be unbootable. It is therefore
recommended to add these files to the exclude list.
Restoring an Eisa Utility Partition
Steps
1. If you do not maintain the Eisa utility partition (EUP), you must manually create it. Note that the
EUP should reside on the first disk as seen by the system BIOS. Since Disk Manager cannot
create an EUP, create a normal FAT16 partition and assign it a drive letter.
2. Restore its contents using Data Protector. Select the Restore As option for the Eisa Utility
Partition Configuration object. The drive letter assigned must be the one that was assigned during
the EUP creation and the directory to restore into must be the root directory ().
3. Rearrange the root directory entries if necessary.
a. Run omnipm, select the EUP and click Root.... The root directory of the EUP is displayed.
b. Reorder the root directory entries to their original positions. Use either drag and drop or right
click an entry to display the options menu.
4. Change the FAT16 partition into a real EUP.
a. Select the EUP and click Unmap. The drive letter is removed.
b. Click Type. A dialog windows displays. Select Eisa Utility Partition.
Enhanced Automated Disaster Recovery
(EADR)
Enhanced Automated Disaster Recovery is used to recover ordinary Data Protector Cell Managers and
clients as well as Data Protector Cell Managers and clients that are part of the Microsoft Cluster Server
(MSCS).
This section describes the steps/tasks that you need to perform after you encounter a disaster
recovery situation.
Overview
chapter. The general steps using the Enhanced Automated Disaster Recovery method for a Windows
client are:

1. Phase 1
b. Start the target system from the disaster recovery CD, USB drive, or through the network and
select the scope of recovery. This is a completely unattended recovery.
Windows Server 2003: If you are recovering a domain controller, before the Disaster
Recovery Wizard is launched, a standard Windows logon dialog box prompts you to enter the
username (Administrator) and password of the Directory Services Restore Mode
administrator account.
2. Phase 2
a. Depending on the recovery scope you select, the selected volumes are automatically
restored. Critical volumes (the boot partition and the operating system) are always restored.
3. Phase 3
a. Use the standard Data Protector restore procedure to restore user and application data.
Prepare a disaster recovery CD, a bootable USB drive, or a network bootable image with the recovery
set in advance for any critical systems that must be restored first (especially DNS servers, Cell
Managers, Media Agent clients, file servers, and so on.).
Prepare removable media containing encryption keys in advance for Cell Manager recovery.
The following sections explain the limitations, preparation, and recovery that pertains to EADR of the
Windows clients. See also the “Advanced recovery tasks” section for details.
Prerequisites
Before selecting this method of disaster recovery, consider the following requirements and limitations:
l You need a new hard disk to replace your affected disk. The new disk have to be the same size or
bigger than the affected disk. If it is larger than the original disk, the difference will remain
unallocated.
l The replacement disks have to be attached to the same host bus adapter on the same bus.
l For disaster recovery of the Cell Manager, you should have a valid Internal Database backup image
that is newer than the filesystem backup image.
l The hardware configuration of the target system must be the same as that of the original system.
This includes the SCSI BIOS settings (sector remapping).
l Ensure that you have enabled the Automount feature. The Automount feature ensures that all the
volumes (without a mountpoint) are online. When the Automount is disabled, all the volumes without
the drive letter are offline during the booting process. Therefore the System Reserve partition will not
have access to the drive letter, and this may result in the failure of the disaster recovery procedure.
If you need to disable the Automount feature, then ensure that you have mounted the System
Reserve partition.
l Windows Server 2003: If the affected system is a domain controller, you need the password of the
Directory Services Restore Mode administrator account.
l On Windows XP and Windows Server 2003 systems, the boot partition (on which the DR OS is
installed) must be larger than 200 MB or disaster recovery will fail. If this disk space is not available,
the disaster recovery fails. If you had applied the Compress Drive on the original partition, you must

have 400 MB free.
l On Windows Vista and later releases, at least one volume must be an NTFS volume.
l On Windows Server 2003 systems, all drivers required for booting must be installed under the
%SystemRoot%folder.
l For a remote restore, the network must be available when you boot DR OS image.
Preparation for Enhanced Automated Disaster
Recovery (Windows and Linux)
procedure for all disaster recovery methods before completing the steps listed in this topic. You have to
prepare in advance in order to perform a disaster recovery fast and efficiently. You should pay special
attention to disaster recovery preparation for the Cell Manager.
Prerequisites
Before selecting this method of disaster recovery, consider the following requirements and limitations:
l The Data Protector Automatic Disaster Recovery component must be installed on systems for
which you want to enable recovery using this method and on systems where the DR OS image will
be prepared. For details, see the HPE Data Protector Installation Guide.
l On Windows Vista and later releases, at least one volume must be an NTFS volume.
l A backup of all necessary data for disaster recovery may require a significant amount of free space.
While normally 500 MB is enough, up to 1 GB may be required depending on the operating system.
l During the DR OS image creation, the partition on which Data Protector is installed should have at
least 500 MB of temporary free space. This space is required to create a temporary image.
Reserve partition.
l On Windows Server 2003 systems, all drivers required for booting must be installed under the
%SystemRoot%folder.
Reserve partition.
l In a cluster environment, a cluster node can be successfully backed up if the bus address
enumeration on each cluster node is the same. This means that you need:

l Equal cluster node motherboard hardware
l The same OS version on both nodes (service packs and updates)
l The same number and type of bus controllers
l Bus controllers must be inserted in the same PCI mother board slots.
l The operating system should be activated at the time of the backup. Otherwise, when the activation
period expires, disaster recovery fails.
l To create a DR OS image for Windows Vista and later releases, you must install the appropriate
version of Windows Automated Installation Kit (WAIK) or Assessment and Deployment Kit (ADK)
on the system on which you will create the image:
Windows Vista and Windows Server 2008:
Automated Installation Kit (AIK) for Windows Vista SP1 and Windows Server 2008
Windows 7 and Windows Server 2008 R2:
l Windows Automated Installation Kit (AIK) for Windows 7
l Windows Automated Installation Kit (AIK) Supplement for Windows 7 SP1 (optional, for
Microsoft Windows 7 SP1 and Windows Server 2008 R2 SP1)
Windows 8 and Windows Server 2012:
l Assessment and Deployment Kit (ADK 1.0) for Windows 8 and Windows Server 2012
Data Protector checks the WAIK/ADK version and aborts the image creation if no appropriate
version is available.
Windows 8.1 and Windows Server 2012 R2:
l Assessment and Deployment Kit (ADK 1.1) for Windows 8.1 and Windows Server 2012 R2
l For a disaster recovery from a bootable USB device, make sure that:
l the size of the USB storage device is at least 1 GB
l the target system supports booting from the USB device. Older systems may require a BIOS
update or might not be able to boot from an USB storage device at all.
l To create a bootable network image for Windows Vista and later Windows systems versions, the
following requirements must be met:
l On the target system, the network adapter is enabled to communicate through the PXE protocol.
The BIOS of this system should be compliant with the PXE protocol.
l Windows Deployment Services (WDS) server is installed and configured on the Windows Server
2008 and later Windows systems. WDS server must be either a member of an Active Directory
domain or a domain controller for an Active Directory domain.
l A DNS server and a DHCP server with an active scope are running in the network.
l To back up the IIS configuration object residing on a Windows Vista and later releases, install the IIS
6 Metabase Compatibility package.

Limitations
l Multiboot systems that do not use Microsoft's boot loader are not supported.
database are not restored automatically during Phase 2. They can be restored to the target system
l You can create a bootable USB drive on Windows 7, Windows 8, Windows Server 2008 R2
systems (on all supported platforms), Windows Server 2008 systems (on the Itanium platform),
Windows Server 2012, and later releases.
l On Windows XP and Windows Server 2003, recovery of a SAN boot configuration is not supported.
l VSS disk image backup of the logical volumes can be used for disaster recovery only on Windows
Vista and later releases.
l On Windows XP and Windows Server 2003, you cannot boot the target system over the network.
l On Windows XP and Windows Server 2003, a console interface is available instead of the HPE
Data Protector Disaster Recovery GUI.
l On Windows Vista and later releases, originally encrypted folders can only be restored as
unencrypted.
l Do not select backup object versions which belong to a checkpoint restart backup session.
l When selecting an object copy as the source for the recovery, the following applies:
l Only copies of full backup objects can be selected for recovery.
l Object copies can be selected only if you create a volume recovery set from a list of volumes.
Sessions are not supported.
l Media copies are not supported.
l The DRM restore monitor monitors the overall bytes written to a disk by the VRDA process. The
overall bytes written to a disk do not always match what is displayed in the Data Protector session
manager.
Note: The new Recovery Session monitor is implemented only on Windows Vista and later
releases.
l Sparse files are restored to their full size during offline restore. This may result in the target volume
running out of space.
l AUTODR does not support recovery of btrfs on multiple devices (various btrfs raid configurations)
as they are not supported by SLES 11.3.
l The current btrfs tools on SLES 11.3 do not set the UUID on a newly created btrfs file system.
Therefore, AUTODR cannot set the same UUID on btrfs file systems during recovery as done for
backup.

If you mount the btrfs file systems by UUID instead of a device name, you need to manually edit the
/etc/fstab file after restore. This needs to be done to reflect the new and correct UUIDs of the
recovered btrfs devices. The same is applicable for the GRUB configuration, so avoid the UUID.
After a system recovery, the btrfs has different UUIDs than the ones during backup. If another
recovery is performed from backups created before the last recovery of the system, the AUTODR
tries to identify healthy btrfs file systems and skips recreating them.
l AUTODR can only map the btrfs device configurations in backup to btrfs devices in the present
system being recovered by UUID. It can skip recovering wrong devices or recreated ones.
To avoid this, recover btrfs file systems only from backups created after the last system recovery or
destroy manually present btrfs file systems before a system recovery. The same is applicable for
btrfs file systems manually recreated by users after the last backup.
Note: Data Protector warns users of this before starting the recovery process.
l btrfs snapshots can be backed up but restored only as oridinary sub volumes. During such an
instance, none of the data will be shared between the snapshot and sub volume from where the
snapshot is created. The overall Copy On Write (COW) relationship between the parent and its
snapshot is lost. Therefore, in some cases, restore of complete data set is not possible, as data
from the snapshot is duplicated and runs out-of-space on the underlying device during restore.
l Only data from the mounted btrfs sub volumes are protected. Consider child sub volumes
accessible from an OS file system interface and parent sub volume being mounted. In such a case,
the sub volumes are not protected, as Disk Agent (DA) detects them as a different file system and
skips them because they do not have a dedicated mount point.
l Sub volumes mounted using the subvolid (refer to the btrfs documentation) mount option in
/etc/fstab file can be skipped from mount in the recovered system or mounted on a wrong mount
point, as subvolid of recovered sub volume need not be the same as the one during backup. Even
though all sub volumes are recreated, the Data Protector skips restore in such sub volumes or data
can be restored in wrong ones.
Note: Use the subvol option in fstab instead of subvolid.
Disk and partition configuration
l EADR is not supported for shared dynamic disks residing in Windows clusters.
l If the System Reserved volume resides on the dynamic disk, the volume will not be indicated by the
yellow colored icon, instead it will be indicated as a green colored icon in the Data Protector GUI.
l When performing a disaster recovery with dynamic disks, all the disks need to be cleaned up before
starting the EADR.
l After the EADR session, all the volumes will be recreated, but only volumes that are inside the
recovery scope will be restored.
l A new disk has to be the same size or bigger than the crashed disk. If it is larger than the original
disk, the difference will remain unallocated.
l Only vendor-specific partitions of type 0x12 (including EISA) and 0xFE are supported for EADR.
l On Windows XP and Windows Server 2003 systems, disaster recovery ISO images cannot be
created on systems where Data Protector is installed on FAT/FAT32 partitions. You need at least
one client in the cell where Data Protector is installed on an NTFS volume to be able to create
disaster recovery images

l Recovery of operating systems which have been deployed using the HPE Intelligent Provisioning
tool (v.1.4 and v.1.5) may fail because of incorrect MBR partition information.
l Sparse files are restored to their full size. This may result in that the target volume runs out of space.
l Storage Spaces configurations where physical disks do not entirely belong to a storage pool are not
supported.
1. Perform a full backup of the client system. It is recommended that you back up the whole client,
however, you need to select at least the following critical volumes and objects:
l the boot and system volumes
l the Data Protector installation volume
l the volume where the CONFIGURATION object is located
l the Active Directory database volume (in case of an Active Directory controller)
l the quorum volume (in case of a Microsoft Cluster Server)
For a Data Protector Cell Manager system, see "Additional preparations for the Cell Manager" on
the next page..
See the HPE Data Protector Help index: “backup, Windows specific” and “backup, configuration”
During a full client backup, the recovery set and P1S file are stored on the backup medium and
(recovery set optionally) on the Cell Manager.
Considerations:
Windows Vista and later releases:
l Make sure that you back up also the system volume if present.
l You can back up logical volumes using disk image backup that uses VSS writers. VSS disk
image backup ensures that the volume remains unlocked during the backup and can be
accessed by other applications. The IDB and CONFIGURATION objects, as well as volumes
that are not mounted or are mounted as NTFS folders, must be backed up using regular
filesystem backup.
Windows Server 2012 (R2):
l Use disk image backup to back up volumes in the following cases:
o Deduplicated volumes
During a filesystem restore, the volume is rehydrated and you might run of space on the
destination volume during recovery. A disk image restore keeps the size of the volume.
o Volumes with Resilient File System (ReFS)
Microsoft Cluster Server:

l Consistent backup includes (in the same backup session):
o all nodes
o administrative virtual server (defined by the administrator)
o if Data Protector is configured as a cluster-aware application, Cell Manager virtual server
and IDB.
The above items should be included in the same backup session.
For details, see "About Disaster Recovery of a Microsoft Cluster Server " on page 66.
l Cluster Shared Volumes: Before performing a full backup of the client system, back up the
Virtual Hard Drive (VHD) files and CSV configuration data using the Data Protector Virtual
Environment first. See the HPE Data Protector Integration Guide.
Virtual Hard Drives (VHD) must be dismounted to ensure consistency.
l After you performed the backup, merge the P1S files for all nodes in the MSCS, so that P1S file
of each node contains information on the shared cluster volumes configuration.
If the full client backup was encrypted, store the encryption key on a removable medium so that
it is available for disaster recovery. You will need the key if you are recovering a Cell Manager
or if the connection to the Cell Manager cannot be established.
Active Directory on Windows Server 2008 and later Windows Server versions:
l If your Windows Server is a domain controller whose Active Directory size exceeds 512 MB,
the backup specification for the client backup needs to be modified: in the source page, expand
the CONFIGURATION object, and clear the checkboxes for the ActiveDirectoryService and
SYSVOL items.
Note: The Active Directory and SYSVOL will still be backed up as part of the system
volume (C:/) backup. By default, they are located in C:/Windows/NTDS and
C:/Windows/SYSVOL respectively.
2. After a disaster occurs, use the EADR Wizard to convert the DR image into a disaster recovery
CD ISO image.
Windows Vista and later releases: Alternatively, create a bootable network image or a bootable
USB drive with the DR OS image instead of a disaster recovery CD.
3. Record the disaster recovery CD ISO image on a CD using any CD recording tool that supports
the ISO9660 format. This disaster recovery CD can then be used to boot the target system and
automatically restore critical volumes.
4. Execute a disaster recovery test plan.
5. On Windows systems, if some service or driver is not operational after the boot, you may have to
manually edit the kb.cfg file.
Additional preparations for the Cell Manager
Successful disaster recovery of the Cell Manager requires additional preparation.
l Regularly back up the IDB. The IDB session should not be older than the file system session.
l Store the Cell Manager's SRD file at a safe location (not on the Cell Manager).

l Prepare a disaster recovery OS image for the Cell Manager in advance.
Saving a Recovery Set to the Cell Manager
A recovery set is packed in a single large file and stored on the backup medium and optionally on the
Cell Manager during a full client backup. Saving the recovery set file to the Cell Manager is useful if you
plan to record the disaster recovery CD on the Cell Manager, because it is much faster to obtain the
recovery set from the hard disk than to restore it from a backup medium.
If the recovery set is saved to the Cell Manager during backup, it is saved to the default Data Protector
P1S files location.
To change the default location, specify a new global option EADRImagePath = valid_path (for
example, EADRImagePath = /home/images or EADRImagePath = C:temp).
See the HPE Data Protector Help index: “Global Options, modifying”.
Tip: If you do not have enough free disk space in the destination directory, you can create a mount
point (Windows systems) or a link to another volume (UNIX systems).
Saving the recovery set file to the Cell Manager for all clients in the
backup specification
Steps
1. In the Context List, click Backup.
2. In the Scoping Pane, expand Backup Specifications and then Filesystem.
3. Select the backup specification you will use for a full client backup (create it if you have not done
so already). For details, see the HPE Data Protector Help index: “creating, backup specifications”.
4. In the Results Area, click Options.
5. Under Filesystem Options click Advanced.
6. In the Other page, select Copy Recovery Set to disk.
7. Windows Vista and later releases: In the WinFS Options page, select the Detect NTFS
hardlinks and leave the Use Shadow Copy option selected, and leave Allow Fallback cleared.
Note that the Detect NTFS hardlinks option is not automatically selected if you manually add
objects or update existing backup specifications.

WinFS options tab
Saving the recovery set file to the Cell Manager for a particular client in
the backup specification
To copy the recovery set files only for particular clients in the backup specification, perform the
following steps:
4. In the Results Area, click Backup Object Summary.
5. Select the client for which you would like to store its recovery set file onto the Cell Manager and
click Properties.
7. Windows Vista and later releases: In the WinFS Options page, leave the Detect NTFS
hardlinks and Use Shadow Copy options selected, and leave Allow Fallback cleared. Note

that the Detect NTFS hardlinks option is not automatically selected if you manually add objects
or update existing backup specifications.
Preparing the Encryption Keys
For a Cell Manager recovery or an offline client recovery, you must ensure that the encryption keys are
available during the disaster recovery by storing them on a removable medium. For a Cell Manager
recovery, prepare the removable medium in advance, before the disaster occurs.
The encryption keys are not part of the DR OS image file. During the disaster recovery image creation,
the keys are automatically exported to the Cell Manager to the file Data_Protector_program_
dataConfigServerexportkeysDR-ClientName-keys.csv (Windows systems) or
/var/opt/omni/server/export/keys/DR-ClientName-keys.csv (UNIX systems), where
ClientName is the name of the client for which the image is being created.
Ensure that you have the correct encryption key for each backup that is prepared for a disaster
recovery.
Preparing a DR OS image
After a disaster occurs, you should prepare a DR OS image to be recorded on a disaster recovery CD
or saved to a bootable USB drive, which can then be used for Enhanced Automated Disaster
Recovery. Alternatively, you can prepare a bootable network image.
Note that the Data Protector Automatic Disaster Recovery component must be installed on the system
where a DR OS image will be prepared.
A new disaster recovery OS image has to be prepared after each hardware, software or configuration
change from a new recovery set.
Prepare a DR OS image in advance for any critical systems that must be restored first, especially
systems required for the network to function properly (DNS servers, domain controllers, gateways, and
so on), Cell Managers, Media Agent clients, file servers, and so on.
It is recommended to restrict access to backup media and disaster recovery CDs or USB drives
containing the OS image.
Steps
2. In the Scoping Pane, click Tasks, and then click Disaster Recovery to start the Disaster
Recovery Wizard.
3. In the Results Area, select the client for which you would like to prepare the DR OS image from
the Host to be recovered drop down list and click Validate to validate the client.
Note: The validated client gets added to the Host to be recovered drop down list.
4. From the Recovery media creation host drop down list, select the client on which you will
prepare the DR OS image. By default, this is the same client for which the DR OS image is
prepared for. The client on which you prepare the DR OS image must have the same OS type
installed (Windows, Linux) and must have a Disk Agent installed.

5. Keep the Enhanced Automated Disaster Recovery selected and select whether the volume
recovery set will be built from a backup session or a list of volumes. By default, Backup session
is selected.
Click Next.
6. Depending on the recovery set build method select:
l If you selected Backup session, select the host backup session and in case of a Cell Manager,
the IDB session.
l If you selected Volume list, for each critical object select an appropriate object version.
Click Next.
7. Select the location of the recovery set file. By default, Restore recovery set file from a backup
is selected.
If you have saved the recovery set file on the Cell Manager during backup, select Path to the
recovery set file and specify its location. Click Next.
8. Select the image format. The following options are available:
l Create bootable ISO image: a DR ISO image (by default, recovery.iso)
l Create bootable USB drive: a DR OS image on a bootable USB drive
l Create bootable network image: a DR OS image that can be used for the network boot (by
default, recovery.wim)
9. If you are creating a bootable ISO image or a bootable network image, select the destination
directory, where you would like to place the created image.
If you are creating a bootable USB drive, select the destination USB drive or disk number, where
you would like to place the created image.
During the creation of the bootable USB drive, all data stored on the drive will be lost.
10. Optionally, set a password to protect the DR OS image from unauthorized use. The lock icon
indicates whether a password has been set.
Click Password to open the Password Protect Image dialog window and enter the password. To
remove the password, clear the fields.
11. Windows Vista and later releases::
Review and if necessary, modify the list of drivers that are inserted into the DR OS image.
You can use this option to add missing drivers to the DR OS. Add or remove drivers manually by
clicking Add or Remove. To reload the original drivers, click Reload. The drivers from the
%Drivers% part of the recovery set are automatically injected into the DR OS image.
The drivers collected during the backup procedure and stored within the recovery set's %Drivers%
directory may not always be appropriate for use in the DR OS. In some cases, Windows
Preinstallation Environment (WinPE) specific drivers may need to be injected to ensure that the
hardware is functioning properly during the recovery.
12. Click Finish to exit the wizard and create the DR OS image.
13. If you are creating a bootable CD or DVD, record the ISO image on a CD or DVD using a recording
tool that supports the ISO9660 format.

Recovering Windows Systems Using Enhanced
Automated Disaster Recovery
You can successfully perform the Enhanced Automated Disaster Recovery of a Windows system only
if all preparation steps were fulfilled. If you are recovering a Cell Manager, first the Internal Database is
restored from its backup image, and restore of the volumes and the CONFIGURATION object from
their backup image follows afterwards. For details on supported operating systems, see the HPE Data
Protector Product Announcements, Software Notes, and References.
Steps
Phase 1
1. Unless you are performing an offline disaster recovery, add a Data Protector account with the
following properties to the Data Protector admin user group on the Cell Manager, depending on the
operating system of the target system:
l Type: Windows
l Name: SYSTEM
l Group/Domain: NT AUTHORITY
l Client: the temporary hostname of the system being recovered
A temporary hostname is assigned to the system by the Windows Preinstallation Environment
(WinPE). You can retrieve it by running the hostname command in the Command Prompt
window of the WinPE.
Windows XP, Windows Server 2003:
l Type: Windows
l Name: DRM$Admin
l Group/Domain: hostname of the target system
l Client: fully qualified domain name (FQDN) of the target system
For more information on adding users, see the HPE Data Protector Help index: “adding Data
Protector users”.
Adding a user account

Note: If you are using encrypted control communication between the clients in a Data
Protector cell, you must add the client to the Security Exceptions list on the Cell Manager
before you start the recovery. Unless you are using a local device, the Media Agent client
must be added to the Security Exceptions list on the Cell Manager as well.
2. Boot the client system from the disaster recovery CD, the bootable USB drive, or the bootable
network image of the original system. If you are starting the target system from a disaster
recovery CD, ensure that no external USB disks (including USB keys) are connected to the
system before you start the recovery procedure.
Note: If the screen is locked during a recovery, you can log on with following credentials:
User: DRM$ADMIN
Password: Dr8$ad81n$pa55wD
3. Windows Server 2003: If you are recovering a domain controller, when the Welcome to Windows
dialog box appears, press Ctrl+Alt+Delete, enter the password of the Directory Services Restore
Mode administrator account, and then click OK.
4. Select the scope of the recovery and recovery options. The following steps differ depending on the
operating system:
a. The Disaster Recovery GUI (the Installer Wizard) appears and displays the original system
information. Click Next.

Tip: There are some keyboard options available when the progress bar appears. You can
check which options are available and their description by hovering over progress bar.
b. In the Recovery scope page, select the scope of the recovery:
o Default Recovery: Critical volumes (system disk, boot disk, and the Data Protector
installation volume) are recovered. All other disks are partitioned and formatted and remain
empty and ready for Phase 3.
o Minimal Recovery: Only system disks and boot disk are recovered.
o Full Recovery: All volumes in the Restore Set are recovered, not only the critical ones.
o Full with Shared Volumes: Available for Microsoft Cluster Server (MSCS). This option
should be used if all nodes in the MSCS have been struck by a disaster and you are
performing EADR of the first node. It will recover all volumes in the Restore Set including
cluster shared volumes that were locked by the backed-up node at backup time. If at least
one node is up and the MSCS service is running, then shared volumes will not be restored
because the node keeps them locked. In this case, you should use Default Recovery.
c. Optionally, to modify the recovery settings, click Settings to open the Recovery settings
page.
The following additional recovery options are available, some of them are used in cases where
the disaster recovery does not finish completely or requires additional steps:
o Use original network settings: Select this option if you need to restore the
original network configuration (for example, due to a missing DHCP server). By default,
this option is not selected and the DR OS recovery environment uses a DHCP network
configuration.
o Restore BCD: If selected, Data Protector also restores the Boot Configuration Data (BCD)
store in advance during the disaster recovery session, before it is restored in the Data
Protector restore session. The option is selected by default.
o Restore DAT: If selected, the Data Protector disaster recovery module also restores
Microsoft VSS writers' data. By default, the DR module skips the restore of VSS writer's
data. You can use this option if Data Protector fails to back up critical writers during a non-
VSS backup. To restore the data before a DR module restore, select Pre. To restore the
data after a Data Protector, select Post.
o Initialize Disks Manually: This option enables you to manually map the original and
current system disks and initialize them to match the original configuration. By default, this
option is not selected.
If selected, a new disk mapping and initialization page is displayed when the recovery
process starts. The disaster recovery module will provide the initial disk mapping and
display the result of the initial mapping attempt. Use the provided options to change the
disk mapping. Once the mapping is completed, the volumes are initialized and the system
restarts.
o Restore Storage Spaces: By default, Storage Spaces are restored. You can deselect
the option and restore the virtual disks directly to physical ones, at recovery time, if the
storage configuration permits this. Note that you need to manually initialize the disks if you
restore Storage Spaces to dissimilar hardware or USB disks.
o Enable Dissimilar Hardware Restore: If enabled, Data Protector scans the system
for missing drivers during the recovery. The option is enabled by selecting one of the

following methods from the drop-down list:
l Unattend (default): This mode automatically configures the operating system to
various hardware platforms using a predefined configuration file. This is the primary
mode of recovery with dissimilar hardware. Use it in the first instance.
l Generic: Select this if Unattend mode fails (perhaps because of a misconfiguration of
the restored operating system). It is based on adapting the restored OS registry and its
drivers and services to the dissimilar hardware.
o Remove Devices: Available if the Dissimilar Hardware option is enabled. If selected,
Data Protector removes original devices from the registry of the restored operating
system.
o Connect iSCSI Devices: This option is enabled and selected if the original machine was
using iSCSI. By selecting this option Data Protector automatically restores the basic
iSCSI configuration as it was at backup time. If not selected, the iSCSI configuration will
be skipped.
You can also use the native Microsoft iSCSI configuration wizard to manage a more
complex iSCSI configuration. If the DR GUI detects certain iSCSI features (for example,
security options) which require a manual configuration, it offers the option to run the
Microsoft iSCSI configuration wizard.
o Map Cluster Disks Manually: Available on Windows Server 2008 and later releases. If
selected, you can map cluster volumes manually. If not selected, the volumes will be
mapped automatically. It is recommended to check that all volumes are mapped
appropriately after automatic mapping.
o Remove Boot Descriptor: Available on Intel Itanium systems. Removes all Boot
Descriptors left over by the disaster recovery processes.
o Manual disk selection: Available on Intel Itanium systems. If the disk setup has
changed significantly, the disaster recovery module may not be able to find the boot disk
(s). Use this option to select the correct boot disk.
To reset the options to the default settings, click Reset default settings.
Click Save > to save the changes.
d. Click Finish to start the recovery. The recovery process starts and you can monitor the
progress.
If the volumes are encrypted using BitLocker Drive Encryption, you are prompted to unlock
the encrypted drives.
Tip: In the Disaster Recovery GUI, you can click Tasks to perform the following:
o run Command Prompt, Task Manager, or Disk Administrator
o access the Map Network Drives and Load Drivers tools
o view log files specific to the disaster recovery process
o enable or disable the DRM configuration file, view this file in text editor, and edit it
o edit the hosts file of the WinPE recovery environment
o access Help and view the legends to GUI icons
Windows XP and Windows Server 2003 systems:

a. Press F12 when the following message is displayed: To start recovery of the machine
Hostname press F12.
b. The scope selection menu is displayed at the beginning of the boot process. Select the scope
of recovery and press Enter. There are five different scopes of recovery:
o Reboot: Disaster recovery is not performed and the system is restarted.
o Default Recovery: Critical volumes (system disks, boot disk, and the Data Protector
volume) are recovered. All other disks are partitioned and formatted and remain empty and
ready for Phase 3.
Phase 2
4. After you have selected the scope of the recovery, Data Protector starts setting up the DR OS.
You can monitor the progress and, when the DR OS is set up, the system restarts. On Windows
Vista and later releases, the system restart is not performed.
Wait for 10 seconds when prompted To start recovery of the machine Hostname press
F12, to boot from the hard disk and not from the CD.
On Windows XP and Windows Server 2003, if the DR OS does not boot normally or cannot
access network, you may need to edit the kb.cfg file.
The Disaster Recovery Wizard appears. To modify the disaster recovery options, press any key
to stop the wizard during the countdown and modify the options.
The following options are available:
l Debugs...: Enables debugging. See "Debugging disaster recovery sessions" on page 119.
l Omit deleted files: Files, deleted between successive incremental backups, are not
restored. This may slow down the recovery.
l Install only: This option will install only the temporary operating system to the target
system and thus finish the Phase 1 of disaster recovery. Phase 2 of disaster recovery will not
start automatically. You can use this option for example if you need to edit the SRD file.

Additionally, you can start the Registry Editor, the command line, or the Task manager using the
appropriate buttons.
Click Finish to continue with the disaster recovery.
5. If the DR OS image is password protected, provide the password and continue the recovery.
6. If the disaster recovery backup is encrypted and you are either recovering the Cell Manager or a
client where the Cell Manager is not accessible, the following prompt will appear:
Do you want to use AES key file for decryption [y/n]?
Press y.
Ensure that the keystore (DR-ClientName-keys.csv) is available on the client (for example, by
inserting a CD-ROM, floppy disk, or USB flash drive) and enter the full path to the keystore file.
The keystore file is copied to the default location on the DR OS and is used by the Disk Agents.
Disaster recovery now continues without further interruption.
8. Data Protector will then reestablish the previous storage structure within the selected scope of
recovery and restore all critical volumes. The temporary DR OS will be deleted after the first login,
except in the following cases:
l Minimal Recovery is selected.
l You interrupt the Disaster Recovery Wizard during the 10 second pause (after it has found the
DR installation and SRD file on the backup medium) and select the Debugs option.
On Windows Vista and later releases, the temporary DR OS is never retained.
Note that Data Protector will first try to perform online recovery. If the online recovery fails for any
reason (for example, the Cell Manager or network services are not available, the firewall is
preventing access to the Cell Manager) Data Protector will then try to perform a remote offline
recovery. If even the remote offline restore fails (for example, because the Media Agent host
accepts only requests from the Cell Manager), Data Protector will perform a local offline restore.
9. Remove the client’s local Administrator account created in step 1 from the Data Protector Admin
user group on the Cell Manager, unless it existed on the Cell Manager before the disaster
recovery.
10. If you are recovering a Cell Manager, make the IDB consistent.
Phase 3
Note: Data Protector does not restore the volume-compression flag after recovery. All files
that were compressed at backup time will be restored as compressed, but you will have to
manually set the volume compression if you want any new files created to be compressed as

well.
11. Additional steps are necessary if you are performing disaster recovery of all nodes in a Microsoft
Cluster Server.
One Button Disaster Recovery (OBDR) is a automated Data Protector recovery method for Windows
Data Protector clients, where user intervention is reduced to minimum. For details on supported
operating systems, see the latest support matrices at
OBDR collects all relevant environment data automatically at backup time. During backup, data
required for temporary DR OS setup and configuration is packed in a single large OBDR image file and
stored on the backup tape. When a disaster occurs, the OBDR device (backup device, capable of
emulating CD-ROM) is used to boot the target system directly from the tape which contains the OBDR
image file with disaster recovery information.
Once DR OS Image is booted, Data Protector automatically formats and partitions the disk and finally
restores the original operating system with Data Protector as it was at the time of backup.
Perform a new backup after each hardware, software or configuration change. This also applies to any
network configuration changes, such as change of IP address or DNS server.
The recovered volumes are:
l The boot partition
l The system partition
l The partitions storing the Data Protector installation data
Any remaining partitions can be recovered using the standard Data Protector recovery procedure.
Overview
chapter.The general steps using the One Button Disaster Recovery method for a Windows client are:
1. Phase 1
Boot from the recovery tape and select the scope of recovery.
2. Phase 2
Depending on the recovery scope you select, the selected volumes are automatically restored.
Critical volumes (the boot partition and the operating system) are always restored.
3. Phase 3
Restore any remaining partitions using the standard Data Protector restore procedure.
HPE recommends to restrict access to OBDR boot media.
The following sections explain the requirements, limitations, preparation and recovery pertaining to One
Button Disaster Recovery on Windows systems. See also the section “Advanced recovery tasks”.

Requirements
l The Data Protector Automatic Disaster Recovery must be installed on systems for which you want
to enable recovery using this method. For details, see the HPE Data Protector Installation Guide.
l The client system must support booting from the tape device that will be used for OBDR.
For more information about supported systems, devices and media, see the HPE Tape Hardware
Compatibility Table and the latest support matrices at http://support.openview.hp.com/
selfsolve/manuals.
l The new disk have to be the same size or bigger than the affected disk. If it is larger than the original
l Replacement disks have to be attached to the same host bus adapter on the same bus.
l Windows XP, Windows Server 2003: An additional 200 MB of free disk space is required on the boot
partition at backup time. If this disk space is not available, the disaster recovery fails. If you had
applied the Compress Drive on the original partition, you must have 400 MB free.
l During OBDR backup,, the partition on which Data Protector is installed should have at least 500
MB of temporary free space. This space is required to create a temporary image.
l Windows Server 2003: All drivers required for booting must be installed under the
%SystemRoot%folder.
l A media pool with a Non-appendable media usage policy and a Loose media allocation policy has to
be created for the OBDR capable device. Only media from this pool can be used for disaster
recovery.
l Windows XP, Windows Server 2003: The operating system should be activated at the time of the
backup. Otherwise, when the activation period expires, disaster recovery fails.
l To create a DR OS image for Windows Vista and later releases, you must install the appropriate
version of Windows Automated Installation Kit (WAIK) or Assessment and Deployment Kit on the
system on which you will create the image:
Windows Vista and Windows Server 2008:
Automated Installation Kit (AIK) for Windows Vista SP1 and Windows Server 2008
Windows 7 and Windows Server 2008 R2:
l Windows Automated Installation Kit (AIK) for Windows 7
l Windows Automated Installation Kit (AIK) Supplement for Windows 7 SP1 (optional, for
Microsoft Windows 7 SP1 and Windows Server 2008 R2 SP1)
Windows 8 and Windows Server 2012:
l Assessment and Deployment Kit (ADK 1.0) for Windows 8 and Windows Server 2012
Windows 8.1 and Windows Server 2012 R2:
l Assessment and Deployment Kit (ADK 1.1) for Windows 8.1 and Windows Server 2012 R2

l To back up the IIS configuration object residing on a Windows Vista, Windows 7, or Windows
Server 2008 system, install the IIS 6 Metabase Compatibility package.
Limitations
l One Button Disaster Recovery (OBDR) is not available for Data Protector Cell Managers.
l Multiboot systems that do not use Microsoft's boot loader are not supported.
l On Windows XP and Windows Server 2003, recovery of a SAN boot configuration is not supported.
l VSS disk image backup of the logical volumes can be used for disaster recovery only on Windows
Vista and later releases.
l On Windows XP and Windows Server 2003, a console interface is available instead of the HPE
Data Protector Disaster Recovery GUI.
l On Windows XP and Windows Server 2003, recovery of a configuration with Network Teaming
adapters is not supported.
l On Windows Vista and later releases, originally encrypted folders can only be restored as
unencrypted.
database are not restored automatically during Phase 2. They can be restored on the target system
l The DRM restore monitor monitors the overall bytes written to a disk by the VRDA process. The
overall bytes written to a disk do not always match what is displayed in the Data Protector session
manager.
Note: The new Recovery Session monitor is implemented only on Windows Vista and later
releases.
l Dynamic disks are not supported (including mirror sets upgraded from Windows NT).
l Only vendor-specific partitions of type 0x12 (including EISA) and 0xFE are supported for OBDR.
l OBDR is supported on systems where Data Protector is installed on an NTFS volume.
l On Intel Itanium systems, recovery of a boot disk is supported only for local SCSI disks.
Preparation for One Button Disaster Recovery
(Windows and Unix)
procedure for disaster recovery before completing the steps listed in this topic. Prepare in advance in
order to perform a disaster recovery fast and efficiently.

Preparatory steps
After you have completed the general preparation for disaster recovery, perform the following specific
steps to prepare for OBDR.
1. Create a media pool for DDS or LTO media with the Non-appendable media usage policy and the
Loose media allocation policy (because the backup media is formatted during OBDR backup). In
addition,specify this media pool as the default media pool for the OBDR device. See the HPE
Data Protector Help index: “creating media pool”. Only media from such pool can be used for
OBDR.
2. Perform the OBDR backup locally on the system for which you want to enable recovery using
OBDR.
Considerations
Windows Vista and later releases: Make sure that you back up system volumes (such as boot
volumes) if present.
Windows Server 2012 (R2): Use disk image backup to back up volumes in the following cases:
l Deduplicated volumes
During a filesystem restore, the volume is rehydrated and you might run of space on the
destination volume during recovery. A disk image restore keeps the size of the volume.
l Volumes with Resilient File System (ReFS)
Microsoft Cluster Server: Consistent backup includes (in the same backup session):
l All nodes
l Administrative virtual server (defined by the administrator)
l If Data Protector is configured as a cluster-aware application, the client system's virtual server.
To enable an automatic restore of all shared disk volumes on the MSCS using the OBDR method,
move all volumes temporarily to the node for which you are preparing the OBDR boot tape so that
shared disk volumes are not locked by another node during the OBDR backup. It is namely
impossible to collect enough information for configuring the disk during Phase 1 for shared disk
volumes that are locked by another node during the backup.
Cluster Shared Volumes: Before performing a full backup of the client system, back up the
Virtual Hard Drive (VHD) files and CSV configuration data using the Data Protector Virtual
Environment first. See the HPE Data Protector Integration Guide. The backup must be performed
on a separate device, because an OBDR backup can be performed only on non-appendable
media.
Virtual Hard Drives (VHD) must be dismounted to ensure consistency.
If the full client backup was encrypted, store the encryption key on a removable medium so that it
is available for disaster recovery. You will need the key if the connection to the Cell Manager
cannot be established.

4. On Windows systems, if some service or driver is not operational after the system startup, you
may have to manually edit the kb.cfg file.
Creating the Backup Specification for One Button Disaster
Recovery
You need to create a One Button Disaster Recovery (OBDR) backup specification in order to prepare
the OBDR boot tape.
Prerequisites
l Before adding an OBDR device, create a media pool for DDS or LTO media with the Non-
appendable media usage policy and the Loose media allocation policy. The created media pool must
be selected as the default media pool for the OBDR device.
l This device has to be connected locally to the system, for which you want to enable recovery using
OBDR.
l The Data Protector Automatic Disaster Recovery and User Interface components must be installed
on systems for which you want to enable recovery using the OBDR method.
l This backup specification has to be created locally on the system, for which you want to enable
recovery using OBDR.
Tip: To enable an automatic restore of all shared disk volumes in the MS Cluster using the OBDR
method, move all volumes temporarily to the node for which you are preparing the OBDR boot tape.
It is practically impossible to collect enough information to configure the disk in Phase 1 for shared
disk volumes that are locked by another node.
Limitations
This backup specification is unique to the One Button Disaster Recovery method. By default, the
required volumes are backed up as filesystems. However, on Windows Vista and later releases, you
can choose to back up logical volumes as disk images by using the VSS writers. This ensures that the
volumes remain unlocked during the backup and can be accessed by other applications. To back up
logical volumes as disk images, you must modify the backup specification created for OBDR.
Creating a backup specification for OBDR
Modifying an OBDR backup specification to use disk image backup
Steps
2. In the Scoping Pane, click Tasks, and then click One Button Disaster Recovery Wizard.
3. In the Results Area, select the client for which you would like to perform an OBDR backup (locally

on the client) from the drop-down list and click Next.
4. The critical volumes that you need to back up are already selected. Click Next.
Important volumes are selected automatically and cannot be deselected. Select any other
partitions you want to keep, because during the recovery procedure Data Protector deletes all
partitions from your system.
5. Select the local device or drive to be used for the backup. Only one device or drive can be
selected. Click Next.
6. Windows Vista or later releases:
Review and if necessary, modify the list of drivers that are inserted into the DR OS image.
You can use this option to add missing drivers to the DR ISO image. Add or remove drivers
manually by clicking Add or Remove. To reload the original drivers, click Reload. The drivers
from the %Drivers% part of the recovery set are automatically injected into the DR OS image.
Optionally, select the backup options.
The drivers collected during the backup procedure and stored within the recovery set's %Drivers%
directory may not always be appropriate for use in the DR OS. In some cases, Windows
Preinstallation Environment (WinPE) specific drivers may need to be added to ensure that the
hardware is functioning properly during the recovery.
Linux: Select backup options. For more details on available options, see the HPE Data Protector
Help index: “backup options”.
Click Next.
7. Optionally, schedule a backup. Click Next.
8. In the Backup Summary page, review the backup specification settings, and then click Next.
You cannot change a previously selected backup device or the order in which the backup
specifications follow one another. Only OBDR non-essential backup objects can be deleted and
only general object properties can be viewed. You can also change a backup object description.
9. Save the modified backup specification as an OBDR backup specification to keep it in the original
One Button Disaster Recovery format.
10. a. Click Start Backup to run the backup interactively. The Start Backup dialog box appears.
Click OK to start the backup.
If the backup is an encrypted, encryption IDs are exported automatically by the
omnisrdupdate utility which is executed as a post-exec command.
A bootable image file of the system, containing all information required for installation and configuration
of temporary DR OS, will be written at the beginning of the tape to make it bootable.
Important: Perform a new backup and prepare a bootable backup medium after each hardware,
software, or configuration change. This also applies to any network configuration changes, such as
change of IP address or DNS server.

Modifying an OBDR backup specification to use disk image backup
Steps
1. In the Scoping Pane, click the created OBDR backup specification. When you are asked, whether
you want to treat it as an OBDR backup specification or as an ordinary backup specification, click
No.
Note: When an OBDR backup specification is saved as an ordinary backup specification, it
can be still used for the OBDR.
2. In the Backup Object Summary page, select the logical volumes that you want to back up as disk
images and click Delete.
Note: You can back up only logical volumes. The configuration objects, as well as volumes
that are not mounted or are mounted as NTFS folders, should be backed up with filesystem
backup.
3. Click Manual add to open the wizard.
4. In the Select Backup Object page, click the Disk image object option, and then click Next.
5. In the General Selection page, select a client with the disk image you want to back up and provide
an appropriate description. Click Next.
Note: Description must be unique for each disk image object. Use a descriptive name, for
example, [Disk Image C] for C: volume.
6. In the General Object Options property page, set data protection to None. Click Next.
Note: When you set data protection to None, the content of the tape can be overwritten by the
newer OBDR backups.
7. In the Advanced Object Options property page, you can specify advanced backup options for the
disk image object. Click Next.
8. In the Disk Image Object Options property page, specify the disk image sections to back up. Use
the following format:
.DriveLetter:, for example: .E:
Note: When the volume name is specified as a drive letter, the volume is not being locked
during the backup. A volume that is not mounted or is mounted as an NTFS folder cannot be
used for the disk image backup.
9. Click Finish to exit the wizard.
10. In the Backup Object Summary page, review the summary of the backup specification. The logical
volumes that you specified as disk images should be of a Disk Image type. Click Apply.

recovery.
Recovering Windows Systems Using One Button
Disaster Recovery
You can successfully perform the One Button Disaster Recovery (OBDR) of a Windows system only if
all preparation steps were fulfilled.
For details on supported operating systems for OBDR, see the HPE Data Protector Product
Announcements, Software Notes, and References.
Prerequisites
l You need a new hard disk to replace your affected disk.
l You should have a bootable OBDR backup medium with all critical objects of the client that you
want to recover. The OBDR backup has to be performed locally on the client.
l You need an OBDR device connected locally to the target system.
Steps
Phase 1
1. Unless you are performing an offline disaster recovery, add the account with the following
properties to the Data Protector admin user group on the Cell Manager, depending on the operating
system of the target system:
l Type: Windows
l Name: SYSTEM
l Group/Domain: NT AUTHORITY

l Client: the temporary hostname of the system being recovered
A temporary hostname is assigned to the system by the Windows Preinstallation Environment
(WinPE). You can retrieve it by running the hostname command in the Command Prompt
window of the WinPE.
l Type: Windows
l Name: DRM$Admin
l Group/Domain: hostname of the target system
l Client: fully qualified domain name (FQDN) of the target system
Protector users”.
2. Insert the tape containing the image file and your backed up data into an OBDR device.

3. Shut down the target system and power off the tape device. Ensure that no external USB disks
(including USB keys) are connected to the system before you start the recovery procedure.
4. Power the target system on and, while it is being initialized, press the Eject button on the tape
device and power it on. For details, see the device documentation.
5. Select the scope of the recovery and recovery options. The following steps differ depending on the
operating system:
Windows Vista and later releases::
a. The Disaster Recovery GUI (the Installer Wizard) appears and displays the original system
information. Click Next.
Tip: There are some keyboard options available when the progress bar appears. You can
check which options are available and their description by hovering over progress bar.
b. In the Recovery scope page, select the scope of the recovery:
o Default Recovery: Critical volumes (system disks, boot disk, and the Data Protector
installation volume) are recovered. All other disks are partitioned and formatted and remain
empty and ready for Phase 3.
c. Optionally, to modify the recovery settings, click Settings to open the Recovery settings
page.
o Use original network settings: Select this option if you need to restore the
original network configuration (for example, due to a missing DHCP server). By default,
this option is not selected and the DR OS recovery environment uses a DHCP network
configuration.
o Restore BCD: If selected, Data Protector also restores the Boot Configuration Data (BCD)
store in advance during the disaster recovery session, before it is restored in the Data
Protector restore session. The option is selected by default.
o Restore DAT: If selected, the Data Protector disaster recovery module also restores
Microsoft VSS writers' data. By default, the DR module skips the restore of VSS writer's
data. You can use this option if Data Protector fails to back up critical writers during a non-
VSS backup. To restore the data before a DR module restore, select Pre. To restore the
data after a Data Protector, select Post.
o Initialize Disks Manually: This option enables you to manually map the original and
current system disks and initialize them to match the original configuration. By default, this
option is not selected.

If selected, a new disk mapping and initialization page is displayed when the recovery
process starts. The disaster recovery module will provide the initial disk mapping and
display the result of the initial mapping attempt. Use the provided options to change the
disk mapping. Once the mapping is completed, the volumes are initialized and the system
restarts.
o Restore Storage Spaces: By default, Storage Spaces are restored. You can deselect
the option and restore the virtual disks directly to physical ones, at recovery time, if the
storage configuration permits this. Note that you need to manually initialize the disks if you
restore Storage Spaces to dissimilar hardware or USB disks.
o Enable Dissimilar Hardware Restore: If enabled, Data Protector scans the system
for missing drivers during the recovery. The option is enabled by selecting one of the
following methods from the drop-down list:
l Unattend (default): This mode automatically configures the operating system to
various hardware platforms using a predefined configuration file. This is the primary
mode of recovery with dissimilar hardware. Use it in the first instance.
l Generic: Select this if Unattend mode fails (perhaps because of a misconfiguration of
the restored operating system). It is based on adapting the restored OS registry and its
drivers and services to the dissimilar hardware.
o Remove Devices: Available if the Dissimilar Hardware option is enabled. If selected,
Data Protector removes original devices from the registry of the restored operating
system.
o Connect iSCSI Devices: This option is enabled and selected if the original machine was
using iSCSI. By selecting this option Data Protector automatically restores the basic
iSCSI configuration as it was at backup time. If not selected, the iSCSI configuration will
be skipped.
You can also use the native Microsoft iSCSI configuration wizard to manage a more
complex iSCSI configuration. If the DR GUI detects certain iSCSI features (for example,
security options) which require a manual configuration, it offers the option to run the
Microsoft iSCSI configuration wizard.
o Map Cluster Disks Manually: Available on Windows Server 2008 and later releases. If
selected, you can map cluster volumes manually. If not selected, the volumes will be
mapped automatically. It is recommended to check that all volumes are mapped
appropriately after automatic mapping.
To reset the options to the default settings, click Reset default settings.
Click Save > to save the changes.
d. The recovery process starts and you can monitor the progress.
If the volumes are encrypted using BitLocker Drive Encryption, you are prompted to unlock
the encrypted drives.
Tip: In the Disaster Recovery GUI, you can click Tasks to perform the following:

o run the Command Prompt, Task Manager, or Disk Administrator
o access the Map Network Drives and Load Drivers tools
o view log files specific to the disaster recovery process
o enable or disable the DRM configuration file, view this file in text editor, and edit it
o edit the hosts file of the WinPE recovery environment
o access Help and view the legends to GUI icons
a. Press F12 when the following message is displayed: To start recovery of the machine
HOSTNAME press F12.
b. The scope selection menu is displayed at the beginning of the boot process. Select the scope
of recovery and press Enter. There are five different scopes of recovery:
o Reboot: Disaster recovery is not performed and the system is restarted.
o Default Recovery: Critical volumes (system disks, boot disk, and the OBInstall
volume) are recovered. All other disks are partitioned and formatted and remain empty and
ready for Phase 3.
performing OBDR of the first node. It will recover all volumes in the Restore Set including
Phase 2
6. After you have selected the scope of recovery, Data Protector starts setting up the DR OS directly
to the hard disk. You can monitor the progress and, when the DR OS is set up, the system
restarts. If the DR OS does not boot normally or cannot access network, then you may need to
edit the kb.cfg file. On Windows Vista and later releases, the DR OS is not installed and the
system restart is not performed.
7. If the disaster recovery backup is encrypted and you are recovering a client whose Cell Manager is
not accessible, the following prompt is displayed:
Press y.

recovery and restore all critical volumes. The temporary DR OS will be deleted after the first login,
except in the following cases:
l Minimal Recovery is selected.
l You interrupt the Disaster Recovery Wizard during the 10 second pause (after it has found the
DR installation and SRD file on the backup medium) and select the Debugs option.
Note that Data Protector first tries to perform an online restore. If the online restore fails for any
reason (for example, the Cell Manager or network service is not available or firewall is preventing
access to the Cell Manager) Data Protector tries to perform remote offline recovery. If the remote
offline restore fails (for example, because the Media Agent host accepts requests only from the
Cell Manager), Data Protector performs a local offline restore.
10. Remove the client's local Administrator account created in step 1 from the Data Protector admin
recovery.
Phase 3
Note: Data Protector does not restore the volume-compression flag after recovery. All files
that were compressed at backup time will be restored as compressed, but you have to
manually set the volume compression if you want any new files to be compressed as well.
13. Additional steps are necessary if you are performing disaster recovery of all nodes in a Microsoft
Cluster Server.

Advanced tasks
Disaster Recovery of Microsoft Cluster Server
About Disaster Recovery of a Microsoft Cluster Server
Microsoft Cluster Server (MSCS) can be recovered using any disaster recovery method, except for
Disk Delivery Disaster Recovery. All specifics, limitations and requirements pertaining a particular
disaster recovery method also apply for the disaster recovery of the MSCS. Select the disaster
recovery method that is appropriate for your cluster and include it in your disaster recovery plan.
Consider the limitations and requirements of each disaster recovery method before making your
decision. Perform tests from the test plan.
For details on supported operating systems, see the HPE Data Protector Product Announcements,
Software Notes, and References.
All prerequisites for disaster recovery (for example, a consistent and up-to-date backup, an updated
SRD file, replaced faulty hardware, and so on) must be met to recover the MSCS.
Possible scenarios
There are two possible scenarios for disaster recovery of an MSCS:
l a disaster occurred to a non-active(s) node
l all nodes in the cluster have experienced a disaster
Preparation for Microsoft Cluster Server Disaster Recovery
Specifics
All prerequisites for disaster recovery (such as consistent and up-to-date backup images, an updated
SRD file, replaced faulty hardware, ...) must be met to recover the Microsoft Cluster Server (MSCS).
All specifics, limitations, and requirements pertaining a particular disaster recovery method will also
apply for the disaster recovery of an MSCS.
Consistent backup image for an MSCS includes:
l all nodes
l the virtual server
l if Data Protector is configured as a cluster-aware application, the Cell Manager should be included in
the backup specification

EADR specifics
It is practically impossible to collect enough information to configure the disk in Phase 1 for shared disk
volumes that are locked by another node during backup. This information is necessary to enable the
restore of all shared cluster volumes. To include information on shared cluster volumes in the P1S files
for all nodes in the cluster, do one of the following:
l After a full client backup has been performed, merge the information on shared cluster volumes in
the P1S files for all nodes in the cluster, so that the P1S file of each node contains information on the
shared cluster volumes configuration.
l Move all shared cluster volumes temporarily to the node which you are going to back up. This way all
required information about all shared cluster volumes can be collected, but only that node can be the
primary node.
OBDR specifics
To enable faster restore, use the omnisrdupdate command as a post-exec command to update the
SRD file after the OBDR backup. Insert the diskette with an updated SRD file in the floppy disk drive
when performing OBDR to provide Data Protector with information on the location of backed up objects
on the tape. Restoring the MSCS database will be faster because Data Protector will not search the
tape for the location of the MSCS database.
To enable the automatic restore of all shared disk volumes in the MSCS, temporarily move all volumes
to the node for which you are preparing the OBDR boot tape. It is impossible to collect enough
information to configure the disk in Phase 1 for shared disk volumes that are locked by another node
during backup.
Recovering a Microsoft Cluster Server
There are two possible scenarios for disaster recovery of a Microsoft Cluster Server (MSCS):
At least one of the nodes is up and running
All nodes in the cluster have experienced a disaster
At least one of the nodes is up and running
This is the basic scenario for disaster recovery of an MSCS. The prerequisites that follow must be
fulfilled in addition to other prerequisites for disaster recovery.
Prerequisites
l At least one of the cluster nodes is functioning properly (active node).
l The cluster service is running on this node.
l All physical disk resources must be on-line (that is, owned by the cluster).
l All normal cluster functionality is available (the cluster administration group is on-line).
l The Cell Manager is online.

In this case, the disaster recovery of a cluster node is the same as the disaster recovery of a Data
Protector client. You should follow the instructions for the specific disaster recovery method that you
will use to restore the affected non-active node.
Only local disks are restored, because all shared disks are moved to the working node after the disaster
and locked.
After the secondary node has been recovered, it will join the cluster after boot.
You can restore the MSCS database after all nodes have been recovered and have joined the cluster to
ensure its coherency. The MSCS database is a part of the CONFIGURATION object on Windows
systems.
All nodes in the cluster have experienced a disaster
In this case, all nodes in the MSCS are unavailable and the cluster service is not running.
The prerequisites that follow must be fulfilled in addition to other prerequisites for disaster recovery.
Prerequisites
l The primary node must have write access to the quorum disk (the quorum disk must not be locked).
l The primary node must have access to all IDB volumes, when recovering the Cell Manager.
In this case, you have to restore the primary node with the quorum disk first. The IDB has to be restored
as well if the Cell Manager has been installed in the cluster. Optionally you can restore the MSCS
database. After the primary node has been restored, you can restore all remaining nodes.
For AMDR, the MSCS service uses a hard disk signature written into the MBR of every hard disk to
identify physical disks. If the shared cluster disks have been replaced, this means that the disk
signatures were changed during Phase 1 of disaster recovery. As a consequence, the MSCS Service
will not recognize the replaced disks as valid cluster resources, and cluster groups depending on these
resources will fail. To prevent this, restore the original hard disk signatures, if you replaced the shared
cluster disks.
Steps
1. Perform disaster recovery of the primary node (including the quorum disk).
Assisted Manual Disaster Recovery (AMDR):
All user and application data on the quorum disk will be restored automatically by the drstart -
full_clus command.
Enhanced Automatic Disaster Recovery (EADR), One Button Disaster Recovery (OBDR):
When you are asked to select the scope of recovery, select Full with Shared Volumes to restore
the quorum disk.
2. Restart the system.
3. Restore the MSCS database, which is a part of the CONFIGURATION object on Windows
systems. MSCS service must be running in order to be able to restore the MSCS database,
therefore it cannot be restored automatically during Phase 2 of disaster recovery. However, the
cluster database can be restored manually at the end of Phase 2 using the standard Data
Protector restore procedure.

4. Methods other than One Button Disaster Recovery (OBDR):
If you are recovering a Cell Manager, make the IDB consistent.
5. The quorum and IDB volumes are restored. All other volumes are left intact and are claimed by the
recovered primary node if they are not corrupted. If they are corrupted, you have to perform the
following steps:
a. Disable the cluster service and cluster disk driver (the steps are described in MSDN Q176970).
b. Restart the system.
c. Reestablish the previous storage structure.
d. Enable the cluster disk driver and cluster service.
e. Restart the system and restore user and application data.
6. Restore the remaining nodes.
Merging P1S Files for Microsoft Cluster Server
After a backup has been performed, another step is required for Enhanced Automated Disaster
Recovery (EADR) to restore the active node. Information on shared cluster volumes in P1S files for all
nodes in the Microsoft Cluster Server (MSCS) has to be merged so that the P1S file of each node
contains information on the shared cluster volumes configuration. This is necessary to enable restore
of all shared cluster volumes. You can avoid merging P1S files after backup by moving all shared
cluster volumes temporarily to the node which you are going to back up. In this case, all required
information about all shared cluster volumes can be collected. This means that only that node can be
the primary node.
Windows
To merge the P1S files of all nodes, execute the merge.exe command from the Data_Protector_
homebindrimbin directory:
merge p1sA_path ... p1sX_path
where p1sA is the full path of the first node’s P1S file and p1sX is the full path of the P1S file of the last
node in the MSCS.
Filenames of updated P1S files have .merged appended (for example,
computer.company.com.merged). Rename the merged P1S files back to their original names (delete
the .merged extension).
For example, to merge the P1S files for an MSCS with 2 nodes, type:
merge Data_Protector_program_dataConfigserverdrp1snode1.company.com Data_
Protector_program_dataConfigserverdrp1snode2.company.com.
The merged files will be node1.company.com.merged and node2.company.com.merged.
UNIX
The merge.exe command works only on Windows systems with the Data Protector Automatic
Disaster Recovery component installed. On a UNIX Cell Manager, perform the procedure below.

Steps
1. Copy the P1S files to a Windows client which has an Automatic Disaster Recovery component
installed.
2. Merge the files.
3. Rename the merged P1S files back to their original names.
4. Copy the merged P1S files back to the UNIX Cell Manager.
Restoring Original Hard Disk Signatures on Windows Systems
The Microsoft Cluster Server (MSCS) service uses a hard disk signature written into the MBR of every
hard disk to identify physical disks. If the shared cluster disks have been replaced, this means that the
disk signatures were changed during Phase 1 of disaster recovery. As a consequence, the Cluster
Service will not recognize the replaced disks as valid cluster resources, and cluster groups depending
on those resources will fail. This applies only to the restore of the active node (that is, if all nodes in the
cluster have experienced a disaster), since shared cluster resources are operational as long as at least
one of the nodes is up and running and claims ownership of the resources. This problem does not apply
to EADR and OBDR critical disks because the original disk signatures of all EADR and OBDR critical
disks are automatically recovered. In case you have replaced any other disks, you will have to restore
their hard disk signatures as well.
The most critical shared disk is the cluster quorum resource. If it has been replaced, then the original
disk signature must be restored, or the cluster service will not start. During Phase 2, the MSCS
Database is restored into the TEMPClusterDatabase directory on the system volume. After the
system is rebooted, the cluster service will not be running, because the quorum resource will not be
identified due to the changed hard disk signature in Phase 1.
Restoring original hard disk signatures on Windows
On Windows systems, this can be resolved by running the clubar utility (located in the Data_
Protector_homebinutilns), which restores the original hard disk signature. After clubar
successfully finishes, the cluster service is automatically started.
For example, to restore a MSCS Database from C:tempClusterDatabase, type the following at the
command prompt:
clubar r C:tempClusterDatabase force q:.
For more information on clubar usage and syntax, see the clubar.txt file located in the Data_
Protector_homebinutilns.
If the Data Protector shared disk on the Cell Manager is different from the quorum disk, it has to be
restored as well. To restore the signature of the Data Protector shared disk and any other application
disk, you should use the dumpcfg utility included in the Windows Resource Kit. For details on using
dumpcfg, run dumpcfg /? or see the Windows Resource Kit documentation. For more information on
problems with hard disk signatures on Windows systems, see MSDN article Q280425.

Obtaining original hard disk signatures
You can obtain the original hard disk signatures from the SRD files. The signature is a number following
the -volume keyword in the SRD file.
The signature of the quorum disk is stored only in the SRD file of the active node (at backup time),
because it keeps the quorum disk locked and thus prevents other nodes from accessing the quorum
disk. It is therefore recommended to always back up the whole cluster, because you need the SRD
files of all nodes in the cluster, since only all SRD files together include enough information to configure
the disk in Phase 1 for shared disk volumes. Note that a hard disk signature stored in the SRD file is
represented as a decimal number, whereas dumpcfg requires hexadecimal values.
Example of Hard Disk Signatures in the SRD File
You can obtain the original hard disk signatures from the SRD files. The signature is a number following
the -volume keyword in the SRD file. The following is an example of a hard disk signature in the SRD
file:
-volume 5666415943 -number 0 -letter C -offslow 32256 -offshigh 0 -lenlow 320430592
-lenhigh 2 -fttype 4 -ftgroup 0 -ftmember 0
-volume 3927615943 -number 0 -letter Q -offslow 320495104 -offshigh 2 -lenlow
1339236864 -lenhigh 0 -fttype 4 -ftgroup 0 -ftmember 0
The number following the -volume keyword is the signature of the hard disk. In this case the SRD file
stores information about a local hard disk (with drive letter C) and a quorum disk (with drive letter Q).
Restoring the [%=DP.DP_BriefProductName%] Cell
Manager specifics
This section explains additional steps for particular methods that should be performed when restoring
Windows Cell Manager.
Making IDB consistent (all recovery methods)
The procedure described in this section should only be used after you have performed the general
disaster recovery procedure.
To make the IDB consistent, import the medium with the last backup so that the information about the
backed up objects is imported into the IDB. In order to do so, perform the following steps:
1. Using the Data Protector GUI, recycle the medium or media with the backup of the volumes that
remain to be restored for enabling the medium or media to be imported in the IDB. For more
information on recycling media, see the HPE Data Protector Help index: “recycling media”.
Sometimes it is not possible to recycle a medium since Data Protector keeps it locked. In such a
case stop Data Protector processes and delete the tmp directory by executing commands:

a. omnisv -stop
b. del Data_Protector_program_datatmp*.*
c. omnisv -start
2. Using the Data Protector GUI, export the medium or media with the backup of the volumes that
remain to be restored. For more information on exporting media, see the HPE Data Protector Help
index: “exporting, media”.
3. Using the Data Protector GUI, import the medium or media with the backup of the partitions that
remain to be restored. For more information on importing media, see the HPE Data Protector Help
index: “importing, media”.
Enhanced Automated Disaster Recovery specifics
Two additional steps are required in Phase 0 if you are recovering Windows Cell Manager using
Enhanced Automated Disaster Recovery:
l A disaster recovery CD or an USB drive containing the DR OS image or a network bootable image
for the Cell Manager should be prepared in advance.
Perform a new backup and prepare a new DR OS image after each hardware, software, or
configuration change. This also applies to any network changes, such as change of IP address or
DNS server.
l In addition to the Cell Manager, you should save the updated SRD file of the Cell Manager on
several safe locations as a part of the disaster recovery preparation policy, because the SRD file is
the only Data Protector file where information about objects and media is stored when the IDB is not
available. If the SRD file is saved only on the Cell Manager, it is not accessible if the Cell Manager
fails. See “Preparation” (page 27).
l If your backups are encrypted, you must save the encryption key to a removable medium before a
disaster occurs. If the encryption key is saved only on the Cell Manager, it is not accessible if the
Cell Manager fails. Without the encryption key, disaster recovery is not possible. See “Preparation”
(page 27).
HPE recommends to restrict access to backup media, recovery set files, SRD files, removable media
with encryption keys, disaster recovery CDs, and USB drives storing DR OS data.
Restoring Internet Information Server Specifics
Internet Information Server (IIS) is not supported for disaster recovery. To recover the IIS, the following
requirements must be met (in addition to the requirements required for Assisted Manual Disaster
Recovery):
Requirements
l Do not install the IIS during the clean installation of the system.
Perform the following steps (in addition to the steps required for Assisted Manual disaster recovery):

Steps
1. Stop or uninstall the IIS Admin Service, if it is running.
2. Run the drstart command.
The IIS Database is restored as a plain file (with the filename DisasterRecovery) into the default IIS
location (%SystemRoot%system32inetsrv).
After the successful boot, restore the IIS Database using the standard Data Protector restore
procedure or IIS Backup/Restore snap-in. Note that this may take quite some time.
Editing the kb.cfg File
The kb.cfg file is located in the Data_Protector_homebindrimconfig directory and stores
information on the location of driver files from the %SystemRoot% directory. The purpose of this file is to
provide a flexible method to enable Data Protector to include drivers (and other needed files) in the DR
OS to cover systems with specific boot relevant hardware or application configurations. The default
kb.cfg file already contains all files necessary for industry standard hardware configurations.
For example, functionality of some drivers is split into several separate files, all required for the driver to
function properly. Sometimes, Data Protector cannot identify all driver files, if they are not listed in the
kb.cfg file on a case-by-case basis. In this case, they will not be included in the DR OS. Create and
execute a test plan using the default version of the kb.cfg file. If the DR OS does not boot normally or
cannot access network, then you may need to modify the file.
If you want to back up these drivers, add information about dependent files to the kb.cfg file in the
appropriate format as described in the instructions at the beginning of the kb.cfg file. The easiest way
to edit the file is to copy and paste an existing line and replace it with the relevant information.
Note that the path separator is “/” (forward slash). White space is ignored, except inside quoted
pathname, so the depend entry can span several lines. You can also add comment lines that start with
a “#” (pound) sign.
After you finished editing the kb.cfg file, save it to the original location. Then perform another full client
backup to include the added files in the recovery set.
Due to the numerous configurations of system hardware and applications, it makes it impossible to
provide an "out of the box" solution for all possible configurations. Therefore you can modify this file to
include drivers or other files at your own risk.
Any modification to this file are at your own risk and as such not supported by HPE.
Caution: It is recommended to create and execute a test plan to be sure the disaster recovery will
work after you have edited the kb.cfg file.
Editing the SRD Files
The information about backup devices or media stored in the updated SRD file (recovery.srd) may be
out of date at the time you are performing disaster recovery. This is not a problem if you are performing

an online recovery, because the required information is stored in the IDB on the Cell Manager.
However, if you are performing an offline recovery, the information stored in the IDB is not accessible.
For example, a disaster stroke not only the Cell Manager, but also a backup device connected to it. If
you replace the backup device with a different backup device after the disaster, the information stored
in the SRD file will be wrong and the recovery will fail. In this case, edit the updated SRD file before
performing the Phase 2 of the disaster recovery to update the wrong information and thus enable a
successful recovery.
To edit the SRD file, open it (for the location of the SRD file see specifics for particular method below)
in a text editor and update the information that has changed.
Tip: You can display the device configuration information using the devbra -dev command.
For example, if the client name of the target system has changed, replace the value of the -host
option. You can also edit the information regarding the:
l Cell Manager client name (-cm),
l Media Agent client (-mahost),
l device name (-dev),
l device type (-type),
l address (-devaddr),
l policy (-devpolicy),
l robotics SCSI address (-devioctl)
l library slot (-physloc), and so on.
The procedure on using the edited SRD file for disaster recovery differs between some disaster
recovery methods and operating systems. Specific details for particular disaster recovery methods are
explained below.
You should restrict access to the SRD files due to security reasons.
AMDR
EADR/OBDR
AMDR
Perform the following steps before performing the regular AMDR recovery procedure, if the information
in the SRD file is out-of-date.
Steps
1. Open the recovery.srd file (located on the first drsetup/ASR diskette) in a text editor and make
the necessary changes.
2. Save the file to its original location in Unicode (UTF-16) format.

EADR/OBDR
If the information in the SRD file is out-of-date, perform the following additional steps before proceeding
with the regular EADR/OBDR procedure.
Steps
Windows systems
1. When the Disaster Recovery Wizard appears, press any key to stop the wizard during the
countdown, select the Install Only option and click Finish. This option will install only the
temporary operating system to the target system and thus finish the Phase 1 of disaster recovery.
Phase 2 of disaster recovery will not start automatically if the Install only option is selected.
The Install Only option in the Disaster Recovery Wizard
2. Select Omit Deleted Files option. This option enables removal of deleted files between
successive incremental backups at restore time. If specified the omnidr binary will forward the
same option to Data Protector restore tools (omnir and omniofflr) in case of incremental
backup. The option has no effect on the restore of full backup object versions. However, selecting
this option can significantly prolong the time of restore.

3. Run Windows Task Manager (press Ctrl+Alt+Del and select Task Manager).
4. In the Windows Task Manager, click File and then New Task (Run...).
5. Run the following command from the Run dialog: notepad
C:DRSYSSystem32OB2DRbinrecovery.srd and press Enter. The SRD file will be opened in
the Notepad.
6. Edit the SRD file.
7. After you have edited and saved the SRD file to the original location, run the following command
from C:DRSYSSystem32OB2DRbin
omnidr -drimini C:$DRIM$.OB2OBRecovery.ini
8. Proceed with the next step in the regular EADR/OBDR recovery procedure.
Linux systems
1. When the Disaster Recovery Wizard appears, press q to stop the wizard during the countdown
and select the Install Only option. This option will install only a minimal version of Data Protector
to the target system. Phase 2 of disaster recovery will not start automatically if the Install Only
option is selected.
2. Switch to another shell.
Edit the SRD file /opt/omni/bin/recovery.srd. For details, see the HPE Data Protector
Disaster Recovery Guide.
3. After you have edited and saved the SRD file, execute:
omnidr -srd recovery.srd -drimini /opt/omni/bin/drim/drecovery.ini
4. Once the recovery finishes, return to the previous shell and proceed with the next step in the
ordinary EADR/OBDR recovery procedure.
Example of Editing the SRD File
If the information in the SRD file is not up to date anymore (for example, you changed a backup device),
modify the updated SRD file (recovery.srd) before performing Phase 2 of disaster recovery to
update the wrong information and thus enable a successful recovery.
You can display some of the device configuration information using the devbra -dev command.
Changing the MA client
You performed a backup for disaster recovery purposes using a backup device connected to the client
old_mahost.company.com. At the time of disaster recovery, the same backup device is connected to
the client new_mahost.company.com with the same SCSI address. To perform a disaster recovery,
replace the -mahost old_mahost.company.com string in the updated SRD file with -mahost new_
mahost.company.com before performing the Phase 2 of disaster recovery.
If the backup device has a different SCSI address on the new MA client, modify also the value of the -
devaddr option in the updated SRD file accordingly.

Changing the backup device
To perform disaster recovery using another device than the one which was used for the backup, modify
the following option values in the updated SRD file:
-dev, -devaddr, -devtype, -devpolicy, -devioctl, and -physloc
Where:
-dev specifies the logical name of the backup device or drive (library) to be used for the
backup,
-devaddr specifies its SCSI address,
-devtype specifies the Data Protector device type,
-devpolicy specifies the device policy, which can be defined as 1 (Standalone), 3 (Stacker), 5
(Jukebox), 6 (external control), 8 (Grau DAS exchanger library), 9 (STK Silo medium
library) or 10 (SCSI-II Library),
-devioctl specifies the robotics SCSI address.
-physloc specifies the library slot
-storname specifies the logical library name
For example, you performed a backup for disaster recovery purposes using an HPE Ultrium standalone
device with the device name Ultrium_dagnja, connected to the MA host dagnja (Windows systems).
However, for the disaster recovery you would like to use an HPE Ultrium robotics library with the
logical library name Autoldr_kerala with drive Ultrium_kerala connected to the MA client kerala
(Linux systems).
First, run the devbra -dev command on kerala to display the list of configured devices and their
configuration information. You will need this information to replace the following option values in the
updated SRD file:
-dev "Ultrium_dagnja" -devaddr Tape4:1:0:1C -devtype 13 -devpolicy 1 -mahost
dagnja.company.com
with something like:
-dev "Ultrium_kerala" -devaddr /dev/nst0 -devtype 13 -devpolicy 10 -devioctl
/dev/sg1 -physloc " 2 -1" -storname "AutoLdr_kerala" -mahost kerala.company.com.
Windows BitLocker Drive Encryption
During the disaster recovery process on Windows Vista and later releases, you can unlock volumes
that are encrypted using BitLocker Drive Encryption.

Limitation
If you do not unlock a specific volume or if the volume is damaged, cannot be unlocked, and must
therefore be formatted, the volume is no longer encrypted after disaster recovery. In such
circumstances, you need to encrypt the volume again.
Note that the system volume is always restored unencrypted.
Steps
1. When the disaster recovery module detects an encrypted volume, you are prompted to unlock it.
Click Yes to start the Unlocker wizard. Note that if you click No, the encrypted volumes will
remain locked.
2. In the Select Locked Volumes page, the detected encrypted volumes are listed. Select the
volumes you want to unlock and then click Next.
3. In the Unlock Volume pages (one page for each selected volume), you are requested to specify
the unlock method. The following unlock methods are available:
l Password (available on Windows 7 and later releases)
A string of characters that was used when you encrypted the volume.
l Passphrase
A string of characters longer than the usual password that you used when you encrypted the
volume.
l Recovery key
A special hidden key you created on each volume that you encrypted. The recovery key has a
BEK extension, it is saved in the recovery key text file. You can click Browse to locate the
recovery key file.
Type the requested information in the text box and then click Next.
4. Check whether the volumes were unlocked successfully and then click Finish.
Note: If the unlocking process failed, you can review the error information and retry or skip the
unlocking procedure.
Recovery to Dissimilar Hardware
Note: Recovery to dissimilar hardware is an extension of Enhanced Automated Disaster
Recovery. You should refer to that as well as the information here.
After hardware failure or a similar disaster, you may need to restore a backup to a system where some
or all of the hardware is different from the original (dissimilar hardware).
Dissimilar hardware restore adds the following to the standard EADR and OBDR procedures:

1. At backup time, the disaster recovery module also collects network configuration information and
hardware information.
2. It enables the injection of critical device drivers into the DR OS image, so that they are available
during restore. You can also inject missing drivers manually at restore time if some are missing.
3. During restore, the network and hardware information is used to configure and map the network
properly for the restored OS, and to detect critical hardware that is missing.
When dissimilar hardware restore might be needed
l Hardware failure
Dissimilar hardware restore is needed when some of the boot-critical hardware (such as the storage
controller, processor, or motherboard) fails and must be replaced with non-identical hardware.
l Disaster
Dissimilar hardware restore is needed after total machine disaster where:
l No matching machine can be found (because of limited budget, the failing machine’s age or other
causes).
l Down-time cannot be afforded; the system must be up and running immediately.
In these situations, the use of dissimilar hardware restore can mean lower budget cost since exact
clones of the original systems are not needed.
l Migration
Dissimilar hardware restore is needed in the following situations:
l Moving to another machine (for example, to faster or newer hardware) where OS reinstallation
and reconfiguration is not an option.
l Moving from a physical system to a virtual environment or the other way round.
From the disaster recovery module's point of view, a virtual environment is another hardware
platform for which you need to provide critical drivers in order to restore a system backup taken
on some other virtual or physical platform. Limitations and requirements listed below also apply to
virtual environments.
Overview
The phases of restore to dissimilar hardware are the standard disaster recovery phases with the
following differences:
l Phase 0: Additional information is collected about the network configuration and the hardware.
l Phase 1: The machine is brought into a state where disaster recovery executables have access to
disks, file systems, the network and WIN32 API. Restore critical devices are checked. If any
drivers are missing, you are prompted to provide them.
l Phase 2, restoring the OS, is the same, but an extra sub-phase occurs after it:
l Phase 2a: The restored operating system is prepared and adapted to the hardware, through

injecting critical drivers, updating the registry and mapping the network.
l Phase 3 is the same, in which data not restored in Phase 2 is restored.
Requirements
l You must provide at least all boot-critical drivers (including network drivers) for the target machine.
These drivers can be added directly to the image at image creation time (recommended) or loaded at
restore time (during Phase 1). In addition, drivers of locally attached backup devices (such as a tape
device) must also be available if a local restore is attempted.
For more information see "Drivers" on the next page.
l Automatic network configuration restore for the restored OS requires network drivers to be present at
restore time.
l The restore system must have at least the same number of disks (with the same or greater size) as
the backup system did.
l The original OS should be supported on the target machine (server or workstation) by the hardware
manufacturer.
l It is advisable for the system firmware of the target machine to be up-to-date before a dissimilar
hardware restore.
l If you need to disable dissimilar hardware support during backup, edit the file drm.cfg on the system
you want to back up and set the enable_disshw option to 0.
l The system must include at least one NTFS volume, which serves as a storage point for VSS
purposes during the backup phase.
Limitations
The disaster recovery module only supports dissimilar hardware restores if the backup was performed
with the Use Shadow Copy option (selected by default for supported platforms).
l Dissimilar hardware support is provided only for EADR and OBDR on the following operating
system releases:
l Windows Vista
l Windows 7
l Windows Server 2008
l Windows Server 2008 R2
l Windows 8
l Windows 8.1
l Windows Server 2012
l Windows Server 2012 R2

For details, see the latest support matrices at http://support.openview.hp.com/selfsolve/manuals.
l The following cross-platform restore combinations are supported:
From To
64-bit (x64) operating system 64-bit (x64) hardware architecture
32-bit operating system 32-bit or 64-bit (x64) hardware architecture
Dissimilar hardware restore of upgraded operating systems is only supported with the “Generic”
recovery mode option (see "Recovery procedure" on the next page).
l Network card teaming configurations are not supported. If you need them, you must reconfigure
them after the OS is restored. The disaster recovery module only restores physical network card
configurations.
l The disaster recovery module can only inject drivers for which an INF file is provided. Drivers that
have their own installation procedures (such as graphics drivers) are not supported and cannot be
injected during Phase 1 or Phase 2a. However, for boot-critical device drivers, manufacturers
typically provide INF files.
l The target machine’s disks should be kept attached to the same type of host adapter buses (such as
SCSI or SAS), otherwise the restore may fail.
l When restoring Domain Controllers, using the “Unattend” mode, you must login manually in order to
complete sysprep cleanup. Once the cleanup is completed the OS will reboot automatically and the
system will be ready for usage.
Recommendations
The system firmware of the target machine should be up-to-date before a dissimilar hardware restore is
attempted.
Drivers
Note: The DR OS image includes a large database of generic critical drivers, especially for storage
controllers. If you cannot find original drivers to inject, there is a good chance that generic ones
already exist in the DR OS image.
To enable restore onto dissimilar hardware, drivers vital for the restore and boot of the new system
must be available. You will need to provide the following drivers:
l For all storage controllers of the target system. This will enable the detection of the underlying
storage at restore/boot time.
l Network card drivers to enable network restore and access to existing driver store locations, along
with drivers for locally attached backup devices (such as tape drives) if a local restore is attempted.
Drivers for the original hardware can be included in the DR OS image during backup in the preparation
phase (Phase 0), and you can add drivers for new hardware during the creation of the image. You also
have the option of adding them manually during the restore process.

Although the disaster recovery module searches only for boot-critical drivers during the restore
process, you can add additional non-boot-critical drivers in the DR OS image, which you can then inject
during the restore using the “Load Drivers” Tasks menu option.
When the operating system has been booted you should install other missing hardware drivers.
You can inject drivers from a CD-ROM, DVD-ROM, or USB drive, a network share, or a local folder.
Preparation
Note: You need to perform this preparation after each hardware configuration change to the
system.
Preparation is the same as for EADR (see Preparation for EADR) and OBDR (see Preparation for
OBDR) with the following changes:
l The disaster recovery module also collects network configuration and hardware information.
l Critical device drivers (such as for storage, network or tape) should be present, so the disaster
recovery module can inject the drivers into the DR OS image at the image creation time. See
"Drivers" on the previous page.
Recovery procedure
If you enabled the dissimilar hardware restore in the Recovery Options page of the HPE Data Protector
Disaster Recovery GUI, the system is scanned for the missing drivers during the recovery process. If
any critical driver (such as storage, tape, network drivers, or disk controllers) is missing, you are
prompted to load the missing driver.
Steps
1. When you are prompted to load missing drivers during the disaster recovery procedure, click Yes
to start the Dissimilar Hardware wizard. If you click No, the driver injection procedure is skipped.
2. In the Select Devices page, select the devices, for which you want to load drivers. Click Next.
3. In the Driver Search Locations page, specify the locations on the running system where you keep
your drivers. Browse for the device driver or type the location in the Driver path text box and then
click Add path to add the specified path to the list. You can use the Search tree depth option to
adjust the search to your system specifics.
Note: You can remove the specified location from the search list by right-clicking this location
and then selecting Remove.
The specified locations will be searched for the missing drivers. Click Next.
4. After the specified locations are searched for the missing drivers, the following results are
possible:
l The device driver is found: the full path to the corresponding driver information file (*.inf) is
specified in the Driver path text box. Verify, if this driver is appropriate and click Next to load it.
l The device driver is not found: the Driver path text box is empty. Do one of the following:

If you want to search for a different driver, click Browse. In the Browse file dialog, select the
device driver path and then click Next.
If you do not want to load a driver to this device, you can leave the Driver path text box empty
and click Next to proceed to the next page, or, you can click Skip to exit the wizard.
Note: If you specify a driver that does not correspond to the device, this driver is indicated
as being invalid and you are not able to load it. If the driver is not appropriate, you can
change it or skip loading.
5. In the Driver Installation Progress page, you can view whether the device drivers were loaded
successfully. If any errors are reported, you can retry to load the drivers by clicking Retry. Click
Finish.
Restoring and preparing the OS
The process of restoring the OS is the same as in the standard EADR (from Step 5) and OBDR (from
Step 6) processes. After it, the recovery process prepares and adapts the restored OS to the dissimilar
hardware to prepare the OS for the restore of applications and files. This includes injecting boot-critical
drivers, updating the registry of the restored OS and mapping the network.
Since all boot-critical drivers should exist (loaded into the running DR OS image during Phase 0 or
added manually during the restore of the OS), injecting them occurs automatically. However your
intervention may be required to correct the network mappings.
Correcting network mappings
After you finished with restoring to dissimilar hardware, disaster recovery module checks, whether the
network adapters on the system you are recovering are different from the network adapters of the
original system. The disaster recovery module cannot always map the network configuration of the
original system to the network configuration of the target system on its own. This happens, for
example, when the target system has one network card and the original system has two or more
network cards, or when you add additional network adapters to the target system. When such
difference is detected or if the correct network mappings cannot be determined automatically, you have
an option to map the original network adapters to the network adapters discovered on the target
system.
Note: The network mapping occurs only for available network adapters. Network adapters without
drivers cannot be mapped. Because of this, you should load network card drivers before the restore
process begins.
Steps
1. In the Network Adapter Mapping page, select the network adapters of the original system in the
Original network adapters drop-down list. In the current network adapters drop-down list, select
one of the network adapters available on the target system. Click Add mapping. The mapping
you created is added to the list.
Note: You can remove a mapping from the list by right-clicking the mapping and then

selecting Remove.
2. When you mapped all the network adapters you wanted, click Finish.
After the OS is successfully restored
Dissimilar hardware restore resets the OS activation. Once the OS is successfully restored, you
should:
l Re-activate the OS.
l Check and, if needed, reinstall missing system drivers.
Restoring user and application data
This phase is the same as for EADR. See "Enhanced Automated Disaster Recovery (EADR) " on page
35.
Note: Third-party application services and drivers may fail to load once the OS is booted. These
applications will probably need to be reinstalled, reconfigured or removed from the current system if
they are not needed.
Recovery of a physical system to a virtual machine (P2V)
Data Protector supports recovery to virtualization environments which provide support for the original
operating system, such as VMware vSphere, Microsoft Hyper-V, or Citrix XenServer.
Prerequisites
The target virtual machine must meet the following requirements:
l The guest operating system must be of the same type as the original one (Windows, Linux).
l The virtual machine must have the same or larger number of disks than the original system.
l The disks must have the same or lager size as their original counterparts.
l The disk order must be the same as on the original system.
l The amount of memory assigned to a virtual machine may have an impact on the recovery process,
therefore it is recommended to allocate at least 1 GB of memory to the virtual machine.
l The virtual video card memory size must meet the requirement of the original system based on the
display resolution of the original system. If possible, use automatic settings.
l Add the same number of network adapters as on the original machine. The adapters must be
connected to the same network as the original ones.
Procedure
Boot the virtual machine using the DR OS image and follow the standard disaster recovery procedure
to dissimilar hardware.

Recovery of a virtual machine to a physical system (V2P)
Disaster recovery of a virtual machine to a physical system is performed using the standard disaster
recovery to dissimilar hardware.

Chapter 4: Disaster recovery on UNIX
systems
Manual Disaster Recovery (MDR)
Manual Disaster Recovery is a basic recovery method. This method involves recovering the system by
reinstalling it in the same way that it was initially installed. Data Protector is used to restore all files, including
the operating system.
MDR of an HP-UX client is based on the Ignite-UX product; an application primary developed for HP-UX
system installation and configuration tasks, which offers (in addition to a powerful interface for the system
administration) preparation and recovery of the system from a disaster.
While Ignite-UX is focused on the disaster recovery of the target client, Data Protector must be used to
restore the user and application data in order to complete Phase 3 of disaster recovery.
Note: This section does not cover the full functionality of Ignite-UX. For detailed information, see the
Ignite-UX administration guide.
Overview
Ignite-UX offers 2 different approaches to preparing a system for and recovering a system from a disaster:
l Using a custom installation medium (Golden Image)
l Using system recovery tools (make_tape_recovery, make_net_recovery)
While the usage of a custom installation medium is most suitable for IT environments with a large number of
basically identical hardware configurations and OS releases, the usage of system recovery tools supports the
creation of recovery archives, which are customized for individual systems.
Both methods allow the creation of bootable installation media like DDS-Tapes or CDs. Using these media,
the system administrator is able to perform a local disaster recovery directly from the system console of the
failed client.
In addition, both methods can also be used to run a network-based recovery of the client by assigning the
failed client a suitable Golden Image or the previously created “recovery archive”. In this case, the client boots
directly from the Ignite Server and runs the installation from the assigned depot, which must be located on an
NFS share on the network.
Use Ignite-UX GUI where it is supported.

Preparation for Manual Disaster Recovery (HP-UX Cell
Manager)
To prepare for a successful disaster recovery, you should follow the instructions related to the general
preparation procedure, together with the specific method requirements. You have to prepare in advance
in order to perform a disaster recovery fast and efficiently.
Preparation for a Manual Disaster Recovery of the Cell Manager includes:
l Gathering information for your backup specification
l Preparing your backup specification (using a pre-exec script)
l Executing a backup
l Executing Internal Database backup sessions regularly
All of these preparatory steps are necessary before executing disaster recovery on the Cell Manager.
One-time preparation
You should document the location of these files in the disaster recovery plan so that you can find the
information when disaster strikes. Also you should consider version administration (there is a collection
of the “auxiliary information” per backup).
If the system to be backed up has application processes active at low run-levels, you should establish
a state of minimal activity (modified init 1 run-level) to prepare the Cell Manager for a
consistent backup.
HP-UX systems
l Move some kill links from /sbin/rc1.d to /sbin/rc0.d and complement the changes for the
boot-up section. The kill links include the basic services which would otherwise be suspended by
moving to run-level 1, and they are needed for the backup.
l Ensure that rpcd is configured on the system (configure the option RPCD=1 within the
/etc/rc.config.d/dce file).
This prepares the system so that it enters a state of minimal activity that can be characterized as
follows:
l Init-1 (FS_mounted, hostname_set, date_set, syncer_running)
l Running processes: network, inetd, rpcd, swagentd
Backing up the system
After you have prepared the backup specification, you should execute the backup procedure. Repeat it
on a regular basis, or at least after every major system configuration change, especially after any
change in the physical or logical volume structure. Pay special attention to the IDB and filesystem
backup:
Chapter 4: Disaster recovery on UNIX systems

l Back up the IDB regularly, ideally in a separate backup specification, and scheduled after the
backup of the Cell Manager itself.
l Run the IDB and filesystem backup on a specific device attached to the Cell Manager system so
you know that the medium in the device contains the most recent backup version of the IDB.
Installing and Configuring HP-UX Systems Manually
(Cell Manager)
After a disaster happens, you should first install and configure the operating system (Phase 1). Then
you can recover the Cell Manager.
Steps
Phase 1
1. Replace the affected disk.
2. Boot your system from the operating system installation medium.
3. Reinstall the operating system. During the installation, use the data gathered during the
preparation phase (using a pre-exec script) to re-create and configure the physical and logical
storage/volume structure, filesystem, mount points, network settings, and so on.
Restoring System Data Manually (HP-UX Cell Manager)
After you have installed and configured the operating system (Phase 1), you can use Data Protector to
recover the Cell Manager.
Prerequisites
l You need media containing the latest backup image of the root volume of the Cell Manager system
and a newer latest backup image of the IDB.
l You need a device connected to the Cell Manager system.
Steps
Phase 2
1. Reinstall the Data Protector software on the Cell Manager.
2. Restore the IDB and the /etc/opt/omni directory from their respective latest backup images to a
temporary directory. This simplifies the restore of all other files from backup media. Remove the
/etc/opt/omni/ directory and replace it with the /etc/opt/omni directory from the temporary
directory. This re-creates the previous configuration.
3. Start Data Protector processes with the omnisv -start command.

Phase 3
4. Start the Data Protector GUI and restore the needed files from your backup images.
Your Cell Manager should now be successfully recovered.
Preparation for Manual Disaster Recovery (HP-UX
Client)
Ignite-UX offers 2 different approaches to preparing a system for and recovering a system from a
disaster:
Using custom installation Medium (Golden Image)
Using system recovery tools (make_tape_recovery, make_net_recovery)
Using custom installation medium (Golden Image)
Large IT environments often consist of a large number of systems that are based on identical hardware
and software. The installation time for the OS, applications and required patches for a new system can
be significantly reduced if a complete snapshot of an installed system is used to install other systems.
Ignite-UX includes a feature that allows you to modify parameters like networking or filesystem
settings, as well as add software like Data Protector to the image (with the Ignite-UX command make_
config) before you assign such a Golden Image to another system. This feature can thus be used to
recover a system from a disaster.
The general steps using a custom installation medium are:
1. Phase 0
a. Create a Golden Image of a client system.
2. Phase 1 and 2
a. Replace the faulty disk with a replacement disk.
b. Boot the HP-UX client from the Ignite-UX server and configure the network.
c. Install the Golden Image from the Ignite-UX server.
3. Phase 3
Creating a Golden Image
1. Copy the /opt/ignite/data/scripts/make_sys_image file from your Ignite-UX Server into a
temporary directory on the client system.
2. Run the following command on the client node to create a compressed image of the client on
another system: make_sys_image -d directory of the archive -n name of the
archive.gz -s IP address of the target system

This command will create a gzipped file depot in the specified directory on the system defined with
the -d and -s options. Make sure that your HP-UX client has granted password-free access to the
target system (an entry in the .rhosts file with the name of the client system on the target
system), otherwise the command will fail.
3. Add the target directory to the /etc/exports directory on the target system and export the
directory on the target server (exportfs -av).
4. On the Configuring Ignite-UX server, copy the archive template file core.cfg to archive_
name.cfg: cp /opt/ignite/data/examples/core.cfg /var/opt/ignite/data/OS_
Release/archive_name.cfg.
Example: cp /opt/ignite/data/examples/core.cfg /var/opt/ignite/data/Rel_
B.11.31/archive_HPUX11_31_DP70_CL.cfg
5. Check and change the following parameters in the copied configuration file:
l In the sw_source section:
load_order = 0
source_format = archive
source_type="NET"
# change_media=FALSE
post_load_script = "/opt/ignite/data/scripts/os_arch_post_l"
post_config_script = "/opt/ignite/data/scripts/os_arch_post_c"
nfs_source = "IP Target System:Full Path
l In the matching OS archive section:
archive_path = "archive_name.gz
6. Determine the “impacts” entries by running the command archive_impact on your image file and
copy the output in the same “OS archive” section of your configuration file:
/opt/ignite/lbin/archive_impact -t -g archive_name.gz.
Example: /opt/ignite/lbin/archive_impact -t -g /image/archive_HPUX11_31_DP70_
CL.gz
impacts = "/" 506Kb
impacts = "/.root" 32Kb
impacts = "/dev" 12Kb
impacts = "/etc" 26275Kb
impacts = "/opt" 827022Kb
impacts = "/sbin" 35124Kb
impacts = "/stand" 1116Kb
impacts = "/tcadm" 1Kb
impacts = "/usr" 729579Kb
impacts = "/var" 254639Kb
7. To make Ignite-UX aware of the newly-created depot, add a cfg entry to the
/var/opt/ignite/INDEX file with the following layout:
cfg "This_configuration_name" {

description "Description of this configuration”
"/opt/ignite/data/OS/config"
"/var/opt/ignite/data/OS/ archive_name.cfg"
}
Example:
cfg "HPUX11_31_DP70_Client" {
description "HPUX 11.i OS incl Patches and DP70 Client"
"/opt/ignite/data/Rel_B.11.31/config"
"/var/opt/ignite/data/Rel_B.11.31/archive_HPUX11_31_DP70_CL.cfg"
}
8. Make sure that one or more IP addresses reserved for booting clients are configured in the
/etc/opt/ignite/instl_boottab file. The number of IP addresses is equal to the number of
parallel booting clients.
After the above described procedure is completed, you will have a Golden Image of an HP-UX client
(with a specific hardware and software configuration), which can be used to recover any client of a
similar layout.
You need to repeat these steps to create a Golden Image for all systems with different hardware and
software configurations.
Ignite-UX enables you to create a bootable tape or CD based on the created Golden Image. See the
Ignite-UX Administration Guide for more information.
Recovering an HP-UX Client
There are 3 different methods to recover HP-UX clients using Manual Disaster Recovery (MDR):
Recovery using a Golden Image
Recovery from the bootable backup tape
Recovery from the network
Recovery using a Golden Image
You can recover an HP-UX client by applying the Golden Image, which is located on an NFS share on
your network.
On the client
Steps
1. Replace the faulty hardware.
2. Boot the HP-UX client from the Ignite-UX server: boot lan.IP-address Ignite-UX server
install.

3. Select Install HP-UX when the Welcome to Ignite-UX screen appears.
4. Choose Remote graphical interface running on the Ignite-UX server from the GUI Option
screen.
5. Respond to the Network configuration dialog.
6. The system is now prepared for a remote Ignite-UX Server-controlled installation.
On the Ignite-UX Server
Steps
1. Right-click the client icon in the Ignite-UX GUI and select Install Client - New Install.
2. Select the Golden Image you want to install, check the settings (network, filesystem, time zone,
...) and click Go!.
3. You can check the installation progress by right-clicking the client icon and choosing Client
Status.
4. After the installation has finished, restore additional user and application data using the standard
Data Protector restore procedure.
Recovery from the bootable backup tape
A bootable backup tape is created using the make_tape_recovery command.
Steps
1. Replace the faulty hardware.
2. Make sure that the tape device is locally connected to the affected HP-UX client and insert the
medium with the archive you want to restore.
3. Boot from the prepared recovery tape. To do so, type in SEARCH at the boot admin menu to get a list
of all available boot devices. Determine which one is the tape drive and type in the boot command:
boot hardware path or boot Pnumber.
4. The recovery process starts automatically.
5. After the recovery has completed successfully, restore additional user and application data using
the standard Data Protector restore procedure.
Recovery from the network
You can boot the target system over the network from the recovery archive file located on the Ignite-UX
server. Follow the instructions on how to perform a recovery using a Golden Image and make sure you
have selected the desired archive for the installation.

Using system recovery tools (make_tape_recovery, make_net_
recovery)
The usage of the system recovery tools bundled with the Ignite-UX enables a fast and easy recovery
from a disk failure. The recovery archive of system recovery tools includes only essential HP-UX
directories. However, it is possible to include other files and directories (for example, additional volume
groups or the Data Protector files and directories) in the archive to speed up the recovery process.
make_tape_recovery creates a bootable recovery (installation) tape, customized for your system and
enables you unattended disaster recovery by connecting the backup device directly to the target
system and starting up the target system from the bootable recovery tape. The backup device has to be
locally connected to the client during the creation of the archive and recovery of the client.
make_net_recovery allows you to create a recovery archive over the network onto the Ignite-UX
server or any other specified system. The target system can be recovered across subnets after starting
up either from a bootable tape created by the Ignite-UX make_boot_tape command or the system
boots directly from the Ignite-UX server. Starting up directly from the Ignite-UX server can be
automated with the Ignite-UX bootsys command or interactively specified on the boot console.
The general steps using system recovery tools are:
1. Phase 0
a. Create a recovery archive of an HP-UX client using the Ignite-UX GUI on the Ignite-UX
server.
2. Phase 1 and 2
a. Replace the faulty disk with a replacement disk.
b. For local restore, boot from the prepared recovery tape.
c. In case of a local restore, the recovery process starts automatically.
For network restore, boot from the Ignite-UX client and configure the network and UI.
In case of a network restore, install the Golden Image from the Ignite-UX server.
3. Phase 3
Prerequisites
Before you can to prepare your system for disaster, the Ignite-UX fileset must be installed on the client
in order to enable the Ignite-UX server to communicate with the client.
Make sure that the revisions of the Ignite-UX fileset on the Ignite-UX server and on the client are the
same. The simplest way to keep everything consistent is to install Ignite-UX from a depot build on the
Ignite-UX server. This depot can be constructed by running the following command on the Ignite-UX
server: pkg_rec_depot -f. This creates an Ignite-UX depot under
/var/opt/ignite/depots/recovery_cmds, which can be specified as a source directory by
swinstall on the client for the Ignite-UX software installation.
After you have installed Ignite-UX on the client node, you can use the GUI on the Ignite-UX server to
create recovery archives using make_net_recovery or make_tape_recovery.

Creating an archive using make_tape_recovery
1. Make sure that a backup device is connected to the HP-UX client.
2. Start the Ignite-UX GUI by executing the following command: /opt/ignite/bin/ignite &.
3. Right-click the client icon and select Create Tape Recovery Archive.
4. Select a tape device if more than one device is connected to the HP-UX client.
5. Select the volume groups you want to include into the archive.
6. The tape creation process will now begin. Check the status and log file on the Ignite-UX server by
right clicking the client icon and selecting Client Status.
Note: Ignite-UX recommends the usage of 90m DDS1 backup tapes to ensure that the tapes will
work with any DDS drive.
Creating an archive using make_net_recovery
The procedure for creating a recovery archive using make_net_recovery is almost the same as using
make_tape_recovery. The advantage is that there is no need for a locally-attached backup device, as
the recovery archive is stored on the Ignite-UX server by default.
1. Start the Ignite-UX GUI by executing the following command: /opt/ignite/bin/ignite &
2. Right-click the client icon and select Create Network Recovery Archive.
3. Select the destination system and directory. Make sure that there is enough space to store the
compressed archive.
4. Select the volume groups that you want to include in the archive.
5. The archive creation process will now begin. Check the status and log file on the Ignite-UX server
by right-clicking the icon and selecting Client Status.
Note: Ignite-UX allows you to create a bootable archive tape out of a compressed archive file. See
the chapter Create a Bootable Archive Tape via the Network in the Ignite-UX
Administration Guide.
Disk Delivery Disaster Recovery (DDDR)
There are two possible methods for Disk Delivery Disaster Recovery. You can use a working Data
Protector client system and create the new disk while connected to this client. Alternatively, you can
use an auxiliary disk without an additional working client. You need to collect enough data before the
disaster to be able to correctly format and partition the disk.
Overview
Disk Delivery of a UNIX client is performed using an auxiliary disk (which can be carried around), with a
minimal operating system with networking and a Data Protector agent installed on it.

chapter. The general steps using an auxiliary disk for a UNIX client are:
1. Phase 1
a. Replace the faulty disk with a replacement disk, connect the auxiliary disk to the target
system and restart the system with the minimal operating system installed on the auxiliary
disk.
b. Manually re-partition the replacement disk and re-establish the storage structure and make the
replacement disk bootable.
2. Phase 2
a. Use the standard Data Protector restore procedure to restore the boot disk of the original
system onto the replacement disk (use the Restore into option).
b. Shut down the system and remove the auxiliary disk. You do not need to shut down the
system if you are using a hot-swappable hard disk drive.
c. Restart the system.
3. Phase 3
Limitations
l An auxiliary disk should be prepared on a system of the same hardware class as the target system.
l The cluster environment recovery may differ from the standard procedure. Depending on the
configuration of the cluster environment, additional steps and modification to the environment may
be necessary.
l RAID is not supported.
Preparation for Disk Delivery Disaster Recovery of
UNIX Clients
To prepare for a successful disaster recovery, you should follow the instructions related to the general
preparation procedure, together with the specific method requirements. You have to prepare in advance
in order to perform a disaster recovery fast and efficiently. For details on supported operating systems,
see the HPE Data Protector Product Announcements, Software Notes, and References.
Preparation for a Disk Delivery Disaster Recovery includes:
l gathering information for your backup specification
l preparing an auxiliary disk
l preparing your backup specification (using a pre-exec script)
l executing the backup
All of these preparatory procedures are necessary before executing a disaster recovery on the client
system.

One-time preparation
If the information is collected as part of a pre-exec command, you should document the location of
these files in the disaster recovery plan so that you can find the information when disaster strikes. Also,
you should consider version administration (there is a collection of the “auxiliary information” per
backup).
You should also establish a state of minimal activity (modified init 1 run-level) on each client
system to prepare it for a consistent backup and thus avoid problems after recovery. Consult your
operating system documentation for details.
HP-UX Example
l Move some kill links from /sbin/rc1.d to /sbin/rc0.d and complement the changes for the
boot-up section. The kill links include the basic services which would otherwise be suspended by
moving to run-level 1, and they are needed for the backup.
l Ensure that rpcd is configured on the system (configure the option RPCD=1 within the
/etc/rc.config.d/dce file).
follows:
l Init-1 (FS_mounted, hostname_set, date_set, syncer_running)
l Network must be running
l Running processes: network, inetd, rpcd, swagentd
Solaris Example
l Move some kill links from /etc/rc1.d to /etc/rc0.d and complement the changes for the boot-
up section. The kill links include the basic services which would otherwise be suspended by moving
to run-level 1, and they are needed for the backup.
l Ensure that rpcbind is configured on the system.
follows:
l Init-1
l Network must be running
l Running processes: network, inetd, rpcbind
AIX
No action is required, because the alt_disk_install command, used to prepare the auxiliary disk,
ensures consistent disk image without entering the state of minimal system activity.

Preparing the auxiliary disk
If you want to work with an auxiliary disk, you need to prepare it first. Only one bootable auxiliary disk is
required per cell and platform. This disk has to contain the operating system and network configuration,
and has to be bootable.
Backing up the system
After you have prepared the backup specification, you should execute the backup procedure. Repeat it
on a regular basis, or at least after every major system configuration change, especially after any
change in the physical or logical volume structure.
Creating the Backup Specification for Disaster
Recovery of a UNIX Client
To configure a backup specification for Disaster Recovery of a UNIX client, either modify an existing
specification or create a new one with specified pre- and post-exec scripts. For details on supported
operating systems, see the HPE Data Protector Product Announcements, Software Notes, and
References.
Steps
1. Provide a Pre-exec script that will perform the following:
l Collect all necessary information about the environment and store it where it is available in case
a disaster recovery is needed. The information includes:
o The physical and logical storage structure of the system
o The current logical volume structure (for example, on HP-UX systems, using vgcfgbackup
and vgdisplay -v)
o Cluster configuration data, disk-mirroring, and striping
o A filesystem and mountpoint overview (for example, on HP-UX systems, using bdf or copy
of /etc/fstab)
o System paging space information (for example, on HP-UX systems, the output of the
swapinfo command)
o An I/O-structure overview (for example, on HP-UX systems, using ioscan -fun and
ioscan -fkn on HP-UX systems)
o Client network settings
An emergency copy of the data can also be put into the backup itself. If so, extract the
information prior to the actual recovery.
l Log out all users from the system.
l Shut down all applications, unless the application data gets backed up separately, for example,

using online database backup.
l Optionally, restrict network access to the system, so that nobody can log on to the system while
the backup is running (for example, on HP-UX systems, overwrite inetd.sec and use inetd -
c).
l If needed, enter a state of minimal system activity (for example, on HP-UX systems, use
sbin/init 1; wait 60; check if run-level 1 is reached). Note that this is a modified "init 1"
state.
2. Provide a post-exec script that will restore the system to the standard run-level, restart
applications, and so on.
3. Configure a backup specification for the client on the Data Protector Cell Manager using pre- and
post-exec scripts. It should include all the disks.
4. Execute this backup procedure and repeat it on a regular basis, or at least at every major system
configuration change, especially any change in the logical volume structure (for example, using
LVM on HP-UX).
Installing and Configuring a UNIX Client Using DDDR
After a disaster occurs, you should first install and configure a new disk for the faulty client (Phase 1).
Prerequisites
l An auxiliary disk should be prepared on a system of the same hardware class as the target system.
l An auxiliary disk should contain the relevant UNIX operating system and the Data Protector agents.
l You should have a valid full backup of the client that you want to recover.
Steps
1. Replace the faulty disk with a new disk of comparable size.
2. Attach the auxiliary disk (which contains the required operating system and the Data Protector
client) to the system and make it the boot device.
3. Boot from the auxiliary operating system.
4. Reconstruct the logical volume structure if applicable (for example, using LVM on HP-UX
systems). Use the backed-up data for the non-root volume groups (for example, with
vgcfgrestore or SAM on HP-UX systems).
5. Additionally, create the root volume group to be restored on the repaired disk (for example, using
vgimport on HP-UX systems). It will not look like a root volume group during the restore process,
because the operating system from the auxiliary disk will be running.
6. Make the new disk bootable using the relevant UNIX commands.
7. Reconstruct any other storage structures like mirror, striping, HPE Serviceguard, and so on from
the data saved on a secondary storage device during backup.

8. Create the filesystems and mount them as required by the data from the backup. Use similar but
not the original mountpoint names (for example, /etc_restore for /etc, and so on).
9. Remove any files in the mountpoints to be restored; they must be empty.
10. Proceed with restoring the system data.
Restoring System Data Using DDDR (UNIX Client)
You can restore a system to the state when the last successful backup was performed. You should
first install and configure the UNIX client (Phase 1). For details on supported operating systems, see
the HPE Data Protector Product Announcements, Software Notes, and References.
Prerequisites
l The relevant operating system should be installed and configured.
l Data Protector should be installed.
l You should have a valid full backup of the client that you want to recover.
l The media required for the restore should be available.
Steps
Phase 2
1. Start the Data Protector user interface and open a connection to the Data Protector Cell Manager.
2. Import the system with the auxiliary disk into the cell.
3. Select the backup version from which you want to restore.
4. Restore all the required mountpoints, including the (future) root-volume to the system, using the
option Restore As new_mountpoint.
The root-volume from the backup is restored to the root-volume on the "repaired disk". Nothing is
restored to the currently-running auxiliary operating system on the auxiliary disk.
5. Shut down and restart the system that was just restored.
6. Disconnect the auxiliary disk from the system.
7. Restart the system from the new (or repaired) disk.
Phase 3

Enhanced Automated Disaster Recovery
(EADR)
Data Protector offers an enhanced disaster recovery procedure for Linux Data Protector Cell Manager
and clients. For details on supported operating systems, see the latest support matrices at
EADR collects all relevant environment data automatically at backup time. During a full backup of the
entire client system, data required for the temporary DR OS setup and configuration is packed in a
single large recovery set file and stored on the backup tape (and optionally on the Cell Manager) for
each backed up client in the cell.
In addition to this image file, a Phase 1 Startup file (P1S file), required for correct partitioning and
formatting of the disk is stored on a backup medium and on the Cell Manager. When a disaster occurs,
the Enhanced Automated Disaster Recovery Wizard is used to restore the recovery set from the
backup medium (if it has not been saved on the Cell Manager during the full backup) and convert it into
a disaster recovery CD ISO image. The CD ISO image can be recorded on a CD using any CD burning
tool and used to boot the target system.
Once DR OS Image is booted, Data Protector automatically formats and partitions the disks, and
finally recovers the original system with Data Protector as it was at the time of the backup.
HPE recommends to restrict access to backup media, recovery set files, SRD files, and disaster
recovery CDs.
Overview
chapter. The general steps using the Enhanced Automated Disaster Recovery method for a Linux
client are:
1. Phase 1
b. Boot the target system from the disaster recovery CD or USB flash drive and select the scope
of recovery. This is a completely unattended recovery.
2. Phase 2
a. Depending on the recovery scope you select, the selected volumes are automatically
restored. Critical volumes (the boot and root volumes and the volumes containing the Data
Protector installation and configuration) are always restored.
3. Phase 3
Prepare a DR OS image in advance for any critical systems that must be restored first (especially DNS
servers, Cell Managers, Media Agent clients, file servers, and so on).
Prepare removable media containing encryption keys in advance for Cell Manager recovery.

The following sections explain the limitations, preparation steps, and the recovery procedure that
pertains to EADR of the Linux clients.
Requirements
which you want to enable recovery using this method and on systems where the DR OS image will
be prepared. For details, see the HPE Data Protector Installation Guide.
l An additional 200 MB of free disk space is required on the boot partition at backup time. If this disk
space is not available, the disaster recovery fails.
l During the EADR preparation, the volume on which Data Protector is installed should have at least
800 MB of temporary free space. This space is required to create a temporary image.
l The system’s BIOS must support bootable CD extensions, as defined in the El-Torito standard, and
read/write access to hard disk drives using LBA addressing via INT13h function XXh. The BIOS
options can either be checked in the user manuals of the system or by inspecting the system setup
before the boot.
Limitations
l Enhanced Automated Disaster Recovery (EADR) and One Button Disaster Recovery (OBDR) are
available on Linux systems only.
l You must create DR ISO images for Linux systems on Linux systems. You cannot create DR ISO
images for on other systems (Windows systems, HP-UX systems, Solaris systems). The limitation
does not apply for updating the SRD file or other tasks.
l If you have a mount point with the name CONFIGURATION and it contains the directory
SystemRecoveryData, data in the directory SystemRecoveryData will not be backed up.
l Do not mount disks using the disk ID, because the ID is unique and depends on the disk serial
number. In case of a disaster, the disk may be replaced and the new disk will have a new ID. As a
result, the disaster recovery fails.
l A custom kernel installation or configuration is not supported, only the original kernels provided with
the distributions are supported.
l When restoring a Linux client with SELINUX enforcing mode enabled, the system has to relabel all
system files after recovery which, depending on system configuration, can take some time to
complete. If permissive mode is used, the system log will contain a large number of SELINUX
warning messages.
l When you create a backup specification with the CONFIGRATION/SYSTEMRECOVERYDATA
object selected, the folders /opt/omni/bin/drim/log and /opt/omni/bin/drim/tmp are by
default excluded from the backup.

l Fusion IO disks that do not automatically attach at MiniOS boot time need to be manually attached
prior to recovery. This is required when replacing an old Fusion IO disk with a new one or when an
internal Fusion IO disk error occurs. Those disks need to be formatted using specific tools before
being attached in the MiniOS. To format and attach a Fusion IO disk manually to the system, you
need to run the following commands in Linux shell present in MiniOS before the recovery starts:
l fio-status – List the status of all the Fusion IO disks.
l fio-format [path] – Perform low-level format of the Fusion IO disk.
l fio-attach [path] – Attach the Fusion IO disk to the system.
l AUTODR does not support recovery of btrfs on multiple devices (various btrfs raid configurations)
as they are not supported by SLES 11.3.
l The current btrfs tools on SLES 11.3 do not set the UUID on a newly created btrfs file system.
Therefore, AUTODR cannot set the same UUID on btrfs file systems during recovery as done for
backup.
If you mount the btrfs file systems by UUID instead of a device name, you need to manually edit the
/etc/fstab file after restore. This needs to be done to reflect the new and correct UUIDs of the
recovered btrfs devices. The same is applicable for the GRUB configuration, so avoid the UUID.
After a system recovery, the btrfs has different UUIDs than the ones during backup. If another
recovery is performed from backups created before the last recovery of the system, the AUTODR
tries to identify healthy btrfs file systems and skips recreating them.
l AUTODR can only map the btrfs device configurations in backup to btrfs devices in the present
system being recovered by UUID. It can skip recovering wrong devices or recreated ones.
To avoid this, recover btrfs file systems only from backups created after the last system recovery or
destroy manually present btrfs file systems before a system recovery. The same is applicable for
btrfs file systems manually recreated by users after the last backup.
Note: Data Protector warns users of this before starting the recovery process.
l btrfs snapshots can be backed up but restored only as oridinary sub volumes. During such an
instance, none of the data will be shared between the snapshot and sub volume from where the
snapshot is created. The overall Copy On Write (COW) relationship between the parent and its
snapshot is lost. Therefore, in some cases, restore of complete data set is not possible, as data
from the snapshot is duplicated and runs out-of-space on the underlying device during restore.
l Only data from the mounted btrfs sub volumes are protected. Consider child sub volumes
accessible from an OS file system interface and parent sub volume being mounted. In such a case,
the sub volumes are not protected, as Disk Agent (DA) detects them as a different file system and
skips them because they do not have a dedicated mount point.
l Sub volumes mounted using the subvolid (refer to the btrfs documentation) mount option in
/etc/fstab file can be skipped from mount in the recovered system or mounted on a wrong mount
point, as subvolid of recovered sub volume need not be the same as the one during backup. Even
though all sub volumes are recreated, the Data Protector skips restore in such sub volumes or data
can be restored in wrong ones.
Note: Use the subvol option in fstab instead of subvolid.

l EADR of systems with Fibre Channel over Ethernet (FCoE) LUNs and Fibre Channel over Ethernet
(FCoE) SAN boot are not supported..
l Only vendor-specific partitions of type 0x12 (including EISA) and 0xFE are supported for EADR.
Preparation for Enhanced Automated Disaster
Recovery
procedure for all disaster recovery methods before completing the steps listed in this topic. You have to
prepare in advance in order to perform a disaster recovery fast and efficiently. You should pay special
attention to disaster recovery preparation for the Cell Manager.
1. Perform a full backup of the client system. It is recommended that you back up the whole client,
however, you need to select at least the following critical volumes and objects:
l the boot and system volumes
l the Data Protector installation volume
l the volume where the CONFIGURATION object is located
For a Data Protector Cell Manager system, see "Additional preparations for the Cell Manager"
below..
See the HPE Data Protector Help index: “backup, UNIX specific” and “backup, configuration”
During a full client backup, the recovery set and P1S file are stored on the backup medium and
(optionally) on the Cell Manager.
2. After a disaster occurs, use the EADR Wizard to convert the DR image into a disaster recovery
CD ISO image.
3. Record the disaster recovery CD ISO image on a CD using any CD recording tool that supports
the ISO9660 format. This disaster recovery CD can then be used to boot the target system and
automatically restore critical volumes.
Additional preparations for the Cell Manager
Successful disaster recovery of the Cell Manager requires additional preparation.

l Regularly back up the IDB. The IDB session should not be older than the file system session.
l Store the Cell Manager's SRD file at a safe location (not on the Cell Manager).
l Prepare a disaster recovery OS image for the Cell Manager in advance.
Saving a Recovery Set to the Cell Manager
A recovery set is packed in a single large file and stored on the backup medium and optionally on the
Cell Manager during a full client backup. Saving the recovery set file to the Cell Manager is useful if you
plan to record the disaster recovery CD on the Cell Manager, because it is much faster to obtain the
recovery set file from the hard disk than to restore it from a backup medium.
If the recovery set is saved to the Cell Manager during backup, it is saved to the default Data Protector
P1S files location.
To change the default location, specify a new global option EADRImagePath = valid_path (for
example, EADRImagePath = /home/images or EADRImagePath = C:temp).
See the HPE Data Protector Help index: “Global Options, modifying”.
Tip: If you do not have enough free disk space in the destination directory, you can create a mount
point (Windows systems) or a link to another volume (UNIX systems).
Saving the recovery set to the Cell Manager for all clients in the backup
specification
Steps
4. In the Results Area, click Options.
5. Under Filesystem Options click Advanced.

Other options tab
Saving the recovery set to the Cell Manager for a particular client in the
backup specification
To copy the recovery set files only for particular clients in the backup specification, perform the
following steps:
4. In the Results Area, click Backup Object Summary.
5. Select the client for which you would like to store its recovery set file onto the Cell Manager and
click Properties.

recovery.
Preparing a DR OS image
After a disaster occurs, you should prepare a DR OS image to be recorded on a disaster recovery CD
or saved to a bootable USB drive, which can then be used for Enhanced Automated Disaster
Recovery. Alternatively, you can prepare a bootable network image.
Note that the Data Protector Automatic Disaster Recovery component must be installed on the system
where a DR OS image will be prepared.
A new disaster recovery OS image has to be prepared after each hardware, software or configuration
change.
Prepare a DR OS image in advance for any critical systems that must be restored first, especially
systems required for the network to function properly (DNS servers, domain controllers, gateways, and
so on), Cell Managers, Media Agent clients, file servers, and so on.
It is recommended to restrict access to backup media and disaster recovery CDs or USB drives
containing the OS image.
Steps
2. In the Scoping Pane, click Tasks, and then click Disaster Recovery to start the Disaster
Recovery Wizard.
3. In the Results Area, select the client for which you would like to prepare the DR OS image from
the Host to be recovered drop down list and click Validate to validate the client.
Note: The validated client gets added to the Host to be recovered drop down list.
4. From the Recovery media creation host drop down list, select the client on which you will
prepare the DR OS image. By default, this is the same client for which the DR OS image is
prepared for. The client on which you prepare the DR OS image must have the same OS type
installed (Windows, Linux) and must have a Disk Agent installed.
5. Keep the Enhanced Automated Disaster Recovery selected and select whether the volume
recovery set will be built from a backup session or a list of volumes. By default, Backup session
is selected.
Click Next.
6. Depending on the recovery set build method select:

l If you selected Backup session, select the host backup session and in case of a Cell Manager,
the IDB session.
l If you selected Volume list, for each critical object select an appropriate object version.
Click Next.
7. Select the location of the recovery set file. By default, Restore recovery set file from a backup
is selected.
If you have saved the recovery set file on the Cell Manager during backup, select Path to the
recovery set file and specify its location. Click Next.
8. Select the image format. The following options are available:
l Create bootable ISO image: a DR ISO image (by default, recovery.iso)
l Create bootable USB drive: a DR OS image on a bootable USB drive
l Create bootable network image: a DR OS image that can be used for the network boot (by
default, recovery.wim)
9. If you are creating a bootable ISO image or a bootable network image, select the destination
directory, where you would like to place the created image.
If you are creating a bootable USB drive, select the destination USB drive or disk number, where
you would like to place the created image.
During the creation of the bootable USB drive, all data stored on the drive will be lost.
10. Optionally, set a password to protect the DR OS image from unauthorized use. The lock icon
indicates whether a password has been set.
Click Password to open the Password Protect Image dialog window and enter the password. To
remove the password, clear the fields.
11. Click Finish to exit the wizard and create the DR OS image.
12. If you are creating a bootable CD or DVD, record the ISO image on a CD or DVD using a recording
tool that supports the ISO9660 format.
Recovering Linux Systems Using EADR
You can successfully perform the Enhanced Automated Disaster Recovery of a Linux system only if all
preparation steps were fulfilled. If you are recovering a Cell Manager, first the Internal Database is
restored from its backup image, and restore of the volumes and the CONFIGURATION object from
their backup image follows afterwards. For details on supported operating systems, see the HPE Data
Prerequisites
l You should have a valid full filesystem backup of the entire system that you want to recover (client
backup).

l For disaster recovery of the Cell Manager, you should have a valid Internal Database backup image
that is newer than the filesystem backup image.
l You need a disaster recovery CD.
Steps
Phase 1
1. Unless you are performing an offline disaster recovery, add a Data Protector admin account with
the following properties to the Data Protector admin user group on the Cell Manager:
l Start restore
l Restore to other clients
l Restore as root
Note: The disaster recovery procedure can only be performed by the root user.
Protector users”.

2. Boot client system from the disaster recovery CD of the original system.
3. Press Enter when the following message is displayed: Press Enter to boot from Recovery CD.
4. The DR OS is loaded first into memory and then the scope menu is displayed. Select the scope of
recovery. There are four different scopes of recovery and two additional options:
l Reboot: Disaster recovery is not performed and the computer is restarted.
l Default Recovery: Recovers the /boot and / (root) volumes and all volumes on which Data
Protector installation and configuration files are located (/opt, /etc, and /var). All other disks
are not partitioned and formatted and are ready for Phase 3.
l Minimal Recovery: Recovers only the /boot and / (root) volumes.
l Full Recovery: All volumes are recovered, not only the critical ones.
l Full with Shared Volumes: All volumes are recovered, including shared volumes that were
locked at backup time.
l Run shell: Runs the Linux shell. You can use it for advanced configuration or recovery tasks.
Note: All BTRFS volumes and sub volumes are recovered by Disaster Recovery irrespective
of the selected recovery scope (default, minimal, or full recovery).
Phase 2
5. The Disaster Recovery Wizard appears. To modify the disaster recovery options, press any key
to stop the wizard during the countdown and modify the options. To continue with the disaster
recovery, select Proceed With Restore.
Note: Ensure that the Cell Manager and Media (backup) host is reachable. If not, you may
have to modify the NIC and MAC addresses. For more information, see Cell Manager and
RMA hosts are not responding.
6. If the disaster recovery backup is encrypted and you are either recovering the Cell Manager or a
client where the Cell Manager is not accessible, the following prompt will appear:
Press y.
7. If the information in SRD file is not up to date (for example, because you changed the backup

recovery and restore all critical volumes.
Note that Data Protector will first try to perform online restore. If the online restore fails for any
access to the Cell Manager), Data Protector tries to perform remote offline recovery. If even the
remote offline restore fails (for example, because the Media Agent host accepts only requests
from the Cell Manager), Data Protector will perform a local offline restore.
9. Remove the client’s local Data Protector account created in step 1 from the Data Protector admin
recovery.
10. If you are recovering a Cell Manager, make the IDB consistent.
Phase 3
12. Additional steps are necessary if you are performing disaster recovery of all nodes in a cluster.
One Button Disaster Recovery (OBDR) is an automated Data Protector recovery method for Linux
Data Protector clients, where user intervention is reduced to minimum. For details on supported
operating systems, see the latest support matrices at
OBDR collects all relevant environment data automatically at backup time. During backup, data
required for temporary DR OS setup and configuration is packed in a single large OBDR image file
(recovery set) and stored on the backup tape. When a disaster occurs, OBDR device (backup device,
capable of emulating CD-ROM) is used to boot the target system directly from the tape which contains
the OBDR image file with disaster recovery information.
Data Protector then runs and configures the disaster recovery operating system (DR OS), partitions
and formats the disks and finally restores the original operating system with Data Protector as it was at
the time of backup.
Perform a new backup after each hardware, software or configuration change. This also applies to any
network configuration changes, such as change of IP address or DNS server.
The OBDR procedure recovers volumes depending on the selected scope of the recovery.
Any remaining volumes can be recovered using the standard Data Protector restore.
Overview
chapter. The general steps using the One Button Disaster Recovery method for a Windows client are:

1. Phase 1
Boot from the recovery tape and select the scope of recovery.
2. Phase 2
Depending on the recovery scope you select, the selected volumes are automatically restored.
Critical volumes (the boot partition and the operating system) are always restored.
3. Phase 3
Restore any remaining partitions using the standard Data Protector restore procedure.
HPE recommends to restrict access to OBDR boot media.
The following sections explain the requirements, limitations, preparation and recovery pertaining to One
Button Disaster Recovery on Windows systems.
Requirements
which you want to enable recovery using this method. Additionally, the Automatic Disaster
Recovery component must be installed on systems where the DR OS image will be prepared. For
details, see the HPE Data Protector Installation Guide.
l The client system must support booting from the tape device that will be used for OBDR.
For more information about supported systems, devices and media, see the HPE Tape Hardware
Compatibility Table and the latest support matrices at
l The volume on which Data Protector is installed should have at least 800 MB of free space. This
space is required to create a temporary image.
l A media pool with a Non-appendable media usage policy and a Loose media allocation policy has to
be created for the OBDR capable device. Only media from this pool can be used for disaster
recovery.
l In a SAN boot configuration, make sure the following items on the target system are identical to the
ones on the original system:
l The local HBA's BIOS parameters
l The SAN disks LUN numbers
l In multipath SAN disk configurations, the LUNs and WWIDs of the target system disks must be
identical to the ones on the original system.
Limitations
l A One Button Disaster Recovery backup session can only be run for one selected client or Cell
Manager on the same OBDR device at a time. This has to be done on a single, locally-attached

OBDR capable device.
l USB tape storage devices are not supported.
l If you have a mount point with the name CONFIGURATION and it contains the directory
SystemRecoveryData, data in the directory SystemRecoveryData will not be backed up.
l Do not mount disks using the disk ID, because the ID is unique and depends on the disk serial
number. In case of a disaster, the disk may be replaced and the new disk will have a new ID. As a
result, the disaster recovery fails.
l When restoring a Linux client with SELINUX enforcing mode enabled, the system has to relabel all
system files after recovery which, depending on system configuration, can take some time to
complete. If permissive mode is used, the system log will contain a large number of SELINUX
warning messages.
l When you create a backup specification with the CONFIGRATION/SYSTEMRECOVERYDATA
object selected, the folders /opt/omni/bin/drim/log and /opt/omni/bin/drim/tmp are by
default excluded from the backup.
l Fusion IO disks that do not automatically attach at MiniOS boot time need to be manually attached
prior to recovery. This is required when replacing an old Fusion IO disk with a new one or when an
internal Fusion IO disk error occurs. Those disks need to be formatted using specific tools before
being attached in the MiniOS. To format and attach a Fusion IO disk manually to the system, you
need to run the following commands in Linux shell present in MiniOS before the recovery starts:
l fio-status – List the status of all the Fusion IO disks.
l fio-format [path] – Perform low-level format of the Fusion IO disk.
l fio-attach [path] – Attach the Fusion IO disk to the system.
l Only vendor-specific partitions of type 0x12 (including EISA) and 0xFE are supported for OBDR.
Preparation for One Button Disaster Recovery
procedure for disaster recovery before completing the steps listed in this topic. Prepare in advance in
order to perform a disaster recovery fast and efficiently.
Preparatory steps
After you have completed the general preparation for disaster recovery, perform the following specific
steps to prepare for OBDR.

1. Create a media pool for DDS or LTO media with the Non-appendable media usage policy and the
Loose media allocation policy (because the backup media is formatted during OBDR backup). In
addition,specify this media pool as the default media pool for the OBDR device. See the HPE
Data Protector Help index: “creating media pool”. Only media from such pool can be used for
OBDR.
2. Perform the OBDR backup locally on the system for which you want to enable recovery using
OBDR.
If the full client backup was encrypted, store the encryption key on a removable medium so that it
is available for disaster recovery. You will need the key if the connection to the Cell Manager
cannot be established.
Creating the Backup Specification for One Button Disaster
Recovery
You need to create a One Button Disaster Recovery (OBDR) backup specification in order to prepare
the OBDR boot tape.
Prerequisites
l Before adding an OBDR device, create a media pool for DDS or LTO media with the Non-
appendable media usage policy and the Loose media allocation policy. The created media pool must
be selected as the default media pool for the OBDR device.
l This device has to be connected locally to the system, for which you want to enable recovery using
OBDR.
l The Data Protector Automatic Disaster Recovery and User Interface components must be installed
on systems for which you want to enable recovery using the OBDR method.
l This backup specification has to be created locally on the system, for which you want to enable
recovery using OBDR.
Tip: To enable an automatic restore of all shared disk volumes in the MS Cluster using the OBDR
method, move all volumes temporarily to the node for which you are preparing the OBDR boot tape.
It is practically impossible to collect enough information to configure the disk in Phase 1 for shared
disk volumes that are locked by another node.
Limitations

Steps
2. In the Scoping Pane, click Tasks, and then click One Button Disaster Recovery Wizard.
3. In the Results Area, select the client for which you would like to perform an OBDR backup (locally
on the client) from the drop-down list and click Next.
4. The critical volumes that you need to back up are already selected. Click Next.
Important volumes are selected automatically and cannot be deselected. Select any other
partitions you want to keep, because during the recovery procedure Data Protector deletes all
partitions from your system.
5. Select the local device or drive to be used for the backup. Only one device or drive can be
selected. Click Next.
6. Select backup options. For more details on available options, see the HPE Data Protector Help
index: “backup options”.
7. Click Next to proceed to the Scheduler page, which can be used to schedule the backup. See the
HPE Data Protector Help index: “scheduling backups on specific dates and times”.
8. In the Backup Summary page, review the backup specification settings, and then click Next.
Note: You cannot change a previously selected backup device or the order in which the
backup specifications follow one another. Only OBDR non-essential backup objects can be
deleted and only general object properties can be viewed.
You can also change a backup object description.
9. In the final page of the Backup wizard, you can save the backup specification, start the interactive
backup, or preview the backup.
HPE recommends to save the backup specification so that you can schedule or modify it later.
Once a backup specification is saved, you can edit it. Right-click the backup specification and
select Properties. You are offered to treat the modified backup specification as a standard Data
Protector backup specification or as an OBDR backup specification. Save it as an OBDR backup
specification to ensure that you do not override OBDR-specific options in it. If saved as a standard
backup specification, it may not be usable for OBDR purposes.
10. Click Start Backup to run the backup interactively. The Start Backup dialog box appears. Click OK
to start the backup.
If the backup is an encrypted, encryption IDs are exported automatically by the omnisrdupdate
utility which is executed as a post-exec command.
A bootable image file of the system, containing all information required for installation and configuration
of temporary DR OS, will be written at the beginning of the tape to make it bootable.
Perform a new backup and prepare a bootable backup medium after each hardware, software, or
configuration change. This also applies to any network configuration changes, such as change of IP
address or DNS server.

recovery.
Recovering Linux Systems Using OBDR
You can successfully perform the One Button Disaster Recovery (OBDR) of a Linux system only if all
preparation steps were fulfilled.
For details on supported operating systems for OBDR, see the HPE Data Protector Product
Announcements, Software Notes, and References.
Prerequisites
l You should have a bootable OBDR backup medium with all critical objects of the client that you
want to recover. The OBDR backup has to be performed locally on the client.
l You need an OBDR device connected locally to the target system.
Steps
Phase 1
1. Unless you are performing an offline disaster recovery, add a Data Protector admin account with
the following properties to the Data Protector admin user group on the Cell Manager, depending on
the operating system of the target system:
l Start restore
l Restore to other clients
l Restore as root
Note: The disaster recovery procedure can only be performed by the root user.

Protector users”.
2. Insert the tape containing the image file and your backed up data into an OBDR device.
3. Shut down the target system and power off the tape device.
4. Power the target system on and, while it is being initialized, press the Eject button on the tape
device and power it on. For details, see the device documentation.
5. The DR OS is loaded first into memory and then the scope menu is displayed. Select the scope of
recovery. There are four different scopes of recovery and two additional options:
l Reboot: Disaster recovery is not performed and the computer is restarted.
l Default Recovery: Recovers the /boot and / (root) volumes and all volumes on which Data
Protector installation and configuration are located (/opt, /etc, and /var). All other disks are
not partitioned and formatted and are ready for Phase 3.
l Minimal Recovery: Recovers only the /boot and / (root) volumes.

l Full Recovery: All volumes are recovered, not only the critical ones.
l Full with Shared Volumes: All volumes are recovered, including shared volumes that were
locked at backup time.
l Run shell: Runs the Linux shell. You can use it for advanced configuration or recovery tasks.
Phase 2
6. The Disaster Recovery Wizard appears. To modify the disaster recovery options, press any key
to stop the wizard during the countdown and modify the options. Select Proceed With Restore to
continue with the disaster recovery.
7. If the disaster recovery backup is encrypted and you are recovering a client whose Cell Manager is
not accessible, the following prompt is displayed:
Press y.
recovery and restore all critical volumes.
Note that Data Protector first tries to perform an online restore. If the online restore fails for any
access to the Cell Manager) Data Protector tries to perform remote offline recovery. If the remote
offline restore fails (for example, because the Media Agent host accepts requests only from the
Cell Manager), Data Protector performs a local offline restore.
10. Remove the client’s local Data Protector account created in step 1 from the Data Protector admin
recovery.
Phase 3
recovery tasks (such as editing the SRD files).

Chapter 5: Troubleshooting disaster
recovery
This chapter contains descriptions of problems you might encounter while performing a disaster recovery.
You can start with problems connected to a particular disaster recovery method and continue with general
disaster recovery problems. For information where to find the error messages, see "Troubleshooting disaster
recovery" above.
For general Data Protector troubleshooting information, see the HPE Data Protector Troubleshooting Guidee.
Before you begin
l Ensure that the latest official Data Protector patches are installed. For more information on how to verify
this, see the HPE Data Protector Help index: “patches”.
l For general Data Protector limitations, as well as known problems and workarounds, see the HPE Data
l For an up-to-date list of supported versions, platforms, and other information, see
Troubleshooting Automatic Disaster Recovery
The AUTODR.log file
Automatic Disaster Recovery includes two disaster recovery methods: EADR and OBDR. Messages
relevant to these methods are logged in the AUTODR.log file, located in the default Data Protector temporary
files directory. You should inspect it if an error has occurred.
AUTODR.log logs many different messages, mostly for development and support purposes. Only some of
them are relevant to you and indicate that an error has occurred. These error messages are usually logged at
the end of the log file with a traceback appended.
There are four levels of messages (note that they do not correspond to the same report levels for messages
that are reported at the end of a backup session in the Data Protector GUI) in the AUTODR.log file:
l Critical error: the error is so serious that the backup of the object cannot continue and will be aborted.
l Error: there is an error but if it is critical, depends on different factors.
For example, AUTODR.log reports an error that some driver has not been included in the DR OS. The
missing driver may be the reason why the recovered system is not operational after the recovery. This can
also result in some non-critical service not to be running after the boot of the operating system. The
seriousness of an error depends on which driver has not been backed up.
l Warning and Info: These are not error messages and usually do not mean that anything is wrong.
Two of the most common messages stated in the AUTODR.log file are:

l unsupported location: Data Protector notices that a certain file required by a service or a driver
that will be included in the DR OS, is not located under the %SystemRoot% directory.
Such drivers are often used by the antivirus and remote control software (for example, pcAnywhere).
This message is important, because it can mean that the service/driver that requires the missing file,
will not be operational after the boot. The success of disaster recovery depends on which service or
driver was affected. A possible solution to this problem is copying the missing file into the
%SystemRoot% directory and changing its path in the Windows Registry. Note that incorrect editing
of the Windows Registry may severely damage your system.
Debugging disaster recovery sessions
During a disaster recovery session, the debugging settings and the location of the debug logs depend
on the disaster recovery phase:
l During the DR OS preparation, the debug logs are automatically saved to X:$DRM$log (Windows
Vista and later releases), c:$DRM$log (Windows XP, Windows Server 2003), or
/opt/omni/bin/drim/log/Phase1.log (Linux systems).
l During the data restore step, you must manually select the debugging options in the Disaster
Recovery Wizard to enable debugging.
Windows
To enable creation of debug logs:
1. In the Disaster Recovery Wizard, press any key to stop the wizard during the countdown.
Select the check box to the left of the Debugs button.
Enabling debugs during a disaster recovery session
Chapter 5: Troubleshooting disaster recovery

2. To specify the debug options, such as the location where the debugs are saved, click Debugs....
By default, the debugs are saved into the %SystemRoot%system32OB2DRtmp directory.
Note: On Windows Vista and later releases, the directory
%SystemRoot%system32OB2DRtmp resides on RAM disk. The RAM disk size is typically
limited to less than 64 MB. Once the RAM disk usage reaches the limit, Data Protector may
start to behave unpredictably. Thus, if you expect that the disaster recovery session will
produce a large amount of debugs, you must change the location to which the debugs will be
saved.
The Debug Options window appears.
Changing the debug logs location

3. Enter the location, where the debug logs are saved. The drive must be preceded by ?, for
example, ?Z:debug.txt. If you choose to save the debugs on a network share, use the net
use command to mount the share to which the debug logs are written. For example, net use X:
"clientdebug_output_folder /user:username password".
Linux systems
To enable creation of debug logs:
1. In the Disaster Recovery Wizard, select Use debugs.
2. On the debug options screen, select to either use the default options or modify them.
Select one of following options:
1) Use Default Debug Option "-debug 1-200 dr.txt"
2) Specify Different Debug Option
3) Disable Debug option
Command [1-3]:
Note: On Linux systems, the directory to which the debug logs are saved, resides on RAM
disk. The RAM disk size is typically limited. Once the RAM disk usage reaches the limit, Data
Protector may start to behave unpredictably. Thus, if you expect that the disaster recovery
session will produce a large amount of debugs, you should change the location to which the
debugs will be saved. To change the location, select Specify Different Debug Option.
3. A new screen will appear on which you can enter the debug parameters.
Examples:
-debug 1-200 debug.txt (local storage)
-debug 1-200 //servername/sharename/debug.txt (windows share)
-debug 1-200 servername:/sharename/debug.txt (nfs share)

Specify the debug option string that you want to use:
You can choose to save the debug files to a Windows shared disk or an NFS shared folder.
Setting omnirc options during disaster recovery
For general information on omnirc options, see the HPE Data Protector Troubleshooting Guide.
If you need to set an omnirc option during the disaster recovery on a Windows or Linux system, perform
the following steps:
Windows systems
1. When the Disaster Recovery Wizard appears, press any key to stop the wizard during the
countdown.
2. Click Cmd to start the command prompt.
3. Run the following command:
echo variable > %SystemRoot%system32OB2DRomnirc
where variable is the omnirc option exactly as it should be written in the omnirc file.
For example:
echo OB2RECONNECT_RETRY=1000 > %SystemRoot%system32OB2DRomnirc
This command creates an omnirc file in the disaster recovery operating system with the
OB2RECONNECT_RETRY option set to 1000 seconds.
4. Close the command prompt and click Next in the Disaster Recovery Wizard to proceed with
disaster recovery.
Linux systems
1. In the Disaster Recovery Wizard, switch to another console by pressing Alt F3.
2. In the console, run the following command:
echo variable > /opt/omni/.omnirc
where variable is the omnirc option exactly as it should be written in the .omnirc file.
Example:
echo OB2RECONNECT_RETRY=1000 > /opt/omni/.omnirc
This command creates a .omnirc file in the disaster recovery operating system with the
OB2RECONNECT_RETRY option set to 1000 seconds.
3. Type exit to exit the shell and proceed with disaster recovery in the Disaster Recovery Wizard.
The drm.cfg file on Windows
The Data Protector disaster recovery configuration is set up to cover a broad range of system
configurations. However, in some cases, these settings may not be the most appropriate, or you may
want to modify some of the settings in order to troubleshoot issues on your system.

The drm.cfg file contains several parameters that you can modify and which affect the disaster
recovery process, along with a description of their impact. The file is available for EADR and OBDR.
To change the parameters:
1. Copy the template file drm.cfg.tmpl to drm.cfg. The template is created during an installation or
upgrade in Data_Protector_homebindrimconfig, with all parameters set to their default
values.
2. Edit the drm.cfg file. Set the desired value for parameters. Follow the instructions in the file.
Disabling the automatic collection of EADR or OBDR
When running a full client backup, the CONFIGURATION backup may fail while collecting data needed
for a certain backup method, even though this method will not be used for disaster recovery, because
Data Protector by default collects data for all automatic disaster recovery methods. For example, this
may happen while Data Protector collects data for EADR if the boot disks are LDM disks.
Disable automatic collecting of data for the disaster recovery method that failed. This will allow Data
Protector to collect data needed for other methods.
Set the option OB2_TURNOFF_COLLECTING to one of the following values:
Value Description
0 Default setting, data collection is turned on for all automatic methods (EADR, OBDR).
1 Turn off collecting of EADR/OBDR data
2 EADR/OBDR data is still collected.
3 Turn off collecting for all methods.
Common Problems (All Methods)
While performing disaster recovery, you may encounter the following problems:
You cannot perform a disaster recovery from a media
copy or an object copy
Problem
You cannot perform a disaster recovery from a media copy or an object copy.
Data Protector by default uses the original media set to perform a disaster recovery. Thus, copy
object versions are not displayed in the Disaster Recovery Wizard.
Action

l Object copy: Export all media in the original media set from the IDB and then regenerate the SRD
file. Data Protector then offers you the first available copy of the original media set in the Disaster
Recovery Wizard.
l Media copy: In the SRD file, replace the media IDs of the original media with the media IDs of the
media copies. Data Protector then offers you the first available copy of the original media set in
the Disaster Recovery Wizard.
You cannot log on after disaster recovery finishes
Problem
Problems occur logging on to the system after disaster recovery finishes.
You may receive the following message:
The system cannot log you on to this domain, because the system’s computer
account in its primary domain is missing or the password on that account is
incorrect.
Such a message may be caused by one of the following reasons:
l After collecting all information for disaster recovery, you reinstalled Windows and added it into the
offending domain.
l After collecting all information for disaster recovery, you removed your system from the offending
domain and later added it into the same or some other domain.
In cases like this, Windows generates new system security information, which is incompatible with
information that is restored during disaster recovery.
Action
1. Log on to the system locally as an Administrator.
2. In the Control Panel, click Network and, using the Identification tab, remove the system from
its current domain to a temporary workgroup.
3. Reinsert the system into the domain from which it was previously removed. You need a domain
administrator password. Click OK.
To update this new state, repeat all necessary disaster recovery preparation steps.
Disaster recovery fails due to inappropriate network
settings
Problem
A disaster recovery session fails because Data Protector recovers a client with unsuitable network
configuration.

The default settings that are used to configure the client's network depend on the client's operating
system:
The original network configuration (network configuration at the time of backup), which is specified in
the SRD file.
Network configuration that is defined by the DHCP settings.
Action
To switch to the non-default network configuration:
1. Start a disaster recovery session.
2. When Data Protector displays:
Press F8 in the next 10 seconds to switch network to DHCP...
Press F8 in the next 10 seconds to switch to the network setup at the time of backup...
press F8.
File system of type BTRFS has limited support
Problem
The File System of type BTRFS has limited support.
If mounted btrfs sub volume has child sub volumes, the data from child sub volumes will be skipped
during backup. Child sub volumes will be backed up as empty folders.
Action
1. Mount each sub volume as a new mount point.
2. Configure the new mount point in the backup specification.
Troubleshooting Assisted Manual Disaster
Recovery
While performing Assisted Manual Disaster Recovery, you may encounter the following problems:
"Cannot copy file"
Problem

Drstart reports: “Can not copy filename."
This error is reported because the drstart utility cannot copy the specified file. One of the reasons
may be that the file is locked by the system. For example, if drstart cannot copy omniinet.exe, it
might be because the Inet service is already running. This is not a normal scenario and should not
happen after a clean install.
Action
A dialog box will appear asking you whether you would like to proceed with copying the rest of the
files. If you click Yes, drstart will skip the locked file and continue copying other files. This will
solve the problem if the file is locked by the system, as the process required for the disaster recovery
is already running and therefore the file does not need to be copied.
You can also close the drstart utility by clicking Abort.
Troubleshooting Enhanced Automated Disaster
Recovery and One Button Disaster Recovery
You may run into the following problems during disaster recovery with the Enhanced Automated
Disaster Recovery or One Button Disaster Recovery method:
Automatic DR information could not be collected
Problem
When using EADR or OBDR, it is possible that you will receive the following error: “Automatic DR
information could not be collected. Aborting the collecting of system recovery
data.”
Action
Possible reasons for this error are stored in autodr.log file located in the default Data
Protectortemporary files directory directory:
1. Check if all storage devices are configured correctly. If Device Manager reports a device as
“Unknown Device”, you have to install the proper device drivers before you can perform
EADR/OBDR. A similar entry would appear in autodr.log, if improperly configured storage
devices are attached to your system:
DRIM_WIN_ERROR 13 SetupDiGetDeviceRegistryProperty
2. There must be enough registry space available. It is recommended to set the maximum registry
size to at least twice that of the current registry size. If there is not enough registry space
available, a similar entry would appear in autodr.log:
ERROR registry 'Exception while saving registry' .... WindowsError: [Errno
1450] Insufficient system resources exist to complete the requested service.

3. Ensure that you have enabled the Automount feature. The Automount feature ensures that all
the volumes (without a mountpoint) are online. When the Automount is disabled, all the volumes
without the drive letter are offline during the booting process. Therefore the System Reserve
partition will not have access to the drive letter, and this may result in the failure of the disaster
recovery procedure.
Reserve partition.
If the problem persists, uninstall the Data Protector Automatic Disaster Recovery component (so
that at least Manual Disaster Recovery will work) and contact technical support.
Some non-critical errors were detected
Problem
When using EADR or OBDR, it is possible that you will receive the following error: “Some non-
critical errors were detected during the collecting of Automatic DR data. Review
the Automatic DR log file.
Action
A non-critical error detected during the execution of the Automatic Disaster Recovery module means
that the backup can most likely still be used for disaster-recovery purposes. Possible reason for non-
critical errors are stored in autodr.log located in the default Data Protectortemporary files directory.
For example:
Services or drivers outside of the %SystemRoot% folder (for example, virus scanners). Autodr.log
would contain a similar error message:
ERROR safeboot 'unsupported location' 'intercheck support 06' 2
u'??D:Program FilesSophos SWEEP for NTicntst06.sys'.
You can ignore this error message, as it does not affect the success of disaster recovery.
Restore session fails if the device is created from
StoreOnce/DDBoost device with planned gateway
Problem
When the device is configured from StoreOnce/DD Boost device with planned gateway, and the
same client is configured for the disaster recovery, the restore session ends with the following
warning message on the Cell Manager:
[Major] From: RSM@<hostname> "" Time: 6/14/2016 2:48:49 PM
[61:3003] Lost connection to B2D gateway named "DeviceName" on host <hostname>
Ipc subsystem reports: "unknown"

[Warning] From: RSM@<hostname> "" Time: 6/14/2016 2:48:49 PM
Device <DeviceName> is disabled and will not be used.
This occurs due to loss of connection with the client B2D gateway.
Action
Ignore the warning message that appears when the restore session ends. Enhance Automatic
Disaster Recovery will be successful, and you can see the results on the client recovery console.
Network is not available during restore
Problem
This can be caused by various reasons, for example a damaged network cable or switch. Another
possible reason for network failure is that the DNS server (as configured at backup time) is offline
during the restore. Since the configuration of the DR OS is the same as at backup time, the network
will not be available.
Action
1. Ensure that the problem is not in with switches, cables, and so on.
2. If the DNS server (as configured at backup time) is offline during the restore, you can either:
l perform offline recovery and change the DNS settings after recovery.
l edit the registry before Phase 2 is started. In this case you have to restart the system before
Phase 2 for the changes to take effect. After Phase 2 finishes, you must correct the settings
before Phase 3 can be started.
Caution: Editing the registry incorrectly may result in failed disaster recovery.
Network is not available due to missing network
drivers
Problem
On a Windows Vista or Windows Server 2008 system, during a disaster recovery, the network is not
available because the DR OS does not support the network cards.
Action
Inject the missing drivers in to the DR OS image.

EADR and OBDR online recovery fails when the Cell
Manager and a client are in the different domains
Problem
This can be caused by incorrect network configuration.
Action
1. Update the host files on both Cell Manager and client systems. These files must contain host
names of the Cell Manager and of the client and their IP addresses.
2. Check whether the ping request between the Cell Manager and the client returns the correct
value. In case of a problem, contact your network administrator.
3. Check whether the DNS resolution between the Cell Manager and the client is correct with the
omnicheck -dns command. For more details, see the omnicheck man page or the HPE Data
Protector Command Line Interface Reference. In case of a problem, contact your network
administrator.
When encrypted control communication is enabled, Cell
Manager does not respond during an online recovery of
a client
Problem
On Windows Vista and later releases, when you perform an online disaster recovery of a client in a
DHCP environment with encrypted control communication enabled on the Cell Manager and the
client added as an exception, online restore fails, disaster recovery continues with the offline restore.
The reason is that a new temporary hostname is generated for the DR OS by default.
Action
During disaster recovery, switch to the original network configuration by selecting the Restore
Network Configuration option.
Alternatively, check the hostname of the system after the DR OS is started and add this name as an
exception on the Cell Manager before starting the restore.
Auto logon does not work
Problem

Sometimes auto logon does not work.
Action
Manually log on using an administrator account with a blank password.
Computer stops responding during EADR
Problem
This can be caused by problems with the disaster recovery CD.
Action
l Check if the CD is readable.
l Do not reuse CD-RWs too many times.
Cannot create a CD ISO image for EADR of Microsoft
Cluster Server
Problem
The quorum disk has to be backed up in order to be able to create a CD ISO image.
Action
Back up the quorum disk.
Creating a CD ISO image on a Microsoft Cluster Server
client fails
Problem
In a Microsoft Cluster Server environment, you cannot create an ISO image on a cluster client. The
file system restore works as expected.
The issue arises because Data Protector tries to use the cluster IP (which is a virtual one) instead of
the domain name (which is resolved to the IP of the physical client).
Action
Change the connection order for network services so that the Local Area Connection is on top.

Creating an ISO image fails when antivirus software is
installed on media creation host
Problem
When ISO image is created using WAIK/ADK and antivirus software is installed on the media
creation host, then ISO image creation fails with the following error message:
In GUI:
The creation of ISO image failed. Please check autodr logs located in Data Protector's temporary
directory.
In autodr.log file:
Add-Package operation is failing with Access Denied (5) error.
Action
Temporarily disable antivirus agent on media creation host until ISO image creation process is done.
Volume is not re-mounted during phase 1
Problem
On some systems (depending on the disk controller and its configuration) a volume (without a drive
letter assigned) associated with a mount point on a different volume may not be re-mounted properly
during phase 1 of the disaster recovery. This may occur if the volume containing the mount point is
recreated or reformatted (for example the System Volume with DR OS), causing the operating
system to boot in “Safe Mode” and to miss the detection of the file system present on the original
mount point's target volume. Consequently, the disaster recovery module does not recognize this
volume and reports it as MISSING in the drecovery.ini file. The contents of such a volume are
intact, even if it is not recognized.
Action
l Mount the volume with a drive letter and verify it with the chkdsk /v /f command or wait until the
system is completely restored and then recreate the original mount point.
l Manually restart the system directly to MiniOS (do not start the system from the recovery CD).
The previously dismounted volume will be automatically mounted to a drive letter.

After a failed or aborted disaster recovery, Boot
Descriptors are left
Problem
On Intel Itanium systems, after a failed or aborted disaster recovery session, Boot Descriptors
(named DRM Temporary OS) may be left in the EFI environment. This can cause unwanted behavior
when restarting the disaster recovery process.
Action
Remove the boot descriptor using the option Remove Boot Descriptor from the scope selection
menu. After the boot descriptor is removed, you can proceed with disaster recovery, by selecting the
scope.
A wrong or no boot disk is selected on an Intel Itanium
system
Problem
On an Intel Itanium system, the wrong boot disk (or no boot disk at all) is selected.
Action
1. Select Manual Disk Selection from the scope selection menu. A new menu, listing all
available disks, will display.
2. Determine the correct boot disk. Press o to view information about the original disk and d to see
details about the selected one.
3. Select the disk from the list using cursor keys and press b. You can remove a selection by
pressing c.
If the boot disk is not the same as the system disk (by default, both disks are the same), you
must select the system disk as well.
Select Back.
4. Select the scope of the recovery and disaster recovery will continue.
Disaster recovery fails with "There is not enough space"
message
Problem

A disaster recovery of a Windows Server 2008 R2 domain controller fails with an error similar to the
following:
[Major] From: VRDA@computer.company.com "Dev1" [/CONFIGURATION]" Time:
07.12.2012 15:33:58 X:windowsSystem32OB2DRtmpconfig
ActiveDirectoryServiceD$ WindowsNTDSntds.dit Cannot write:
([112] There is not enough space on the disk. ) => not restored.
Action
1. Modify the backup specification for the client backup: in the source page, expand the
CONFIGURATION object and clear the checkboxes for the ActiveDirectoryService and SYSVOL
items.
Note: The Active Directory and SYSVOL will still be backed up as part of the system
volume (C:/) backup. By default, they are located in C:/Windows/NTDS and
C:/Windows/SYSVOL respectively.
2. Repeat the disaster recovery procedure.
Disaster recovery of a Windows 8.1 client fails with
"Cannot write: ([13] The data is invalid. ) => not
restored." message
Problem
A disaster recovery of a Windows 8.1 client fails with an error similar to the following:
[Major] From: VRDA@computer.company.com "hostname"
[mountpoint]" Time:
<timestamp> <filename> Cannot write: ([13] The data is invalid. ) => not
restored.
Action
Format the partitions of the Windows 8.1 client and continue disaster recovery by booting the client
system from the disaster recovery CD.
Minor errors or warnings are displayed during a client
backup
Problem

During a client backup, minor errors may be reported:
Cannot perform stat(): ([2] No such file or directory)
File is shorter than it was when it was opened
Such warnings and errors may appear due to changed files inside temporary Data Protector
directories. This can happen for example if the /CONFIGURATION mount point and the / (root) mount
points are backed up simultaneously.
Action
Exclude the /opt/omni/bin/drim/tmp and /opt/omni/bin/drim/log directories from your backup
specifications.
In backup specifications created with 8.10 or later versions, these files are automatically excluded.
Cell Manager and RMA hosts are not responding
Problem
Disaster recovery of Linux virtual machines in the RHEL operating systems fails with the following
error messages:
Cell Manager is not responding. Attempting offline restore.
RMA host is not responding.
Such errors may appear because the NIC and MAC address of the virtual machine that is used for
disaster recovery will be different from the original virtual machine. The virtual machine will not have
the IP address, and the online recovery fails.
Action
Perform the following steps:
l Press Alt+F2 to open another command shell.
l Navigate to /etc/sysconfig/network.
l Modify the interface files to match the current interface and MAC address.
l Restart the network service.
l Edit the host files, if required, for the network connection.
l Ensure that the Cell Manager and Media (backup) hosts are reachable to the client.
l Press Alt+F1 to return to the main command shell window, and select the recovery option.

Troubleshooting Disaster Recovery of Internet
Information Server
Problems with disaster recovery of Internet Information Server (IIS) are usually the result of either
services not running or services not being installed.
IIS dependent services do not start automatically
Problem
Any of the IIS dependent services (for example, SMTP, NNTP) does not start automatically after the
recovery of IIS.
Action
1. Start the services manually.
2. If this fails, stop the IIS Admin Service and restore the
%SystemRoot%system32inetsrvMetaBase.bin file using the Overwrite option.
Note: The %SystemRoot%system32inetsrv directory is the default location of the IIS
Service. If you have installed the service into another location, use this location as a
destination for restore of the MetaBase.bin file.
3. Start the IIS Admin Service and all dependent services.

Appendix A: Example Preparation Tasks
Example of Moving Kill Links on HP-UX 11.x
# The system will go from "run-level" 4 to "run-level 1"
# retaining the (rpcd), inetd, networking, swagentd services up. The state is called
"minimum activity" for backup purposes (need networking).
# IMPORTANT: ensure the links are present in /sbin/rc1.d before
# moving and they do have this exact name. You have to rename them for the rc0.d
directory. Put them BELOW the lowest (original "/sbin/rc0.d/Kxx") "K...-link" in rc0.d
# Move K430dce K500inetd K660net K900swagentd into ../rc0.d BELOW the lowest kill
link!!!
echo "may need to be modified for this system"
exit 1
#
cd /sbin/rc1.d
mv K430dce ../rc0.d/K109dce
mv K500inetd ../rc0.d/K110inetd
mv K660net ../rc0.d/K116net
mv K900swagentd ../rc0.d/K120swagentd
Example of the Disaster Recovery Preparation
Table for Windows
Client properties Computer name ANAPURNA
Hostname anapurna.company.com
Drivers tatpi.sys, aic78xx.sys
Windows Service Pack Windows Vista

TCP/IP properties for IPv4 IP address 10.17.2.61
Default gateway 10.17.250.250
Subnet mask 255.255.0.0
DNS order 10.17.3.108, 10.17.100.100
TCP/IP properties for IPv6 IP address td10:1234:5678:abba::6:1600
Subnet prefix length 64
Default gateway td10:1234:5678:abba::6:1603
Preferred DNS server td10:1234:5678:abba::6:1603
Alternate DNS server td10:1234:5678:abba::6:1604
Medium label/barcode number "anapurna - disaster recovery" /
[000577]
Partition information and order 1st disk label
1st partition length 31 MB
1st drive letter
1st filesystem EISA
2nd disk label BOOT
2nd partition length 1419 MB
2nd drive letter C:
2nd filesystem NTFS/HPFS
3rd disk label
3rd partition length
3rd drive letter
3rd filesystem
Appendix A: Example Preparation Tasks

Send Documentation Feedback
If you have comments about this document, you can contact the documentation team by email. If an
email client is configured on this system, click the link above and an email window opens with the
following information in the subject line:
Feedback on Disaster Recovery Guide (Data Protector 9.07)
Just add your feedback to the email and click send.
If no email client is available, copy the information above to a new message in a web mail client, and
send your feedback to AutonomyTPFeedback@hpe.com.
We appreciate your feedback!
Send Documentation Feedback

Hpe Data Protector Disaster Recovery Guide

More Related Content

What's hot (20)

Viewers also liked (15)

Similar to Hpe Data Protector Disaster Recovery Guide (20)

More from Andrey Karpov (16)

Recently uploaded (20)

Hpe Data Protector Disaster Recovery Guide