Oracle® Hierarchical Storage Manager and StorageTek QFS Software Maintenance and Administration Guide Release 6.0 E42064-03 |
|
Previous |
Next |
When you installed and configured Oracle Hierarchical Storage Manager and StorageTek QFS Software, you created secure locations for storing recovery point files and copies of the archiver log. You also configured automated processes for creating recovery points, backing up the logs, and protecting the system configuration. These steps provide the core protection for your file systems. But you may also need to take unscheduled protective measures from time to time as well:
Back up the Oracle HSM configuration and file systems prior to anticipated, potentially disruptive events, such as major changes to physical infrastructure or data center facilities.
Back up the Oracle HSM configuration and file systems after upgrading or reconfiguring software, operating systems, or host platforms, so that the current configuration is protected.
Gather required configuration and status information prior to engaging Oracle HSM support services.
This chapter outlines the procedures for collecting, creating, and storing configuration and file-system recovery files on an as-needed basis. It contains three major sections:
Note that this chapter uses the command line interface for all tasks. If you wish to use the Oracle HSM Manager graphical user interface, refer to the online help for detailed procedures.
This section starts with a brief review of Oracle HSM file system protection, "Understanding Recovery Points and Archive Logs". Then it provides procedures for carrying out the following tasks:
To protect a file system, you need to do two things:
You must protect the files that hold your data.
You must protect the file system itself, so that you can use, organize, locate, access, and manage your data.
In an Oracle HSM archiving file system, file data is automatically protected by the archiver: modified files are automatically copied to archival storage media, such as tape. But if you backed up only your files and then suffered an unrecoverable failure in a disk device or RAID group, you would have the data but no easy way to use it. You would have to create a substitute file system, identify each file, determine its proper location within the new file system, ingest it, and recreate lost relationships between it and users, applications, and other files. This kind of recovery is, at best, a daunting and long drawn-out process.
So, for fast, efficient recovery, you have to actively protect the file-system metadata that make files and archive copies usable. You must back up directory paths, inodes, access controls, symbolic links, and pointers to copies archived on removable media.
You protect Oracle HSM file-system metadata by scheduling recovery points and saving archive logs. A recovery point is a compressed file that stores a point-in-time backup copy of the metadata for an Oracle HSM file system. In the event of a data loss—anything from accidental deletion of a user file to catastrophic loss of a whole file system—you can recover to the last known-good state of the file or file system almost immediately by locating the last recovery point at which the file or file system remained intact. You then restore the metadata recorded at that time and either stage the files indicated in the metadata to the disk cache from archival media or, preferably, let the file system stage files on demand, as users and applications access them.
Like any point-in-time backup copy, a recovery point is seldom a complete record of the state of the file system at the time when a failure occurs. Inevitably, at least a few files are created and changed after one recovery point is completed and before the next one is created. You can—and should—minimize this problem by scheduling creation of recovery points frequently and at times when the file system is not in use. But, in practice, scheduling has to be a compromise, because the file system exists to be used.
For this reason, you must also save point-in-time copies of the archiver log file. As each data file is archived, the log file records the volume serial number of the archival media, the archive set and copy number, the position of the archive (tar
) file on the media, and the path to and name of the data file within the tar
file. With this information, you can recover any files that are missing from the recovery point using Solaris or Oracle HSM tar
utilities. However, this information is volatile. Like most system logs, the archiver log grows rapidly and must thus be overwritten frequently. If you do not make regular copies to compliment your recovery points, you will not have log information when you need it.
The remainder of this section provides instructions for creating recovery points and log copies on demand. It contains the following subsections:
Sometimes you may need to capture the metadata from an archiving file system at a point in time outside your normal schedule. Whenever you anticipate potentially disruptive system or facilities maintenance, for example, you can create before and after recovery points to make sure that file systems are protected.
To initiate creation of an unscheduled, on-demand recovery point on demand, proceed as follows:
Log in to the Oracle HSM server host as root
.
root@solaris:~#
Select an independent location where the recovery point will be stored.
In the example, we create a subdirectory, unscheduled/
, under the directory that we created for recovery points when we initially configured file systems. The /zfs1
file system is remotely located and has no components in common with the Oracle HSM file system:
root@solaris:~# mkdir /zfs1/samqfs_recovery/unscheduled
root@solaris:~#
Change to the file system's root directory.
In the example, we change to the mount-point directory /samqfs
:
root@solaris:~# cd /samqfs
root@solaris:~#
If you are backing up an archiving file system where the data is copied to removable media, back up the metadata only. Use the command samfsdump
-f
recovery-point
, where recovery-point
is the path and file name of the finished recovery point file.
See the samfsdump
man page for additional details. In the example, we create an unscheduled recovery point for the samqfs
file system prior to a scheduled, maintenance-related power outage. We create the recovery-point file 20150315pre-outage
in the directory /zfs1/samqfs_recovery/unscheduled/
(note that the second command below is entered as a single line—the line break is escaped by the backslash character):
root@solaris:~#cd /samqfs
root@solaris:~#samfsdump -f
\/zfs1/samqfs_recovery/unscheduled/20150315pre-outage
root@solaris:~#
If you are backing up a standalone file system where data is not copied to removable media, back up both the metadata and the data. Use the command samfsdump
-U
-f
recovery-point
, where recovery-point
is the path and file name of the finished recovery point file.
Note that recovery-point files that include data as well as metadata can be extremely large. See the samfsdump
man page for additional details. In the example, we create an unscheduled recovery point for the samqfs
file system. We create the recovery-point file 20150315pre-outage
in the remote directory /zfs1/samqfs_recovery/unscheduled/
(note that the second command below is entered as a single line—the line break is escaped by the backslash character):
root@solaris:~#cd /samqfs
root@solaris:~#samfsdump -f
-U
\/zfs1/samqfs_recovery/unscheduled/20150315pre-outage
root@solaris:~#
If you are backing up an archiving file system, Back Up the Archiver Log.
Otherwise, depending on the situation, you may also want to Run samexplorer
(see Gathering Configuration and Diagnostic Information with samexplorer
) and Manually Backup the Oracle HSM Configuration.
While recovery point files contain almost all of the information needed when restoring a file system, they do not hold the metadata for files created or modified after the recovery point was created. Because archiver logs list all of the files that have been archived and their locations on cartridges, archiver logs can be used to recover any files that were archived after the creation of the recovery point. So, if possible, create an unscheduled copy of the archiver log file whenever you create an unscheduled recovery point. Proceed as follows.
Log in to the Oracle HSM server host as root
.
root@solaris:~#
Select an independent location where the backed up archiver log will be stored.
In the example, we decide to store the log in the same directory as the corresponding unscheduled recovery point that we created above. The /zfs1
file system is remotely located and has no components in common with the Oracle HSM file system:
root@solaris:~#ls
/zfs1/samqfs_recovery/unscheduled
20150315pre-outage root@solaris:~#
Copy the current archiver log to the chosen location and give it a unique name. Use the command cp /var/adm/samqfs.archive.log
path
/"date +%y%m%d";
, where path
is the path to the chosen location.
Note that the command below is entered as a single line—the line break is escaped by the backslash character:
root@solaris:~#cp
/var/adm/samqfs.archive.log
\/zfs1/samqfs_recovery/unscheduled/20150315pre-outage/"date +%y%m%d".archive.log
root@solaris:~#
Depending on the situation, you may also want to Run samexplorer
(see Gathering Configuration and Diagnostic Information with samexplorer
) and Manually Backup the Oracle HSM Configuration.
Whenever you change the Oracle HSM configuration, protect your investment by backing up all modified configuration files and related information. Carry out the following tasks:
Run samexplorer
and safely store the output.
For full redundancy, create a local copy of the configuration files whenever you make significant changes to software, operating systems, or hosts. Proceed as follows:
Log in to the file-system host as root
.
root@solaris:~#
In the subdirectory that holds your backup configuration information, create a subdirectory for manual backup copies of your Oracle HSM configuration. Use the command mkdir
mount-point
/
path
, where mount-point
is the mount point directory for the selected independent file system and path
is the path and name of the chosen directory.
In the example, we are configuring recovery points for the archiving file system /samqfs
. So we have created the directory /zfs1/sam_config/samconfig
:
root@solaris:~# mkdir /zfs1/sam_config/samconfig
In the subdirectory that holds manual backup copies of your Oracle HSM configuration, create a subdirectory for the current Oracle HSM configuration. Use the command mkdir
mount-point
/
path
/
subdirectory
, where mount-point
is the mount point for the selected independent file system and path
/
subdirectory
is the path and name of the chosen subdirectory.
In the example, we create a subdirectory in the directory that we created for this purpose during initial configuration, /zfs1/sam_config/samconfig
. We use the date to name the subdirectory:
root@solaris:~# mkdir /zfs1/sam_config/samconfig/20150315
Copy the configuration files to another file system.
/etc/opt/SUNWsamfs/ mcf archiver.cmd defaults.conf diskvols.conf hosts.family-set-name
hosts.family-set-name
.local preview.cmd recycler.cmd releaser.cmd rft.cmd samfs.cmd stager.cmd inquiry.conf samremote # SAM-Remote server configuration filefamily-set-name
# SAM-Remote client configuration filenetwork-attached-library
# Parameters file scripts/* # Back up all locally modified files /var/opt/SUNWsamfs/
Back up all library catalog data, including that maintained by the historian. For each catalog, use the command /opt/SUNWsamfs/sbin/dump_cat -V
catalog-file
, where catalog-file
is the path and name of the catalog file. Redirect the output to dump-file
, in a new location.
In the example, we dump the catalog data for library1
to the file library1cat.dump
in a directory on the independent NFS-mounted file system zfs1
(note that the command below is entered as a single line—the line break is escaped by the backslash character):
root@solaris:~#dump_cat -V
/var/opt/SUNWsamfs/catalog/library1cat
>
\/zfs1/sam_config/20150315/catalogs/
library1cat.dump
Copy system configuration files that were modified during Oracle HSM installation and configuration. These may include:
/etc/ syslog.conf system vfstab /kernel/drv/ sgen.conf samst.conf samrd.conf sd.conf ssd.conf st.conf /usr/kernel/drv/dst.conf
Copy any custom shell scripts and crontab
entries that you created as part of the Oracle HSM configuration to the selected subdirectory.
For example, if you created a crontab
entry to manage creation of recovery points, you would save a copy now.
Copy any custom shell scripts and crontab
entries that you created as part of the Oracle HSM configuration to the selected subdirectory.
For example, if you created a crontab
entry to manage creation of recovery points, you would save a copy now.
Record the revision level of the currently installed software, including Oracle HSM, Solaris, and Solaris Cluster (if applicable), and save a copy of the information in a readme
file in the chosen subdirectory.
In the chosen subdirectory, save copies of downloaded Oracle HSM Oracle HSM, Solaris, and Solaris Cluster packages so that you can restore the software quickly, should it become necessary.
Next, Run samexplorer
.
samexplorer
The samexplorer
is a diagnostic tool that captures and reports comprehensive configuration and status information for the Oracle HSM software and file systems. Whenever you make changes to your Oracle HSM configuration, you should run samexplorer
and store the resulting report with your backup copies of the configuration files. You should also run samexplorer
when you are troubleshooting a problem and whenever you are requested to do so by Oracle HSM support services personnel. Proceed as follows:
samexplorer
Log in to the file-system host as root
.
In the directory that holds your backup configuration information, create a subdirectory for samexplorer
reports. Use the command mkdir
mount-point
/
path
, where mount-point
is the mount point directory for the selected independent file system and path
is the path and name of the chosen directory.
In the example, we create the new subdirectory in the directory that we created for this purpose during initial configuration, /zfs1/sam_config/
. We name the new subdirectory explorer/
:
root@solaris:~# mkdir /zfs1/sam_config/explorer
Create the samexplorer
report in the selected directory. Use the command samexplorer
path
/
hostname
.
YYYY
MM
DD
.
hh
mm
z
.
tar.gz
, where path
is the path to the chosen directory, hostname
is the name of the Oracle HSM file system host, and YYYY
MM
DD
.
hh
mm
z
is a date and time stamp.
The default file name is /tmp/SAMreport.
hostname
.
YYYY
MM
DD
.
hh
mm
z
.tar.gz
. In the example, we create a report for the host samhost1
dated March 15, 2015, at 4:59 PM Mountain time (note that the command below is entered as a single line—the line break is escaped by the backslash character):
root@solaris:~#samexplorer
\/zfs1/sam_config/explorer/
samhost1
.20150315.1659MST.tar.gz
Report name: /zfs1/sam_config/explorer/samhost1.20150315.1659MST.tar.gz Lines per file: 1000 Output format: tar.gz (default) Use -u for unarchived/uncompressed. Please wait............................................. Please wait............................................. Please wait...................................... The following files should now be ftp'ed to your support provider as ftp type binary. /zfs1/sam_config/explorer/samhost1.20150315.1659MST.tar.gz
Repeat this procedure whenever you significantly reconfigure your file systems.
Stop here. The Oracle HSM configuration is backed up.