For securing consistency of backup target files, boot the system from a CD-ROM device (or network) or boot the system in single user mode to create backups. To ensure consistency, it is recommended to boot from a CD-ROM device (or network).
a) When booting the system from a CD-ROM device (or the network) and creating backups
a1) If there is a possibility of write access to backup target slices during backup, temporarily unmirror backup target disks.
For example, if the fsck(1M) command is used for a backup target file system, the command may write data to the backup target slices. Additionally, if a file system where ufs logging is on is backed up with the ufsdump(1M) command, the command writes data to the backup target slices. In these situations, it is necessary to unmirror the disks temporarily using this procedure in advance.
The command line shown below is an example of disconnecting disk Root2 from group Group1 for backing up Root1 in a situation where disks Root1 and Root2 are connected to Group1 and mirrored.
# sdxdisk -D -c System -g Group1 -d Root2 |
Confirm that only one disk is connected to group Group1 (Group1 is indicated in the GROUP field of only one disk).
# sdxinfo -D -c System |
Information
If disk Root1 has an INVALID slice, disconnect the Root1.
If a keep disk is disconnected (if the disconnected disk's TYPE field value is keep in the sdxinfo -D command output), change the type attribute to undef to keep its connectibility to a group (or remove the disk from the class once and register it again as an undef disk). For the disk type attribute setting method, see "Changing the Disk Attributes" of "5.4.1 Class Configuration" or "D.7 sdxattr - Set objects attributes."
Example) Changing the type attribute of Root1 to undef after keep disk Root1 is disconnected from Group1
# sdxattr -D -c System -d Root1 -a type=undef |
See
When using GDS Management View, see "5.4.2 Group Configuration" of "5.4 Changes."
For the fsck(1M) command, ufs logging, and the ufsdump(1M) command, see the Solaris manual.
Note
If this procedure is not performed and data is written in backup target slices in the following procedures, the synchronized status of backup target volumes is not ensured. In this situation, using the procedure described in "6.3.3 Restoring (When the System Cannot Be Booted)," restore the backup target volumes.
a2) Acquire the target-port parameter of the physical disk to be backed up.
If the disk to be backed up is the disk of Expansion File Unit that is connected to 6 Gbps SAS card or internal disk of SPARC M12/M10, SPARC T4-4/T4-2/T4-1/T3-4/T3-2/T3-1, check the target-port parameter of the physical disk and make note of them.
For other disks, this procedure is not necessary.
# prtconf -v /dev/rdsk/c5t5000039488225F20d0s2 disk, instance #2 Driver properties: ... Hardware properties: ... Paths from multipath bus adapters: ... name='target-port' type=string items=1 value='5000039488225f22' ... |
a3) When using the shared class or local class, set the GDS configuration parameter.
Add the setting of SDX_DB_FAIL_NUM=0 to the end of /etc/opt/FJSVsdx/sdx.cf configuration file.
# vi /etc/opt/FJSVsdx/sdx.cf
...
SDX_DB_FAIL_NUM=0 <- Added |
The reason to perform this setting is to prevent the shared/local class from closing down after restoring even though the shared/local class configuration database layout differs from backing up to restoring the system disk.
a4) Shut down the system.
# shutdown -g0 -i0 -y |
a5) Boot the system from a CD-ROM device (or the network).
For the procedure, see the Solaris manual.
Note
The version of an OS booted from a CD-ROM device (or the network) must correspond to the version of the OS you are backing up.
In a system where the disks are mirrored by GDS, if the system is booted from a CD-ROM device (or the network) and operations are performed improperly, the mirroring status may collapse. Be sure to perform operations according to the procedures described here. Operations other than those described here should not be performed.
When mounting the file system on a physical slice at the time of recovery, mounting as read-only is required. If the slice is mounted without the read-only option on, it can be written in and thus the mirrored state may be ruined.
a6) Check the physical slice names of the root (/), /usr, and /var file systems you want to back up and make a note of them.
# eeprom nvramrc | grep sdx-root-slice
devalias sdx-root-slice-1 /devices/pci@1f,4000/scsi@3/sd@0,0:a,raw
devalias sdx-root-slice-2 /devices/pci@1e,4000/scsi@3/sd@0,0:a,raw# eeprom nvramrc | grep sdx-usr-slice
devalias sdx-usr-slice-1 /devices/pci@1f,4000/scsi@3/sd@0,0:g,raw
devalias sdx-usr-slice-2 /devices/pci@1e,4000/scsi@3/sd@0,0:g,raw# eeprom nvramrc | grep sdx-var-slice
devalias sdx-var-slice-1 /devices/pci@1f,4000/scsi@3/sd@0,0:b,raw
devalias sdx-var-slice-2 /devices/pci@1e,4000/scsi@3/sd@0,0:b,raw |
In this example, the original physical slice names are:
/ : /devices/pci@1f,4000/scsi@3/sd@0,0:a,raw
/usr : /devices/pci@1f,4000/scsi@3/sd@0,0:g,raw
/var : /devices/pci@1f,4000/scsi@3/sd@0,0:b,raw
The mirror physical slice names are:
/ : /devices/pci@1e,4000/scsi@3/sd@0,0:a,raw
/usr : /devices/pci@1e,4000/scsi@3/sd@0,0:g,raw
/var : /devices/pci@1e,4000/scsi@3/sd@0,0:b,raw
Information
If step a1) is performed, the mirror physical slice names are not given.
If /usr and /var file systems do not exist, the physical slice names are not displayed as shown below.
# eeprom nvramrc | grep sdx-usr-slice # eeprom nvramrc | grep sdx-var-slice |
For MPLB disks, check the physical slice names of paths after the first one as follows. In an environment booted from the network, if paths after the first one are defined, it is also possible to create backups from the physical slices of the paths.
# eeprom nvramrc | grep sdx-root-slice (First path)
devalias sdx-root-slice-1 /devices/pci@1f,4000/fibre-channel@4/sd@10,0:a,raw
...# eeprom nvramrc | grep sdx-root-alt-slice (Second path)
devalias sdx-root-alt-slice-1b /devices/pci@1f,4000/fibre-channel@5/sd@10,0:a,raw
... |
a7) Identify the name of the physical slice to be backed up.
The following procedure is an example of checking the original physical slice name of root (/).
The procedure on obtaining the name of the physical slice to be backed up differs between the disk of Expansion File Unit that is connected to 6 Gbps SAS card or internal disk of SPARC M12/M10, SPARC T4-4/T4-2/T4-1/T3-4/T3-2/T3-1 and other cases.
[Disk of Expansion File Unit that is connected to 6 Gbps SAS card or internal disk of SPARC M12/M10, SPARC T4-4/T4-2/T4-1/T3-4/T3-2/T3-1]
Identify the name of the physical disk whose device name includes the target-port acquired in step a2).
# format </dev/null | grep -i t5000039488225f22d |
For the argument of the grep command, specify "t" + <target-port> + "d."
In this example, the physical disk name to be backed up is c0t5000039488225F22d0.
Check the physical slice name from the physical disk name.
# ls -l /dev/rdsk/c0t5000039488225F22d0* | grep ":a,raw" |
For the argument of the grep command, specify the part after ":" of the device name confirmed in step a6).
In this example, the main physical slice name of the root (/) is c0t5000039488225F22d0s0.
[Other than the above]
Check the physical slice name from the device name of physical slice confirmed in step a6).
# ls -l /dev/rdsk | grep /devices/pci@1f,4000/scsi@3/sd@0,0:a,raw
lrwxrwxrwx 1 root root 45 Oct 19 23:36 c0t0d0s0 -> ../../devices/pci@1f,4000/scsi@3/sd@0,0:a,raw |
For the argument of the grep command, specify the device name confirmed in step a6).
In this example, the main physical slice name of the root (/) is c0t0d0s0.
a8) Create a backup of file system data in a tape medium.
The command line shown below is an example of one used to back up root file system data to a tape medium of tape device /dev/rmt/0 using the ufsdump(1M) command when the root file system type is ufs.
# ufsdump 0cf /dev/rmt/0 /dev/rdsk/c0t0d0s0 |
See
For details on the ufsdump(1M) command, see the Solaris manual. After understanding the usage and the meaning of options, specify options properly.
a9) Reboot the system.
# reboot |
Note
If the system is booted from an emergency startup disk for restoration, reboot the system using the shutdown(1M) command.
a10) When using the shared class or local class, undo the GDS configuration parameter.
Comment out the line of SDX_DB_FAIL_NUM=0 in the /etc/opt/FJSVsdx/sdx.cf configuration file.
# vi /etc/opt/FJSVsdx/sdx.cf |
See
If step a1) is not performed and a file system where ufs logging is on is backed up with the ufsdump(1M) command, the synchronized status of mirrors may collapse and it may be impossible to start the OS. After this kind of operation, be sure to restore the relevant file system. For the restore method, see "6.3.2 Restoring (When the System Can Be Booted)" and "6.3.3 Restoring (When the System Cannot Be Booted)."
a11) When step a1) was performed, reconnect the disk disconnected in that step to the group.
# sdxdisk -C -c System -g Group1 -d Root2 |
Confirm that disk Root2 is connected to group Group1 (Group1 is indicated in the GROUP field of the Root2 line).
# sdxinfo -D -c System |
Synchronization copying will automatically take place, and when it is completed, the mirroring status is restored.
See
When using GDS Management View, see "5.4.2 Group Configuration" of "5.4 Changes."
Information
If a keep disk is disconnected from the group in step a1) and if the type attribute is not changed to undef, step a11) will result in an error and the error message "keep disk cannot be connected to existing group" will be output. In this event, change the disk's type attribute to undef first and retry step a11).
For the disk type attribute setting method, see "Information" in step a1).
b) When booting the system in single user mode and creating backups
b1) Exit all running application programs.
b2) Shut down the system.
# shutdown -g0 -i0 -y |
b3) Boot the system in single-user mode.
ok boot -s |
b4) When using the shared class or local class, set the GDS configuration parameter.
Add the setting of SDX_DB_FAIL_NUM=0 to the end of /etc/opt/FJSVsdx/sdx.cf configuration file.
# vi /etc/opt/FJSVsdx/sdx.cf
...
SDX_DB_FAIL_NUM=0 <- Added |
The reason to perform this setting is to prevent the shared/local class from closing down after restoring even though the shared/local class configuration database layout differs from backing up to restoring the system disk.
b5) Check the volume of the file system to be backed up.
The following example shows the procedure for backing up the root (/) file system.
# mount |
In this example, the device special file for the volume of the root (/) file system is /dev/sfdsk/System/dsk/root Volume.
b6) Back up data of the file system to a tape medium.
The following example shows the procedure for backing up data to a tape medium of tape device /dev/rmt/0 with the ufsdump(1M) command.
# ufsdump 0ucf /dev/rmt/0 /dev/sfdsk/System/rdsk/root |
For the ufsdump command's argument, specify the device special file of the volume displayed in step b5).
See
For details on the ufsdump(1M) command, see the Solaris manual. After understanding the usage and the meaning of options, specify options properly.
b7) When using the shared class or local class, undo the GDS configuration parameter.
Comment out the line of SDX_DB_FAIL_NUM=0 in the /etc/opt/FJSVsdx/sdx.cf configuration file.
# vi /etc/opt/FJSVsdx/sdx.cf ... # SDX_DB_FAIL_NUM=0 |
b8) Reboot the system.
# reboot |
Note
If the system is booted from an emergency startup disk for restoration, reboot the system using the shutdown(1M) command.
