test

Solstice Backup 5.1 Administration Guide

New Backup Client Configuration

After you install the client software on the Backup client machine, you create a client resource on the Backup server that contains your configuration choices for each Backup client. These choices determine what data is backed up, according to which schedule, and whether additional features, such as archiving, are enabled.

How to Create a New Client

To create a new Backup client, display the Clients resource in either the Backup administration program (nwadmin) or the nsradmin interface. Select the Create option and enter the hostname of the client machine.

If you choose not to customize the configuration choices, the new Backup client is automatically assigned the default configuration, after you apply and save the changes. (See "Clients Resource " for more information about the default configuration for Backup clients.) The default setting of All for the Save Set attribute means that all the files on the client are backed up during a scheduled or manual backup. (See "What Is a Save Set? " for information about client save sets.)

Refer to the Backup online help for specific information about each of the attributes you can configure in the Clients resource. Refer to the nsradmin man page for more information on how to use the nsradmin interface to create, edit, and delete Backup resources.

Backup Clients of Different Platforms

The Backup server can back up clients from a variety of platforms. This section provides configuration tips for configuring clients to enable them to back up to the Backup server.

To use clients of a different operating system than that of your Backup server, you must purchase and enable the appropriate ClientPak. See "How Backup Enforces Client Licensing " for information about ClientPaks and how the Backup server checks each client before it allows backup to begin.

Support for 64-bit filesystems exists for clients that run Solaris 2.6, AIX 4.2, and HP-UX 10.20. You can archive, backup, browse, and recover files larger than two gigabytes for clients of Solaris 2.6, AIX 4.2, and HP-UX 10.20. If your clients are not 64-bit capable, you can browse files larger than 2 gigabytes, but you cannot recover them.

UNIX Clients

On all Backup clients for UNIX, you must manually update and verify the following files:


127.0.0.1 				localhost			loopback
137.69.8.1 				server			server.companyname.com
137.69.8.2 				client 			client.companyname.com

Backup does not automatically configure and update the /etc/hosts file. You must manually edit the file and verify that the information in this file is accurate. Do not delete or comment out the entry for the localhost loopback.

Windows NT Clients

On Backup clients for Windows NT, you must manually update and verify the following files:

Windows 95 Clients

On Windows 95 clients, you must manually edit and verify the following files accordingly:

NetWare Clients

On NetWare clients, you must manually update and verify the following files accordingly:

Macintosh Clients

A Macintosh client must meet the following requirements:

Storage Node Affinity

The link between a client resource and a list of storage nodes is called storage node affinity. You define storage node affinity in the Storage Nodes attribute in the Clients resource. The default setting for the Storage Nodes attribute on most Backup client resources is the Backup server. For the client resource of a storage node machine, the default setting of the Storage Nodes attribute is the storage node and the Backup server. You can add the names of other storage nodes to the list. The Backup server uses the list in the Storage Nodes attribute to determine which device writes the data from each savestream.

Caution - Caution -

When the server's index and the bootstrap save set are backed up, the data is always written to a device that is local to the Backup server. A bootstrap cannot be backed up to a remote device, but a bootstrap clone can be written to a remote device. If you use mmrecov to recover a bootstrap save set or the server's index, you must recover the data from a local device.

During backup, only the devices attached to the storage node machine in the Storage Nodes attribute list are considered to receive that client's data. You cannot specify a different list of storage nodes to be used for different operations, but you can add and remove storage node names from the Storage Nodes attribute in the Clients resource at any time.

If a backup fails with the following message, the problem is storage node affinity:


no matching devices; check storage nodes, devices or pools

Common storage node affinity problems include the following:

A common example is when the client only has one storage node in its affinity list and all devices on that storage node are disabled.

You must fix the problem and restart the backup. To fix the problem:

Specifying the Kind of Backup

Assign each Backup client to an existing schedule in the Schedule attribute of the Clients resource. Backup schedules define what level of backup Backup runs for each calendar day. If none of the existing schedules suit your needs, you can create a custom schedule in the Schedules resource. For more information on schedules, see "Schedule Configuration ".

Specifying When Backup Starts

Two attributes in the Clients resource, Group and Client Priority, determine what time a client's scheduled backup begins.

Backup Group

Backup groups determine what time the scheduled backup starts. For each client, in the Clients resource, you select one or more backup groups from the list of available backup groups in the Groups attribute. Use the Groups resource to create custom backup groups. For more information on backup groups, see "Backup Group Configuration ".

Client Priority

The Client Priority attribute in the Clients resource specifies the order in which participating clients are probed for the information needed to complete the save set worklist for that client. The Client Priority attribute can contain a value between 1 and 1000. The lower the value, the higher the priority.

The client with the lowest value for the Client Priority attribute is placed at the top of the list to be contacted by the Backup server. If you do not specify a value in the priority attribute, the contact order is random.

While the Client Priority attribute specifies the order of client contact, many variables affect the order in which clients complete their backups, including the following scenarios:

Specifying Which Data Is Backed Up

The Save Set attribute of the Clients resource specifies the data to be backed up for the client machine. You can specify more than one save set in the Clients resource. The Backup server starts a new instance of the client's save program for each save set you specify.

What Is a Save Set?

Save sets are groups of files from a single client machine to be backed up by Backup. A save set can include any of the following:

Use of Unique Client/Save Set Combinations

You can use one client license on a machine, but back up different portions of its data at different times. This is useful if a client has a large volume of data. You schedule the client machine backup as several, separate client/save set backups. When you redefine a large filesystem into multiple client/save set instances, you automatically back up a large client filesystem and balance the system load by avoiding a full backup of the entire filesystem at one time.

How to Create Client/Save Set Combinations

  1. Create a client in the Clients resource that specifies a portion of the client's data, for example, a single filesystem, in the Save Set attribute.

  2. Create another client in the Clients resource that uses the same client hostname but specifies a different portion of the client's data in the Save Set attribute.

    If you specify more than one save set, enter each save set on a separate line.

  3. Associate each client/save set instance with a different backup group to vary the start time of the backups.

  4. Associate each client/save set instance with a different schedule to specify that each client/save set instance runs its full backup on a different day of the week.

    You can associate the same save set with more than one client instance, so it can be associated with more than one group or schedule for backup.

    If the default keyword "All" appears in the Save Set attribute in the Clients resource, all local filesystems for the client machine are backed up according to the group and schedule listed in the Clients resource.

    When you configure multiple client resources for the same machine, the most conservative of the assigned browse and retention policies is automatically implemented for all of them.

    Caution - Caution -

    The core file is not backed up unless you specify it in the Save Set attribute of the Clients resource.

Logical Volume Backup

A logical volume is a type of primary (disk) storage on a client machine that can span several physical disk volumes. The logical volume has its own device address, and it is treated similarly to a disk partition by the filesystem. When Backup backs up data from clients, it has to determine how many save sessions to allocate to each client for best performance. To avoid contention, there should not be more than one backup operation running per physical disk. Backup attempts to allocate different sessions across different physical disks to avoid contention.

To determine how many save sessions to allocate, the Backup server probes (queries) the clients in a backup group (using the savefs -p command) to find out what data to back up and where the data is physically located. Backup tries to determine whether there are logical volumes. It stores this information in two variables, disk-number and maximum-sessions, according to the following rules:

The server uses the output from the savefs probe to allocate its save sessions (up to the maximum server parallelism) across the clients in the backup group:

  1. First, the server allocates one save session per client in the backup group.

  2. Then, if there are still save sessions available, it allocates one save session per physical disk on each client.

  3. If, after that, there are still save sessions available, it allocates save sessions to each disk-number value, up to the limits in maximum-sessions for each client and client parallelism.

How to Specify How Long Backed-Up Data Is Kept

Use browse and retention policies to specify how long data is available for recovery. You can specify browse and retention policies for each client.

What Are Browse and Retention Policies?

The Backup server maintains one file index for each client machine (regardless of the number of client resources configured for it) and one media database that tracks data from all clients. Each time a backup is completed, Backup creates entries for the backed-up files in the client file indexes. The media database stores one entry for each save set and storage volume during each backup operation.

Each client file index is a browsable structure of data from a single client machine. Users can specify anything from a single file to a complete filesystem and direct Backup to reconstruct the data during a recover session to look exactly as it did at a specific time. The information that the client index contains and coordinates enables Backup to automatically handle situations such as assembling data from backups based on levels, and to accommodate all file or directory renamings or deletions. Backup uses browse policies to manage the life cycle of data and to automatically control the size of the client file index.

The Failed Cross Reference Format determines how long files are maintained in the client's file index on the Backup server. During the period of the browse policy, users can browse backed-up data in the Backup recover program (nwrecover) and select individual files or entire filesystems for recovery. After the browse policy for a file is exceeded, Backup automatically deletes the entry for that file. Backup deletes these entries to manage the size of the client index, which can grow rapidly: one entry for each file backed up during each scheduled backup of the client.

The media database is the structure that tracks the location of save sets on storage volumes. Backup uses a Failed Cross Reference Format to manage the longevity of Backup managed data. Data is recoverable as long as entries exist in the media database; there is nothing to be gained by rushing to delete media database entries. For all these reasons, the media database retention policy does not trigger the automatic removal of media database entries. Instead, the retention policy determines how long an entry for a save set remains protected from being accidentally written over.

The retention policy determines how long save sets are maintained in the Backup server's media database. For at least the period of the retention policy, you can recover a client's backed-up save sets from media. No save set is considered recyclable until, at a minimum, it has exceeded its retention policy. No storage volume can be relabeled and written over until, at a minimum, all save sets on the storage volume have exceeded their retention policies. Theoretically, entries for a save set or a storage volume can remain in the media database forever, long after the retention policy has been exceeded. Entries are removed from the media database only if a storage volume is relabeled or if you manually delete the entries.

How the Browse Policy Works

You can recover a file that has an entry in the client file index through the Backup recover program, which enables users to browse and mark files and initiate data recovery. Client file index entries are not necessarily deleted the same day that the browse policy is exceeded. Backup does not remove the entry for a file until all the save sets that are dependent on the file have also exceeded their browse policies. In general, the entries for a full backup that are older than the browse policy are not removed until an additional length of time equal to one backup cycle passes as well. This extra time ensures that you can reconstruct a file to any point in time included in the browse policy period.

The following figures demonstrate how a browse policy affects data availability in the client file index. For more information about schedules, see "Schedule Configuration ", and for more information about backup levels, see "Backup Levels ".

In Figure 5-1, both the backup cycle and the browse policy are set at one week. A backup cycle is the length of time between full backups. Entries for the first full backup on October 2 remain in the client file index until all the incremental and level 5 backups that depend on it exceed the one-week browse policy. The full backup performed on October 2 is not removed until October 16, when the incrementals and level 5 that depend on the full backup expire.

Figure 5-1 One-Week Browse Policy

Graphic

To illustrate why the browse policy works this way, suppose that on October 12, you decide that you want to recover information backed up on October 6. The backup performed on the 5th is an incremental backup dependent on the October 5 backup, which is a level 5 backup. The October 5 level 5 backup, in turn, is dependent on the full backup performed on October 2. The entry for the full backup performed on October 2 must remain in the client file index for a period of time equal to the browse policy (one week) plus one complete backup cycle (one additional week)--that is, until the level 5 backup on October 5 and all incremental backups dependent on the full backup pass their browse policy. In the example shown in Figure 5-1, entries from the Week 1 backup cycle are removed from the client file index on October 16.

In Figure 5-2, the browse policy is two weeks, which is twice as long as the backup cycle (1 week). In this example, on October 19 a user can still find browsable entries in the client file index from backups created on October 5. The backup performed on October 6 is an incremental backup dependent on the October 5 backup, which is a level 5 backup. The October 5 level 5 backup, in turn, is dependent on the full backup performed on October 2. The full backup performed on October 2, and the incremental and level backups that depend on it, must remain in the client file index for a period of time equal to the browse policy (two weeks), plus one complete backup cycle (one additional week). In this example, entries for the Week 1 backup cycle are not removed from the client index until October 23.

Figure 5-2 Two-Week Browse Policy

Graphic

How the Retention Policy Works

The Backup media retention policy specifies a period of time during which backed-up data is protected from accidental overwrite. After the retention period is exceeded, the save set is eligible to change its status from recoverable to recyclable. The save set's status, however, does not change to recyclable until it and all the save sets that depend on it have passed their retention policy. Backup keeps track of save set dependencies regardless of whether the dependent save sets are stored on the same media volume or on different volumes. The expiration of a save set's retention policy does not remove the save set's entries from the media database.

When the retention policy for every save set on a volume expires and the status for every save set on a volume changes from recoverable to recyclable, Backup changes the mode of that storage volume to recyclable. Since a volume can contain save sets from multiple backup sessions, all with different retention policies, the mode of a volume might not change to recyclable for a long time. The term "recyclable" is best understood as "eligible for recycling."All the data on the volume remains available for recovery using either save set recover or the scanner command. All the entries for "recyclable" save sets remain in the media database.

The change in status to recyclable is a passive reminder that you can overwrite the volume if conditions are right. If you place the volume in an autochanger or mount the volume in a standalone device and enable the auto media management attribute in the Devices resource, the volume is available for relabel and use by Backup. The existing data is nonrecoverable after the volume is relabeled, so the entries for the overwritten save sets are removed from the media database. For more details about this feature of auto media management, see "How Backup Selects a Storage Volume for Relabeling ".

The save set's entries are also removed from the media database when you manually delete a volume from the Backup volume inventory. However, the data on a volume that you delete manually is still available for recovery using the scanner program. The scanner program retrieves the information needed to re-create entries in either the client file index, in the media database, or in both places. If you re-create the entries in the client file index, a user with the proper permissions can recover data through the Backup recover program (nwrecover). If you re-create the save set's entries in the media database, a user with Backup administration privileges can recover data with save set recover. See Appendix B, Command Line Reference Utilities, or refer to the scanner man page for more information on how to use the scanner program.

Figure 5-3 illustrates how a retention policy works. In this example, the backup cycle is set at one week and the retention policy is set at three weeks.

Figure 5-3 One Week Backup Cycle; Three Week Retention Policy

Graphic

The save set entries for Week 1 have passed their browse policy and retention policy, but they remain available for recovery using the scanner program until you relabel. When all the save set entries on a volume change status to recyclable, the volume mode changes from full or appendable to recyclable, and the volume is ready to be relabeled for reuse. When you relabel the volume, the data on the volume can no longer be recovered by Backup.

For more information about storage volume modes, see Table 4-3.

For more information about schedules, see "Schedule Configuration ", and for more information about backup levels, see "Backup Levels ".

How the Browse and Retention Policies Manage the Data Life Cycle

The browse and retention policies that you associate with a client save set control both the growth of the client file index and the media database, and how long data remains available for recovery. Figure 5-4 traces the data life cycle through the client file index and the media database. In the example, the entries for the September 1 through September 7 backup cycle remain in the client index for one month (the browse policy), plus the length of a full backup cycle (one week), to ensure that all dependent entries pass their browse policies. In this case, the file index entries for the September 1 through September 7 backup cycle are removed on October 13. Since the entries exist in the client file index, you can browse and recover the data through the recover program's GUI (nwrecover). As long as the save set's file entries remain in the client file index, the status of the source save sets is browsable. After the save set status changes from browsable to recoverable, you cannot perform file recovery directly.

The status for each save set backed up during the September 1 through September 7 backup cycle remains recoverable until their retention policies expire, plus however long it takes for all the dependent save sets to pass their retention policies. In this case, the entries from the September 1 through September 7 backup cycle change from recoverable to recyclable on December 8. When all of the save set entries on a volume change status to recyclable, the mode of the volume itself changes from either full or appendable to recyclable.

While the status of a save set is either recoverable or recyclable, you can recover any save set from the storage volume by using either the save set recover operation or the scanner program. Alternatively, you can use the scanner program to re-create a save set's entries in the client file index, which enables file recovery directly from the GUI. For more information about using Save Set Recover and the scanner program, see "Save Set Recover and Scanner".

Figure 5-4 Data Life Cycle in the Client Index and the Media Database

Graphic

On October 13, all data entries from September 1 to September 7 are removed from the client file index. On December 8, the save set entries from September 1 to September 7 in the media database change status from recoverable to recyclable. After all save sets on a volume change status from recoverable to recyclable, the volume mode changes to recyclable. If auto media management is enabled, the volume may be relabeled automatically by Backup to satisfy a volume mount request. After you relabel the volume, all existing data on the volume is unavailable for recovery.

Caution - Caution -

When you relabel a volume for reuse within the same pool, the volume identification (the volume name as it appears on the volume label) remains unchanged. Even so, after relabeling, the information that Backup needs to locate and access all existing data on the volume is destroyed and neither the Save Set Recover feature nor the scanner program are options. At this point, the volume is ready for new data. All existing data is inaccessible and is overwritten.

Save Set Status Values

Backup assigns to each backed-up save set a status based on the success of the backup or the age of the save set data. The save set status changes in the following situations:

Table 5-1 provides a list of all the possible values for save set status.

Table 5-1 Save Set Status Values

Status Value 

Meaning 

Description 

abort

Aborted 

You aborted the backup for this save set manually or a crash occurred during the operation. This save set is considered immediately eligible for recycling. 

brows

Browsable 

The files in this save set retain entries in the client file index. You can restore all the files using an index-based recover.  

inpro

In progress 

This save set is currently being backed up.  

recov

Recoverable 

The files in this save set do not have browsable entries in the client file index and have not passed the retention policy.  

recyc

Recyclable 

The save set and all the save sets that are dependent on this save set for recovery have exceeded their retention policies. 

scann

Scanned-in 

The client file index entry for this save set was restored with the scanner program. This entry remains in the client file index and media database until you remove it manually.

susp

Suspect 

An attempt to recover this save set failed. The recover program could not read all the blocks of the save set, for example, if there was a bad spot in the tape.

How to Customize Policies

Use the Policies resource to create a custom browse policy or retention policy. In the Policies resource, give the policy a unique name and specify a time period. After you define a policy, it is available as a choice in the Browse Policy and Retention Policy attributes in the Clients resource.

Save Set Recover and Scanner

Use save set recover to recover backed-up data that has passed the period of its browse policy but is still in the media database. You can initiate save set recover either from the command line by executing the recover program and providing specific save set identification numbers (ssid) as options, or from the Backup administration program (nwadmin). You can specify individual files or directories by including the exact path along with the ssid. Permission to perform a save set recovery is granted only to root.

Use save set recover only when the entries have been removed from the online file index (when the save set has passed its browse policy). When you perform a save set recover, you must recover the level full backup first, then recover the other backups in level order from 1 through 9, then recover the incremental backups.

If no entries for the volume exist in the media database, use the scanner program to re-create client file index entries or re-create media database entries. The scanner program can read the storage volume directly, without assistance from Backup.

To find the volume that contains the file you want, use the mminfo program if the volume is still in the media database or the scanner program if the volume is no longer in the media database. The mminfo and the scanner programs provide detailed information of the contents of the volume. This information includes:

How to Rebuild a Save Set Entry in the Client File Index

If the file is not browsable (which means that the save set's browse policy has expired) but its save set is still tracked by Backup in the media database (which means that the save set's retention policy has not expired), follow these steps to recover the save set's entry back into the client file index:

  1. Run the mminfo program:


    # mminfo -a -v volume-name

  2. From the mminfo output, find the ssid that you believe contains the file you want. Make sure it is not the bootstrap ssid.

  3. After you have the proper ssid, replace the save set entry in the file index with the scanner program:


    # scanner -i -S save-set-id device-name

  4. Use the Backup recover program to mark the file for recovery.

    Caution - Caution -

    If the save set spans volume boundaries, use the scanner program to read from all the volumes. Otherwise, the client file index is not fully rebuilt, making it impossible to perform an online recovery of the files in this save set.

  5. Use the Backup recover program to mark the file for recovery.

    If the save set that contains the file is not browsable and the save set is not represented in the media database, both the browse and retention policies have expired. Follow these steps to rebuild the save set's entry in both the client file index and the media database:

    1. Run the scanner program on the backup volume that you believe contains the file you want.

      Make a guess based on the adhesive label on the volume or use the procedures listed under "How to Find a Volume Name":


      # scanner device-name

    2. Use the output from the scanner program to decide whether to reintroduce the contents of this volume into the client file indexes and whether the save set you want to rebuild is on this volume.

      You must locate all the volumes that contain this save set ID.

    3. After you have determined which volumes to reintroduce into the online indexes, run the scanner command:


      # scanner -i device-name

      The scanner command prompts for a new volume until you terminate it. To rebuild the indexes completely, you must scan in all the volumes that contain the ssid.

    4. Use the nwrecover program to browse the file index for the file you want to recover.

How to Recover an Entire Save Set to the Backup Server

To recover an entire save set directly to your disk volume, use the following options to invoke the scanner program:


# scanner -S save-set-id device-name | uasm -rv

This command reads all the information associated with the ssid from the volume and places a copy of this data on the Backup server in the exact way that it is stored on the backup volume. In other words, the backup volume may contain files for a client, but is recovered to the Backup server's hard drive.

If you want to be sure this action is correct before you perform it, add the -n flag to the uasm command. The -n flag sends the output from scanner to /dev/null and lists all the filenames contained in the save set.

You could also use rsh (or its equivalent) in conjunction with the following command to recover the save set to the client, if the save set originated on a Backup client instead of the Backup server:


# scanner -S ssid device-name | rsh client "(cd destdir; /pathto/uasm -rv)"

How to Recover One File Directly from a Volume

To recover a single file from a volume, run one of the following commands:


# scanner -S save-set-id device-name | uasm -rv filename

or


# scanner -S save-set-id device-name | uasm -rv -m source=dest filename

The -m option of uasm maps (relocates) the recovered file from the source to the dest (destination) directory.

Adding Processing Instructions to the Scheduled Backup

The Directive and Backup Command attributes in the Clients resource add instructions for client-side data processing to a scheduled backup.

What Are Directives?

Directives are special programs Backup applies to save set data to initiate additional data processing. For example, a compression directive can reduce the amount of data you back up, possibly even eliminating the need to change backup volumes on the days you perform a full backup. Directives appear as selectable options associated with the Directives attribute in the Clients resource.

A directive contains instructions to assist the backup process, maximize the efficiency of a backup, and handle special files. During a scheduled backup of a client save set, Backup applies directive instructions to specified files. For example, you can use the null directive to omit certain files from the backup entirely.

Creating Customized Directives

Use the Directives resource to create a directive and apply it to a specific client through the Clients resource. Because every environment is different, it is impossible to prescribe directive-writing rules that work in every case. Instead, examples of the most commonly requested customizations are provided below to give you models to follow.

Examples: Directives to Back Up Specific Directories on a UNIX Client

Assume you want to save only the directory /aaa/zzz on client 123 and no others. This directive restricts Backup from walking the directories /aaa and /zzz to locate and back up other files or subdirectories. This directive invokes a UNIX application-specific module (uasm) called null. The use of null skips files in the directory specified; the use of +null skips files in the directory specified as well as those below the directory specified. The content of the directive to back up only /aaa/zzz appears as follows:


<< / >>  uasm: 	aaa  null: *.?<< /aaa >>	  uasm: zzz<< /aaa/zzz >>   +uasm: *.?*

In another example, assume you want to back up all non-root mounted disks, and back up the /home and /users directories off the root disk. You also want to back up the cron files and the calendar databases. For each client, the Save Set attribute contains the value All. The directive appears as follows:


<< / >>  uasm: home users var  null: *.?*  +null: core<< /home >>  +compression: *.?*  +null: core<< /users >> *   compression  +null: core<< /var >>  uasm: spool  null: *.?*  +null: core<< /var/spool >>  uasm: calendar cron  null: *.?*  +null: core<< /var/spool/calendar >>  +compression: *.?*  +null: core<< /var/spool/cron >>  +compression: *.?*  +null: core<< /cdrom >>  null: *.?*<< /opt >>  null: *.?*<< /tmp >>  null: *.?*<< /usr >>  null: *.?*

The use of null as part of a directive instructs Backup not to save the specified files during the particular backup, but to include an entry in the index listing created by Backup to indicate that the files were included in the backup operation. Because the files are included in the index, the filenames are available for browsing in the directory and the view of the filesystem through Backup corresponds to the actual filesystem. That is, the recover program's GUI displays files that are available for recovery, even if you skipped the files in more recent backups and the data available for recovery is not as recent as the data available for other files.

This behavior differs slightly from the behavior of the skip uasm directive. The skip uasm results in a view of your filesystem from the browser that reflects the backed-up data, not the closest approximation to the actual filesystem. For these reasons as well as other, more technical, advantages, the use of null is recommended over skip.

Backup Command

You can enter a custom backup command in the Clients resource that includes additional processing instructions. This custom backup command is used instead of the default save program when scheduled backups are initiated.

You can run pre-processing and post-processing commands that execute only once per client backup with the savepnpc program. The savepnpc program, like the save program, saves files to long-term storage. Before performing the first save operation on the client, savepnpc performs any pre-processing commands that exist in the /nsr/res/<group_name>.res file. After the last save operation completes successfully on the client, savepnpc performs any post processing commands listed in the /nsr/res/<group_name>.res file. See "savepnpc " of Appendix B and the man pages for more detailed information about savepnpc.

You can customize your client backups by creating additional programs that affect the way Backup backs up client filesystem data.

For example, you can create a program that shuts down either a mail server or a database before Backup performs a backup operation and then restarts the mail server or database after the backup is completed. Or you can create a program that prints a message (such as backup started at 3:33 a.m.) before the backup operation begins, then executes the backup on the client data and prints a message when the backup is completed (such as backup completed at 6:30 a.m.).

The backup command is performed for each save set that is defined for the client, not on a per-client basis. If you specify a save set value of All, the backup command batch file is executed the same number of times as the number of filesystems on the client. The simplest implementation of a customized backup command is to create a special separate client with a single save set listed in the Save Set attribute.

Consider the following issues as you determine what level of customization works best for your environment:

Caution - Caution -

Unlike savepnpc, new instance of the customized Backup Command, like the standard save program, is invoked for each save set listed in the Save Set attribute. Bear this in mind when you create a Client resource with a customized Backup Command for a database, because a shutdown command is executed for each save set you list.

How to Create Customized Backup Commands

The syntax you use to create the backup program or batch file must adhere to the criteria described in the following list. The list is detailed and includes programming details. Do not attempt to write your own backup command unless you can follow these recommendations.

The program should contain commands in the following order:

Follow these steps to create a pre- or post-backup command:

  1. Use a text editor to create a program file in the directory where the Backup save command resides.

  2. Enter the name of the backup program in the Backup Command attribute of the Clients resource.

  3. Try backing up the client to ensure that the backup command you created works.

Example: Customized Backup Command

The following script is an example of a custom backup command that does pre- and post-processing. This script locks a ClearCase VOB (version object base), does the backup, then unlocks the VOB.


#!/bin/sh
# export the SHELL that we are going to use
SHELL=/bin/sh
export SHELL
# export the correct PATH so that all the required binaries can be
found
case $0 in
/* ) PATH=/usr/atria/bin:/bin:/usr/bin:`/bin/dirname $0`
c=`/bin/basename $0`
;;
* )PATH=/usr/atria/bin:/bin:/usr/bin:/usr/sbin
c=$0
;;
esac
export PATH
# These are the valid statuses which save reports on completion of
the backup
statuses="
failed.
abandoned.
succeeded.
completed savetime=
"
# Perform the PRECMD (Lock VOB)
/usr/atria/bin/cleartool setview -exec
"/usr/atria/bin/cleartoollock -c \
  `VOB backups in progress' -vob /cm_data/mis_dev" magic_view >
/tmp/voblock.log 2>&1
# Perform backup on client
save "$@" > /tmp/saveout$$ 2>&1
# cat out the save output
cat /tmp/saveout$$# search for the backup status in the output reported by save
for i in ${statuses}; do
      result=`grep "${i}" /tmp/saveout$$`
      if [$? != 0]; then
               echo ${result}
      fi
done
# Perform the POSTCMD (Unlock VOB)
/usr/atria/bin/cleartool setview -exec
"/usr/atria/bin/cleartoolunlock -vob
/cm_data/mis_dev" \
    magic_view > /tmp/vobunlock.log 2>&
# make sure to gracefully exit out of this shell script
exit 0

How to Allow Other Clients Remote Access Rights

Backup clients are preconfigured so that only the client itself can browse or recover its own files. If your company is concerned about security, leave the Remote Access attribute blank, so that only the client itself can recover its backed-up files.

To give other users or machines permission to recover a client's files, enter the user ID and hostname (in the format user@hostname) or netgroup name (if you are using NIS) in the Remote Access attribute in the Clients resource.

When you enable remote access rights, authorized users can view and recover files from other Backup clients from the Backup recover program. In the recover program, change to the client, then browse or recover the files you want.

To restrict permission to execute backup commands (save and savefs) on a client during a scheduled backup, enter a user ID in the Remote User attribute in the Clients resource. When this attribute is blank, the username, by default, is root.