6 Backing Up the Configuration and File Systems

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:

Backing Up File Systems
Backing Up the Oracle HSM Configuration
Gathering Configuration and Diagnostic Information with samexplorer.

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.

Backing Up File Systems

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:

Create a Recovery Point on Demand
Back Up the Archiver Log
Gathering Configuration and Diagnostic Information with samexplorer
Manually Backup the Oracle HSM Configuration.

Understanding Recovery Points and Archive Logs

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:

Create a Recovery Point on Demand
Back Up the Archiver Log.

Create a Recovery Point on Demand

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.

Back Up the Archiver Log

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.

Backing Up 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:

Manually Backup the Oracle HSM Configuration
Run samexplorer and safely store the output.

Manually Backup the Oracle HSM Configuration

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 file
     family-set-name            # SAM-Remote client configuration file
     network-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.

Gathering Configuration and Diagnostic Information with `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:

Run `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.YYYYMMDD.hhmmz.tar.gz, where path is the path to the chosen directory, hostname is the name of the Oracle HSM file system host, and YYYYMMDD.hhmmz is a date and time stamp.

The default file name is /tmp/SAMreport.hostname.YYYYMMDD.hhmmz.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.