TBMR for Solaris Version 2.12 SPARC Platform Step-By-Step Guide

Cristie Software Ltd 

New Mill 

Chestnut Lane 

Stroud GL5 3EH 

United Kingdom 

Tel:+44(0)1453 847000 

Fax:+44(0)1453 847001 

cbmr@cristie.com 

TBMR for Solaris Version 2.12 

SPARC Platform 

Step-By-Step Guide 

Cristie Data Products GmbH 

Nordring 53-55 

63843 Niedernberg 

Germany 

Tel: +49 (0) 60 28/97 95 7-19 

Fax: +49 (0) 60 28/97 95 7-99 

cbmr@cristie.de 

Cristie Nordic AB 

Gamla Värmdövägen 8 

SE-131 37 Nacka 

Sweden 

Tel:+46(0)8 718 43 30 

Fax:+46(0)8 718 53 40 

cbmr@cristie.se

TBMR Version 2.12 for Solaris – Step-by-Step Guide 

Table of Contents 

1) Setup TBMR Recovery Client……………………………………………………………..……………………………. 1 

1.1) Installing TBMR for Solaris on Recovery Client………………………………………………………………….. 1 

2) TBMR Preparation…………………………………………………………………………………………………………… 2 

2.1) TBMR Backup & TBMR Recovery Scripts……………………………………………………………………………. 2 

2.2) Creation of Bootable CD………………………………………………………………….………………………………… 2 

2.3) Saving Configuration………………………………………………………….……………………………………………... 4 

3) Jumpstart Based Recovery (Preparation)……………………………………..……………………………………. 6 

4) Disaster Recovery…………………………………………………………………………………………………………….. 7 

4.1) CD Based Recovery…………..………………………………………………………………………………………………. 7 

4.2) Jumpstart Based Recovery…………..……………………………………………………………………………………. 7 

4.3) TBMR Disaster Recovery…………..………………………………………………………………………………………. 7 

4.4) Locating Configuration Files………………………………………………………………………………………………. 8 

4.5) Specifying the Backup Location used to backup Solaris ………………………………………..……..…… 13 

4.6) Automatic Recovery………………………………………………………………………………..………………………… 13 

5) Copying Log Files to Network Share or Floppy Disk ………………………………………………………….... 15 

6) Finalising Logical Volume Manager Setup………………………………………………………………………….. 16 

6.1) Solaris Volume Manager / Solstice DiskSuite ……………………………………………………………………. 16 

6.2) Veritas Volume Manager…..………………………………………………………………………………………………. 17 

6.3) After TBMR Recovery…………..……………………………………………………………………………………………. 17 

7) Notes……………………………………………………………………………………..………………………………………... 17 

7.1) Controlling files restored as part of TBMR Disaster Recovery 17 

7.2) Recovery of Solaris Volume Manager / Solstice DiskSuite when config files are missing……… 18 

7.3) Recovery of Veritas Volume Manager when config files are missing…………………………….……… 19 

7.4) Recovering a machine with networked storage………………………………………………………………….. 20 

7.5) Log Files………………………………………………………………………………………………………………………….. 23


1) Setup TBMR Recovery Client 

1.1) Installing TBMR for Solaris on the Recovery Client 

1.1.1) Installing TBMR From CD-ROM 

If Solaris already has volume management running then inserting the Solaris TBMR distribution CD into the drive will 

automatically mount the CD. 

Selecting the sparc folder from the top-level directory produces the following… 

Selecting the “tbmr” sub-directory gives… 

Running the script install_t will copy the required files from the installation CD to the restore client machine. 

To uninstall TBMR for Solaris either run the uninstall script or run the install script with the option –u. 

Installation of the Solaris TBMR Client application is now complete. 

To run the TBMR client application type sol_tbmr at the the command command command line. 

line. 

Page 1 of 23


2) TBMR Preparation 

2.1) TBMR Backup and TBMR Recovery Scripts 

TBMR does not require a dedicated disaster recovery backup to be taken. However all the Operating System files 

needed for a bootable machine must be included in the TSM BA Client backup to be used as the source of files 

during the disaster recovery process. You should therefore ensure that the BA Client exclude lists do not exclude 

these files from the backup. 

TBMR uses two “script” files during the disaster recovery to limit the number of files recovered and therefore limit 

the time taken to get the machine up & running. These two scripts “tbmr_root.scp” and “tbmr_fs.scp” are located in 

the /etc/cristie/scripts directory and are saved as part of the list of files making up the TBMR configuration. 

“tbmr_root.scp” controls the files and sub-directories in the root filesystem that get restored as part of the DR 

process. If this file is not present the entire root filesystem will be restored. 

“tbmr_fs.scp” controls which of the remaining BA Client filespaces are recovered. If this file is not present then only 

the root filesystem will be restored during the disaster recovery. A list of filespaces can be obtained by carrying out a 

BA Client Filespace Query. 

(See section 7.1 below for details of contents of tbme_root.scp & & tbmr_fs.scp) 

tbmr_fs.scp) 

Note Note Note 1: 1: The TBMR recovery is not not intended to carry out a complete restore of your machine in a single step. The 

Disaster Recovery should restore only those files required for the Solaris Operating Environment and theTSM BA 

Client .TBMR is only intended to get your machine up and running as quickly as possible in order to restore your files 

and data from the latest full backup. By minimising the number of files recovered the time taken to carry out the 

restore is minimised, and the time taken to get the machine up and running after a disaster is also reduced. 

Once the machine is up and running after a disaster a full restore can be carried out and may overwrite some of the 

files restored by the DR process. 

Note Note 2: 2: Co Co-Location Co 

Location Location of configuration files with with TBMR backup. TBMR for Solaris Versions 2.12 and later allow the 

configuration of the system, required for recovery, to be saved as part of the main TBMR backup. If this facility IS 

IS 

being used the configuration of the TBMR client machine must be saved locally to directory /TBMRCFG 

(See section 2.3 below). 

2.2) Creation of Bootable CD 

2.2.1) Disk Space Requirements 

The Bootable TBMR CD is based on a copy of the Solaris Installation Media with any unnecessary files removed and 

Cristie’s software and scripts added. 

Note: Note: Creation of the Bootable CD requires a copy of the first CD CD in the set of Solaris media or the DVD DVD version of 

the Solaris distribution. Copies of the Solaris Installation media are available for download from Sun’s website at 

www.sun.com . 

The TBMR Client Application will need to know where to find the Drive containing the Solaris Media so you will need 

to find the identity of your drive in the form cXtXdX. 

The Solaris Installation Media will be copied to the Hard Drive of the client machine being used to create the CD. 

It will be modified by the TBMR Client Application, then a new ISO file created. 

To carry out this action a directory needs to be identified with enough free space for both the copy of the Solaris 

Installation Media and the new ISO image. (1200 MB for Solaris 8, 1400 MB for Solaris 9, or 1000 MB for Solaris 

10). This space is only required during the generation of the bootable CD and the copy of the original CD can be 

deleted once the ISO has been created. Once the ISO has been burned to a suitable CD-ROM this file can also be 

deleted. 

2.2.2) CD Creation 

At the main menu select Crea Create Crea 

te Bootable ISO file 

Page 2 of 23


The system then runs a small utility program to interrogate the hard-drives and store the results in the file 

/etc/cristie/cbmr_s.ini. 

After obtaining the Geometry information, if you are using a Logical Volume Manager such as Solstice DiskSuite 

(Solaris 8), Solaris Volume Manager (Solaris 9 & 10) or Veritas Volume Manager, you may be prompted to tell the 

system which LVM you are using. 

For Solaris 10 the structure of the DVD is very different to the structure of the first CD in the set of installation media. 

The system will therefore ask you which type of media you are using. 

You will then be prompted to enter the path to be used to hold the bootable CD Image. This will be a directory with 

sufficient free space, as outlined in section 2.2.1 above. 

If a previously extracted CD Image already exists at this location you will be warned and asked if you wish to 

continue. 

And if you wish to continue you will be asked if you wish to re-use the existing CD Image or extract a new image from 

the Solaris media. 

Page 3 of 23


If no previous CD Image existed, or you have chosen to extract a new image, you will be prompted for the location of 

your CD Drive. (In the form cXtXdX as identified in section 2.2.1 above). 

The final step before TBMR creates the Bootable CD is to tell the system whether you want the configuration files 

generated by TBMR stored on the CD. 

Copying the files does not increase the size of the ISO file created by TBMR, so unless you are absolutely sure you 

don’t want these files on the CD then it is safer to copy them. 

After completing this dialog the system will create the bootable CD. 

Note Note : depending on the speed of your CD-ROM drive this will take quite a few minutes. 

The CD creation process is carried out in three stages. 

Extraction of slices on the original media 

Modification of files on hard disk 

Creation of new ISO CD image 

Once the process has finished the new ISO file will be named cbmr_boot.iso and will be located in the CD subdirectory 

of the directory selected above. This ISO file needs to be burned to a CD-ROM using third party CD 

mastering software such as CDRecord, written by Jörg Schilling and freely available on the Internet. 

At this point it is probably worth testing whether the CD is bootable, the configuration files are readable, and the 

UBax device chosen for the backup is accessible during the TBMR recovery. To do this see the first few steps of the 

disaster recovery process outlined below (See section 4.1) . 

2.3) Saving configuration 

When TBMR for Solaris creates a Bootable CD the configuration information for that machine gets saved on the CD 

for use during the recovery. However since it is possible to use the same Bootable CD to recover a number of client 

machines then the facility to save the configuration on a floppy disk , network share or second CD ROM is provided. 

If the configuration of the machine is saved locally in directory /TBMRCFG, and this directory is included in the BA 

Client backup, then TBMR can read the configuration files from the main backup as part of the DR process. 

After the configuration has been saved it is possible to manually make changes to the saved config files. 

If, for instance, the client machine having its configuration saved is attached to a networked storage device (e.g 

SAN), or has a number of hard disks that will not be present in the machine being recovered then the disrec.ini file 

can be edited after saving to network share or floppy. (see section 7.5 for details). 

Note: Note: It is not possible to extract the Bootable CD from a client machine during a CD based recovery. For a CD based 

recovery therefore the configuration information should only be saved on CD ROM if a second CD drive will be 

available, either within the client itself or over the network during the restore. 

Page 4 of 23


2.3.1) Specify location for saved Configuration Files. 

At the main menu select Set Location for for Config Info. 

This will display the following form to specify where the saved configuration files will be placed. 

If the config files are to be saved on an NFS share, and the share has been exported with RW permissions, and if the 

share has been mounted on a mountpoint on the client machine then the configuration files can be written directly 

to the network. If this is the case the “Local” field on the form above should be set to N; the “Hostname” and “IP” 

fields should be set to the name and address of the remote machine; and the last field should be set to the 

destination directory. 

Note Note Note 1 1 : : Either the hostname OR the IP Address are required, but not necessarily both (Depending on which was 

used in the mount command when mounting the directory on the client machine). 

The CBMR directory specified here should be the actual directory on the remote server, not the mount point on the 

client.. 

Note Note Note 2 2 : : If If the the configuration configuration files files are are being being saved saved as as part part of of the the TSM TSM BA BA Client Client backup backup then then the the files files MUST MUST be be saved sa 

ved 

locally locally in in directory directory /TBMRCFG /TBMRCFG before before taking taking the the backup backup. backup 

If the intended destination directory on the network is not shared with RW permissions then the “Local” field should 

be set to Y and the CBMR directory field set to a location on the client machine where the configuration files can be 

found later and copied to the network manually. 

If the configuration files are being saved to floppy disk or CD ROM then the “Local” field should be set to “Y” and the 

CBMR directory set to a convenient location for subsequent copying to the desired media. 

2.3.2) Save configuration information. 

Choosing the next option, Save Save Configuration Information, from the top-level menu will firstly run the Hard Drive 

Geometry utility then copy the INI file containing the configuration and any other files required to recover the Solaris 

Environment to the location set up in the previous step. 

If you are using a Logical Volume Manager, such as DiskSuite or Solaris Volume Manager, then you may be 

prompted to let the system know which one at this point.. 

The two TSM configuration files, dsm.opt & dsm.sys, will also be copied to the same location as the TBMR 

configuration. 

The The The process process of of preparing preparing for for a a disaster disaster is is now now now complete complete for for this this this client client client machine. 

machine. 

Page 5 of 23


3) Jumpstart Based Recovery (Preparation) 

To simplify the administration of large networks of Solaris systems Sun provides the “Jumpstart” mechanism. 

Jumpstart can be used either to install the operating system from scratch or to perform similar upgrades to a 

number of machines located on the network. 

TBMR and/or CBMR modify the Solaris Image on the Jumpstart Server in a similar way to the filesystem on the 

bootable CD to add the utilities and scripts required to carry out the disaster recovery. 

Unlike the CD filesystem however none of the existing files in the Jumpstart image are removed or re-named so any 

existing Jumpstart behaviour will be un-altered. 

To prepare the Jumpstart Server to carry out TBMR recoveries, TBMR must first be installed on the Jumpstart Server 

in the same way as on the TBMR client (See section 1 above). 

As part of the TBMR installation a script “mk_cbmr_scp2_js” will be copied to the directory 

/etc/cristie/mk_cbmr/create. 

Running this script and passing it the path to the directory holding the Jumpstart image will copy the necessary 

scripts and utilities into the Jumpstart Image. 

For example if the Jumpstart Server has the Solaris 9 image located at /export/home/jump_5.9… 

> > cd cd /etc/cristie/mk_cbmr/create 

/etc/cristie/mk_cbmr/create 

> > . . /mk_cbmr_scp2_js /mk_cbmr_scp2_js /export/home/jump_5.9 

/export/home/jump_5.9 

The Jumpstart Server is now almost ready to carry out a TBMR recovery in the event of a disaster. 

Page 6 of 23


4) Disaster Recovery 

WHEN WHEN A A DISASTER DISASTER OCCURS... 

OCCURS... 

4.1) CD Based Recovery 

Firstly obtain the correct TBMR Bootable CD for the machine as prepared above. 

Boot the machine 

As soon as the screen comes to life type Stop+A (That’s the Stop key plus “a” together) to get the “ok” prompt 

(You may need some other key sequence to get to the OK prompt depending upon your machine) 

At this point you will be able to open the CD drawer, insert the Bootable CD and type …. 

ok boot cdrom 

(That’s boot cdrom ) at the OK prompt 

The normal Solaris Installation process will then start displaying a series of messages on the screen and may 

present you with a series of simple prompts. 

4.2) Jumpstart Based Recovery 

Firstly the “Normal” Jumpstart behaviour must be replaced by TBMR Jumpstart. 

As part of the installation process for TBMR carried out in section 3 above a modified version of the inittab file was 

copied to the Image of Solaris on the Jumpstart Server. 

This file will be located somewhere like /export/jump_5.9/Solaris_9/Tools/Boot/etc/inittab_cbmr 

(Depending of course on the location of your Solaris Image). 

The original inittab file will also have been copied to “inittab_sun”. 

Before attempting to restore the client machine the TBMR version of inittab needs to be copied to “inittab”. 

> > > cd cd /export/jump_5.9/Solaris_9/Tools/Boot/etc/ 

/export/jump_5.9/Solaris_9/Tools/Boot/etc/ 

> > cp cp inittab_cbmr inittab_cbmr inittab 

inittab 

When the client machine is Jumpstarted the modified version of inittab will execute the TBMR scripts and software 

instead of the Sun Jumpstart mechanism. 

We can now boot the TBMR recovery client. 

Wait 'til it finishes doing its memory test, then press Stop-A to interrupt the normal boot process & get an "ok" 

prompt. At this point type... 

boot boot ne net ne t – install 

install 

(That's boot space net space - space install). 

The Jumpstart based recovery will now start. 

4.3) TBMR Disaster Recovery 

At this point the TBMR process takes over from the Sun boot process and starts by asking you to confirm the 

networking setup of the machine. 

For each network card the system has detected TBMR will either display the IP Address and netmask for the card 

and ask you if you wish to change them, or let you know that the system has been unable to resolve an IP Address 

and prompt you to enter one. 

TBMR will then ask you if you wish to set up a default router. This will be necessary if the machine holding the 

backup is on a different subnet to the recovering machine. 

You will then be asked if you wish to set up a DNS Nameserver. Again this will be useful if your backup is placed on a 

remote machine that has its IP Address allocated dynamically. 

The last step in setting up networking is to get you to confirm the hostname of the machine if it has been resolved, or 

to enter it if it hasn’t. 

Page 7 of 23


The system will then launch the Solaris TBMR Disaster Recovery application. 

4.4) Locating the configuration files 

As outlined above the Bootable TBMR media may be used to recover several client machines. The saved 

configuration files may be located on the Boot CD, Network Share, Floppy Disk, or saved with the TSM BA Client 

backup. The first step in the recovery is to locate the configuration files for the client machine being recovered. 

4.4.1) Locate Configuration File (disrec.ini) 

Choosing the first option on the Disaster Recovery application’s main menu brings up a list of possible locations for 

the configuration files. 

4.4.1.1) CBMR Boot CD 

For the simplest case with the configuration files saved on the boot CD itself, selecting the item CBMR CD from the 

list will bring up a form to allow you to enter the path and filename of the config file. 

For this simple case you can accept the defaults shown here. 

Page 8 of 23


4.4.1.2) Floppy Disk 

If the configuration had been stored on floppy disk, selecting the relevant option from the “File Location” 

list would bring up a screen looking like…. 

…and assuming the floppy containing the config files was present in the drive you should then get a confirmation 

message… 

… followed by…. 

Assuming the config files were saved in the root directory of the floppy disk you can accept the defaults shown. 

If for any reason the system is unable to mount the floppy or a message will be displayed on the screen. 

If the system is unable to read the configuration file specified above again an error message will be displayed on the 

screen. The most likely cause of this is a typo when entering the path to the config file. 

4.4.1.3) Network Share 

If the configuration files for this TBMR client were stored on a Network share, after selecting the correct entry on the 

list of locations you will be presented with a form along the lines of…. 

Page 9 of 23


In this case the first field on the form needs to be filled with the path to the shared directory on the network . 

The second field needs to be filled with the path from the shared directory to the directory containing the config file. 

The third field needs to be filled with the filename of the config file itself. 

Example Example : : If the IP address of the server holding the config file “disrec.ini” is 10.0.4.5; 

The config file – disrec.ini - is located in directory /export/cbmr/configs/U30 on that server; 

And the server has shared directory /export/cbmr shared over the network ; 

The form should be completed as follows… 

The Path to NFS share is 10.0.4.5:/export/cbmr (No trailing slash required) 

The Path is configs/U30 (No leading or trailing slashes) 

And finally the filename (In this case disrec.ini). 

If for any reason the system is unable to mount the network share a message will be displayed on the screen. 

If the system is unable to read the configuration file specified above again an error message will be displayed on the 

screen. The most likely cause of this is a typo when entering the path to the config file. 

4.4.1.4) Saved with TSM BA Client Backup 

If the TSM BA Client parameters have not yet been set up then you will be presented with a small menu... 

Selecting the first of these options will display the contents of the dsm.sys file copied onto the Bootable media 

during ISO creation. 

The second option produces a form to allow you to enter / modify these parameters… 

The first three fields are self explanatory, the NodeName is the node on the TSM server containing your BA Client 

backup and the password field allows you to enter the password for the specified node. 

The ”Command line” field allows you to enter any additional command line switches, such as –quiet or –pitt, to be 

passed to TSM during file restore. These options will be used when reading the configuration files and during the 

main file restore. 

If the “Command Line” field or OK / Cancel buttons are not displayed on this form using CTRL+N will display the 

second page of the form. After completing the form you will return to the Client Setup menu then, when you exit from 

the menu, TBMR will attempt to read the configuration files from the BA Client backup 

Page 10 of 23


4.4.2) TSM Configuration Files. 

After locating the configuration files TBMR will check in the same location to see whether the files dsm.sys and/or 

dsm.opt exist. If these files are present (Saved in step 2.2.2 above) then you will be given the option of using these 

files instead of the ones in the recovery environment. 

As per the prompts in the dialog shown selecting “OK” will replace the dsm.opt and dsm.sys files from the CD with 

those found alongside the configuration files. 

Note: Note: If your configuration files were saved as as part of of the the BA BA Client Client ba backup, ba ckup, and you have carried out the the steps 

above above to to configure configure dsm.sys, dsm.sys, dsm.sys, then then then you you should should NOT NOT use use the the files files files recovered recovered as as part part of of of the the configuration. 

configuration. 

4.4.3) LVM Configuration Files – SDS / SVM. 

When creating the configuration file the TBMR Client Application makes a note of any Logical Volume Manager in 

use. In the case of Solaris Volume Manager Manager or Solstice DiskSuite DiskSuite the TBMR Client Application also makes a copy of 

the outputs from the metastat metastat and metadb commands. After locating the configuration file the TBMR recovery 

application checks whether SVM or SDS were in use on the original system and if so checks for the existence of the 

files “metastat_p metastat_p metastat_p” metastat_p and “metatdb_i metatdb_i metatdb_i”. metatdb_i 

This may simply be an error in the configuration file. If Solaris Volume Manager or DiskSuite were not in fact in use 

on the original system then we can select OK from this dialog and TBMR will not attempt to recover the LVM setup. 

If SVM or SDS were in use but these files are missing then TBMR will be unable to complete an Automatic Recovery. 

(See Notes in section 7.2 at the end of the document). 

Page 11 of 23


4.4.4) LVM Configuration Files – VxM. 

As stated above when creating the configuration file the TBMR Client Application makes a note of any Logical 

Volume Manager in use. In the case of Veritas Veritas Vol Volume Vol 

ume Manager the TBMR Client Application also makes a copy of 

the file /etc/vfstab.prevm, or attempts to build this file from notes that VxM makes at the end of /etc/vfstab. 

This file is then stored as part of the configuration for TBMR recovery. 

During a TBMR restore, after locating the configuration file, the TBMR recovery application checks whether VxM was 

in use on the original system and if so checks for the existence of the file vfstab.prevm in the same location. If the 

file is missing the following warning is displayed. 

This may simply be an error in the configuration file. If Veritas Volume Manager was not in fact in use on the original 

system then we can select OK from this dialog and TBMR will not attempt to recover the LVM setup. 

If VxM was in use but vfstab.prevm is missing then TBMR will be unable to complete an Automatic Recovery. 

(See Notes in section 7.3 at the end of the document). 

If you continue with the recovery (Either Automatic or Manual) with this file missing, at the point that TBMR attempts 

to restore the VxM setup you will get the following dialog displayed. 

At this point it is necessary to use the “Shell” option from the top-level menu to edit the file /etc/vfstab to remove 

references to the VxM volumes and replace then with the correct “native” partitions to mount any filesystems. 

Even if vfstab.prevm is not present then TBMR will still comment out the lines relating to Veritas Volume Manager in 

/etc/system. The system should boot correctly from the native Solaris partitions once the necessary changes have 

been made to /etc/vfstab. 

Page 12 of 23


4.5) Specifying the Backup Location used to backup Solaris 

After completing the dialogs above to locate the TBMR configuration files you will return to the main menu 

If the location holding the TBMR backup has not yet been specified, then this is the next step.. 

Selecting the second option allows you to set up the BA client parameters to be used for file restore 

(see section 4.4.1.4 above) 

Selecting the third option “Test Backup” runs a TSM BA Client filespace query (Or reads the volume header of a UBax 

location), to test the connection to the specified location. 

4.6) Automatic Recovery 

Assuming everything is OK so far we are now ready to begin the TBMR Recovery. 

Selecting the third option from the main menu begins the Automatic Recovery process and the following screen will 

be displayed… 

The system will then read the selected configuration file, interrogate the hard drives on the machine being recovered 

and generate Volume Table of Contents (VTOC) files for each hard disk. 

Once the disks have been labelled – if necessary – and re-partitioned the following screen will be displayed . 

TBMR will always format the disk containing the root filesystem. 

TBMR will always format any disks which had no labels and therefore were labelled automatically in the previous 

step. 

Page 13 of 23


If the other disks on the system were not corrupted during whatever disaster ocurred and have data on them that 

you might wish to preserve then setting the Format All flag to N will skip formatting for disks other than those 

mentioned above 

If all the hard disks known to be on the system, or the the “Format “Format All” All” field, field, field, or or the the the OK OK and and Cancel Cancel buttons buttons ar are ar e not not 

not 

displayed, displayed, then then using using CTRL+N CTRL+N will will display display the the next next page page of of the the form. 

form. 

After accepting the form shown above TBMR will format any disks. 

The system will now use the TSM BA Client (Or Cristie’s UBax software, depending upon the backup location selected 

above) to restore the Solaris files. 

If the BA Client is used the files are restored in two phases… 

4.6.1) Root Filesystem 

Firstly files from the root filesystem are recovered. If the file tbmr_root.scp, saved as part of the configuration, exists 

then this determines which files from the root filespace are restored (See section 7.1.1). If this file does not exist 

then the entire root filespace will be restored. If a selective restore is carried out by specifying files in tbmr_root.scp, 

but for an individual entry in this file there are no files to be restored then the BA Client reports an “error”. 

If this, or any other errors occur then the following menu will be displayed at he end of the root filespace restore. 

Unfortunately TSM returns the same error code for this trivial error as for more serious ones. 

After exiting the above dialog box you will be presented with a simple menu… 

Selecting the first option from this menu will display the log file generated by the TSM BA Client. 

If no serious errors are reported then selecting the second option will continue with the recovery of remaining 

filespaces from the BA Client backup. 

4.6.2) Non-Root Filesystems 

After recovering the files from the root filespace any remaining filespaces, listed in the tbmr_fs.scp file, are restored. 

If this file is not present then only the root filespace will be restored as part of the DR process (See section 7.1.2) 

Page 14 of 23


4.6.3) Final stages of TBMR recovery 

When the recovery of files using BA Client (or UBax) finishes TBMR will continue the recovery process by setting up 

any Logical Volume Manager (DiskSuite. Solaris Volume Manager etc) in use on the original system. 

Then, when the recovery is more or less complete the Disaster Recovery Application will display a message box 

informing you that the restore is finished and you should choose “Exit” from the main menu. 

At this point you may wish to copy the various log files generated during the recovery to a shared network directory, 

or to floppy disk. (Note that, depending on the logging level used, the log files may be too large to fit on a floppy disk) 

See section 5 below for details. 

When the restore is complete and you exit the DR application, the system will ask you if you wish to run a shell 

window before re-booting the machine. 

TBMR TBMR is is now now finished 

finished 

Your machine will re-boot with a working Solaris Operating Environment. 

You can finalise the setup of your logical volume manager (See section 6 below) then you can recover any remaining 

files from your latest backup. 

5) Copying Log Files to Network Share or Floppy Disk 

At any point in the recovery, if the user has access to the top-level menu, the log files generated by TBMR can be 

copied to a shared directory on the network, or to a floppy disk. 

Selecting the option shown above from the top-level menu brings up the following sub-menu… 

Before the logs can be copied, the destination for the log files must be specified. Choosing the highlighted option 

brings up the following… 

Page 15 of 23


Selecting the Network Share option produces a dialog similar to the one used to specify the location of the 

configuration files (See section 4.4.1.3 above)… 

Once the destination for the log files has been specified the logs themselves can be copied by choosing the “Copy 

Log Files” item from the “Log Fles” sub-menu. 

If the directory chosen as the destination for the log files does not already exist then you will be asked if you wish to 

create it before the files are copied to the desired location. 

6) Finalising Finalising Logical Volume Manager Setup 

TBMR uses information stored prior to any disaster to recover the setup of a Logical Volume Manager (LVM) 

(Solstice DiskSuite for Solaris 8, Solaris Volume Manager for Solaris 9 or 10, or Veritas Volume Manager). 

The system does not however attempt to completely recover the LVM setup. 

The full LVM setup of a large system using a variety of stripes, concatenations and mirrors can be extremely complex 

and the consequences of restoring this incorrectly can be very serious, resulting in the loss of data and possibly 

preventing the recovering machine from booting. 

Bearing this in mind TBMR recovers the files saved in the backup onto the partitioned and formatted hard disks prior 

to setting up the LVM. 

6.1) Solaris Volume Manager / Solstice DiskSuite 

TBMR will attempt to create concats / stripes on partitions that had filesystems mounted on stripes in the original 

configuration. TBMR will also create mirrors for any of these partitions that were mirrored in the original system and 

will attach the “primary” sub-mirror. 

TBMR will also create concats / stripes on partitions that originally mirrored these stripes, but will not attempt to 

attach these sub-mirrors. 

(TBMR re-scales partitions on hard disks where the geometry has changed, this may result in the partitions used for 

sub-mirrors differing slightly in size and therefore the attempt to attach the sub-mirror might fail). 

In the case of concatenations, TBMR will create the first metadevice in the concatenation but will not attach any 

further partitions. 

During the file restoration phase of the recovery all the files that were backed up from the concatenated volume will 

be restored to the first partition of the concatenation. This is another reason to be selective with the TBMR script 

used to restore the Solaris files. 

Page 16 of 23


6.2) Veritas Volume Manager 

TBMR uses configuration information stored by the client machine prior to any disaster to obtain the “native” 

partitions for any Veritas Volumes. i.e the partitions that these volumes were mounted on prior to the installation of 

Veritas. 

TBMR restores the saved Solaris Operating Environment files onto these partitions, then makes adjustments to files 

/a/etc/vfstab and /a/etc/system in order to make the system bootable. Copies of these files prior to TBMR making 

any changes are stored as /a/etc/vfstab_original and /a/etc/system_original respectively. 

6.3) After TBMR Recovery 

Once the TBMR process has finished the recovering machine will be bootable and will have the relevant Logical 

Volume Manager installed. The Solaris system admininistrator can then finalise the setup of the LVM. This is a much 

lower risk strategy than TBMR attempting to do the full LVM recovery automatically. 

7) 7) No Notes No tes 

7.1) 7.1) 7.1) Controlling Controlling files files files restored restored as as as part part part of of TBMR TBMR Disaster Disaster Recovery 

TBMR uses two script files to limit the number of files restored as part of the DR process. 

These files are located in the directory /etc/cristie/scripts on the TBMR Client machine and get saved as part of the 

list of configuration files when preparing for a disaster. 

Two example scripts are copied to this directory as part of the installation of CBMR 

7.1.1) 7.1.1) TBMR_root.scp 

TBMR_root.scp 

This file is used to limit the files restored from the root filespace as part of the TBMR Disaster recovery. 

If this file is missing from the saved configuration the entire root filespace will be restored. 

The file takes the form… 

/ -subdir=no 

/boot/ -subdir=yes 

/cbmr/ -subdir=no 

/usr/ -subdir=yes –quiet 

…with each line being a path specification followed by any BA Client command line switches to be applied to that line 

when carrying out the restore. 

In the above example … 

/ -subdir=no -- Will restore files in the root directory, but not sub directories 

/boot/ -subdir=yes -- Will restore the /boot/ directory and any sub-directories 

/cbmr/ -subdir=no -- Will restore the /cbmr/ directory but not sub-directories 

/usr/ -subdir=yes –quiet -- Will restore the /usr/ directory and any sub-directories 

and will suppress listing of the files as they are recovered 

Note Note : The trailing slash at the end of the path is is required 

7.1.2) 7.1.2) TBMR_fs.scp 

TBMR_fs.scp 

File is used to specify which of the remaining filespaces in the BA Client backup are restored as part of the DR 

process. If this file is missing from the saved configuration ONLY the root filespace will be restored. 

The file takes the form… 

/export/home/ 

/export/home0/ 

/user_data/ 

… and is simply a list of the filespaces to be restored from the BA Client backup. Once again the trailing slashes at 

the end of each entry in this file must be present. 

A list of the filespaces contained in the backup can be obtained by running a BA Client filespace query 

> dsmc query filespace 

Page 17 of 23


7.2) 7.2) Recovery Recovery of of Solaris Solaris Volume Volume Manager Manager / / Solstice Solstice DiskSuite DiskSuite when when confi configuration confi guration files are are missing 

When preparing for disaster recovery on a client machine using Solaris Volume Manager (SVM) or Solstice DiskSuite 

(SDS) the TBMR Client Application saves the output from the metadb and metastat commands in three files:- 

metadb_i metadb_i -- The output from metadb –i 

metastat_i metastat_i -- The output from metastat –i 

metastat_p metastat_p -- The output from metastat –p 

These three files are then saved alongside the disrec.ini file on floppy disk, network share or the JumpStart Server; or 

in the directory / /etc/cristie/lvm 

/ 

etc/cristie/lvm on the Bootable TBMR CD. 

During the recovery, when the user has identified the location of the configuration file TBMR reads the file to check 

whether SVM or SDS were in use on the original machine, then if necessary checks whether the above files are 

present. 

If these files are not present, either because there was an error copying them when storing the configuration, they 

have subsequently been deleted, or the entry in the configuration file is correct and SVM/SDS was not in use on the 

original system, then TBMR will be unable to automatically recover the Logical Volume Manager setup. 

In this case the following dialog will be displayed… 

For the case where SVM/SDS were not in use on the original machine i.e. the entry in the configuration file is 

incorrect simply select OK to exit the dialog and carry on with the recovery. The entry in the configuration file will be 

ignored and TBMR will not attempt to set up the Logical Volume Manager. 

If however SVM/SDS were in use but the files are missing we have more of a problem, but all is not lost… 

During preparation for disaster recovery, when the TBMR Client application copies the configuration files to network 

share or floppy disk it also appends the contents of the metasat_p and metadb_I files to the end of the configuration 

file (disrec.ini). Therefore it may be possible to recreate the files we need. 

Exit the dialog above using Cancel Cancel, Cancel 

because we still want to attempt setup the volume manager. 

At the main menu select the Shell option. 

Run the commands 

>cd >cd >cd / / 

/ 

>find >find >find . . . –name name disrec.ini disrec.ini 

disrec.ini 

to locate the configuration file. If you are carrying out a CD Based recovery but are using a configuration file on 

network share or floppy disk you may find more than one instance, it should be obvious which is the correct one 

(/etc/cristie/cbmr/disrec.ini is the one located on the bootable CD itself) 

Change directory to the location of the disrec.ini file then use vi to examine the contents. At the end of the file should 

be two sections starting with [METASTAT_P] and [METADB_I] [METADB_I]. 

[METADB_I] 

If entries are present and look as though they contain the correct information to set up the logical volume manager 

we can proceed as follows. 

Exit from vi 

Copy disrec.ini to metastat_p 

Copy disrec.ini to metadb_I 

Use vi to edit the new metatstat_p file – Remove everything up to and including the line [METASTAT_P]. 

-- Remove everything from, and including, [METADB_I] to the end. 

Use vi to edit the new metadb_i file – Remove everything up to and including the line [METADB_I]. 

Page 18 of 23


Return to the TBMR Recovery Application (On a CD Based recovery use CTRL+D to exit the shell) 

Continue with the recovery, TBMR will use the re-created metastat_p and metadb_i files to recover the volume 

manager configuration. 

If the disrec.ini file does not contain the required information, but you know where to place the SVM or SDS State 

Database Replicas we can still recover the Logical Volume Manager setup manually. 

After inspecting the disrec.ini file without SVM/SDS setup information return to the Recovery Application. 

Re-select the configuration file and you should be presented with the dialog shown above with the warning about 

missing metastat_p & metadb_i files. This time exit the dialog with OK to proceed with recovery but to skip the 

attempt to recover the SVM/SDS setup. The recovery should run to completion and display a message along the 

lines of “Restore is complete – Select EXIT to finish recovery and re-boot”. 

At this point DO NOT select Exit. 

Instead select the Shell option once more. 

You can now manually use the command metadb –a to create the required state database replicas (See Sun 

Documentation). 

After setting up the State Database replicas you can use metainit to create the required concats / stripes / mirrors 

(Again see Sun Documentation) – The original configuration of concats / stripes / mirrors shuold have been restored 

to the file /a/etc/lvm/md.cf. 

Finally to copy the newly setup SVM/SDS configuration to the restored filesystem you need to run the script 

>/etc/cristie/c 

>/etc/cristie/cbmr/finish_svm 

>/etc/cristie/c bmr/finish_svm 

We can now return to the TBMR Application and select Exit to finish the recovery process and re-boot the machine. 

7.3) 7.3) Recovery Recovery Recovery of of Veritas Veritas Volume Volume Manager Manager Manager when when config config files files files are are missing 

missing 

When preparing for disaster recovery on a client machine using Veritas Volume Manager the TBMR Client 

Application saves a copy of the file /etc/vfstab.prevm, or attempts to build this file from notes that VxM makes at 

the end of /etc/vfstab. 

This file is then stored as part of the configuration for TBMR recovery. 

If this file is missing TBMR will be unable to automatically update the vfstab file restored as part of the backup of 

Solaris files. 

In this case the file /a/etc/vfstab will need to be manually edited using vi from the “Shell” option of the top level 

menu. 

The file restored as part of the Solaris backup may have notes made by Veritas included at the end as follows:- 

#device device mount FS fsck mount mount 

#to mount to fsck point type pass at boot options 

# 

fd - /dev/fd fd - no - 

/proc - /proc proc - no - 

/dev/vx/dsk/bootdg/swapvol - - swap - no nologging 

/dev/vx/dsk/bootdg/rootvol /dev/vx/rdsk/bootdg/rootvol / ufs 1 no 

nologging 

/dev/vx/dsk/bootdg/usr /dev/vx/rdsk/bootdg/usr /usr ufs 1 no 

nologging 

/dev/vx/dsk/bootdg/home /dev/vx/rdsk/bootdg/home /export/home ufs 2 

yes - 

swap - /tmp tmpfs - yes - 

#NOTE: volume rootvol (/) encapsulated partition c0t0d0s0 

#NOTE: volume swapvol (swap) encapsulated partition c0t0d0s1 

#NOTE: volume usr (/usr) encapsulated partition c0t0d0s5 

#NOTE: volume home (/export/home) encapsulated partition c0t0d0s6 

In this case the entries in vfstab relating to VxM volumes can easily be changed to the correct native partitions by 

referring to the notes made by Veritas. If these notes are not present then it may be possible to determine the 

correct entries for each filesystem either by looking at the VTOCs for the system’ hard disks. 

> > prtvtoc prtvtoc /dev/rdsk/c0t0d0s2 

/dev/rdsk/c0t0d0s2 

Page 19 of 23


or by examining the configuration file saved by the TBMR Client application. 

> > vi vi /etc/cristie/cbmr/disrec.ini 

/etc/cristie/cbmr/disrec.ini 

then looking at the [MOUNT_POINT_X] sections to see which “SLICE” entries relate to each MOUNT_POINT. 

After manually updating /a/etc/vfstab return to the TBMR recovery application. 

Select “Settings / CBMR Progress Flags”. 

On the resulting form set the “Setup logical volume manager” flag to 1 then exit from the form with OK. 

(If this field or the OK/Cancel buttons are not displayed on the form use CTRL+N to get to the next page of the form). 

When you return to the top-level menu use the “Automatic Recovery” option to complete any tidying up. 

You should now get a message stating that the recovery is complete and you can use “Exit” to exit the application 

and re-boot. 

7.4) 7.4) Notes Notes on on recovering recovering client client machine machine with with networked networked storage 

storage 

When obtaining configuration information from the client machine TBMR makes entries in disrec.ini corresponding 

to each visible hard disk and for each partition with a mounted filesystem. 

In the case of networked storage (e.g SAN) these disks may not be available when the machine is being recovered. 

At the start of the recovery TBMR will examine the hardware available, may warn the user (If there are still enough 

partitions to mount all the required filesystems) or may report an error and be unable carry out an Automatic 

recovery. 

7.4.1) 7.4.1) 7.4.1) TBMR TBMR TBMR Configu Configuration 

Configu ration 

Even if there are enough partitions to cope with all the mountpoints from the original system this may result in the 

filesystems being mounted in the “wrong” place. I.e filesystems from the original networked storage may be 

mounted on “spare” partitions on internal hard disks. 

To avoid this situation the configuration files for such a machine should be saved to network share or to floppy disk, 

then edited manually using vi or any similar text editor. Before making any changes to disrec.ini it is probably worth 

taking a copy of the file so that any changes can be undone if required. 

Firstly the sections relating to mount points on networked disks need to be removed. These sections can be 

identified by the section header [MOUNT_POINT_X], where X is the mount point number, and the MOUNT_POINT 

field is set to a filesystem that we will exclude from the recovery. 

(Make careful note of the SLICE field for any sections removed, this will identify which HARD_DISK sections need to 

be removed below). 

Once the unneeded MOUNT_POINT_X sections have been removed then any remaining sections need to be 

renumbered to form a consecutive list . 

Next the hard disk and partition sections in the INI file relating to the above MOUNT_POINT sections need to be 

removed. These sections can be identified by the section header [HARD_DISK_X], where X is the hard disk number, 

and the field DEVICE_NODE corresponds to the SLICE entry of a MOUNT_POINT removed above. 

After removing section [HARD_DISK_X] the sections [PARTITION_X_N] that follow it need to be removed, once again X 

is the hard disk number and N is the number of each partition in turn. 

There is no need to re-number any remaining hard disk or partition sections. 

7.4.2) 7.4.2) Disrec.ini Disrec.ini Sample 

Sample 

Below is an example of a disrec.ini file modified to exclude networked drives… 

Lines to be deleted are shown in RED, changed entries shown in Blue. 

;INI File for Cristie CBMR 

[JS_CLIENT] 

OS_VER="5.9" 

PLATFORM="SUNW,Ultra-30" 

MACHINE="sun4u" 

CBMR="2.01-5" 

HOSTNAME="U30-9" 

VOL_MGR="SVM" 

HardDiskCount="3" 

VTOC_DIR="configs/U30-9" 

UBX_DIR="configs/U30-9/ubax" 

[JS_SERVER] 

Page 20 of 23


SRVR_HOSTNAME="" 

SRVR_IP_ADD="" 

SRVR_BMR_ROOT="/etc/cristie/cbmr_test" 

SRVR_MNT_PT="/etc/cristie/cbmr_test" 

LOCAL="Y" 

[MOUNT_POINT_0] 

MOUNT_POINT="/" 

FS_TYPE="ufs" 

OPTIONS="rw,intr,largefiles,onerror=panic,suid,dev=1540000" 

SLICE="c0t0d0s0" 


MOUNT_POINT="/export/home" 

FS_TYPE="ufs" 

OPTIONS="rw,intr,largefiles,onerror=panic,suid,dev=800006" 


; The following lines should be deleted 


MOUNT_POINT="/user_data1" 

FS_TYPE="ufs" 

OPTIONS="rw,intr,largefiles,logging,xattr,onerror=panic,suid,dev=3dc0008" 




FS_TYPE="ufs" 

OPTIONS="rw,intr,largefiles,logging,xattr,onerror=panic,suid,dev=3dc0009" 



MOUNT_POINT="/app_data1" 

FS_TYPE="ufs" 

OPTIONS="rw,intr,largefiles,logging,xattr,onerror=panic,suid,dev=3dc000b" 



; Was originally [MOUNT_POINT_5] 

MOUNT_POINT="/export/home0" 

FS_TYPE="ufs" 

OPTIONS="rw,intr,largefiles,onerror=panic,suid,dev=80000d" 


[HARD_DISK_0] 

VTOC_FILE="dsk_vtoc_0" 

SECTORS="248" 

SECT_PER_CYL="4712" 

CYLINDERS="7506" 

BYTES_PER_SECTOR="512" 

DEVICE_NODE="c0t0d0" 

PartitionCount="5" 

[PARTITION_0_0] 

PARTITION_TAG="2" 

PARTITION_FLAGS="00" 

START_SECTOR="4433992" 

NUMBER_OF_SECTORS="10309856" 

ENDING_SECTOR="14743847" 

MOUNT_POINT="/" 

MOUNT_TYPE="ufs" 

MOUNT_OPTIONS="rw,intr,largefiles,onerror=panic,suid,dev=1540000" 

PARTITION_NUMBER="0" 















Page 21 of 23








MOUNT_POINT="/export/home" 


MOUNT_OPTIONS="rw,intr,largefiles,onerror=panic,suid,dev=800006" 









[HARD_DISK_1] 


SECTORS="248" 



















MOUNT_POINT="/export/home0" 


MOUNT_OPTIONS="rw,intr,largefiles,onerror=panic,suid,dev=80000d" 









; The following lines should be deleted 

[HARD_DISK_2] 


SECTORS="96" 














MOUNT_OPTIONS="rw,intr,largefiles,logging,xattr,onerror=panic,suid,dev=3dc0008" 



Page 22 of 23









MOUNT_OPTIONS="rw,intr,largefiles,logging,xattr,onerror=panic,suid,dev=3dc0009" 















MOUNT_POINT="/app_data1" 


MOUNT_OPTIONS="rw,intr,largefiles,logging,xattr,onerror=panic,suid,dev=3dc000b" 


The above process can also be use (with extreme care) to recover onto a system having fewer hard disks than the 

original TBMR client. 

7.5) 7.5) Notes Notes on on Log Files 

7.5.1) Setting Log Levels 

If problems are experienced during the TBMR recovery it will be necessary to examine the log files in order to isolate 

the problem. The number of logging messages generated by TBMR can be changed by the user to provide more 

information at a cost of lower performance. 

To set the log levels select the “Settings” option from the top-level menu. 

Select the “CBMR Parameters” option from the next sub-menu. 

On the resulting form set the CBMR log level to the desired level (Default = 3). 

0 – no logging, 7 – maximum, lots of messages least performance. 

If the TBMR process is having problems during the file restoration phase then it may be useful to increase the 

UBax log level (0 – no logging, 5 – Maximum). Note that if UBax log level is set to 4 or 5 then all paths and filenames 

will be displayed and logged as the restore proceeds. This will have a serious effect on the recovery performance. 

7.5.2) Saving Log Files 

At any point in the recovery, if the user has access to the top-level menu, the log files generated by TBMR can be 

copied to a shared directory on the network, or to a floppy disk. (See Section 5 above). 

In the case of serious problems where the system crashes and does not return to either the TBMR Recovery 

application or the shell it may be necessary to write the log files directly to network share. 

In this case it will be necessary to restart the TBMR recovery then, as soon as the TBMR Recovery application starts, 

select the “Shell” option from the top-level menu. 

Mount a network share on /cbmr. 

Create a directory /cbmr/cbmr_logs. 

Return to the TBMR Recovery application (CTRL+D). 

Select the Settings / CBMR Parameters menu item. 

Set the “Working Directory”field on the form to /cbmr/cbmr_logs/. 

Set the CBMR log_level and UBax log_level as appropriate. 

Exit the form with OK. 

If the OK button or any of the fields on the form are not visible then use CTRL+N to display the next page of the form. 

Return to the top-level menu and continue with the recovery attempt. 

Page 23 of 23

TBMR for Solaris Version 2.12 SPARC Platform Step-By-Step Guide

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?