This content is submitted by a BigAdmin user. It has not been reviewed for technical accuracy by Sun Microsystems, though it may have been lightly edited to improve readability. If you find an error or would like to comment on the article, please contact the submitter or use the comment field at the bottom of the article.
Community submissions may not follow Sun trademark guidelines. For information on Sun trademarks, please see http://www.sun.com/suntrademarks/.
Disaster Recovery Plan for Sun Servers Using VERITAS
By Joel Andrews
Purpose
This plan is designed to provide a general outline of how to recover like systems in the event of a disaster. This document can also be followed within the confines of a disaster recovery test. The plan is for systems using VERITAS Volume Manager and VERITAS File System.
The following two methods are supported by VERITAS with regards to restoration of Sun servers. This plan is based on the Sun systems being Sun Fire V880 servers.
Method 2: UFS Dump/Restore
This article recommends Method 2 and will focus solely on this method.
UFS Dump
The best method is to back up the root (/) file system to a file. Here is the procedure:
On the boot disk, UFSDUMP the root file system to a file:
# ufsdump 0uf /export/backups/root.backup /
Once the backup (ufsdump) is complete, VERITAS NetBackup then backs up the dump file (root.backup). At the appointed time, VERITAS NetBackup will restore the dump file (root.backup) to the assigned machine.
Note: It is assumed that the dump file is restored to the root disk (primary boot disk).
Before restoring (ufsrestore), place the dump file on a secondary disk within the system, following these steps:
Format the secondary disk in preparation to receive the dump file (root.backup).
Create file system for root (s0) on the secondary disk.
# newfs /dev/rdsk/<Secondary Disk>
Note: This procedure will destroy any data on this file system.
Example:
# newfs /dev/rdsk/c1t0d0s0
Mount the newly created root file system on the secondary disk (/mnt by default).
# mount /dev/dsk/<Secondary Disk> /mnt
Example:
# mount /dev/dsk/c1t0d0s0 /mnt
Place the dump file (root.backup) on the secondary disk within the newly mounted root file system (/mnt).
Note: Verify that the /mnt file system is mounted via the df -k command. Also, once the dump file is on the secondary disk within /mnt, verify file size and type.
# cp <Dump File> /mnt
Example:
# cp root.backup /mnt
Next you'll prepare the boot disk for the restore procedure.
Place the system into single-user mode via the OS media (CD-ROM).
# (From The [ok] prompt) boot cdrom -s
Create new root file system on boot disk and then mount said file system on /a.
# newfs /dev/rdsk/<Boot Disk>
Note: This procedure will destroy a data on this file system.
# mount /dev/dsk/<Boot Disk> /a
Example[s]:
# newfs /dev/rdsk/c0t0d0s0
# mount /dev/dsk/c0t0d0s0 /a
Mount the /mnt file system containing the dump file (root.backup) on the secondary disk.
# mount /dev/dsk/<Secondary Disk> /mnt
Example:
# mount /dev/dsk/c1t0d0s0 /mnt
Note: Verify that the /mnt and /a file systems are mounted via the df -k command.
UFS Restore
Change directories to /a and begin restore procedures from the dump file (root.backup) residing within /mnt on the secondary disk.
# cd /a
# ufsrestore rf /mnt/root.backup
Once the restore is complete, you will have to manually un-encapsulate the restored boot disk.
Note: Before you proceed with the un-encapsulation, manually reconfigure the system to not respond to IPMP Multipathing daemon. To do this, remove the file /a/etc/hostname.eri0. Also, edit the file /a/etc/hostname.ge0 placing only the IP Address of the ge0 interface in the file.
Once the preceding procedure is complete, continue with the manual un-encapsulation.
Important Note: Follow the steps as shown here.
Step 1: Manual Un-Encapsulation
With /a still mounted, manually un-encapsulate the boot disk:
Make a copy of the vfstab:
cp -p vfstab vfstab.bak.<date>
Copy the file vfstab.prevm to the vfstab. Note: Edit the newly copied vfstab to reflect the new disk name (c#t#d#).
Make a copy of the system file.
Vi system and comment out the following two lines (using *):
*rootdev:/pseudo/vxio@0:0
*set vxio:vol_rootdev_is_volume=1
Next:
# touch /a/etc/vx/reconfig.d/state.d/install-db
Step 2: Reboot
Important Note: Read this before rebooting. If you have a mismatch in hardware (for example, you are restoring from a Sun Fire V880 server to a Sun Enterprise 420R), it will be necessary to rebuild the /etc/path_to_inst file along with the /dev/rdsk,dsk and rmt directories.
In case of a hardware mismatch, use one of the two methods that follow:
Accept the default for all questions except the path_to_inst file.
When you get to that one, specify /dev/null.
It should then prompt you if you want to create a new /etc/path_to_inst file from scratch. Say yes.
Run vxinstall to encapsulate the boot disk.
Note: If the disk destined to be the root mirror is the same size as the boot disk, do the following: Once the boot disk is encapsulated, do not initialize the disk to be used as the root mirror. Use the procedures outlined in BigAdmin Tech
Tip VERITAS Disk Setup.
The information and links on this page have been provided by a BigAdmin
user. The submitter is solely responsible for such information and
links. Sun is not responsible for the availability of external sites or
resources, and does not endorse and is not responsible or liable for any
content, advertising, products, or other materials on or available from
such sites or resources. Sun will not be responsible or liable, directly
or indirectly, for any actual or alleged damage or loss caused by or in
connection with use of or reliance on the information posted here, or
goods or services available on or through any external site or
resource.
Print-friendly Version
