test

Solstice Backup 5.1 Administration Guide

Chapter 3 Server and Storage Node Operations

This chapter describes operations that you manage through the Backup server. This chapter consists of the following sections:

Client/Server Communication Configuration

Communication between the Backup server and its clients is described by configuration values you enter in the Server resource and Clients resource. Backup relies on full and accurate configuration of the network to implement features that protect data and ensure security.

Each client resource should include both the DNS (domain name service) short name and long name in the Aliases attribute of the Clients resource in the Backup administration program.

For more details about how to set up Backup clients in the Clients resource, see "New Backup Client Configuration ".

To diagnose problems with network communications that affect Backup, use the instructions in "Client-Server Communications ".

Permissions Management

Although any user can view the server's resources from a client machine, only users you specify in the Administrator attribute in the Server resource can add to or change the configuration of the Backup server. When you first install Backup, root@server-name is the only user authorized to change the Backup configuration. To add other user IDs or machine names to the list of administrators, you must become root on the Backup server and add the other user IDs to the Administrator attribute in the Server resource.

Valid entries in the Administrator attribute include:

If you use the nsradmin interface to input these entries, you must separate them by commas.

You can also add or restrict user privileges for individual clients. For more details, see "How to Allow Other Clients Remote Access Rights ".

Caution - Caution -

When you add a user to the Administrator attribute in Backup, that person has Backup administration privileges for only that Backup server. Users in the Backup Administrator list do not automatically have root privileges on the Backup server or other machines in the network. A Backup administrator can change attributes for clients and other resources of the Backup server. Backup administrators have no special rights to client data for either backup or recovery.

Storage Node Configuration

A storage node is a machine that is connected to a Backup server and one or more devices used in Backup's backup, archive, and HSM operations. Devices attached to storage nodes are called remote devices because they are not physically attached to the controlling Backup server. The storage node runs special Backup software that controls devices. The data stored on media in remote devices is tracked in the media database and online client file indexes on the controlling Backup server.

Storage nodes you add to your Backup configuration can increase the Backup server's performance, give you more flexibility in designing your network, and centralize the control of data management activities to one or a few Backup servers.

To create a storage node, install the storage node binaries from the Backup software distribution on the storage node machine. Then define the storage node's devices. The method for defining devices is described in "Remote Device Configuration ".

The storage node hostname does not need to be on the server's Administrator list unless you run jb_config and scanner on the storage node. The entry for this is root@storage_node_hostname.

For an autochanger or silo, you must manually add the storage node's hostname to the Administrator list before you define the devices with the jb_config program. When the jb_config program is completed, you can remove the storage node's hostname from the Administrators list. If you need to configure a new autochanger later, you must add the hostname before you run the jb_config program again. After you add the storage node's hostname to the Administrator list, one instance of nsrmmd starts on the storage node for each device that it controls.

Converting an Existing Backup Server to a Storage Node

Existing Solstice Backup servers can be converted to storage nodes. Converting an existing Backup server to a storage node involves:

  1. Ensuring that you have a current backup copy of the current environment.

  2. Updating/upgrading the server to Solstice Backup 5.1.

    Servers running the Backup Server Edition software must be upgraded to Backup Network Edition 5.1.

  3. Choosing one of the servers to be the controlling (master) Backup server.

  4. Configuring the new master server to use the remaining server(s) as a storage node(s). Maintain your /nsr directory on the storage nodes.

    You will need to call a Sun License Center for your storage node enabler(s). In the U.S., call 1-800-872-4786 (#3 at the prompt). For all other countries, refer to the Sun Licensing Center web page at http://www.sun.com/licensing.

  5. Noting the date of the conversion as part of the recovery process.

  6. Recovering data that was backed up before the date of conversion.

    To do so, convert the storage node to a Backup server by starting the nsrd process on the machine that contains the data required and inventory the jukebox or library attached to the server, if one of these automated devices is being used.

  7. Converting the system back to a storage node by shutting down the nsrd process and inventorying the jukebox or library, after recovery of the data.

Caution - Caution -

Do not merge the resource database, media database, and client file indexes of Backup server(s) and storage node server(s) due to potential conflicts that may arise.

From a Backup server, an administrator can view resources controlled by storage nodes associated with that Backup server. In addition, the administrator can perform all storage operations (mount, unmount, label, inventory, volumes, pools, devices, autochangers, clone, and nsrjb) for local and remote devices, as well as defining and controlling all Backup client operations.

One Backup server can control multiple storage node servers. You can establish an affinity between a client and a prioritized list of storage nodes, to ensure that a client is backed up to a preferred storage node. Such client affinity is kept in the resource database of the controlling Backup server.

Storage nodes added to your Backup configuration can increase the Backup server's performance, give you more flexibility in designing your network, and centralize the control of data management activities to one or a few Backup servers.

Scheduled Backup Configuration

This section describes how to set up the scheduled backup features of Backup, including automated group backups and customizable backup schedules.

Backup Group Configuration

Use Backup groups to designate what time a client's scheduled backup starts. You can assign client save sets to Backup groups to control which client's save sets back up at which times. You can also assign a client's save sets to more than one group.

If you have an especially large number of client machines, consider creating several groups with different start times to help reduce network traffic. For example, you could start the backup time of the group that includes the engineering department's machines at four o'clock in the morning, and the group with all other clients on the network at midnight.

If you create different groups, be sure to stagger their start times to avoid overloading the server. Schedule them far enough apart so that one group has completed its backup before the next group starts. Backup does not start a new group's backup until all the groups with earlier start times are finished. See "Example: Scheduling Large Client Filesystems".

How to Create a Customized Group

Backup provides several preconfigured groups for you to use. If you need a different group configuration, you can create new groups to fit your situation. To create and use a customized group, follow these steps:

  1. Create the group in the Groups resource.

  2. Edit an existing pool or create a new pool in the Pools resource. Select the new group in the Groups attribute.

  3. In the Clients resource, edit or create the client resources for the client machines that contain the save sets you want to include in the group. Select the new group in the Groups attribute.

    Caution - Caution -

    Do not include spaces in a group name.

How Backup Uses Backup Groups

The client save sets in each Backup group begin their automatic scheduled backups according to the start time of the group. You can balance the backup loads by taking the client's backup schedule into account when you decide which clients to include in a specific group. (Refer to "Schedule Configuration " for more information about creating schedules that vary the days that different clients perform full backups.)

Figure 3-1 illustrates how Backup uses backup groups to back up multiple client save sets.

Figure 3-1 How Backup Uses Groups to Back Up Multiple Clients

Graphic

In this example, three client machines, Oak, Elm, and Fir, are part of the group named Weekly Full, which starts its automatic scheduled backup at midnight. Client Oak runs a full backup of all its save sets every Monday and incremental backups of its save sets on the other days; client Elm runs a full backup of all its save sets on Tuesday and incremental backups on the other days; and client Fir runs a full backup of all its save sets on Wednesday and incremental backups on the other days of the week. Because each client runs its full backup on a different day of the week, the server is not overloaded.

The second group, "Accounting," illustrates how you can group clients by department. Group Accounting contains client machines Birch and Pine and starts its backups at 7:00 p.m., when the machines in the Accounting Department are available for backup. Although the two client machines run full backups on the same day, machine Pine is scheduled to back up only the /usr/home save set; all the save sets on machine Birch are backed up. By estimating how long a backup takes, you can determine what start time to set for the next group.

The save sets from each group are written to appropriate volumes mounted on storage devices. Backup uses pools of volumes to organize, track, and store save sets; it uses groups to determine what time clients start their scheduled backups.

Backup Default Group Settings

Backup ships with a preconfigured group named "Default." To ensure that all data is backed up, Backup automatically adds all clients to the Default group. However, you must enable the default group for Backup to back it up. Depending on your needs, you can keep a client in the Default group, or you can put the client in one or more customized groups.

The two critical attributes in any group are the Start Time attribute and the Autostart attribute. The Start Time attribute for the Default group is set to start its daily backup at 3:33 a.m. You can change the Start Time attribute. You must enable the Autostart attribute for the Default group, and any other group you create, before Backup can run a scheduled backup of the group.

Client Retries

If the Backup server cannot make a connection with a client, the Client Retries attribute in the Groups resource specifies the number of times that the server should try to connect to the client before the effort should be considered a failure. The first retry does not occur until after an attempt has been made to contact each client (at a minimum). The Inactivity Timeout attribute in the Groups resource specifies the number of minutes that the Backup server waits for evidence of backup activity on the client. If the server has not received status information for longer than the time specified, the server abandons the backup operation for the save set.

Note -

The backup of an abandoned save set might be completed, but the automated report from savegrp does not show that the backup is completed. For example, if the client is being backed up over a network filesystem (NFS) connection and the NFS server crashes and reboots, the Backup backup hangs until it times out. The Backup server marks the save set "abandoned," but when the NFS server comes back up, the backup continues and is completed.

The preconfigured attributes for the Default group are described in "Groups Resource ". You can make changes to any Default group attribute, but you cannot delete the group. You can, however, create or delete as many customized groups as you need.

Using a Group Schedule to Override a Client's Regular Backup Schedule

You can use a group's Level and Schedule attributes to override a client's regular backup schedule. For example, one evening you might want to run a full backup on all the clients in a group, regardless of the clients' regular backup schedules. The entry you make in the Level attribute overrides the backup level setting for every client in the group.

Alternatively, you might want a group of clients to follow the same backup schedule instead of each client's individual schedule. You could assign a group of clients to follow the default schedule (full every Sunday) regardless of each client's individual schedule. If you leave the group's Level and Schedule attributes blank (the preconfigured setting), the clients follow their individual backup schedules.

Monitoring and Managing Group Backups

Use the Group Control window in the Backup administration program to monitor scheduled groups during a backup. The Group Control feature, savegroup completion message, bootstrap printout, and system console log provide information about the success of scheduled backups and the information you need to recover your data.

The Group Control feature provides status information and contains controls for previewing, stopping, and starting scheduled backup groups.

The status information about the most recently started backup group is displayed as one of the following:

Monitoring Operations

The Group Control Details feature available in the Backup administration program enables you to view more detailed information about a completed group backup. Use this feature to determine which client save sets were backed up successfully and which save sets failed.

The Group Control Details window displays the status of client save sets in the backup process in one of three message fields:

You can use the Group Control Preview feature to simulate a backup for a specific group. This feature helps you identify potential problems before Backup runs an upcoming group backup. To preview a backup group with the Backup administration program, display the Group Control window and click the Preview button. To preview a backup group from the command line, become root on the Backup server, then issue the savegrp -p group-name command at the shell prompt.

Backup displays information about how a group will perform during its next scheduled backup, instead of displaying past information about completed group backups.

Immediate Start of a Scheduled Group Backup

When you start a scheduled backup group manually (on demand), Backup runs the backup at the level of the next scheduled backup, which can be full, level 1-9, or incremental.

To immediately start a group backup in one of two ways:

When you use the Start Now control, Backup overrides the Groups scheduled start time and immediately backs up the clients in the group.

Stop and Restart of a Scheduled Group Backup

After you initiate a Stop in the Group Control window, Backup completes its backup of the current save set, halts the rest of the scheduled backup, and displays Not Finished in the Status field in the Group Control window.

After you initiate a Restart through the Group Control window, Backup resumes the scheduled backup for the group and displays Running in the Status field.

Management of Open Files During a Scheduled Backup

If a client's open files change during a scheduled backup, Backup backs up the old version of the files and detects that they are changing. A warning message similar to the following appears in the Group Control Details window:


warning: file filename changed during save

The changes to the file are not backed up. To back up the changes, you can restart the backup group or allow Backup to back up the client during the next scheduled backup.

Savegroup Completion Message

When the backup is completed, Backup generates a report about the success of the scheduled backup. Backup sends the root user an automatic notification and displays the same information in the Backup administration program.

Bootstrap Generation and Printout

When the backup group contains data from the Backup server, Backup generates a special save set called the bootstrap, which includes the server file index, media database, and configuration files. The bootstrap information is essential for recovery from a disaster. By default, the bootstrap is printed to the Backup server's default printer. To change the default printer, change the Printer attribute in the Groups resource.

A bootstrap printout is created with any scheduled backup of a group that includes the server, or after other scheduled backups if the server is not in an active group. A bootstrap printout is generated whether the scheduled backup is initiated automatically or manually.

How to Save the Bootstrap to a File

You can save the bootstrap to a file or email it to one or more user IDs.

  1. Run nwadmin and select Notifications from the Customize menu.

  2. Select Bootstrap.

    The Action attribute displays:


    /usr/bin/lp -s -c -t bootstrap -d%PRINTER

  3. Change this to:


    /bin/cat >> /directory/filename

  4. To email the bootstrap file to more than one user IDs, change the line to:


    /usr/ucb/Mail -s "nwserver bootstrap" user-name@corp.com

System Console Log

The UNIX system log displays messages passed from Backup. When Backup is installed, it adds lines to the configuration log file (syslog.conf) to tell the system log facility what types of notices to direct to which file or user. For example:


daemon.notice                   /dev/console
daemon.notice                   /nsr/logs/messages
daemon.notice                   operator
local0.notice                   /nsr/logs/summary
local0.alert                    root, operator

Schedule Configuration

The Backup server determines the amount of data to back up for each client system across your network according to the backup schedule you assigned to each client. Schedules can be very simple or very sophisticated, depending on the needs of your environment. All clients can share the same schedule, or each client can have its own schedule. Use the Schedules resource to create customized schedules that you can apply to client save sets through the Clients resource. See Chapter 5, Backup Client Operations for more information about the Clients resource and client configuration.

How Backup Uses Backup Schedules

Backup uses a client's backup schedule to determine what level of backup operation to perform on a given day for the specified save sets. The time of day the backup operation begins is determined by the Start Time assigned to the Group resource with which the client save sets are associated.

Backup supports four different types of backup levels:

(See "Backup Levels " for a detailed description of backup levels.)

Use the Schedules resource to customize backup schedules to best suit your needs. For example, some clients may have data you want to back up at level "full" every three days, with incremental backups in between. Other clients may have less critical data that only needs a full backup once a month, with incremental backups or level 1-9 backups on other days.

The time from one full backup to the next full backup is called a "backup cycle." Figure 3-2 illustrates a weekly backup cycle. In this example, a full backup is performed for a client each Sunday and incremental backups are performed the other days of the week.

Figure 3-2 Weekly Backup Cycle

Graphic

You can use backup schedules to balance and stagger the load on your Backup server. Depending on the size of your network, you can apply the same schedule to all clients. For example, if no one works on Sunday and you want to run full backups on that day, you can apply the default schedule to all your clients. The default schedule tells Backup to perform full backups on Sunday and incremental backups the rest of the week. Figure 3-3 illustrates how the default schedule works for three clients: Client A, Client B, and Client C.

Figure 3-3 Using the Backup Default Schedule for Multiple Clients

Graphic

Because full backups can take a long time, you may want to stagger them throughout the week. For example, you can apply a schedule that performs a full backup for Client A on Sunday, a second schedule that performs a full backup for Client B on Tuesday, and a third schedule that performs a full backup for Client C on Thursday. Figure 3-4 illustrates how you can use staggered backup schedules for multiple clients.

Figure 3-4 Staggered Weekly Schedules for Multiple Clients

Graphic

When you balance and stagger the load on your Backup server, you can increase server efficiency. Using different start times for groups of clients also helps increase server efficiency.

Backup Schedules

Backup makes it easy to set up your backup schedules. Deciding which backup schedules best fit your environment, however, requires a planned strategy.

When you create backup schedules, consider the following factors:

Additionally, you must determine a policy for recovering files. For example, if users expect to recover any version of a lost file for at least three months (that is, the retention policy is equal to three months), you need to maintain all the save set entries in the media database for three months. On the other hand, if users only expect to recover data from the last month, you can use level 1-9 backups to decrease the quantity of volumes you need to maintain.

The length of time data is available for Backup to recover is determined by the browse and retention policies associated with each client. See "How the Browse and Retention Policies Manage the Data Life Cycle " for more information about how Backup manages the data life cycle.

Example: Scheduling Large Client Filesystems

At a moderate backup rate of 400KB per second, a full backup for a client with 10GB of data takes about 5.5 hours to complete. Consequently, it may not be convenient to complete a scheduled, full backup for client save sets as large as this because of the amount of time the backup takes.

You can schedule the client's disk volumes for backup at different times by separating them into different backup groups. When you split one client's save sets into multiple backup groups, you back up all the client's files, but not all at once. It is less time-consuming than a full backup of all the local data at one time.

To back up the client's filesystems individually, add and configure the same client several times addressing the different filesystems in the Clients resource. For example, configure the first client resource to back up one filesystem, /usr, with one backup schedule in one group, and configure the second client resource to back up another filesystem, /var, with a second backup schedule in another group.

Caution - Caution -

When you create separate backup schedules and explicitly list save sets, any files or filesystems not included in an explicit list are omitted from backup. This includes any new disk volumes that are added to the system. This risk of omission does not exist when you enter the special value "All" in the Save Set attribute; Backup automatically adds the new disk volumes to the backups.

Schedule Configuration Attributes

To create a customized backup schedule, you must define the following schedule configuration values in the Schedule resource:

Configuration Order for Backup Schedules

If you want to use your own customized schedule, you must configure the schedule before you can associate it with a client or save set in the Clients resource. The start time for your automatic daily scheduled backup is determined by the backup group with which the client save sets are associated. The length of time that the data is available for browsing or recovery is determined by the browse and retention policies you configure for the client's save sets, rather than by the schedule.

Backup Levels

Because it may not be practical or efficient for you to run a full level backup every day, Backup enables you to specify the level of the backup operation performed during its automatic, scheduled group backups. Limiting how often you perform a full backup can help maintain server efficiency, while still ensuring that your data is protected. Different backup levels enable you to trade off the number of volumes and amount of time required to complete a backup with the number of volumes and amount of time required to recover from a disk crash.

Backup supports four kinds of backup levels for filesystem data:

How Backup Uses Backup Levels

A backup schedule defines what level backup should be done on a given day during a backup cycle. You can apply one or more of these backup levels to customize a backup schedule. If you are considering using backup levels in a customized schedule, consider the following issues to help you make decisions that best suit your environment:

Caution - Caution -

The online client file indexes, server index, and media database are backed up whenever the Backup server is backed up. In general, they take on the backup level of the server. For example, if the Backup server's backup is a full level, the backup of the online client file indexes, server index, and media database is also a full level; if the Backup server's backup is a level 5, the backup of the online client file indexes, server index, and media database is also a level 5. However, when the server's backup level is incremental, the backup of the online client file indexes, server index, and media database is level 9.

How Backup Levels Work

Backup levels work in conjunction with a client's backup schedule. The way you define the backup levels directly affects how long the recovery from a disk crash takes and how many backup volumes you need.

The following paragraphs, accompanied by graphics, illustrate the concept of how Backup backup levels work and the data requirements for recovery in the event of data loss.

On October 2, a full backup runs. On October 3, the incremental backup saves everything that changed since the full backup. On October 4, the incremental backup backs up everything that changed since the 3rd. On October 5, the level 7 backup backs up everything that changed since the full backup. To fully recover from a disk crash on October 5, you need only two volumes: the full volume and the level 7 volume. You no longer need the data on the volumes from October 3 and 4, because the level 7 volume includes that information. (See Figure 3-5.)

Figure 3-5 Example: Backups for October 2 through October 8

Graphic

On October 6, 7, and 8, the incremental backup backs up everything that has changed since the level 7 backup. On October 9, as shown in Figure 3-6, the level 5 backup backs up everything that changed since the full backup. To fully recover from a disk crash on October 9, you need only two volumes: the full volume and the level 5 volume. You no longer need the data on the volume from the level 7 backup or the subsequent incremental backups because the level 5 volume includes that information.

Figure 3-6 Example: Backups for October 2 through October 15

Graphic

On October 12, the level 7 backup backs up all the data that changed since the last lower numbered backup, in this case the level 5 backup from October 9. To recover from a disk crash on October 12, you need three volumes: the full volume, the level 5 volume, and the new level 7 volume. (See Figure 3-6.)

On October 16, the level 5 backup backs up all the data that changed since the last lower numbered backup. Because no lower numbered level backup has been performed (for example, levels 1 - 4), the level 5 backup backs up all the data that changed since the full backup. To recover from a disk crash on October 16, you need two volumes: the full volume and the new level 5 volume. (See Figure 3-7.)

Figure 3-7 Example: Backups for October 2 through October 16

Graphic

Level 1-9 backups help you maintain control over the number of volumes you use. A carefully thought-out backup strategy enables you to recover everything to disk with a minimum number of volumes. The fewer volumes you need to recover from a disk crash, the less time you must spend restoring the disk.

You can also control the size and time it takes to back up your data by using directives, which compress and eliminate unnecessary data from your backups. For example, you can use a directive that tells Backup to skip certain files or filesystems when performing a backup. For more information on directives, see "What Are Directives? ".

Index Management

Backup tracks the files it backs up in the client file indexes and the media database. The client file indexes keep track of the files that belong to a save set, and the media database tracks the name of the volume, the backup dates of the save sets on the volume, and the filesystems in each save set. Backup can automatically control the size of the client file indexes and media database according to the browse policies and retention policies you set. For more details about using browse and retention policies, see "How the Browse and Retention Policies Manage the Data Life Cycle ".

Index Size and Structure

The structure of the client file indexes avoids operating system restrictions on file size and allows the client file index for a single client to continue to grow. As the client file index grows, it splits into segments of 2 GB each. If you want to check the size of a client's file index, enter the nsrls -f command, for example:


# nsrls -f /nsr/index/clientname/db

The path in the example is the default path. To change the path where the index resides, change the value in the Index Path attribute in the details view of the Clients resource.

Do not use the UNIX ls command to check the size of the client's file index. The output of the nsrls -f command is a table, for example:


# nsrls -f /nsr/index/mars/db
Volume id 0: /nsr/index/mars/db
 Fid |    Kbytes |     Count | Name
------------------------------------------
   0 |     18504 |    119798 | sr
   1 |      2016 |    119798 | sr_i0
   2 |      1768 |    119436 | sr_i1

How to Manually Reduce the Client File Indexes and Media Database

You can also use manual methods to control the size of the client file indexes and the media database:

When you purge or delete a volume, the client file indexes do not shrink automatically. Instead, the freed index space is used to allocate records that are added in the future. To reduce the size of the client file indexes immediately after you purge or delete index entries, run the following command:


# nsrck -C clientname

To reclaim the index space for all clients, change to the /nsr/index directory and run the nsrck -C command.

Large indexes may take up to a few hours to compress with nsrck. For more details, refer to the following man pages: nsrck, mminfo, scanner, nsr, nsrmm.

How to Override a Retention Policy

Save sets are retained on volumes and in the media database until the save sets expire. Ordinarily, a save set expires and is recyclable when the save set and all save sets that depend on it for recovery pass their retention policies. However, you can explicitly specify an expiration date for a save set that overrides the retention policy. Dependency rules still apply, however, which means that a save set is not marked "recyclable" until all save sets that depend on it are also marked as recyclable.

To explicitly override the retention policy, use the save -e manual backup command:


# save -e

Backup Performance

Backup performance varies based on the specific network environment in which Backup operates, in addition to Backup settings. Several factors external to Backup enter into performance calculations, including CPU speed, speed of data storage devices, the limitations of the network, and the volume of network traffic.

Within Backup, you can tune performance by changing the following attributes:

You can increase backup speed by setting Backup to multiplex (or interleaf) data on a storage device. That is, data from more than one save set can be written to a single storage volume, and data from one save set can be spread across multiple volumes. (Each save set that is multiplexed must, by definition, belong to the same pool of storage volumes.) Multiplexing optimizes and distributes the flow of data from multiple clients to all the storage devices that are available to Backup.

At recover time, performance can suffer because the data from one save set may have been written to several volumes.

Backup maintains the integrity of each save set's data through a function that codes and tracks data by a save set identification number (ssid). The extent of multiplexing that can occur on any storage device is defined by the device's value for Target Sessions.

It is often more efficient for Backup to multiplex multiple save sets to the same volume than to write each save set to a separate device. For this reason, Backup attempts to assign to each device a number of save sets up to the target value of sessions before assigning a save set to the next device.

Event Notification

Backup reports activity and status to the system administrator through several different programs and interfaces. Backup uses notifications to determine which events to report and how to report on those events.

Preconfigured Notifications

Backup includes many preconfigured notifications, which define the response of Backup to specific Backup events. The preconfigured notifications are described in "Notifications Resource ". You can edit the preconfigured notifications and create your own custom notifications. By selecting Details from the View menu in the nwadmin GUI, or Display Options from the Options menu, then Hidden, in the nsradmin interface.

Routine Data Movement Operations Reports

The degree of success in the completion of scheduled group backups, group cloning, and archive operations is reported to you by the savegrp program through a savegroup completion report. (This report is the action invoked by the preconfigured notification called Savegroup Completion.) The report is emailed to root and sent to the log file in /nsr/logs/messages. The report consolidates the following information:

A second report, sent to the Backup server's designated default printer, repeats the bootstrap information as hard copy, which you should keep on-hand in a secure location. (This printed report is the action invoked by the preconfigured notification called Bootstrap.) Disaster recovery is much easier to perform if you have access to the bootstrap information in the most recent printed report.

Backup provides the nsrinfo program, which enables you to query the contents of the Backup client file index. (Appendix B, Command Line Reference Utilities describes the most commonly used nsrinfo commands and options.)

Backup also provides the nsrwatch program, which enables you to use a character-based interface to monitor Backup activity as it occurs.

Storage Management Application Reports

Table 3-1 lists the programs that Backup provides to query the contents of the storage management system. (Appendix B, Command Line Reference Utilities describes the most commonly used commands and options in more detail.)

Table 3-1 Storage Management report Programs

Program Name 

Function 

mminfo

Generates a report that provides the contents and mode of the storage volumes and/or the identification numbers and status of the stored save sets 

mmlocate

Generates a report that provides the user-defined location of storage volumes 

nsrinfo

Generates a report that provides the contents of the client file index 

nsrmm

Generates a report that provides the status of the storage devices known to Backup 

Backup Server Statistics and Diagnostic Reports

Messages that report on Backup diagnostics are displayed in the Backup administrator interface and are also contained in the /nsr/logs/messages Backup messages file. These messages include warning and error conditions and notice of lost connections.

Message Log Files

The messages generated by the Backup server daemons (nsrd, nsrindexd, nsrmmdbd, and nsrmmd) are contained in the Backup messages log and the daemon.log file, typically found in the /nsr/logs directory.

Maintenance Tasks

This section contains tasks you might need to perform after you install and configure your Backup server.

Message Log Management

Backup stores the messages generated by the Backup server daemons in a message log file in the /nsr/logs directory. When the log file becomes too large, you have to delete some messages from the log. To automatically control the size of the log, you can use variables in the Backup startup script in the /etc directory or create a script that uses the operating system services.

How to Set the Startup Script to Trim Log Files

To modify the way that Backup services manage the Backup log files, change the following environmental variables in the Backup startup script, networker in the /etc/init.d directory before you start the nsrd daemon:

Every time nsrd starts, it checks the size of the daemon.log file. By default, when the daemon.log file reaches the 1024 KB limit, it is renamed daemon.001 and a new empty daemon.log is created. If the daemon.log file fills again, the names of each existing file shift so that the daemon.001 file is renamed daemon.002, daemon.log is renamed daemon.001, and a new empty daemon.log file is created. This process is repeated until the value in NSR_MAXLOGVERS is reached, at which point the highest numbered log is removed.

Caution - Caution -

The trimming mechanism only functions when you start nsrd. The nsrd daemon does not check periodically to see whether the log file has exceeded NSR_MAXLOGSIZE. If nsrd runs for a long time, the log file can still grow very large. To activate the trimming mechanism, enter nsr_shutdown to stop the Backup daemons, then restart the nsrd and nsrexecd daemons.

How to Use the Operating System Services to Trim Log Files

You can use the Solaris operating environment services to automatically manage the size of the Backup log files.

Solaris software provides a two-part mechanism for managing the syslog message file (/var/log/syslog): a shell script (/usr/lib/newsyslog) and a crontab entry for root to periodically invoke the script.

You can modify the newsyslog script to manage and maintain a short history of the Backup server's log file. The modified script maintains a three-file history of the Backup server`s daemon.log file.

To manage your Backup log file, follow these steps:

  1. Use your favorite text editor to add the following lines to /usr/lib/newsyslog:


    LOGDIR=/nsr/logs
LOG=daemon.log
if test -d $LOGDIR
then
    cd $LOGDIR
    test -f $LOG.1 && mv $LOG.1 $LOG.2
    test -f $LOG.0 && mv $LOG.0 $LOG.1
    test -f $LOG   && mv $LOG   $LOG.0
    cp /dev/null $LOG
    chmod 644 $LOG
fi

    Backup cannot use the new log file until you shut down and restart the Backup daemons. Shut down the daemons with the nsr_shutdown command, either manually or as an additional command in the newsyslog script. Make sure that the script does not run during a scheduled save. Then, restart Backup manually using the following commands:


    # /etc/init.d/networker start

  2. Add an entry to crontab for root to control the frequency of running the newsyslog script.

    The entry shown in the following example invokes the newsyslog script every Saturday morning at 4:05 a.m.:


    5 4 * * 6   /usr/lib/newsyslog

    If your Solaris system does not have the newsyslog script and crontab entry to invoke it, create the newsyslog script manually and add the crontab entry for it. See the crontab(1) man page for more information.

How to Move Your Backup Server License to a Different Machine

To move the Backup server license from one machine to another, follow these steps:

  1. Use Backup to perform a full backup of all the filesystems on the old Backup server.

  2. Shut down the Backup daemons on the old server, using the nsr_shutdown -a command.

  3. Make a tar tape of the entire /nsr directory from the old server, and reload it on the new server.

    If /nsr is a symbolic link on the old server, make sure the new server has the /nsr symbolic link setup also.

  4. Shut down your old server and disconnect all the devices.

  5. Shut down the new machine, add the hardware devices to the new server, and restart both machines. Start up the old machine first, and then the new one.

  6. Install Backup on the new server.

    If you have an autochanger, do not select the option to start the Backup daemons. Refer to the instructions in the Solstice Backup 5.1 Installation and Release Notes to learn how to install and test the Backup device drivers.

    Because you create a new host, you must correctly define the index entry for the new host before you start the Backup daemons. Correct the index entry using one of the two methods:

    • Name the new server with the same hostname as the old server at the operating system level before you modify client resources.

    • Create a new hostname for the new server with the same configuration choices as the old server.

    To create a new hostname for the new server, follow these steps:

  1. Create a new hostname for the new server with the same configuration choices as the old server.

  2. Delete the hostname entry for the old server.

  3. Shut down the Backup daemons on the old server and the new server:


    # nsr_shutdown -a

  4. Change to the directory containing the old server index entry:


    # cd /nsr/index

    The entry for the new server hostname is empty.

  5. Delete the entry for the new server hostname:


    # rmdir new-hostname

    You must remove this entry or the next step creates a subentry for the new server instead of the correct entry.

  6. Rename the old index directory to the new server hostname:


    # mv old-hostname new-hostname

    The Backup daemons start up on the new server.


    new-server syslog: Backup Server: (notice) started
new-server syslog: Backup Registration: (notice) invalid auth codes
detected.
new-server syslog:
new-server syslog: The auth codes for the following licenses enablers
are now invalid.
new-server syslog: The cause may be that you moved the Backup server
to a new computer.
new-server syslog: You must re-register these enablers within 15 days
to obtain new codes.
new-server syslog:
new-server syslog: License enabler #xxxxxx-xxxxxx-xxxxxx (Backup
Advanced/10)

    Reregister your new Backup server. After you move Backup from one system to another, you have 15 days to register the new server with SunSoft.

    To reregister your new server, refer to "How to Register and Authorize Your Software ".

    After you have successfully moved your server, follow these steps:

    1. Verify that all the clients are included in the scheduled backups.

    2. Use the Backup recover program to make sure all the client indexes are visible and, therefore, recoverable.

    3. Back up the indexes on the new server or perform a full backup of the new server as soon as possible.

    If you want to set up the old server as a client, first remove all the Backup software and the /nsr directory from the old server, then reinstall the Backup client software.