Disaster Recovery

Introduction

UPSTREAM’s flexibility is demonstrated as its use not only as a backup/restore utility, but it also integrates nicely into an organization’s disaster recovery plans.

Due to the nature of disaster recovery and methods that vary dramatically by operating system, disaster recovery may be addressed in other chapters in this manual:

UNIX and Linux

See UPSTREAM Rescuer.

An important method for disaster recovery, physical disk backups, is discussed in UPSTREAM/SOS chapter and Physical Disk.

UPSTREAM Rescuer

The UPSTREAM Rescuer is an enhancement to UPSTREAM that allows disaster recovery of Linux OS on IBMZ, x86 Linux, Solaris and AIX. select UNIX systems including, x86 Linux, and Solaris

A Rescuer recovery requires first and foremost, a complete backup of the system. Typically, this is accomplished by a successful full “/*” backup that may be followed by incremental backups. UPSTREAM, includes all the information necessary for a full system recovery including device files, FIFOs, hard and symbolic links, and more.

UPSTREAM does not backup partition or other disk definition information. However, on all Rescuer systems, and we no longer recommend producing a report of this information as it reduces flexibility on your new system, though the dr_report is still included if you wish to use it.

The Rescuer uses the single user or emergency boot facilities provided by the UNIX or Linux vendor. Then, with the operating system loaded and running on a RAM or other disk not being recovered, the disk to be recovered is created and mounted and the restore done. This avoids potentially fatal problems of writing to an active operating system disk.

It restores the system as it was originally. This means that you have to be careful with any substantial changes in hardware or file system levels. The Rescuer is a disaster recovery tool; it cannot be used for system upgrades. If you are unsure whether a recovery works, contat Support .

Relax-and-Recover

Relax-and-Recover is the leading Open Source bare metal disaster recovery solution for x86 Linux. It is a modular framework with many ready-to-go workflows for common situations.

UPSTREAM support was introduced with Relax-and-Recover versions 1.18 and higher.

Relax-and-Recover produces a boot-able image which can recreate the system’s original storage layout. Once that is done it initiates a restore from backup. Since the storage layout can be modified prior to recovery, and dissimilar hardware and virtualization is supported, Relax-and-Recover offers the flexibility to be used for complex system migrations.

Currently Relax-and-Recover supports various boot media (incl. ISO, PXE, OBDR tape, USB or eSATA storage), a variety of network protocols (incl. sftp, ftp, http, nfs, cifs) as well as a multitude of backup strategies which now includes UPSTREAM.

Relax-and-Recover was designed to be easy to set up, requires no maintenance and is there to assist when disaster strikes. Its setup-and-forget nature removes any excuse for not having a disaster recovery solution implemented.

Recovering from disaster is made very straight-forward by a 2-step recovery process so that it can be executed by operational teams when required. When used interactively (e.g. when used for migrating systems), menus help make decisions to restore to a new (hardware) environment.

Extending and integrating Relax-and-Recover into complex environments is made possible by its modular framework. Consistent logging and optionally extended output help understand the concepts behind Relax-and-Recover, troubleshoot during initial configuration and help debug during integration.

The support and development of the Relax-and-Recover project takes place on Github:

• Relax-and-Recover website is at: http://relax-and-recover.org/
  
• Github project is at:
  

The description of using UPSTREAM in Relax-and-Recover is in the web site and that should be consulted (as it is kept updated) in the Use Cases section on the main Relax-and-Recover website above. It is also described here below.

Integration of UPSTREAM with Relax-and-Recover

Beginning with version 1.18, ReaR has support for UPSTREAM. To enable this support, add the following line to either /etc/rear/local.conf or /etc/rear/site.conf.

If the UPSTREAM software is installed somewhere other than the default location of /opt/fdrupstream, then you need to paste the following six lines (which can be found in /usr/share/rear/conf/default.conf) into /etc/rear/local.conf or /etc/rear/site.conf. Then change only the first line, from "/opt/fdrupstream" to the actual install location

FDRUPSTREAM_INSTALL_PATH="/opt/fdrupstream"COPY_AS_IS_FDRUPSTREAM=( "$FDRUPSTREAM_INSTALL_PATH" ) COPY_AS_IS_EXCLUDE_FDRUPSTREAM=( "$FDRUPSTREAM_INSTALL_PATH/usserver" ) CHECK_CONFIG_FILES_FDRUPSTREAM=( "$FDRUPSTREAM_INSTALL_PATH/uscmd*""$FDRUPSTREAM_INSTALL_PATH/usdaemon*" "$FDRUPSTREAM_INSTALL_PATH/us""$FDRUPSTREAM_INSTALL_PATH/us1" "$FDRUPSTREAM_INSTALL_PATH/us.ser""$FDRUPSTREAM_INSTALL_PATH/*.so" "$FDRUPSTREAM_INSTALL_PATH/usudb*""$FDRUPSTREAM_INSTALL_PATH/*.dat" "$FDRUPSTREAM_INSTALL_PATH/*.cfg" ) PROGS_FDRUPSTREAM=( ) REQUIRED_PROGS_FDRUPSTREAM=( "$FDRUPSTREAM_INSTALL_PATH/uscmd1" )

ReaR does not perform UPSTREAM backups. ReaR is used to provide a working system to which an UPSTREAM restore can be performed. A sample work-flow follows.

Preparations

On the target system, create a bootable ISO image with this command:

Find the ISO image in /var/lib/rear/output/ and put it someplace safe! Store it off-site, or include it in your regular UPSTREAM backups.

Disaster Recovery Time

On your disaster recovery hardware, boot the ISO image and follow the on-screen instructions.

The disaster recovery hardware starts UPSTREAM and registers to your storage server with the same name as the original target system.

When prompted, use UPSTREAM Director to initiate a restore of the entire / filesystem to the /mnt/local/ directory on the target system.

When the restore is complete, return to your disaster recovery hardware and hit Enter.

Wait for ReaR to complete, and then reboot into your restored system.

SUN SUN Solaris

At disaster recovery time, you must perform the following process:

1. Boot system in single user mode from the first Solaris install CD.
   boot cdrom -s

2. Configure network adapter.

   For example, for adapter hme0 with an IP address of 192.168.150.117:
   ifconfig hme0 192.168.150.117 netmask 255.255.255.0 up

3. Configure routing if required.
   Assuming your router/gateway IP address is 192.168.150.161:

   route add default 192.168.150.161 1

4. Check network configuration.
   ifconfig -a
   netstat -r
   Examine ifconfig output to ensure that the network adapter is up and configured with the desired IP address and netmask.
   If you configured a router/gateway, examine the netstat output to ensure that the router/gateway is defined.
5. Set TERM variable.
   TERM=sun
   export TERM
6. Start rpc services.
   /etc/init.d/rpc start

7. Extract the UPSTREAM disaster recovery image. The UPSTREAM software has to be installed and since you have the CD drive used for the operating system boot, you must get the UPSTREAM software from either and NFS or FTP server running on another machine:

   • To access the tar file from an NFS Server
   • Start the NFS client.
     /etc/init.d/nfs.client start

   • Mount the directory on the NFS server.
     Assuming the IP address of the server is 192.168.150.211, the exported directory is /home, and the usdr.tar is in /home/user on the NFS server:
     mount -F nfs 192.168.150.211:/home /mnt
   • Extract the UPSTREAM disaster recovery image to /tmp/fdrupstream.
     mkdir /tmp/fdrupstream
     cd /tmp/fdrupstream
     tar xvf /mnt/user/usdr.tar
   • Unmount the NFS directory.
     umount /mnt

   • To access the tar file from an FTP Server
   • Create and change to directory /tmp/fdrupstream
     mkdir /tmp/fdrupstream
     cd /tmp/fdrupstream
   • Use ftp to get usdr.tar.
     ftp ip_address_of_server
   • Provide user and password when prompted.
     bin
     cd directory_containing_udsr.tar
     get usdr.tar
     bye
   • Extract the UPSTREAM files
     tar xvf usdr.tar
8. Run uscfg to configure UPSTREAM.
   ./uscfg
   • Provide the IP address of the UPSTREAM Storage Server.
   • Change the port numbers if required.
   • Provide any other parameters required for your installation.
   • Tab to the OK button, hit enter, and save the configuration.
   • ESC+X to exit.

9. Set up disk slices if required.If you are going to restore to your existing drive(s), and do not wish to change the sizes of your existing disk slices, you can skip this step.

   If you are restoring to new drives, or want to make changes to your existing disk slices, use the format command to set up your disks. If you have set up your backups to run the disaster recovery report script, you can use the prtvtoc output in the report to get the sizes of your existing disk slices.

   It is important that you use the same disk slices on the same disks as listed in /etc/vfstab. If you use a different disk slice for one or more file systems, you must edit /etc/vfstab on the restored system before booting it to reflect the changes you have made.

   If you are using Solaris 8 or later with fibre disks, you must use the same world wide name for the disks. See SunSolve article 40133, Correcting device paths when replacing fiber boot disks after a ufs restore.

10. Create and mount file systems, or mount and empty existing file systems.
    To ensure a proper disaster recovery restore, we require that all restores be done to empty file systems.

    If the disk slices to be used for restore are identical to the original disk slices, you can use the mkfs lines from the output generated by the disaster recovery report script to recreate your file systems with the same options as the original file system.

    If you copy the mkfs lines from the disaster recovery report into a separate file, and copy it via ftp or nfs to the system you are restoring, you can make this file executable and run it to recreate your file systems.

    Please note that only UFS file systems in a disk slice can be created while booted from the Solaris CD.

    If you change the size of a disk slice, or restore to a drive with geometry different from the original drive (i.e. a larger drive), it is recommended that you not use the mkfs output. Instead, use the newfs command with any desired options to create the file systems.

    Another alternative if you are restoring to recover from a software problem to your original drive, is to mount all the existing file systems, change to the top level mount point, and use rm -r * to remove all the files from your existing file systems.

    Sample mount commands using a top level mount point of /mnt:

    mount /dev/dsk/c0t0d0s0 /mnt
    mkdir /mnt/usr
    mkdir /mnt/opt
    mkdir -p /mnt/export/home
    mount /dev/dsk/c0t0d0s5 /mnt/opt
    mount /dev/dsk/c0t0d0s6 /mnt/usr
    mount /dev/dsk/c0t0d0s7 /mnt/export/home

    If you are using your original file systems, empty them out\

    cd /mnt
    rm -r *

11. Start UPSTREAM in Disaster Recovery mode.
    cd /tmp/fdrupstream
    ./usdr
    You need to provide the profile name, and a user/password if required. Press the Validate button to continue.

    

    By default, only UFS file systems in a disk slice are enabled for restore. Veritas file systems, or UFS file systems in a Veritas Volume Manager volume or Disk Suite meta device, must be restored after booting the restored system unless you want to restore them to a disk slice with a UFS file system. Assuming you have created and mounted a file system, enable the Allow Any File System Type option and select the appropriate mount points.

    If you do not wish to restore any of the file systems selected by default, make sure that file system is highlighted in the File Systems listbox and use the exclude button to exclude it.

    Move to the More screen by pressing the More button.

    If the Translation tables shown for ASCII to EBCDIC, and EBCDIC to ASCII, are not the same translation tables used for the backup, you should change the names to match the names used for the backup. If this is not done, some of the restored file names may be different. The recommended ASCII to EBCDIC translation table is ans2atoe.tab and the recommended EBCDIC to ASCII translation table is ans2etoa.tab. Press the OK button to return to the System Restore screen.

    Press the Begin Restore button and then press Yes to the confirmation prompt to start the restore.

12. Edit /mnt/etc/vfstab if required.
    If you restored any of your file systems to a different disk slice, you must edit the restored vfstab file and update the appropriate entries with the new device names.

    If you have any file systems that must be created and restored after booting the restored system, you should comment out the lines for those mounts to avoid errors when booting the system for the first time.

13. Install the boot block on the boot drive.
    Use the installboot command to install a boot block on your boot drive.
    For example, to install a boot block on c0t0d0s0, use the following command:
    installboot /mnt/usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t0d0s0
14. Boot the restored system.
15. Restore Veritas file systems and UFS file systems in Veritas Volume Manager volumes or Disk Suite meta devices.
    Veritas file systems, and UFS file systems in Veritas Volume Manager Volumes or Disk Suite meta devices, must be created and restored after booting the restored system.
    After recreating and mounting these file systems on their original mount points, you can use UPSTREAM’s single file system restore option to restore the file systems that could not be restored while booted from the Solaris CD.
    If you commented out the entries for these file systems in /etc/vfstab, you should edit /etc/vfstab to uncomment these entries.

We suggest booting the system after completing the restores, and editing /etc/vfstab, to make sure that your system comes up clean.

Using the Enhanced Linux OS on IBMZ Rescuer

The goal of the Rescuer is to reduce Disaster Recovery (DR) of a Linux OS on IBMZ Virtual Machine (VM) to a single command. This enhanced Rescuer is intended strictly for Linux OS on IBMZ and z⁄VM and is installed automatically when you install the Client on Linux OS on IBMZ.

Currently the operating systems certified are SuSE SLES IBMZ Linux and RedHat's RHEL IBMZ Linux.

The Linux OS on IBMZ Rescuer consists of two programs:

rescuer-setup

This program is used during the backup of your system

rescuer

This program is used during disaster recovery

To properly use the Advanced Rescuer for Linux OS on IBMZ, you need to create the following components:

• The system to be backed up. Most users have created this system as a Linux OS on IBMZ VM guest and is the only way the Advanced Rescuer works (it does not work when run as an LPAR).
  
• The Dirmaint system. This is optional but highly recommended. It is simply a VM system (user) which is running CMS. Rescuer contacts it both during the backup and during the restore to get information about the system being backed up, and to perform VM commands. We recommend that you name it UPSTREAM.
  
• A proxy Linux OS on IBMZ system that is used for recovery. It must be hosted on the same LPAR as the VM system being backed up. It is on this system that you will run the rescuer command to create the disks, recover the data, make them bootable, and perform all the other tasks necessary for a complete disaster recovery.
  

If you are going to use the Dirmaint user, the requirements for the Rescuer Dirmaint interface are:

• A VM user with Dirmaint administrator privileges
  
• This VM user should be disconnected.
  

To use the Rescuer there are several prerequisites need on the Rescuer proxy- machine.

• The vmcp kernel module needs to be configured and set to load on boot.
  
• A minimum of 512MB of memory assigned.
  
• No volume groups should be used. The swap, boot and root filesystems should be slices on a single DASD device. This is a best practices requirement. Rescuer can be used on any Linux OS on IBMZ VM.
  
• To support the Rescuer Dirmaint interface, the vmur module must also be configured and set to load on boot. Consult your system admin for your linux distribution.
  
• The supported versions of Linux OS on IBMZ are RHEL5, RHEL6, SUSE10, or SUSE11.
  
• If using the Rescuer Dirmaint interface, any LINKED disks must have the write password appended to the LINK statement. This is ignored by the Dirmaint subsystem, but needed for automated recovery.
  

Installation#

The Rescuer is included with the standard Client install on Linux OS on IBMZ. During the installation of the product, some questions about your system are asked that allow the rescuer-setup program to run regular full and incremental system backups are performed:

Once this name is entered (the recommended name is UPSTREAM), the installation has completed.

If you wish to change the user to be used as the Dirmaint user, modify the name of the RESCUER_VM in the rescuer.conf file.

Performing backups using rescuer-setup

Before every backup of a whole system, or the data recovery part of a system, you must run the rescuer-setup program prior to performing the backup. This prepares the recovery by interpreting the environment and generating certain files that are automatically recovered as part of the single step recovery.

Similar to the dr_report command, rescuer-setup must be run prior to running a backup. This is similar to the prior dr_report method, however, significantly more advanced. This saves all the system specific information such as:

• 
  
  • 
    
    • Filesystem sizes and types
      
    • Mount points to filesystems
      
    • LVM2 information
      
    • Swap information
      
    • Boot information
      
    • Write passwords for min-disks and linked disks
      
    • The VM definition
      

Rescuer currently supports ext2, ext3, and ext4 filesystems.

The rescuer-setup program will be run at backup time by the JCL as a pre-backup step (see below for an example JCL script) or more simply (and more recommended) as a PREJOB to the backup which backs up the system.

rescuer-setup takes the following options:

-e<exclude>

During backup, specify a drive UCB to be excluded. Typically used for excluding a shared mini-disk that is mounted read-only across multiple Linux OS on IBMZ VMs. Can be specified multiple times. This option is not necessary if all information is obtained from the VM Dirmaint entry.

If not using the Rescuer Dirmaint interface, it is required to specify excludes for those read-only disks. Read-only file systems should be excluded from the backup.

-d

Do not use the Rescuer Dirmaint interface.

Most users specify a simple backup like this:

//* RUN BACKUP WITH PRE-JOB FOR Rescuer
//*
//PREJOB EXEC PGM=USTBATCH
//STEPLIB DD DISP=SHR,DSN=USTEST.UPSTREAM.LOAD
//USTLOG DD SYSOUT=*
//USTPARM DD *
APPLPREF=UPSTR
USAPPL=UPSTREAM
LOGMODE=#INTER
MAXRETRY=0
CONV=WAIT
*
TARGNAME=target.system.registered.name
ACTION 1
JOBOPTIONS 35 * So that PREJOB errors are visible
PREJOB /opt/fdrupstream/rescuer-setup
BACKUPPROFILE profile
MERGE 1 * Full merge
SPEC /*
ENDPARM

Or run a simple PREJOB like this before running the backup:

//* RUN PRE-JOB FOR Rescuer
//PREJOB EXEC PGM=USTBATCH
//STEPLIB DD DISP=SHR,DSN=USTEST.UPSTREAM.LOAD
//USTLOG DD SYSOUT=*
//USTPARM DD *
APPLPREF=UPSTR
USAPPL=UPSTREAM
LOGMODE=#INTER
MAXRETRY=0
CONV=WAIT
*
TARGNAME=target.system.registered.name
ACTION 5
JOBOPTIONS 35
*
SPEC /opt/fdrupstream/rescuer-setup
ENDPARM

To use the Rescuer Dirmaint interface, the vmur and vmcp kernel modules must be configured on the target system. It is also required that the target system have user classes of C, D, and G.

Rescuer

The rescuer program is a Linux OS on IBMZ program, intended to be run in a Linux environment that is running and is healthy and is designed to be used to recover other Linux systems. You will login to this Linux system to begin your recovery.

For recovery, the format of the rescuer program used to recover the system in a single command is:

The definitions of the arguments are:

-l

specify that auto-relabeling of selinux attributes not be performed.

-r

restore the VM definition for the target. (No passwords are restored.)

-d<version-date>

specify a version date to restore back to. If you do not specify the -d option, then the default is to restore back to the last full backup. You can use the Director to explore the backups done with the backup profile you wish to restore from to determine which version date to use.

-n <vault number>

if you are using the UPSTREAM Reservoir and the data is stored on a vault rather than the primary data area, specify the vault number using this form.

[ucb=[A|L]=write-password]

This is used when the Rescuer is not being used. This supplies the Rescuer with the passwords needed to map the disks of the VM being restored.

<profile>

specify the backup profile for the restore (required)

If you are NOT using the Rescuer Dirmaint interface, for example: if the target system had an ECKD disk mapped at address 8F27 and you needed to supply the write password for that disk, where the password is PASSWD12 and with a profile of MYPROFILE, then the command would be:

rescuer MYPROFILE 8f27=PASSWD12

If you use minidisks (via the MDISK statement in the VM definition or the LINK statement) you do not have to specify the ‘=L’ in the password assignment.

If you use a DEDICATE statement then you would need to specify the ‘=A’ in the password assignment. For example:

If you want to restore just the VM definition to a file, issue the command:

The file will be placed in the UPSTREAM directory under the subdirectory VMDEFS. The name of the file will be the name of the VM being restored.

All output of the Rescuer process will be stored in the file:

Where <VMNAME> is the name of the target VM being recovered. You can view progress during the recovery by issuing the ‘tail –f’ command on the log file.

This is your first source for information if there is a problem during the recovery of the system.

You must exclude any read-only disks if “INCLUDE” statements are used as part of the VM definition when running rescuer-setup that are part of the INCLUDE file. Since the passwords for any disks defined in the INCLUDE would not have been available during rescuer-setup, they must be supplied (on recovery) on the rescuer command line as described earlier.

Any VDISK devices will be ignored during the recovery process as these are temporary devices.

Recovering Linux OS on IBMZ Systems Hosted in z⁄VM

If you are using z⁄VM to host Linux OS on IBMZ systems you can recover lost or damaged Linux OS on IBMZ systems without recovering from bare metal (or a bare VM) using the procedures described here.

In preparing for this we strongly recommend that you create a z⁄VM instance strictly for recovering Linux OS on IBMZ systems. That way the chances of this system being destroyed during normal operations decreases. UPSTREAM needs to be configured and tested in this z⁄VM instance.

Also, the UPSTREAM instance needs to be at the same level with all the same patches as the z⁄VM guests which may need to be recovered. So when updating the systems in the z⁄VM environment, do not forget to update the UPSTREAM recovery instance.

As for all recoveries, the success of this recovery requires that each VM instance be backed up from within (each instance has its own Client with regular full system backups (using /* or \\.) - regular fulls and frequent (usually daily or even more often) incremental backups.

1. 1. The VM work consists of:
      

   • 
     
     • Select the new volume to be used as the target of the recovery.
       
     • Format the volume in VM using the VM utilities in the same way the original volume was formatted.
       
     • Attach the new volume to the UPSTREAM rescue system.
       

   1. Bring new volume online - for Suse v9 use chccwdev -e 0.0.xxxx (where xxxx = the restore volume ucb, for example 7f0b).
      

   2. Look up the Linux device name for the new device:
      cat /proc/dasd/devices
      You should see something like:
      0.0.0150(ECKD) at (94: 0) is dasda : active at blocksize: 4096, 3600B
      The name after 'is' (dasda) is the name of the devices in the /dev directory (/dev/dasda in this case).

      If you are using devices which have been previously formatted with dasdfmt, you can skip this step. Otherwise you must use the dasdfmt command as documented in the SuSE installation documentation.

      For example (making sure all options are in lower case, replace '?' with the full name of the device- 'a' in this case):
      dasdfmt -b 4096 -d cdl -l volser -f /dev/dasd?

   3. Build a partition table on it: fdasd /dev/dasd?
   4. Make a filesystem in the partition (this example is for ext2): mke2fs -b 4096 /dev/dasd?1
   5. Make a mountpoint on the server system: mkdir /mnt/xxxx (where xxxx is typically the restore volume's UCB, for example 7f0b).
   6. Mount the volume: mount /dev/dasd?1 /mnt/xxxx (where xxxx is typically the restore volume's UCB, for example 7f0b).

   7. Start the UPSTREAM restore in Disaster Recovery mode.

      1. cd /opt/fdrupstream
         ./us DISASTERRECOVERY=Y

      In the initial login screen provide the backup profile name and a user/password if required, then press the Validate button. If you successfully validate you are brought to the UPSTREAM disaster recovery dialog screen.

      

      If you do not wish to restore any of the file systems selected by default, make sure that file system is highlighted in the File Systems listbox and use the exclude button to exclude it.

      Make sure that the mount point prefix (Dest Prefix) is:

      /<DASD_mount_point>In our example above it would be:

      /mnt/7f0b

      Warning

      If the Dest Prefix is set incorrectly you restore data to the wrong location, potentially destroying a healthy system.

      Once you have all the file systems you wish to restore selected and the ones you wish to not restore excluded, press the Begin Restore button and then press Yes to the confirmation prompt to start the restore.

      Examine the results of the restore (the upstream.log) for any errors. If there are any significant errors, contact BMC Support . Close the UPSTREAM disaster recovery program.

   8. Edit the fstab file if required. If you need to exclude any file systems at boot time, you must edit the restored fstab (/mnt/xxxx/etc/fstab - where “xxxx” is the restore volume UCB, 7f0b in our example above) file and comment out the appropriate entries.
      If you have any file systems that must be created and restored after booting the restored system, you should comment out the lines for those mounts to avoid errors when booting the system for the first time.
   9. Prepare the boot drive of the restored system for Initial Program Load (IPL) by installing a boot loader (if a boot volume was restored). The boot loader must be installed on the restored boot drive. This is required even for an existing drive that already has a boot loader installed. Assuming the same DASD volume and mounted on /mnt/7f0b, you must edit the /mnt/7f0b/etc/zipl.conf file at this time to make the required changes. Change the “parameters=” line to have the new DASD volume name 7f0b, as in the following example:
      parameters=”dasd=7f0b,f23-25,124-125 root=/dev/dasda1 selinux=0 TERM=dumb elevator=cfq”
      Now you can install the boot loader on the restored boot volume using the following example commands:
      cd /mnt/7f0b
      chroot /mnt/7f0b
      zipl -c /etc/zipl.conf
      exit
      
      

   10. Unmount the new DASD volume. As in the following example:cd /

       1. umount /mnt/7f0b

       Once the volume is unmounted, it needs to be set off-line from Linux as in the following example:

       chccwdev -d 0.0.7f0b

   11. Detach (or release from VM) the newly restored volume from the UPSTREAM Rescue system.
   12. Boot the restored system normally. Your system should boot and operate as before the problem.

RedHat Linux for IBMZ Virtual Machines (ECKD Devices)

The following section outlines a methodology for recovering entire z⁄VM hosted, Linux OS on IBMZ, virtual machines. This is done via a series of procedural steps called the Rescuer. This involves creating or supplying a Linux OS on IBMZ “floor” system that is used as a temporary surrogate for the original Linux OS on IBMZ virtual machine whose data is to be restored. We refer to this component hereafter as the “PROXY” virtual machine. The Linux OS on IBMZ virtual machine to be “rescued” or recovered, is referred as the “TARGET” virtual machine. By operating in this manner, UPSTREAM provides a “bare metal” recovery capability for any number of Linux OS on IBMZ virtual machines. to successfully perform this procedure, it is assumed that you are familiar with and have access to the following:

1. 
   
   1. Linux commands, configuration, operations, and facilities.
   2.  The z⁄VM operating system and its role in supporting Linux OS on IBMZ.
   3. The UPSTREAM system and its configuration and interfaces.
   4. The TARGET and PROXY virtual machines should be of the same Linux distribution (SuSE, RedHat, etc.) and operating system release.
      

The overall view of this procedure can be thought of as follows:

In the above diagram, the PROXY machine has the file systems of the TARGET virtual machine built and then mounted within its filesystem and then restored via UPSTREAM. The procedure outlined in the following pages may need to be modified by an individual site to account for configuration difference between the sample system and your operating environment.

This procedure has been validated on RedHat RHEL 5.4 on ECKD DASD.

• 
  
  • Step # 1 – Research the Virtual Machine Configurations.
    

There is some important configuration information that you should gather prior to proceeding.

– At backup time, the UPSTREAM “DR_Report” file is generated, identifying DASD device addresses, volume, Linux Volume Manager(LVM) groups and file system mount point and other specific information for the virtual machine to be recovered. At recovery time, that file must be consulted to determine the virtual machines’ Linux configuration.

– Each Linux OS on IBMZ virtual machine has a z⁄VM User Directory entry that describes its configuration. These should be available for consultation. Here are some example User Directory entries for the PROXY and TARGET virtual machines:

Example 1:

USER PROXY PROXY 512M 512M G
INCLUDE IBMDFLT
IPL CMS PARM AUTOCR
MACHINE ESA
*
NICDEF E014 TYPE QDIO LAN SYSTEM VSWITCH1
*
MDISK 0191 3390 3146 50 VMUSR2 MR READ WRITE MULT

Example 2:

USER TARGET TARGET 512M 512M G
INCLUDE IBMDFLT
IPL CMS PARM AUTOCR
MACHINE ESA
*
NICDEF E017 TYPE QDIO LAN SYSTEM VSWITCH1
*
MDISK 0191 3390 1000 50 VMUSR2 MR READ WRITE MULT
MDISK 8F27 3390 1 10016 VMTRGT MR READ WRITE MULT

• 
  
  • Step # 2 – Synchronize the Virtual Machine Configurations.

– LOGON to the PROXY z⁄VM virtual machine console
– You need to temporarily attach the minidisks that contain the recovered TARGET system file systems to the PROXY VM. This makes them accessible for initialization, formatting and eventually the restore of the filesystem data. This can be done with a series of z⁄VM CP commands, entered via the virtual machine console, similar to the one shown below.
CP LINK TARGET SSSS DDDD MW password

Where:

 SSSS

is the 4 digit ECKD DASD device address of the TARGET virtual machine ROOT filesystem minidisk as it is to be seen by virtual machine PROXY.

 DDDD

is a four digit address that is any unused address on the PROXY virtual machine.

password

is the TARGET virtual machine multi-write password for the SSSS minidisk.

In our examples we assume you entered:

CP LINK TARGET 8F27 1000 MW MULT

– This command needs to be performed for each of the minidisks you intend to recover via the PROXY system. Each must have a unique virtual DASD unit address on the PROXY system.

• 
  

  • Make the ECKD DASD Devices Available to Linux OS on IBMZ.
    From the PROXY system, you execute a series of commands from a Linux OS on IBMZ command prompt. You must be ROOT to run these commands. Commands executed to LINUX are shown in italics. Make sure you substitute the proper device addresses from your system.

    chccwdev –e 1000 # bring the DASD Unit online
    lsdasd # verify that the unit is online and what
    the new name isYou should execute the ‘chccwdev’ command for each DASD unit you need to bring online.

    The output should look something like this, however, on your system you should see one line for each device that is configured.

    Bus-ID      Status     Name     Device     Type     BlkSz    Size     Blocks
    ==========================================================================================

• 
  

  • Step # 4 – Format the TARGET Virtual Machine DASD Devices.
    You need to format each of the devices you brought online with the “chccwdev” commands. If the original disks had labels associated with them, you should use those labels in the format commands. If you don’t know that the labels were, use any unique six (6) letter label for each disk.

    dasdfmt –y –b 4096 –d cdl –f /dev/dasdf –l LABEL1
  • Step # 5 – Partition the TARGET Virtual Machine DASD Devices
    You need to partition each of the disks. Refer to the output of the DR_REPORT command for the report of the sizes of the partitions from the original system. If you don’t have that information, you need to estimate the size of the partitions. If you are estimating, make sure that the sizes you pick are large enough to take all the data you are planning on restoring. Using your favorite editor you need to create a partition file for each disk. We recommend that you create the files in /tmp. In this example we created 2 partitions. The first partition is the boot partition. It is approximately 100MB. This is a fairly common size for the boot partition. The second partition is for the ROOT file system and for SWAP. In this example, we called the file disk1.conf, and it contains the following lines:
    [2,2134]
    [2135,last]

We started the first partition at track 2 to allow space for the boot track information because in this example, this disk is the boot disk.

fdasd –c /tmp/disk1.conf /dev/dasdf

You can see that the disk was partitioned properly by running the command shown below.

The output should look similar to the output shown here.

If you have Logical Volume Manager (LVM) managed volume groups, you need to create physical volumes, volume groups and logical volumes. This document assumes that you are familiar with the concepts of the Linux LVM. If you do not use LVM you can skip ahead to the section discussing file system creation.

• 
  
  • Step # 6 – Define the TARGET Virtual Machine LVM Devices.
    

In this example, the second partition is managed by LVM. The first Logical Volume (LV) is for the root file system, the second LV is for swap. It is vitally important that you do not forget to create a swap partition. Failure to create a swap partition can result in system instability or failing to boot.

pvcreate /dev/dasdf2 # Create the physical volumevgcreate VolGroup00_Rest /dev/dasdf2 # Create the volume group

You need to select a name for the Volume Group (VG) that you are creating. The name of the VG must be different from all the VGs on the Rescuer system. This likely results in a VG with a name that is different than the system being restored. This is okay. To prevent confusion we recommend appending “_Rest” to the name that was used on the system being restored.

You need to create VGs to match each of the VGs from the system being restored.

The next step is to create Logical Volumes. In this example, we are creating two logical volumes, one for the ROOT file system of size 5.5 gigabytes and one for SWAP, at 1.25 gigabytes.

lvcreate –L5.5G –n LogVol00 VolGroup00_Restlvcreate –L1.25G –n LogVol01 VolGroup00_Rest

• 
  

  • Step # 7 – Create the TARGET Virtual Machine File Systems
    You need to determine what type of file system you want to create on each of the partitions you are restoring. It is recommended that you create the same type of file system which was used on the original system. In this example, we are using the ext3 file system type for the ROOT and BOOT file systems.

    mkfs –t ext3 –b 4096 /dev/dadsf1
    mkfs –t ext3 –b 4096 /dev/VolGroup00_Rest/LogVol00
    mkswap /dev/VolGroup00_Rest/LogVol01

• 
  
  • Step # 8 – Create the Target Virtual Machine Linux Mount Points
    Before you can mount the newly created file systems, you need to create the mount point directories. In our example, boot is mounted under root. This is normal for Linux.
    – Create the first restore mount point
      mkdir /restore_mnt
    – Mount the first file system
        mount /dev/VolGroup00_Rest/LogVol00 /restore_mnt
    – Create the /boot file system mount point
      mkdir /restore_mnt/boot
    – Mount the /boot file system
      mount /dev/dasdf1 /restore_mnt/boot

• 
  
  • Step # 9 – Restore the TARGET Virtual Machine File Systems
    

After you have mounted all the file systems, the next step is to restore the files. You can restore them with the UPSTREAM disaster recovery or you can restore them from the Director. This example uses the UPSTREAM disaster recovery interface.

– Enter the backup profile of the server you’re trying being restored

– Insure the Dest. Prefix is set to your equivalent of “restore_mnt”.

– Press the ‘Begin Restore’ and after a number of screens reporting the number of files restored, hard links enabled and the Restore was successful, exit the US program.

• 
  
  • Step # 10– Mount the Restored TARGET Virtual Machine Devices on the PROXY Virtual Machine.
    

Once all the files have been restored, the system needs to be rebuilt and the boot disk needs to have the boot code installed.

– Mount the /proc file system

– Mount the /sys file system

mount –t sysfs sys /restore_mnt/sys

– Mount the /dev file system

– Mount the /selinux file system

– Change the root file system to point at /restore_mnt

–  Change to the /boot file system

cd /boot

Several files need to be updated. Using your favorite editor, edit “/etc/fstab”. You need to change the line for /LABEL=boot to reflect your new boot device. Be aware that the boot device name changes.

In this example, we need to change it from /LABEL=boot to /dev/dasda1. This may seem confusing since the disk has been called /dev/dasdf1 in all the commands so far. This is because /dev/dasda1 is the first partition on the first disk and this is its name when the restored system boots. Still editing “/etc/fstab”, the line for the “/” file system needs to be changed.

In our example, the line starts with “/dev/VolGroup00_Rest/LogVol00”. The line that has swap as the file system needs to be changed to start with “/dev/VolGroup00_Rest/LogVol01”. The before and after lines are shown here. Please note that in your system, “/etc/fstab” has other entries. You may need to change some of them to reflect the changes you made earlier for other file systems, in particular, if the file systems reside on LVs as part of a VG, then the VG name would need to be changed to reflect the new VG name.

Note that tmpfs, devpts, sysfs, proc have not been shown for the sake of clarity. Save the changes and exit the editor.

– BEFORE:

/dev/VolGroup00/LogVol00 / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 /dev/VolGroup00/LogVol01 swap swap defaults 0 0

– AFTER:

/dev/VolGroup00_Rest/LogVol00 / ext3 defaults 1 1
/dev/dasda1 /boot ext3 defaults 1 2 /dev/VolGroup00_Rest/LogVol01 swap swap defaults 0 0

The file “/etc/zipl.conf” needs to be edited. The line that starts with “root=” needs to be changed to reflect your new root file system. In our example, the line would be changed to “root=/dev/VolGroup00_Rest/LogVol00”. Save the changes and exit the editor.

A new initial ramdisk needs to be created.

mv initrd-$(uname –r).img initrd-$(uname –r).img.old
mkinitrd initrd-$(uname –r).img $(uname –r)

And now the boot tracks need to be written.

– Write the Linux boot code into the restored /boot file system

– Force restore of SELINUX labels on reboot

• 
  
  • Step # 11 – Format the TARGET Virtual Machine DASD Devices.
    

You need to unmount all the recovered file systems before using the rescued system. In all cases, the proc, sys, dev, and selinux file systems must be unmounted as shown here.

– Exit the chroot

– Change the directory back to the root of the PROXY virtual machine

– Unmount all the filesystems of the restored TARGET virtual machine from the PROXY virtual machine

umount /restore_mnt/dev
umount /restore_mnt/proc
umount /restore_mnt/sys
umount /restore_mnt/selinux

– You must also unmount all other file systems that you have recovered and this must be done in the reverse order in which they were originally mounted. You may then unmount the following two file systems.

umount /restore_mnt/boot
umount /restore_mnt

– If you have created LVM VGs and LGs during the restore, you need to deactivate all the LGs. You can use the lvchange command to do this. This step is needed to allow you to take the TARGET Virtual Machine disks offline.

– Deactivate the previously activated LVM Logical Volumes (if applicable)

lvchange –an /dev/VolGroup00_Rest/LogVol00 # deactivate Logical Volumes
lvchange –an /dev/VolGroup00_Rest/LogVol01

At this point your TARGET system has all the files it needs to reboot.

– You should now place the disk(s) from the rescued TARGET system into offline status. In our example:

chccwdev –d 1000

• 
  
  • Step # 12 – Cleanup and Restart The TARGET Virtual Machine.
    

You can now detach the rescued DASD from the PROXY system either by issuing the CP DETACH command or logging off the PROXY virtual machine.

Now LOGON/AUTOLOG the TARGET virtual machine and boot the Linux system as per normal procedures.

AIX System Recovery

The procedures below allow you to use an UPSTREAM backup.

Before you perform the following procedures, make sure that your system has at least 645MB free space to be used to create the CD file system structure, up to 4.38GB for DVD sized images. The free space can be in the root volume group (rootvg) or a user volume group. To check how much free space available in the root volume group, type the following command:

Look for the “FREE PPs:” filed for the number of free physical partitions and corresponding size in MB.

Since mksysb creates an installable image of the rootvg of the system, it’s not recommended storing this ISO image to the rootvg and make it unnecessarily larger at the next mksysb backup. We assume that the mksysb image (rootvg) backup gets written to a local disk that is not rootvg itself. A file system needs to be created on the local disk for storing mksysb images. An entry for the file system is put into the /etc/filesystems file. You can use the following command to determine the file system to write the mksysb image to:

These mksysb images should be included in your backups by running UPSTREAM. At the disaster recovery time, you will need the UPSTREAM backup to have the recent mksysb image file restored, then create a bootable AIX CD using this restored ISO backup image.

If there are file systems created on other volume groups, you need to have that information at the disaster recovery time to fully restore your system. All file systems information is in the /etc/filesystems file. To show all file systems in the /etc/filesystems file, type the following command:

The “Size” column in the output is the file system or the logical volume size in 512-byte blocks.

To check if there is any other volume groups except rootvg, type the following command:

To list all logical volumes information within a user volume group named backupvg, type the following command:

You will have above information as a reference to create logical volumes within a volume group other than rootvg and create all file systems accordingly for a complete system recovery.

At Backup Time, Create an AIX System ISO Image

The following command must be done at backup time. We recommend that you create a script to run it as a PREJOB.

Assuming that your AIX server does not have a recordable CD-R, DVD-R, or DVD-RAM drive, you have to backup the AIX system to an ISO image file. At disaster time you will need to restore this image and then transfer it to a system with a CD or DVD writer and software that can burn an ISO image.

For example, to create a boot-able system ISO backup image (mksysb) and store it to the local /backup/mycd directory not within the rootvg, use rootvg for creating temporary file systems used by mkcd command, use the following sample command:

Or as another example, if the rootvg doesn’t have enough free space available, but a user volume group has, for example backupvg, use the following sample command for creating temporary file systems in the volume group named backupvg:

After completion of mkcd command, the final system ISO CD image will be stored in the local /backup/mycd directory and uniquely named using the command process ID as part of the image file name, for example, 

cd_image_7172.

Please note that mkcd-created file systems are removed upon the command’s completion. Refer to the man page of mkcd command for detailed information.

At Recovery Time

At recovery time you must:

1. 
   
   1. Restore the mksysb created image. This requires a working UNIX (including AIX or Linux) machine as UPSTREAM UNIX backups can not be restored onto PC systems.
      

   2. Transfer the image file to a system with a CD or DVD burner. Most users use FTP to a PC. It is important that this image be transferred in binary mode.
      In Windows Vista, Server 2008, and Server 2012, simply drag and drop the ISO image onto the blank CD.
      The following is an example using Nero v6 Ultra Edition to create the bootable CD from the ISO backup image named “cd_image_7172” on a Windows PC:

      – Start Nero 6.

      – Click “Nero Burning ROM” from the Applications pull-down menu.

      – At the prompted “New Compilation” window, make sure the “CD-ROM (ISO)” is highlighted on the left side, click the New button on the right side. You can click the Label tab to type in the Disc name you want to create.

      – Locate the ISO image file “cd_image_7172” in the File Browser section and drag it into the labeled CD in “ISO1” section on the most left side.

      – Click the Yes button at the prompted “Nero Burning ROM” window.

      – At the prompted “Burn Compilation” window, check the box for Finalize CD (No further writing possible!), and click the Burn button to burn the CD.

   3. Restore the AIX system using this bootable CD or DVD

      To ensure a proper disaster recovery restore, we recommend that you put a new hard disk into the same slot in the AIX machine as the original one.

      Important

      If the AIX system has a key, turn it to service.

      – Power on the AIX system.

      – Insert the bootable CD or DVD into the CD/DVD device, and boot from it.

      – You will see display “Starting Software … Please wait” on the screen, when the “Please Define the System Console” screen displayed, press F1 and press Enter.

      – Type 1 and press Enter to have English during install, if asked.

      – At the “Welcome to Base Operating System Installation and Maintenance” screen, type 3 and press Enter for Start Maintenance Mode for System Recovery.

      – At the “Maintenance” screen, type 4 and press Enter for Install from a System Backup.

      – At the “Choose mksysb Device” screen, type the number, for example 1, for your CD-ROM or DVD-ROM device from the display list and press Enter.

      – At the “System Backup Installation and Settings” screen, make sure that all physical volume(s) required for the root volume group are selected and the settings are correct. Type 0 and press Enter for Start Installation.

      – After the restore is complete, turn the key to normal if the system has a key. If the system is keyless, this is automatic.

      – The system reboots once to the restored system. Be sure to eject the CD or DVD quickly.

      Important

      If the AIX system has user volume groups other than rootvg, there maybe error messages prior to a login prompt. Ignore these messages.

   4. Restore the Remaining Data

After restoring the AIX base operating system and booting up the system, you can then use UPSTREAM to restore all the data up to your last full backup. If you have file systems originally created on other volume groups, you must create them based on the /etc/filesystems file and/or related information generated in PREJOB task before running UPSTREAM to restore the remaining data into other volume groups.

Here is an example to create a jfs file system in a user volume group named backupvg, assuming your AIX system’s rootvg was restored on the hard disk named hdisk1:

– Determine which hard disk is available, enter:

lsdev -Cc disk

 – Create a “backupvg” volume group with 16MB Physical Partition (PP) size on an available hard disk named hdisk2, enter:

mkvg -f -y backupvg -s 16 hdisk2

– Create a jfs type logical volume named backuplv1 with 300 PPs size in the backupvg, enter:

mklv -y backuplv1 -t jfs backupvg 300 hdisk2

– Create a large file enabled jfs file system on the backuplv1 logical volume, mounted on /backup directory at each system restart, enter:

crfs -v jfs -a bf=true -d backuplv1 -m /backup -A yes

– Mount the created jfs file system, enter:

mount /backup

Repeat the above three steps if you have more file systems to create manually in the same volume group.

Windows Disaster Recovery

About Windows Disaster Recovery

The UPSTREAM Disaster Recovery Manager is optionally installed by the administrator on a Windows Desktop or Workstation used to create the ISO image that will later on be used for Windows Disaster Recovery Processing.

Requirements for Using the UPSTREAM Disaster Recovery Manager

The following items are required:

• 
  
  • 
    
    • UPSTREAM Client for Windows must be installed on any computer that you want to protect with Disaster Recovery Manager.
      
    • A CD or DVD burning application must be available to burn the created bootable image to a CD or DVD.
      
    • Access to the Internet must be available to download the Microsoft Assessment and Deployment Kit.
      
    • Windows computers must be backed up using the ‘Full Backup’ option in UPSTREAM. See Chapter 7 “Windows” for details.
      
    • Encryption key files must be available for all volumes that are Windows BitLocker Drive Encrypted.
      

There are additional requirements and some restrictions as well:

• 
  
  • 
    
    • Disaster Recovery of Windows Server 2012 and Windows Server 2016 Storage Pools is not supported.
      
    • WinPe Driver Pack may be required for disk and network drivers for your server model.
      
    • The ISO Image created by the Disaster Recovery Manager must be at the same maintenance level or higher than the UPSTREAM Client used for backups of the protected computers.
      
    • The Microsoft Assessment and Deployment toolkit (ADK) presently available for download on the Microsoft Website presently only support the following platforms, but there might be versions 8.0 available for Windows Vista and Windows Server 2008 on the Internet.
      

– Windows 10

– Windows 8.1 (Professional and Enterprise editions only)

– Windows 8 (Professional and Enterprise editions only)

– Windows 7 with Service Pack 1 (Professional, Enterprise, and Ultimate editions only)

– Windows Server 2016

– Windows Server 2012 R2

– Windows Server 2012

– Windows Server 2008 R2 with Service Pack 1

• 
  
  • 
    
    • To run the Disaster Recovery process on a computer with a 32-bit processor the ISO Recovery Manager tool must have created the image on a computer with a similar 32-bit architecture.
      
    • The target computer that is being recovered to must have sufficient RAM memory available to start the operating system.
      
    • The target computer that is being recovered must have the same number of disks as the source computer being backed up. This is a requirement for Windows ASR processing to be able to recreate the damaged file systems.
      
    • If a Windows computer is recovered that had BitLocker encryption enabled - that BitLocker encrypting must be turned back on after the restore.
      
    • If the computer being recovered had RAID devices or setup it might have to be re-configured before the Disaster Recovery can begin.
      

Creating the Bootable Recovery ISO Image

In the Windows Start Menu select ‘UPSTREAM Recovery ISO Creation Tool’

If the application does not detect the Microsoft Assessment and Deployment toolkit (ADK) a message like this will present itself.

ADK Not Installed Message

The backup administrator needs to download and install the missing toolkit from the Microsoft Download Center.

This download can be found by searching for “Microsoft Assessment and Planning Toolkit” on the Internet.

Once the toolkit is downloaded and installed (the ADK download process may take hours to complete) the following screen is presented.

UPSTREAM Recovery ISO Creation Tool

The wizard allows the backup administrator to add language and time zone selections followed by a simple one click process to create the bootable ISO image.

Creating Backups Ready for Disaster Recovery

For UPSTREAM to properly handle a Disaster Recovery the backup of the Computer(s) must include everything needed to recreate the failing system, i.e. a full system backup.

 Considerations Before Running Disaster Recovery

Before the Automated Disaster Recovery process begins, a few items need to be in place and the systems prepared for recovery.

Hardware Considerations

• 
  
  • 
    
    • 
      
      • Hard Drives – Must be of the same type (SCSI, SATA) and number of the original drives and be large enough to hold the entire capacity of the data drives being protected.
        
      • System Boards – The system being restored to must have the same type of boot process (BIOS or EFI) as the system that failed. UPSTREAM can not automatically recover an EFI based system to a BIOS board or vice versa.
        
      • Network Cards – Make sure you use Network cards already supported by the Windows, or add drivers during ISO creation.
        

Restoring to a Virtual Environment such as Hyper-V

Performing an Automated Disaster Recovery to a virtual environment is possible as well.

The virtual hardware considerations are similar to those of a real system.

• 
  
  • 
    
    • 
      
      • Ensure Virtual disks are created and available of the same type and number of as those that were backed up.
        
      • Ensure the Virtual System boot into either EFI or BIOS mode depending upon what was backed up.
        
      • Ensure compatible Virtual Network cards are available - this is always the case with Hyper-V.
        
      • Attach the Bootable Disaster Recovery ISO Image created earlier and boot from it.
        
      • After the system is restored and restarted install the appropriate Hyper-V tool kit.
        

Running the Automated Disaster Recovery Process

Boot from the bootable image created earlier. There are several ways this can be done, depending on the Recovery environment such as.

• 
  
  • 
    
    • Burn the ISO Image to a DVD or CD Image and boot from it.
      
    • Attach the ISO Image to a Virtual Machine and boot from it.
      
    • Upload the ISO Image to a network based deployment service such as Microsoft WDS and perform a PXE Network boot from the Image.
      

Regardless of the method, the Backup administrator is presented with an UPSTREAM screen like this:

UPSTREAM Bare Metal Recovery (BMR)

Profile Information

Enter the Backup Profile needed for the restore - or use a wild-card selection for a list of valid profiles.

Storage Server

Enter the TCP/IP or DNS name of the Storage Server the original backup was stored on and Port Number. Optionally provide a valid User Id and Password if the Storage Server has access security active.

TCP Settings

Decide if DHCP or a Manual (Static) address is needed. Enter a valid TCP/IP address for the FDR/UPSTREAM Recovery process to use. Ask your network administrator for advice if needed.

Network Adapters

Select a Network adapter to use for the network connectivity. If no Network Adapter card is present a driver might have to be loaded using the “Load Drivers” selection.

Selecting the RECOVERY TYPE

The Automated recovery process allows for different recovery scenarios - depending upon the severity of the system that failed.

– Used to perform a Full System Recovery to a blank computer, all old data will be destroyed by this process

– Performs a full System Recovery without any attempts to recreate or format existing disk drives. The ‘Disk Management’ selection is available for advanced Windows Administrators to start the Diskpart process for this.

Select Backup Profile and Version to restore

The “Get Backup Versions” function connects to the Storage Server and product a selectable list like this:

BMR Profile Selection

The backup administrator should select the version they want to restore from and press Select.

BMR Select Version

The system returns showing the Backup Version selected. Press the Start Recovery button to start the Disaster Recovery process.

BMR Disk/Volume Selection

You have the opportunity to select or re-order the disks that you want to recover. Only system critical drives are required but data drives can optionally be added.

For a “Full System” Recovery, all Disk and Directory structures are automatically reformatted and Restored.

BMR Recovery Progress

BMR Recovery Complete