Export (0) Print
Expand All
Expand Minimize

Chapter 4 - Advanced Backup and Restore Operations

Updated: March 04, 2002

This chapter describes the advanced operations of the Galaxy system used in the Backup and Restore Solution for Windows 2000-Based Data Centers. These operations include Storage Area Network configuration, configuring the CommServe, MediaAgents, libraries and drives, and iDataAgents. Detailed instructions and guidelines for managing disaster recovery are also provided. This chapter is part of the Backup and Restore Solution for Windows 2000–based Data Centers.

On This Page

Introduction
Storage Area Network Configuration
CommServe
MediaAgent
Libraries and Drive Operations
Client Job Results
iDataAgents
Managing Disaster Recovery

Introduction

This chapter describes in detail the advanced operations of a Galaxy system, and includes procedures for configuring Galaxy components and the network, and for managing disaster recovery.

Storage Area Network Configuration

When you configure a storage area network (SAN), you must consider a number of configuration, addressing, and mapping issues, as well as errors that may occur during the processes that are involved.

SAN Configuration Overview

Here you can read about particular configuration issues that arise when Galaxy is used in a SAN environment. For general information on configuring Galaxy in a SAN environment, see the Galaxy Media Management Administration Guide.

The Basic SAN Setup

A SAN is a Fibre Channel (FC) network that is dedicated to carrying backup data. A SAN improves backup and restore performance and eases congestion on an enterprise's local area network (LAN), freeing it for normal business activities and communication.

You can configure your SAN environment to use the dynamic drive sharing (DDS) feature to share drives among multiple MediaAgents in a CommCell within a SAN environment.

Basic SAN components include the following:

  • Host Bus Adapter (HBA). Each computer that is attached to a fiber network needs a special adapter called an HBA, which can send and receive signals across FC cables.

  • Bridge, Router or Gateway. These pieces of equipment translate fiber signals to signals that can be understood by SCSI devices (fiber-to-SCSI communications) and vice versa. A gateway can also communicate between an FC network and native fiber devices (fiber-to-fiber communications). Bridges, routers, and gateways are used to connect servers and storage devices to the SAN.

  • Hub. In a Fibre Channel arbitrated loop (FC-AL), the hub is the fault-tolerant center of the network to which servers and storage devices are connected.

  • Switch. In the more complex network environment of switched fiber (see the following), the switch is the center of the fabric, or infrastructure, of the network. Servers and storage devices are connected to the switch, which is more intelligent and has more bandwidth than a hub.

Fibre Channel Configurations

There are two basic SAN configurations. Fibre Channel arbitrated loop (FC-AL) is a logical ring of fiber to which all of the devices are connected. It is created by connecting devices to a hub so that bandwidth and storage resources on the network are pooled and shared by all devices, as shown in Figure 4.1.

Figure 4.1: Fibre Channel Arbitrated Loop

Figure 4.1: Fibre Channel Arbitrated Loop

In a switched fiber (FC-SW) configuration, as shown in Figure 4.2, virtual loops are established between hosts and backup devices. Each host can have exclusive use of its virtually attached storage devices.

Figure 4.2: Fibre Channel Switched Fiber

Figure 4.2: Fibre Channel Switched Fiber

SAN Addressing Overview

For backup devices to be available to Galaxy, the system must know which physical device is mapped to a given SCSI address. When a MediaAgent is directly attached to a storage device, the SCSI address is determined by the physical SCSI connection, and the SAN adds an FC network between the MediaAgent and the SCSI backup device. However, the MediaAgent and the backup device still use the SCSI protocol to communicate across the FC network. Consequently, the MediaAgent still needs to be able to associate each physical device with a SCSI address.

A SCSI address includes three identifiers. Table 4.1 lists the components of a SCSI address and its counterparts in the FC-SW and FC-AL addressing schemes.

Table 4.1 SCSI address components

SCSI address component

FC-AL*

FC-SW

Bus

Loop

Fabric

Target

Arbitrated Loop Physical Address (AL_PA)

Port_ID

Logical Unit Number (LUN)

LUN

LUN

* Conceptually, both a loop and a fabric represent collections of addressable devices. In practice, this part of the address is generally the same as the port number of the HBA that connects the host to the FC network.

SCSI-LUN Mapping Guidelines for SAN Libraries

Note: See your hardware manufacturer's documentation for instructions on setting SCSI targets for storage devices and SCSI-to-FC address mapping for SAN routers.

The SCSI target guidelines that follow are recommendations that can make system administration easier—they are not requirements. However, the LUN guidelines must be followed in order for the system to function properly.

SCSI Target Guidelines

You should observe the following guidelines when assigning SCSI targets to storage devices that are attached to a SAN:

  • Assign each medium changer to a SCSI target that is lower than those of the targets of its drives.

  • When setting the SCSI targets, you should assign SCSI target numbers in ascending order, in accordance with the physical drive location. That is, the drive that has the physical address with the lowest number (for example, Drive 0) gets the lowest SCSI target, while the drive that has the physical address with the highest number (for example, Drive 4) gets the highest SCSI target, with remaining drives assigned in sequence. A good convention to use, when possible, is to set the library medium changer to 0, the first drive to target 1, the second drive to target 2, and so on.

    Note: Physical drive locations are numbered differently depending on the library. The first drive in one library may be 0, whereas in another library it may be 1. See the manufacturer's documentation for details on your library.

  • If multiple SCSI ports are to be attached to a single library, you should attach the SCSI ports in order of the physical device sequence. For example, connect the first SCSI port to the medium changer and drives 1 and 2; the next SCSI port to drives 3 and 4, and so on.

  • Try to assign a unique SCSI target to each device, even for devices on different SCSI ports. Doing so can make it easier to identify the drives later, should that become necessary.

Fibre Channel LUN Guidelines

The following guidelines must be observed when assigning Fibre Channel LUNs to storage devices that are attached to a SAN:

  • Assign each medium changer to a LUN that has a lower number than that of the LUNs of its drives. Otherwise, drives may be associated with the wrong library or incorrectly detected as stand-alone drives.

  • For each router, start with zero when assigning LUNs and continue in ascending sequence. Do not skip any numbers in the sequence. If possible, match the LUN to the SCSI target of the device.

    The following figures show several scenarios that demonstrate the SCSI target and LUN guidelines.

Figure 4.3: Single-router, multiple-library configuration

Figure 4.3: Single-router, multiple-library configuration

Figure 4.3 shows the configuration for a single router that is connected to multiple libraries. Pictured from left to right, the figure shows the following: A MediaAgent contains an HBA that connects it to a SAN router through a Fibre Channel switch. Within the fiber network, SAN devices are addressed by Fibre Channel LUNs, which are set through the LUN mapping interface provided by the manufacturer of the router. The router is connected through SCSI buses and cables to two libraries. Within the libraries, each device has a SCSI target, which is set through the interface provided by the manufacturer of the library. Note the following guidelines in operation:

  • SCSI Target. When you assign SCSI targets, assign target 0 first, and assign the rest in ascending order. The lowest target within each library is assigned to the library's medium changer.

  • LUN. When you assign Fibre Channel LUNs, assign 0 first, followed by contiguous LUNs assigned in ascending order.

Figure 4.4 depicts only those aspects of the SCSI and FC addresses that are commonly configured by the user. 3 shows the complete address translations that are performed by the router between SCSI addresses (Bus, Target, LUN) and Fibre Channel addresses (Loop, AL_PA, LUN), and the reverse translations that are performed by the MediaAgent's HBA. The left-most SCSI addresses are the ones by which the SAN devices are identified in the Galaxy Library and Drive Configuration utility. For additional information on this utility, see the Galaxy CommCell Media Management Guide.

Note that values of zero have been assigned to Loop, AL_PA, and the SCSI bus and target in the address on the left, as shown in Figure 4.4. The actual values depend on the SAN configuration.

Figure 4.4: Single router, multiple library address translations

Figure 4.4: Single router, multiple library address translations

The configuration for multiple routers and a single library, shown in Figure 4.5, can maximize performance for a library containing many drives.

Figure 4.5: Multiple router, single library configuration

Figure 4.5: Multiple router, single library configuration

Pictured from left to right, the figure shows the following: a MediaAgent contains an HBA that connects it to a SAN switch by using a Fibre Channel network. The switch is connected to two SAN routers. Within the fiber network, SAN devices are addressed by Fibre Channel logical unit numbers (LUNs), which are set through the LUN mapping interface provided by the manufacturer of the router. The router is connected by using SCSI buses and cables to a single library containing six drives. Within the library, each device has a SCSI target, which is set by using the interface provided by the manufacturer of the library. Note the following guidelines in operation:

  • SCSI Target. When assigning SCSI targets, assign target 0 first, and assign the rest in ascending order. The lowest target within the library is assigned to the library's medium changer. If the library had additional drives, target 7 would be skipped, because the SCSI controller uses SCSI ID 7 by default, and the assignments continue with target 8.

  • LUN. When assigning Fibre Channel LUNs, assign 0 first, and assign the remaining contiguous LUNs in ascending order. Restart LUN numbering with the second router.

Figure 4.5 depicts only those aspects of the SCSI and FC addresses that are commonly configured by the user. Figure 4.6 shows the complete address translations that are performed by the router between SCSI addresses (Bus, Target, LUN) and FC addresses (Loop, AL_PA, LUN), and the reverse translations that are performed by the MediaAgent's HBA. The SCSI addresses on the left are the ones by which the SAN devices are identified in the Galaxy Library and Drive Configuration utility. (For information on using this utility, see the Galaxy CommCell Media Management Guide.) Each router is represented in the addresses on the left as a separate SCSI target.

Figure 4.6: Multiple router, single library - address translations

Figure 4.6: Multiple router, single library - address translations

Note that in Figure 4.6, values have been assigned to Loop, AL_PA, and the SCSI bus and target in the address on the left. The actual values depend on the system configuration.

Avoiding Common SAN Errors

In setting up a SAN for use by Galaxy, the essential goal is to ensure that each physical device is represented in the CommCell by one, and only one, SCSI address (bus, target, and LUN), and that this SCSI address remains consistent through all layers of the SAN, at all times. If a single device is represented by multiple SCSI addresses, or if multiple instances of a single address for a device exist within the network, resource contention can result when different MediaAgents attempt to use the same drive simultaneously.

Uniform Addressing Across Devices

Within the FC network, the routers, bridges, or gateways that are physically connected to storage devices translate the SCSI addresses of those devices to the LUNs that are used by the FC network.

Each MediaAgent that is attached to the SAN contains an HBA. Among other functions, the HBA translates the FC addresses generated by the router back to SCSI addresses and makes these addresses available to the MediaAgent. Different HBAs use different algorithms to map FCs to SCSI addresses. This can result in a single drive appearing under two different identifiers in the Galaxy Library and Drive Configuration utility, and can cause resource-contention problems.

In addition, different routers, gateways, and bridges may use different SCSI-to-FC mapping algorithms.

Note: To ensure that the SCSI addressing convention is the same for all devices in the SAN, all MediaAgents attached to a SAN must use the same brand and model HBA, and the same driver and firmware revisions. Furthermore, all routers must be of the same brand and model. The drivers and firmware should be the newest available.

Avoiding Dynamic Address Changes

An FC address can change at either the AL_PA/Port_ID level or at the LUN level. In either case, the HBA-translated SCSI address of affected devices changes as well. If the SCSI address of a configured device changes, Galaxy is unable to access the device. The sections that follow show how to maintain address stability within your SAN.

AL_PAs and Port_IDs

AL_PAs and Port_IDs can be set in one of two ways:

  • Hard addressing. This addressing scheme requires that you manually set switches on a device to assign it a permanent AL_PA. (A Port_ID includes the AL_PA plus information about the fabric port to which the device is attached.)

  • Soft addressing. If you use this scheme, AL_PAs are automatically assigned to fiber devices (for example, routers, gateways, HBAs, and so on) when they are attached to the network. However, if devices are added or removed, the addresses of other devices in the network may be reassigned, rendering these devices inaccessible to Galaxy. If the AL_PA of a router changes, all attached libraries become inaccessible to Galaxy.

Soft addresses can be assigned even when you use hard addressing. If the switches on two devices are set for the same AL_PA, the first device detected by the network is assigned that address, while the second device is assigned a soft address.

Note: To ensure that AL_PAs won't change, use hard addressing and make sure that each device is assigned a unique AL_PA. To ensure that Port_IDs won't change, follow the AL_PA guidelines. In addition, do not change the fabric ports of configured devices.

Some gateways do not work well with FC switches unless you enable soft addressing. Also some of the SAN gateways do not allow you to disable soft addressing. Enable soft addressing in both these circumstances.

LUNs

Fibre Channel LUNs are set by bridges, routers, and gateways, which translate the SCSI addresses (SCSI port, target, and LUN) of attached devices to FC addresses. Routers have two addressing modes:

  • Manual. This addressing scheme requires that you manually set the LUN for each device that is attached to the router.

  • Automatic. In this addressing scheme, the router automatically assigns LUNs to attached devices. However, if devices are added or removed, the addresses of other attached devices may be reassigned. Consequently, Galaxy is unable to access the device.

LUNs must start from zero. They must also be sequential and contiguous (that is, they must not skip numbers).

Note: To ensure that the LUNs of devices that are attached to a router will not change, use manual addressing. Make sure that each device is assigned a unique LUN, and that LUNs start from zero and are sequential and contiguous. When you first configure your SAN, you may want to use automatic addressing to ensure that LUNs meet these criteria. You can then switch to manual mode to set the same addresses that were automatically assigned by the router.

SAN Configuration Summary

The following are the essential SAN configuration principles that have an impact on the ability of Galaxy to successfully detect and use SAN storage devices:

  • All MediaAgents attached to a SAN must use the same brand and model HBA, as well as the same driver and firmware revisions; all routers must also be of the same brand and model. This ensures that the same Fibre Channel-to-SCSI address translation is used for all devices in the SAN.

  • The latest firmware and device driver versions must be used.

  • Hard addresses must be used rather than soft addresses to ensure that AL_PAs and Port_IDs will not change.

  • Each device is assigned a unique AL_PA.

  • The fabric port of configured devices that are attached to a switched network must not be changed.

  • The sequential, contiguous LUN order, starting at 0 (assumed by operating systems), must be preserved when you set AL_PAs in manual mode.

  • Manual addressing mode must be used to prevent SAN routers from changing LUNs when the SCSI configuration changes.

  • For easier system administration, SCSI configuration guidelines should be followed when setting SCSI targets for storage devices.

CommServe

Many aspects of the CommServe either require configuration or can be configured according to your specific backup and restore solution.

License Administration

Each component of Galaxy (MediaAgents, libraries, and clients) requires a license for use. When you purchase Galaxy, an installation license is provided with the Galaxy software. This initial installation license applies to the entire CommCell, specifying a license type and count for each CommCell component within the CommCell configuration. The CommServe component does not contain a separate license type and count; it is automatically included in the CommCell configuration.

The Galaxy License Administration feature performs the following functions:

  • Displays and updates all licensing information.

  • Keeps track of installed components.

License information for the entire CommCell, including the type and number of the components installed, is displayed in the License Administration window. When a component is installed or uninstalled, the count of that license type is updated to reflect the new configuration.

Updating the CommServe IP Address

If the CommServe IP address is updated, the CommServe license must also be updated. An updated license must be obtained from CommVault Support before the address is changed. CommVault Support will assist in the process of changing the IP address and updating the license through license administration.

License Types

Galaxy uses the following types of licenses in various situations:

Table 4.2 Galaxy license types

License type

Description

Evaluation license

An evaluation license can be used to install a Galaxy CommCell initially. You can continue to use Galaxy for evaluation for the duration of the license.

Permanent license

There are two types of permanent licenses: Installation is used for new CommCell installations Release upgrade is used to upgrade your Galaxy installation from one major release to another.

Update license

Update licenses are permanent and are used to do the following: Convert an evaluation license to a permanent license.
Add components to an existing Galaxy software installation.
Support change of the CommServe IP address.
Maintain the license database.
Update licenses are permanent in nature.

Note: Contact your Galaxy software provider for instructions on obtaining and using a license. After you have obtained the license, follow the instructions to update your existing license.

Keep the installation license file in a safe place; you may need the file if you ever need to perform ExpressRecovery.

License Administration

The Galaxy License Administration feature allows you to examine and update an existing license.

The License Administration window displays the following information:

  • If and when the license will expire.

  • The types of licenses installed on the CommCell.

  • The total number of each license type.

  • The number of used licenses for each type.

The following procedures explain how to view and update licenses.

To open the License Administration window

  1. In the CommCell Browser, right-click the CommServe and then click License Administration.

  2. The License Administration window indicates the status of existing licenses for the CommCell and its Galaxy software components:

This window may include the following items:

Table 4.3 Items displayed in the License Administration window

Item

Type of data displayed

CommCell ID

A unique serial number for this CommCell

CommServe ID

The IP address of the CommServe computer.

Activation Key

An automatically-generated key for the most current version of the license file.

OEM ID

A unique identifier number of the original equipment manufacturer (OEM) manufacturer. This applies only when the existing CommCell license is an Evaluation license.

OEM License Type

A type of license issued for this OEM. This applies only when the existing CommCell license is an Evaluation license.

Expiration Date

Expiration date of the CommCell license. This applies only when the existing CommCell license is an Evaluation license. After the license expires, Galaxy operations will fail.

License Type

Indicates the Galaxy software component for the specific application (iDataAgent for the Microsoft® Windows® 2000 operating system, MediaAgent for Windows 2000, library control module, and so on).

Total

The total number of licenses for this license type.

Used

The number of licenses in use for this license type.

Expiration Date (for CommCell components)

The expiration date, if applicable, for the listed license type; permanent licenses never expire.

Note: Columns in the License Administration window can be sorted by clicking on the column header.

Updating a License

You can use the License Administration feature to update a Galaxy license in the following situations:

  • To extend the evaluation copy.

  • To update the evaluation license to a permanent license. This enables Galaxy operations to continue uninterrupted beyond the expiration date of the Evaluation license.

  • To add software components (for example, a MediaAgent) to, or increase the license copy numbers of, an existing CommCell.

  • To update the IP address of the CommServe computer.

There are two ways to update a CommCell license: by using the Galaxy Console or by using the command line in a command prompt when the Galaxy Console is unavailable.

To update the CommCell license by using the Galaxy Console

  1. Insert the disk containing the updated license file into the CommServe computer's disk drive.

  2. In the License Administration window, click Update License.

  3. In the Open dialog box, specify the location of the license file and then click Open.

    When finished processing, the system indicates success or failure of the license update as follows:

    • Success: The License Administration window refreshes automatically with new data.

    • Failure: A pop-up window appears, stating that the update failed.

    Note: If the License Administration window does not automatically refresh, close it and reopen it.

  4. If successful, click OK. (If not, contact your Galaxy software provider.)

License Validity and the CommServe IP Address

If you change the CommServe IP address after you have installed the Galaxy software, the CommCell license becomes invalid. This may render the Galaxy software inoperable until you update the license with the new IP address. To update the license, you must obtain an IP Address Change license from your Galaxy provider and follow the instructions in "Updating a License" earlier in this chapter.

Anticipating License Expiration

If you have not converted the CommCell installation license to a permanent license, and you want to know when the installation license will expire, you can check the expiration date from the CommCell Console. Use the Galaxy Event Viewer, which displays license expiration information at a set time before the license actually expires. The event viewer logs a major event if the CommServe license is going to expire within 10 days. The event message is triggered by any type of backup, including synthetic full.

Responding to License Expiration

If the installation license expires, one or more symptoms may result. You can determine the cause of these symptoms by checking the Event Viewer or various log files in the \Galaxy\Log Files folder, as indicated in the following tables. If the installation license has expired for any reason, contact your Galaxy software supplier for instructions. The following list identifies these symptoms:

  • Backups will not run. If this is the only symptom, check for iDataAgent license expiration as follows:

    • Check the Event Viewer for: failure to initialize backup request, invalid or no license for application type app_type. Application name is app_name.

    • Check the JobManager.log file for an expired application license evaluation date.

  • The MediaAgent will not restart. In this scenario, check for MediaAgent license expiration as follows:

    • Check the Event Viewer for an expired application license evaluation date.

    • Check the cvd.log file for an expired application license evaluation date.

  • Only the Event Manager service (Evmgrs) and the Galaxy Console are activated. In this scenario, update the license from the Galaxy Console.

  • The license has expired. Obtain either a purchase license or an extended license from CommVault Systems. Then update your license from the Galaxy Console.

Destination of CommServe ExpressRecovery Backups

The ExpressRecovery backup destination must be a directory specified by a Universal Naming Convention (UNC) network path, preferably within the Windows domain of the CommServe computer. If you specify a drive outside the CommServe's Windows domain, you will need to configure the share to allow ExpressRecovery backups to be written.

Note: We strongly recommend that you write down the destination of your ExpressRecovery backups and keep this information in a secure location.

The destination path cannot be local to the CommServe computer because, while it is possible to direct ExpressRecovery backups to the CommServe's local hard drive, you may be unable to rebuild the CommServe if the computer's hardware fails. Also, the path cannot be a mapped network drive.

You should also reserve enough space on your backup drive for ExpressRecovery backups. The recommended amount of space is 1 gigabyte (GB), although this will vary from system to system. Initially, you probably will not need this much space. However, because an ExpressRecovery backup contains a dump of the Microsoft SQL Server™ database, backups can eventually grow to take up as much space as the database.

ExpressRecovery backups will run only when the SQL Server is run as a System Account. If ExpressRecovery backups have failed from the start, check the services panel to determine whether the SQL Server is set up to log in with a System Account. If the setting is specified differently and the SQL Server brings the Galaxy services down, change the SQL Server service to run from the System Account, restart the SQL Server service, and then restart Galaxy services.

Generally, one ExpressRecovery backup per day per system is sufficient. However, this depends on the retention periods and pruning schedules that you implement for your backups. As a rule of thumb, for each additional ExpressRecovery backup that you want, you should allocate an additional GB of space. If your ExpressRecovery backups start to fail, the appropriate message will be displayed; in such a case, check the amount of available space on your backup drive.

You initially set the backup destination during CommServe installation; however, you can change the destination at any time from the ER Backup tab of the CommCell Properties dialog box.

The backup destination path you enter determines the destination of the next full ExpressRecovery backup. Differential backups are always sent to the same directory as the last full backup.

If you change the backup destination without running a full ExpressRecovery backup, the first backup will by default be converted to a full backup.

If you enter a non-local destination directory for ExpressRecovery backups during the CommServe installation, then you must enter the user name and password of the account that Galaxy will use to access the backup directory, after the installation/upgrade is completed. This account must be a domain account that has access privileges for the backup destination directory. (You can enter the user name and password on the ER Backup tab of the CommCell Properties dialog box.)

You cannot change the ExpressRecovery destination that was entered during installation until an ExpressRecovery user account is entered by using the General tab of the CommCell Properties dialog box. This is true whether the original destination is local or remote, and whether the new backup destination is local or remote. If you change the ExpressRecovery destination to a new non-local destination, make sure that you change the account to a domain account with access to the new destination.

Note: You should check the Galaxy Event Viewer regularly so that you will be aware of any problems associated with ExpressRecovery backups.

To set or change the ExpressRecovery backup destination

To perform this procedure you must have Administrative Management permissions on the Galaxy system:

  1. In the CommCell Browser, right-click the CommServe, and then click Properties.

  2. In the CommCell Properties dialog box, on the ER Backup tab, in the Back Up Metadata to box, enter a backup path either by clicking Browse or by typing the path. The directory must be a valid UNC network path in the UNC format:

    \\server\share\path

Galaxy Service Control Manager

While the procedures in this chapter describe how to start and stop Galaxy services, we recommend that the services remain running at all times. You should avoid stopping Galaxy services whenever possible, and make sure to review and thoroughly understand all procedures in this chapter before you attempt to implement them.

By default, all Galaxy services start automatically when you start a system that has the Galaxy software installed.

Note: Galaxy services must be running in order for backups, restores, and all Galaxy jobs to run properly. Generally, you should leave all Galaxy services running.

When you stop Galaxy services on a given system, the functions that depend on that system's services will no longer be available to the rest of the CommCell. As documented throughout this chapter, it is strongly recommended that you suspend or kill all jobs prior to stopping any Galaxy services. Any interrupted auxiliary copy jobs will need to be restarted after stopping and restarting Galaxy services. Stopping either the CommServe services or the base services will stop all Galaxy operations that depend on that CommServe. Because all Galaxy services depend on the base services, stopping the base services stops all Galaxy services.

Galaxy Service Configurations

As Table 4.4 shows, all Galaxy computer configurations must include at least the base services. Then, depending on which Galaxy components (for example, CommServe and MediaAgents) are installed, their corresponding Galaxy services apply as well. If several Galaxy components are installed on a given computer, then that computer hosts all associated services.

Table 4.4 Galaxy components and services

For these Galaxy components

These Galaxy services apply

... which include the following services

Client only (any Galaxy system)

Galaxy base services

Galaxy Client Event Manager
Galaxy Communications Service

CommServe only

Galaxy base services

Galaxy Client Event Manager
Galaxy Communications Service

 

Galaxy CommServe Services

Galaxy Application Manager
Galaxy Job Manager
Galaxy Media & Library Manager
Galaxy Server Event Manager

MediaAgent only

Galaxy Base Services

Galaxy Client Event Manager
Galaxy Communications Service

 

Galaxy MediaAgent Services

Galaxy Media Mount Manager
Drive Management Service (DMS)
Library Management Service (LMS)
NOTE LMS and DMS apply only to non- Removable Storage Manager (RSM) tape and optical libraries.

Galaxy Service Dependencies

When a Galaxy system has more than one Galaxy component, the Galaxy service dependencies are as shown in Table 4.5.

Table 4.5 Galaxy service dependencies

Using the Galaxy Service Control Manager to do the following:

Has the following effect:

Stop all Galaxy services

Stops all Galaxy services on that system.

Start all Galaxy services

Starts all Galaxy services on that system.

Stop the base services

Stops all Galaxy services on that system because all Galaxy services depend on the base services.

Start the base services

Starts only the base services.
Restarting the other Galaxy services can be done individually or by restarting all services simultaneously.

Stop the CommServe services

Stops only the CommServe services.
Operations for all Galaxy resources that depend on that CommServe are stopped.

Start the CommServe services

Starts the base and CommServe services.

Stop the MediaAgent services

Stops only the MediaAgent Service.

Start the MediaAgent services

Starts the base and the MediaAgent Services.

Controlling the Galaxy Services

Because a system's Galaxy component configuration (CommServe, MediaAgent, client computer) determines which Galaxy services will be running on that system, you will need to choose the procedure(s) most appropriate for each system on which you intend to stop the Galaxy services:

  • Starting and stopping all Galaxy services (strongly recommended)

  • Starting and stopping the base services

  • Starting and stopping the CommServe services

  • Starting and stopping the MediaAgent services

Note: You can use either the Galaxy Service Control Manager or the Windows Services dialog box to view the status of the Galaxy services. To stop and start Galaxy services, however, use only the Galaxy Service Control Manager, and follow the appropriate procedure.

Starting and Stopping All Galaxy Services

The following procedures describe how to stop and restart all Galaxy services on a local system. The option to stop all Galaxy services stops all the Galaxy services on the local computer, no matter which components are installed (for example, CommServe or client). This option is particularly useful if several components are installed and you want to stop the Galaxy services for all of them.

Before you begin, use the Job Controller to suspend or kill all jobs. Alternately, you can wait for a job to complete.

To stop all Galaxy services

  1. Click Start, point to Programs, click Galaxy and then click Galaxy Service Control Manager.

  2. In the Galaxy Service Control Manager dialog box, in the Services field, click Galaxy Base Services.

  3. By default, the Auto-Start Services when OS Starts option is selected, meaning that all Galaxy services applicable to the local system will start automatically when the system is restarted. If you prefer to start all Galaxy services manually, clear this option to disable the auto-start feature.

  4. Click Stop to stop all Galaxy services.

    When the services are stopped successfully, the Galaxy Service Control Manager dialog box updates the All Galaxy Services status from Running to Stopped.

  5. Optionally, you can verify which services you have stopped by clicking Services in Control Panel.

To start all Galaxy services

  1. Click Start, point to Programs, click Galaxy and then click Galaxy Service Control Manager.

  2. In the Galaxy Service Control Manager dialog box, in the Services field, click Galaxy Base Services.

  3. By default, the Auto-Start Services when OS Starts option is selected, meaning that all Galaxy services applicable to the local system will start automatically when the system is restarted. If you prefer to start all Galaxy services manually, clear this option to disable the auto-start feature.

  4. Click Start to restart all Galaxy services.

    When the services are restarted successfully, the Galaxy Service Control Manager dialog box updates the All Galaxy Services status from Stopped to Running.

  5. Optionally, you can verify which services you have restarted by clicking Services in Control Panel.

  6. Resume any jobs you suspended prior to stopping all Galaxy services.

Starting and Stopping the Base Services

The following procedures describe how to stop and restart the base services.

Note: Stopping the base services stops all Galaxy services (for the local system) automatically; however, restarting the base services does not automatically restart all Galaxy services. After stopping the base services, therefore, you can restart all Galaxy services or restart each service separately (base, CommServe, and MediaAgent).

Before you begin, use the Job Controller to suspend or kill all jobs. Alternately, you can wait for a job to complete.

To stop the base services

  1. Click Start, point to Programs, click Galaxy and then click Galaxy Service Control Manager.

  2. In the Galaxy Service Control Manager dialog box, in the Services field, click Galaxy Base Services.

  3. By default, the Auto-Start Services when OS Starts option is selected, meaning that all Galaxy services applicable to the local system will start automatically when the system is restarted. If you prefer to start all Galaxy services manually, clear this option to disable the auto-start feature.

  4. Click Stop to stop the base services.

  5. When prompted to continue, click Yes only if it is acceptable to stop the other services. When the base services are stopped successfully, the Galaxy Service Control Manager dialog box updates the Galaxy Base Services status from Running to Stopped.

  6. Optionally, you can verify which services you have stopped by clicking Services in Control Panel.

To start the base services

  1. Click Start, point to Programs, click Galaxy, and then click Galaxy Service Control Manager.

  2. In the Galaxy Service Control Manager dialog box, in the Services field, click Galaxy Base Services.

  3. By default, the Auto-Start Services when OS Starts option is selected, meaning that all Galaxy services applicable to the local system will start automatically when the system is restarted. If you prefer to start all Galaxy services manually, clear this option to disable the auto-start feature.

  4. Click Start to restart the Base services. When the base services are restarted successfully, the Galaxy Service Control Manager dialog box updates the Galaxy Base Services status from Stopped to Running.

  5. Optionally, you can verify which services you have stopped by clicking Services in Control Panel.

  6. Resume any jobs you suspended prior to stopping the base services.

Stopping and Starting the CommServe Services

The following procedures describe how to stop and restart the CommServe services.

Note: Stopping the CommServe services also stops all Galaxy operations within the CommCell.

Before you begin, use the Job Controller to suspend or kill all jobs. Alternately, you can wait for a job to complete.

To stop the CommServe services

  1. Click Start, point to Programs, click Galaxy, and then click Galaxy Service Control Manager.

  2. In the Galaxy Service Control Manager dialog box, in the Services field, click Galaxy CommServe Services.

  3. By default, the Auto-Start Services when OS Starts option is selected, meaning that all Galaxy services applicable to the local system will start automatically when the system is restarted. If you want to start all Galaxy services manually instead, clear this option to disable the auto-start feature.

  4. Click Stop to stop the CommServe services. When the CommServe services are stopped successfully, the Galaxy Service Control Manager dialog box updates the Galaxy CommServe Services status from Running to Stopped.

  5. Optionally, you can verify which services you have stopped by clicking Services in Control Panel.

To start the CommServe services

  1. Click Start, point to Programs, click Galaxy, and then click Galaxy Service Control Manager.

  2. In the Galaxy Service Control Manager dialog box, in the Services field, click Galaxy CommServe Services.

  3. By default, the Auto-Start Services when OS Starts option is selected, meaning that all Galaxy services applicable to the local system will start automatically when the system is restarted. If you want to start all Galaxy services manually instead, clear this option (to disable the auto-start feature).

  4. Click Start to restart the CommServe services. When the CommServe services are restarted successfully, the Galaxy Service Control Manager dialog box updates the Galaxy CommServe Services status from Stopped to Running.

  5. Optionally, you can verify which services you have started by clicking Services in Control Panel.

  6. Resume any jobs you suspended prior to stopping the CommServe services.

Stopping and Starting the MediaAgent Services

The following procedures describe how to stop and restart the Galaxy services that apply to the MediaAgent.

Note: Stopping or starting the MediaAgent services stops or starts only the Galaxy Media Mount Manager service, DMS, and LMS; that is, operations for all Galaxy resources that depend on that MediaAgent are stopped or started.

Before you begin, use the Job Controller to suspend or kill all jobs. Alternately, you can wait for a job to complete.

To stop the MediaAgent services

  1. Click Start, point to Programs, click Galaxy, and then click Galaxy Service Control Manager.

  2. In the Galaxy Service Control Manager dialog box, in the Services field, click Galaxy MediaAgent Services.

  3. By default, the Auto-Start Services when OS Starts option is selected, meaning that all Galaxy services applicable to the local system will start automatically when the system is restarted. If you want to start all Galaxy services manually instead, clear this option to disable the auto-start feature.

  4. Click Stop to stop the MediaAgent services. When the MediaAgent services are stopped successfully, the Galaxy Service Control Manager dialog box updates the Galaxy MediaAgent Services status from Running to Stopped.

  5. Optionally, you can verify which services you have stopped by clicking Services in Control Panel.

To start the MediaAgent services

  1. Click Start, point to Programs, click Galaxy, and then click Galaxy Service Control Manager.

  2. In the Galaxy Service Control Manager dialog box, in the Services field, click Galaxy CommServe Services.

  3. By default, the Auto-Start Services when OS Starts option is selected, meaning that all Galaxy services applicable to the local system will start automatically when the system is restarted. If you want to start all Galaxy services manually instead, clear this option to disable the auto-start feature.

  4. Click Start to restart the MediaAgent services. When the MediaAgent services are restarted successfully, the Galaxy Service Control Manager dialog box updates the Galaxy MediaAgent Services status from Stopped to Running.

  5. Optionally, you can verify which services you have started by clicking Services in Control Panel.

  6. Resume any jobs you suspended prior to stopping the MediaAgent services.

Operation Window

An operation window is a daily time period when a specific type of operation is allowed to occur. The main purpose of this feature is to help you prevent an unexpected, time-consuming operation from disrupting normal operations. Operation windows can be established either for the entire CommCell or for a specific iDataAgent. By default, all operations can be conducted at any time.

If a job is submitted outside of its window of operation, Galaxy puts the job into a pending status until the window of operation becomes valid. (This is reflected in the job's pending status in the Job Controller window.) For example, if you restrict backups to a 6:00 P.M. to 7:00 A.M. operation window, a backup that is scheduled for 1:00 P.M. remains pending until 6:00 P.M.

If a job is started within its window of operation, but does not complete before the operation window expires, Galaxy manages the job in one of the following ways:

  • Restartable jobs (it can be stopped and restarted at the point of suspension), are put into a pending status when the window expires, then restarted when the window of operation becomes valid again. In the preceding example, if a backup is still running when the 7:00 A.M. operation window expires, Galaxy suspends it until the next backup operation window begins at 6:00 P.M.

  • Non-restartable, are allowed to run to completion.

CommCell Operation Windows

You can establish operation windows for the entire CommCell from the Operation Window tab of the CommCell Properties dialog box. Table 4.6 lists the options that can be included in this tab.

Table 4.6 Operations Window options

All Backups

Defines the daily time period during which any backup (other than full) can occur.

Full Backups

Defines the daily time period during which a full backup can occur. To be effective, this operation window must be within the All Backups operation window at the CommCell level.

Synthetic Full Backups

Defines the time period in which Synthetic Full backup operations can occur. To be effective, this operation window must be within the All Backups operation window at the CommCell level. For information on Synthetic Full backups, see the online Help for the iDataAgents that support this backup type.

ExpressRecovery Backups

Defines the time period during which ExpressRecovery backups can occur.

Restores

Defines the daily time period during which standard restore operations can occur.

Auxiliary Copies

Defines the time period in which auxiliary copy operations can occur.

Also included under this tab is the time zone for the CommServe (for example, Eastern Standard Time).

To set an operation window at the CommCell level

To carry out this procedure, you must have Administrative Management permissions on the Galaxy system.

  1. In the CommCell Browser, right-click CommServe, and then click Properties.

  2. On the Operation Window tab, set the desired starting and ending times of the operation windows.

iDataAgent Operation Windows

Operation windows can be established at the iDataAgent level for backup and restore operations.

When specified at the iDataAgent level, the operation windows apply only to those operations that originate from the specified iDataAgent. The operation windows that are established at the CommCell level apply across the entire CommCell. If you establish operation windows at both levels for any given operation, the effective operation window becomes the times in common to both levels; for example, if restores are permitted between 1:00 P.M. and 5:00 P.M. at the CommCell level and between 2:00 P.M. and 6:00 P.M. for a given iDataAgent, the effective operation window for restores is between 2:00 P.M. and 5:00 P.M. for that iDataAgent. Restores that originate from some other iDataAgent are still valid between 1:00 P.M. and 5:00 P.M. (that is, the CommCell operation window), provided a restore operation window for that iDataAgent does not exist.

For additional details on the operation windows established at the iDataAgent level, see online Help for iDataAgent-specific information.

Job Priorities

Galaxy job priorities are used to determine which of several competing jobs can access limited resources (such as media drives and backup media); the job with the highest priority gets the resources. When multiple jobs have the same priority, resources are allocated on a first-come, first-served basis. When a job completes, the system allocates the newly freed resources to the next job. If a job fails, the system attempts to restart it one hour later and as many as 72 times (default settings).

The way that Galaxy manages jobs is also influenced by the job category: restartable or non-restartable. If a running job is using resources needed by another job with a higher priority, Galaxy will manage the jobs in one of two ways:

  • If the running job is restartable, Galaxy interrupts the running job and then allocates the resources to the higher-priority job. (The interrupted job enters a waiting state and then resumes when the resources it needs become available.)

  • If the running job is not restartable, it runs to completion, regardless of priority of the new job.

Note: Archive pruning jobs cannot start when restores, backup index restores, or auxiliary copy operations are in progress.

Job Priority Overview

When any job is started, the Galaxy Job Manager assigns the job a priority number: the lower the number, the higher the priority. The priority of a given job is based on the following:

  • Priority of the operation type

  • Priority of the client computer that is performing the operation

  • Priority of the type of iDataAgent from which the operation originated

  • Priority precedence (the weighting of the priority of the client computer relative to the priority of the iDataAgent)

Job Priority Number

Each job priority number is based on a three-digit integer; leading zeroes are suppressed. Each digit within this number represents a different priority field as shown in Figure 4.7.

Figure 4.7: Job Priority Numbers

Figure 4.7: Job Priority Numbers

The first digit represents the priority of the job operation. The second and third digits, by default, represent the priorities of the client computer and iDataAgent respectively. You can also change their order of precedence so that they represent the priorities of the iDataAgent and client computer respectively. The following sections discuss each of these topics is greater detail.

Operational Priority

Galaxy assigns priorities for all operation types. These priorities, which represent the first and most significant digit of the three-digit priority number, are fixed and cannot be changed. The priority assignments are shown in Table 4.7; note that restore operations have the highest priority, and Synthetic Full backups have the lowest.

Table 4.7 Operational priorities

Job operation

Assigned priority

Restores

0

Backups

1

Synthetic Full

3

Client Computer Priority

By default, Galaxy assigns the same priority (9 – the lowest) to all client computers. As a result, the Job Manager evaluates all client computers as having the same priority. If desired, you can change the priority of any client computer so that its operations are given a higher priority than another.

For example, you may want operations originating from a specific file server to take precedence over operations originating from users' computers. In such a case, you would assign a higher client priority to the file server than to the other computers within the CommCell.

Client priority is configured at the client-computer level.

iDataAgent Priority

By default, Galaxy assigns the same priority (9 – the lowest) to all iDataAgents within a CommCell. As a result, the Job Manager evaluates all iDataAgents as having the same priority. You can change the priority of any iDataAgent so that its operations are given a higher priority than those of another iDataAgent.

For example, you may want database backup and restore operations for Microsoft Exchange to take precedence over Windows 2000 file system operations. In such a case, you would assign a higher priority to the database iDataAgent for Exchange 2000 Server than to the iDataAgent for Windows 2000.

The iDataAgent priority is configured at the CommCell level. Therefore, the priority that you assign to any iDataAgent is effective for operations that originate from that iDataAgent for all client computers within the CommCell.

Default Job Priorities

The default job priority numbers for various operation types are shown in Table 4.8.

Table 4.8 Default job priorities

Job operation

Default job priority

Archive Pruning

0

ExpressRecovery backups

1

Restore

99

Backup

199

Auxiliary copy

299

Synthetic full backup

399

Because Archive Pruning and ExpressRecovery backup operations are not associated with any client or iDataAgent, they have no second or third digits. Therefore, they are the highest priority Galaxy jobs. The Auxiliary Copy operation also has no associated client or iDataAgent; therefore, Galaxy keeps the priority at 299 and it has a lower priority than backup and restore operations.

Customizing Job Priorities

The priorities for administrative operations (for example, Archive Pruning, Auxiliary Copy, and ExpressRecovery backups) are assigned by Galaxy and cannot be customized. However, you can customize the priorities of client-oriented operations (for example, backups, restores, and Synthetic Full backups) by changing any of the following:

  • Priority precedence

  • Client computer priority

  • iDataAgent priority

Priority Precedence

By default, the client computer, which is represented by the second digit, has precedence over the iDataAgent, which is represented by the third digit. You can reverse the order of these digits, and thus the precedence, so that the iDataAgent has precedence over the client computer.

An example of this is the effect that priority precedence can have when you customize client computer and iDataAgent priorities. Assume there are two client computers; opal and coal. Client opal is a file server that uses the iDataAgent for Windows 2000. Client coal is an server running Exchange that uses the database iDataAgent for Exchange 2000 Server.

The job priorities for backup operations from each client computer are shown in Table 4.9; note that different backup operations have a higher priority (lower number) depending on the setting of the priority precedence. When the priority precedence is set for Client, the File System backup from opal has the higher priority. When the priority precedence is set for iDataAgent, the Exchange Database backup from coal has the higher priority. The corresponding Restore and Synthetic Full backup operations would yield similar results.

Table 4.9 Priority precedence settings

 

Priority precedence setting

 

Operation

Client

iDataAgent

Backup, File System for Windows 2000, Client opal

186

168

Backup, Exchange Database, Client coal

194

149

Viewing Job Priorities

By default, the Job Controller window does not display the priorities of running jobs. To view the job priorities for all jobs, you need to enable the Priority column as described in the procedures in online Help.

Job Control

The Job Controller allows you to manage jobs and view detailed information about them. Information about a job is continually updated and available in the Job Controller window as long as the job exists. When a job is completed, the information about that job is removed from the Job Controller window. If the job was a backup or restore operation, you can still obtain job information by using the backup or restore history feature. For information on viewing backup or restore history, see online Help for iDataAgent-specific details.

Job Controller Windows

You should be familiar with the following before attempting to manage jobs:

  • Job Details dialog boxes

  • Job Controller window

The Job Controller window displays all the current jobs in the CommCell. Table 4.10 shows the information displayed by default by the Job Controller.

Table 4.10 Information shown in the Job Controller display

Job ID

A numeric identifier, unique within the CommCell, identifying the backup, restore, or administrative job.

iDataAgent

The Galaxy software module from which the job originated (for example, iDataAgent for Windows 2000).

User

The Galaxy user who initiated the job.

Operation

Description of the job being performed (backup, restore, and so on).

Status

Current job status.

Client Computer

For backup operations: The computer from which the operation is being performed. For restore operations the computer from which the restored data was originally backed up

Progress

A status bar indicating the job's progress. The progress bar is not visible for certain operations (for example, archive pruning) or for the initial phases of some backup operations.

Priority (not displayed by default)

Job priority number.

Start (not displayed by default)

The time (and date) the job started.

Elapsed (not displayed by default)

The time lapsed since the job started, updated periodically.

To open the Job Controller and rearrange columns

Generally the Job Controller is in view when you first open the CommCell Console. If however, you closed the Job Controller window, you can reopen it as follows.

  • On the CommCell Console, click the Job Controller icon.

  • Drag and drop the headings of the columns that you want to rearrange. The columns will return to their original order if you close and reopen the Job Controller window.

To hide or display columns in the Job Controller

  1. Click the Job Controller window to make it active.

  2. In the CommCell Console, on the View menu, click Table. A list of Job Controller columns appears with a check mark next to each displayed column.

  3. Click the name of a checked column to hide it. Click the name of a cleared column to display it.

Note: You cannot display fewer than three columns.

Controlling Galaxy Jobs

The Job Controller allows you to manually control jobs by using the operations shown in Table 4.11.

Table 4.11 Job Controller operations

Suspend

Temporarily stops a job. A suspended job is not terminated; it can be restarted at a later time. Only restartable jobs can be suspended.

Resume

Resumes a stopped job and returns the status to Waiting, Pending, or Running depending on the availability of resources, or the state of the operation window and activity control settings.

Kill

Terminates a job.

View Events

Allows you to view the events for the job.

Detail

Displays information about the selected job.

The ability to suspend specific jobs depends on their job category; either restartable or non-restartable.

Job Status Levels

A job may have one of eight status levels, as shown in Table 4.12.

Table 4.12 Job status levels

Running

The job is active and has access to the resources it needs.

Waiting

The job is active, waiting for resources (for example, media drives) to become available or for internal processes to start.

Interrupt Pending

Galaxy has suspended the job and is waiting for the completion of associated processes before stopping the job.

Pending

Galaxy has suspended the job and will restart it without user intervention. A pending job may be waiting for a valid operation window, or it may have failed and is waiting for Galaxy to restart it.

Stop Pending

You have suspended the job, and Galaxy is waiting for the completion of associated processes before stopping the job.

Stopped

By using the Suspend option, you have manually stopped the job. It will not complete until you restart it by using the Resume option.

Kill Pending

The job has been terminated, and Galaxy is waiting for the completion of associated processes before killing the job.

Killed

The job is terminated and removed from the Job Controller window.

The status of a job determines the Job Controller actions (kill, suspend, or resume) that you can perform and the resulting status, as shown in Table 4.13.

Table 4.13 Job status actions available

Original status

Actions available

New status

Running

Suspend

Stopped

 

Kill

N/A

Waiting

Suspend

Stopped

 

Kill

N/A

Interrupt Pending

N/A

N/A

Pending

Suspend

Stopped

 

Kill

N/A

Stop Pending

N/A

N/A

Stopped

Resume

Returns to original state, resources and other conditions permitting

 

Kill

N/A

Kill Pending

N/A

N/A

To suspend a job

To carry out this procedure you must have Job Management capability on the Galaxy system.

  1. Right-click the job and then click Suspend.

  2. The job state changes to Stop. (The job status may first change to Stop Pending for a few moments while an operation completes.)

To resume a suspended job

  1. Right-click the job and then click Resume.

  2. The Job Manager attempts to restart the job; the job status changes to Waiting, Pending, or Running.

To kill a job

  1. Right-click the job and then click Kill.

  2. If you are sure you want to kill the job, click Yes when the confirmation prompt appears.

    Note: The job status may change to Kill Pending for a few moments while the operation completes. After the operation completes, the job status will change to Killed and be removed from the Job Controller window.

  3. In the Job Status dialog box, click Detail to see the Job Details dialog box for the terminated job, or click OK to close the dialog box.

To view events on a particular job

  1. Right-click the job and then click View Events.

  2. The All Found Events window appears. Use this window to view all of the events associated with a particular job. See online Help for details.

To view details on a particular job

  1. Right-click the job and then click Details.

  2. The appropriate details window appears (for example, the Backup Job Details for Job ID window.). See online Help for details.

Job Status and Job Details Dialog Boxes

When each job completes, fails, or is killed, Galaxy displays the Job Status dialog box, provided the Job Controller window is open. If this window is not open, the dialog box is not displayed. Click Detail in the Job Status dialog box to view the Job Details dialog box for the completed operation.

You can use the Job Controller window to view details for the following types of jobs:

  • Backups

  • Restores

  • Synthetic Full backups

  • Auxiliary copies

  • ExpressRecovery backups

The Job Details dialog boxes contain a wealth of information about a selected job. This information can be useful in determining job status and progress.

Activity Control

The Activity Control feature allows you to enable or disable backup and/or restore operations at three levels in the Galaxy hierarchy (Table 4.14).

Table 4.14 Activity Control options

CommCell

Allows you to enable/disable all backup and/or restore operations for all client computers within the CommCell.

Client computer

Allows you to enable/disable all backup and/or restore operations on a specific client computer.

Client computer/ iDataAgent

Allows you to enable/disable the backup and/or restore operations of a specific iDataAgent on a specific client computer.

Order of Precedence

When operations are disabled, the CommCell level has the highest priority while the client computer/iDataAgent has the lowest priority. For example, if you disable backups at the CommCell level, all backups throughout the CommCell are disabled regardless of the corresponding settings of the individual client computers and client/iDataAgents. However, if backups are enabled at the CommCell level, you can still disable backup operations at the client computer or client/iDataAgent levels.

By default, all operations are enabled at all levels of the Galaxy hierarchy.

Accessing the Activity Control Feature

You access the Activity Control feature from the Activity Control tab of the associated Properties dialog box. For example, to access the Activity Control feature at the CommCell level, you would open the Activity Control tab of the CommCell Properties dialog box. For information on applying activity control to a specific client computer/iDataAgent, see the appropriate online Help.

To enable or disable backup or restore operations

To perform this procedure you must have CommCell-level Administrative Management capabilities on the Galaxy system.

  1. In the CommCell Browser, right-click the CommServe, client computer, or client iDataAgent, and then click Properties.

  2. On the Activity Control tab, select or clear one or both of the following options:

    • Enable Backup. When selected, enables backups to occur. When cleared, backups are disabled. Backups cannot be started. Running and Waiting backups, if any, run to completion. Backups in the Stopped state cannot be resumed until backups are enabled. (The Job Controller indicates the Job states.) Pending backups do not run until backups are enabled.

    • Enable Restore. When selected, enables restores to occur. When cleared, restores are disabled and Restores cannot be started. Running restores run to completion. Pending restores do not run until restores are enabled.

CommCell Users and Groups

User Administration is an important aspect of CommCell administration. It is through proper user management that users gain access to the Galaxy CommCell in a secure manner.

This section provides an overview of the Galaxy user management system and describes the methodology for creating user accounts and user groups, and assigning resources to users and groups.

CommCell Resources

CommCell resources are manageable entities within a CommCell that perform some operation, possess configurable attributes, or both. Each CommCell has the following resources:

  • The CommServe

  • Each client computer

  • Each Client-iDataAgent

  • Each MediaAgent

  • Each library

  • Each storage policy

The Client-iDataAgent is the combination of the client computer and an individual iDataAgent. This combination allows you to target individual iDataAgents on a client computer for different user groups, as needed.

User Access

Access to a Galaxy CommCell's resources and features is granted or denied based on a combination of the following determining factors:

  • CommCell resources

  • Capabilities

  • User groups

  • User accounts

Using this approach, a CommCell administrator can provide each Galaxy user with the exact capabilities required. These requirements can vary, depending on the tasks each user needs to perform.

Figure 4.8 shows an example of how resources can be distributed within a CommCell.

Figure 4.8: Distributing CommCell resources

Figure 4.8: Distributing CommCell resources

Capabilities (Privileges)

Capabilities are privileges that allow users to perform a variety of functions within a CommCell. These functions include routine operations, such as backing up or restoring data, as well as the more administrative operations such as license administration, archive pruning, or administering user accounts. Table 4.15 identifies Galaxy capabilities and their associated resources, and describes their associated operations.

Associating Resources and Capabilities

Each capability, and its associated operation, affects only one type of resource. For example, the backup capability, which allows all users in a particular user group to perform on-demand backups, operates only on the Client-iDataAgent resources. It does not, for example, operate on a library resource, because libraries do not initiate backups themselves. When you create a user group, choose the capabilities appropriate for the resources that you will associate with that group. Table 4.15 lists the available Galaxy capabilities:

Table 4.15 Galaxy capabilities

Capabilities (Privileges)

Resources

Associated Operations

 

Licensing capabilities:

License Management

CommCell

Update license keys

CommCell Management Capabilities:

Job Management

CommCell

Suspend, resume, and kill jobs

 

Administrative Management

CommCell

Job pruning
Server configuration
Initiate auxiliary copies
ExpressRecovery
Enable/disable backups and restore (CommCell)
Define the operation window on CommCell level
Scheduling functions for administrative jobs
Change network password
Other administrative jobs
Specify mail server for alert messages
Library and drive configuration
NAS client configuration

 

Report Management

CommCell

Run reports
Scheduling functions for reports

 

Storage Policy Management

CommCell

Create/delete storage policies
Add/delete copies
Mark active media full
Migrate media

 

User Management

CommCell

Add/delete user/ user group
Enable/disable user
Enable/disable user groups
Associate a group with an object

 

Alert Management

All

Add/delete alerts for users

Library and MediaAgent Management Capabilities:

Library Management

Library

Move media between scratch pools
Create/delete new scratch pools
Discover media
Import/export media
Mark a drive clean
Replace a drive
Reset filer
Reset library
Set drives online/offline
Migrate magnetic library

 

 

CommCell

Edit Storage Resources properties

 

MediaAgent Management

MediaAgent

Modify MediaAgent properties

 

 

CommCell

Forced De-configure MediaAgent

iDataAgent Capabilities:

iDataAgent Management

Client iDataAgent

Enable/disable backups and restore (client or iDataAgent level)
Create/modify/remove backup sets and subclients
Define the operation window on the iDataAgent level
Forced De-configure iDataAgent

 

 

CommCell

Forced De-configure client

Backup and Restore Capabilities:

Backup

Client-iDataAgent

On-demand backup operations

 

Browse/Restore

Client-iDataAgent

On-demand browse and restore operations

 

iDataAgent Scheduling

Client-iDataAgent

Backup and restore operation scheduling (This operation also requires the Backup and Browse/Restore capabilities, respectively)

Note: Users can add themselves to an alert without Alert Management rights. However, they cannot add others to an alert.

User Groups

User groups are named logical entities—containers to which capabilities, system resources, and users are assigned. This arrangement provides an extremely flexible system that allows you to specify not only the privileges for the member users, but also the resources they can access. Users who are assigned to a group are granted the group's privileges and access to the group's resources.

The master user group, which is predefined by the Galaxy system, is assigned all available rights and system resources. This group is permanent; it cannot be removed, nor can its privileges or access to system resources be curtailed. All other user groups are created and maintained as needed by members of groups that have the user management right.

User cvadmin

Within the master user group is a permanent user called cvadmin. Galaxy creates the cvadmin user automatically; it is the default CommCell administrator, and this user name cannot be changed. As a member of the master user group, cvadmin has all available rights within a CommCell. Using these privileges, cvadmin can create users, groups, and user accounts at any time. Note that cvadmin can also assign additional users to the master group, thereby giving full access to other users as well.

CommCell User Accounts

All CommCell users have a CommCell user account that contains basic Galaxy-related information about the user. Users who are part of groups that have the User Management capability can create CommCell user accounts. The CommCell user accounts are specifically created to control CommCell access.

A user can be a member of more than one group (and have all of the capabilities of each of those groups). If a user is not a member of any group, that user does not have any capabilities and can use the CommCell Console on a view-only basis.

CommCell user accounts are completely separate entities from Windows user accounts; their purposes are different and should not be regarded as interchangeable. CommCell users need not have a Windows user account.

Managing User Groups

User groups provide a convenient means of assigning a common set of capabilities and resources to a set of users. You can create any number of user groups, each having any combination of assigned capabilities.

Proper user-group administration requires a certain amount of planning. Successful planning helps you minimize the number of groups, which is always desirable from an administrative standpoint.

When you plan your user group strategy, take time to consider the following questions:

  • Who needs access to the Galaxy system?

  • What tasks will each Galaxy user need to perform?

  • As an administrator, what are your security needs?

Managing Galaxy user groups requires the following administrative tasks:

  • Creating user groups

  • Changing user groups

  • Deleting user groups

Creating User Groups

User groups are created for users who require access to the Galaxy system. Each user group represents a distinct set of users, capabilities, and CommCell resources. The procedures in this section describe the following aspects of creating user groups:

  • Immediate assignment. When you create a user group, you can immediately assign the users, capabilities, and CommCell resources.

  • Unspecified assignment. Alternately, you can leave these assignments unspecified, which would limit the user to browsing through the CommCell.

To create a user group

To carry out this procedure, you must have the User Management capability on the Galaxy system.

  1. On the CommCell Browser, right-click CommCell User Groups, and then click New User Group.

  2. In the New User Group Properties dialog box, on the General tab, type the following:

    • Name. The name you want to assign to the user group (up to 32 characters; do not include trailing spaces).

    • Description. Some descriptive information that characterizes the user group. Perhaps the users of the group belong to some department or organization. Maybe the group is more closely associated with a specific computer or a CommCell function (for example, backups).

    Note: If you want to leave the user group dormant (without users, capabilities, or associations), in the New User Group Properties dialog box, click OK.

  3. Select Enabled if you want to activate the group (selected by default). If you want the group to be dormant until some later time, clear the Enabled option.

  4. If you want the user group to possess all Galaxy capabilities, select All Capabilities. Otherwise, leave this option cleared.

  5. If you want the user group to be associated with all CommCell resources, select All Associations. Otherwise, leave this option cleared.

    Note: The All Capabilities and All Associations options are very powerful. If they are assigned improperly, you risk exposing all the features and resources of the CommCell to users who may not have adequate training or knowledge. For this reason, these options are cleared by default.

  6. At this point, you have entered all the information required to create the user group; however, you have not yet populated the group with users nor have you associated it with Galaxy capabilities or CommCell resources. If you did not select All Capabilities, the user group has no assigned capabilities. Similarly, if you did not select All Associations, the user group has no associated CommCell resources.

To assign Galaxy capabilities to a user group

  1. In the New User Group Properties dialog box, click the Capabilities tab.

  2. Assign the capabilities to the user group as follows:

    • To assign a capability to a user group, click the capability in the Available Capabilities pane, and then click the < button.

    • To remove a capability from a user group, click the capability in the Assigned Capabilities pane, and then click the > button.

    • Repeat this step for each additional capability you want to add to or remove.

  3. When finished, click OK.

To assign users to a user group

You can assign existing users to a user group in the New User Group Properties dialog box. This procedure is most useful when you want to establish group membership on a group-by-group basis. As an alternative, you can establish user group membership on a user-by-user basis.

  1. Click the Users tab in the New User Group Properties dialog box.

  2. Assign the users to the user group as follows:

    • To assign a user to a user group, click the user name in the Available Users pane, and then click the < button.

    • To remove a user from a user group, click the user name in the Member Users pane, and then click the > button.

    • Repeat this step for each additional user that you want to add or remove.

  3. When finished, click OK.

Associating CommCell Resources to a User Group

CommCell resource associations enable members of a group to perform Galaxy operations on associated resources. The nature of those operations depends on the Galaxy capabilities assigned to the group. If a resource, such as a client computer, is not associated with a given user group, the users of that group cannot perform any Galaxy operations involving that client computer. If, however, the user group was created with the All Associations option set, the group is already associated with all the resources in the CommCell, and the users have all CommCell resources at their disposal.

You can associate the following resources to a user group:

  • The CommServe

  • Each client computer

  • Each Client-iDataAgent

  • Each MediaAgent

  • Each library

  • Each storage policy

Each of these resources supports specific functions within the Galaxy CommCell.

To associate or dissociate a CommCell resource to/from a user group

In this procedure, you will associate a CommCell resource to a user group that is already established. Before starting this procedure, you should know which resources you want to associate to a given user group.

  1. On the CommCell Browser, right-click the CommCell resource that you want to associate to a user group, and then click Properties.

  2. In the Properties dialog box, click the Security tab. The Associated Groups pane displays the names of the user groups to which the resource is associated. The master group is always listed, because all resources are always associated to it.

  3. To associate the selected resource to a user group, click the group you want in the Available Groups pane and then click the << button. Repeat this step for each group you want associated with the selected resource.

  4. To dissociate the resource from a user group, do the reverse; that is, in the Associated Groups pane, click the user group that you want to dissociate from the selected resource, and then click the >> button. Repeat this step for each user group that you want dissociated from this resource.

  5. When finished, click OK.

Changing User Group Properties

Galaxy allows you to change the following user-group properties:

  • Description

  • Assigned capabilities

  • Associated CommCell resources

  • Assigned users

  • Enabled/disabled

Note: Although you cannot change a user group name, you can delete the group and then create a new group with matching attributes and a new name.

All changes are effective immediately, regardless of whether a user from the user group is logged on.

To change the properties of a user group

  1. In the CommCell Browser, click CommCell User Groups.

  2. In the right-hand pane of the CommCell Browser, right-click the user group whose properties you want to change, and then click Properties.

  3. In the User Group Properties dialog box, change the properties as needed.

  4. When finished, click OK.

Deleting User Groups

On occasion, you may want to delete a user group. This could be when your CommCell has grown to a size where you need to reassess and reorganize user responsibilities, or when the functions or membership of a particular user group have become obsolete. Under these circumstances, you may want to delete a user group and create a new one instead of changing the existing user group. The following procedure guides you through this process.

Note: You cannot delete the master user group. The master user group is the primary CommCell administrator (cvadmin) user group and remains available at all times. For the master user group, the Description field is the only property you can change.

To carry out this procedure you must have the User Management capability on the Galaxy system.

To delete a user group

  1. From the CommCell Browser, click the CommCell User Groups icon.

  2. In the right-hand pane of the CommCell Browser, right-click the user group you want to delete, and then click Delete.

  3. When the system prompts you to confirm the deletion, click Yes to delete the user group or click No to cancel the deletion and leave the user group intact.

Managing User Accounts

Managing Galaxy user accounts includes the following tasks:

  • Creating user accounts

  • Changing user accounts

  • Deleting user accounts

Creating User Accounts

User accounts are created for users who need to access the Galaxy system. Each user must have a separate account. When you create a user account, you can immediately assign the account to the available user groups or leave the account unassigned. The following procedures describe both activities.

To carry out this procedure you must have User Management capability on the Galaxy system.

To create a user account

  1. In the CommCell Browser, right-click CommCell Users, and then click New User.

  2. In the New User Properties dialog box, on the General tab, type the following required information:

    • User Name. The name that you want the user to type when they log on to the Galaxy system (up to 32 characters; do not include trailing spaces).

    • Password. The password that you initially assign to the user (up to 32 characters; do not include trailing spaces). (Users can change their own passwords.)

    • Confirm Password. A confirmation of the Password.

  3. Optionally, you can enter the following additional user information:

    • Full Name. The real name of the person to whom the account is assigned (up to 32 characters; do not include trailing spaces).

    • Description. Some descriptive information about the user, such as a job title, department, or organization name.

    • E-Mail. The user's e-mail address.

  4. If you want to enable the user account immediately, select Enabled (selected by default). If you want to create the account, but leave it inactive until some later time, then clear the Enabled option.

  5. If you want the user's password to expire on a periodic basis, select Age Password and then select the number of days for which the password is to remain valid. If you do not want the user password to expire, leave this option cleared (it is cleared by default). A password age of one day means that the password expires at midnight of the present day.

    Note: Unless you assign the user account to a user group, the user will not have any Galaxy capabilities after logging on.

  6. Decide whether to assign the new user to a user group:

    • To leave the user unassigned, in the New User Properties dialog box, click OK. .

    • To assign the user to a user group, click the User Groups tab and follow the next procedure.

The following procedure demonstrates how to assign a user to one or more user groups by using the User Properties dialog box. This procedure is most useful for establishing group membership on a user-by-user basis. As an alternative, you can establish user group membership on a group-by-group basis.

To assign a user to a user group

  1. Click the User Groups tab of the New User Properties dialog box.

  2. Assign the user to the user groups as follows:

    • To assign the user to a user group, in the Available Groups pane, click the group and then click the < button.

    • To remove the user from a user group, in the Member Groups pane, click the group and then click the > button.

  3. When finished, click OK.

Changing the Properties of a User Account

The Galaxy system allows you to change the following user-account properties:

  • Password (and password aging)

  • Full name

  • Description

  • E-mail address

  • Enabled/disabled

  • User-group memberships

Note: You cannot change the User Name property; however, you can delete an account and then create a new account with another user name. The only properties you can change for the cvadmin user account are the password and the e-mail address.

All changes are effective immediately, regardless of whether the user is logged on, except in the following instance: If a user is logged on and you disable his or her account, he or she will still be able to use the CommCell console; however, he or she will be denied access after he or she has logged off.

To perform this procedure you must have User Management capability on the Galaxy system.

To change the properties of a user account

  1. From the CommCell Browser, click the CommCell Users icon.

  2. In the right pane of the CommCell Browser, right-click the user whose account properties you want to change, and then click Properties.

  3. In the User Properties dialog box, change the properties as needed.

  4. When finished, click OK.

Deleting a User Account

One of the usual duties associated with user management is the deletion of user accounts. Deletions are effective immediately, unless the user being deleted is logged on to the Galaxy system. In this case, the deleted user will still be able to use the CommCell console; however, he or she will be denied access after he or she has logged off.

Note: You cannot delete the cvadmin user account. User cvadmin is the primary CommCell administrator and remains enabled at all times.

To perform this procedure, you must have User Management capability on the Galaxy system.

To delete a user account

  1. In the CommCell Browser, click the CommCell Users icon.

  2. In the right pane of the CommCell Browser, right-click the user you want to delete, and then click Delete.

  3. When the system prompts you to confirm the deletion, click Yes to delete the user or click No to cancel the deletion and leave the user account intact.

CommCell Network Password

The CommCell network password is an internal security measure used to ensure that Galaxy communications occur only between CommCell computers. By default, Galaxy assigns each computer in the CommCell a different password. You can, at any time, define a new CommCell network password for any computer in the CommCell. Although you do not need to know the existing password to define a new one, you do need to have the Administrative Management capability.

Note: The CommCell network password is not a user-level password; no user will ever need to enter this password. It is used only on an internal basis.

To carry out this procedure, you must have Administrative Management capability on the Galaxy system.

  1. In the CommCell Browser, right-click the CommCell icon, and then click Change Network Password.

  2. In the Change Network Password dialog box, select the computer whose network password you want to change.

  3. In the New Password field, type new network password and in the Confirm Password field re-type it.

  4. When finished, click OK. Galaxy changes the password of the selected computer.

Job Scheduling

Scheduling the jobs within your CommCell helps ensure that the data that you want to safeguard is secured automatically on a regular basis.

Designing Backup Schedules

Use either the Schedule Wizard or the CommCell Browser to schedule backups. Within the CommCell Browser, you can schedule backups at various levels in the Browser tree by right-clicking the entity that you want to back up and selecting the appropriate menu options.

If your iDataAgent supports backup sets, you can schedule a backup for either a subclient or an entire backup set. Scheduling at the backup set level provides the convenience of scheduling all subclients in one step.

Note: When establishing a backup schedule for an entire backup set, keep in mind that each subclient will initiate a backup at the scheduled time. If two or more subclients are associated with the same storage policy, their backups may run serially. That is, it is possible that one subclient will back up at the specified time, but the other(s) will queue until the storage policy is free.

Depending on the iDataAgent, Galaxy allows you to schedule some or all of the following:

  • Full backups

  • Incremental backups

  • Differential backups

  • Synthetic Full backups

  • Preselected backups (the exact type of the preselected backups depends on what you select during iDataAgent installation)

Before You Begin:

  • When you create a backup schedule, you should establish a full backup cycle. Try to ensure that the backups that comprise a full backup cycle are complementary. For example, if a schedule calls for daily incremental backups with full backups to occur every week, make sure that the incremental backup skips the day that the full backup is scheduled to run, avoiding unnecessary backups and collisions.

  • If you are scheduling backups to establish a full backup cycle, keep in mind that the full backup cycle should be reflective of the associated retention period. For those iDataAgents that support backup sets, if you are scheduling for an entire backup set, then you should consider the storage policy retention periods for all constituent subclients.

  • If your CommCell has several client computers, try to coordinate your backups to minimize media, media drive, and possible network contention.

  • To secure all data for a given iDataAgent on a client computer, be sure to define backup schedules either for all subclients within the iDataAgent or for a backup set (if backup sets are supported).

  • Check to see whether an operational window has been established for the type of backup operation that you want to schedule. If an operational window exists, be sure to schedule the backup within the valid time frame.

Designing Restore Schedules

A scheduled restore operation relieves you of having to manually initiate the restore.

Before you begin, if your CommCell has several client computers, try to coordinate your restore operation to minimize media, media drive, and possible network contention. Check to see whether an operational window has been established for restore operations. If an operational window exists, be sure to schedule the restore within the valid time frame.

The following procedures are available in online Help under the topic job scheduling:

  • Adding a scheduled job

  • Modifying a scheduled job

  • Deleting a scheduled job

Establishing Holidays on Which No Scheduled Tasks Run

Galaxy allows you to establish holidays on which no scheduled tasks will run. This feature affects only scheduled tasks, and it affects all such tasks. (Immediate tasks are allowed to run.) Holidays are defined at the CommCell level and are evaluated in the CommServe Time Zone.

You can establish a holiday for a specific date within a given year or for a specific month/day on a yearly basis (annually). Only one holiday per date is allowed. If you set a holiday to occur on an annual basis, this supersedes any holiday that is set for the same month/day and specific year.

You can also add or delete holidays. Unless it is an annual holiday, a holiday is automatically deleted after it has expired. Annual holidays never expire. Events and alerts are sent for scheduled items that are skipped due to holidays.

To add or delete a holiday

  1. In the CommCell Browser, right-click the CommCell icon, and then click Set Holidays. The Holidays window appears with the current holidays displayed.

  2. Add or delete holidays.

Alert Notifications

An alert is an e-mail message sent by Galaxy, by using the mail server designated on the General tab of the CommCell properties box, to inform the message recipient that a particular Galaxy event has occurred or user action has been taken.

For example, if you configure an alert for changes to CommCell properties, an alert message is dispatched to the designated user when a property at the CommCell level is changed. Or, if you configure an alert for successful backups at the Client Computer level, the selected users will receive an alert message for each successful backup for all iDataAgent installed on that client.

You can configure alerts by selecting one or more events and then selecting which users are to receive alerts for the selected events. Events that are available for alert configuration are listed on the Alert tab of the object's Properties dialog box. You can configure alerts at the CommCell, Client, iDataAgent, Instance, MediaAgent, Library, and Storage Policy levels.

Alerts configured at a higher level in the Galaxy hierarchy affect all lower levels. For example, if you configure an alert for successful backups at the Client Computer level, all successful backups for all iDataAgents on that client will initiate an alert message.

Galaxy Capabilities and Alerts

Galaxy capabilities allow system administrators to assign specific user groups permission to perform particular Galaxy operations. Then, by adding users to those user groups, the system administrator can manage which users can perform which operations in Galaxy.

The Alert Management capability allows a system administrator to control which user accounts have permission to configure alerts. Users can configure their own alerts, regardless of group membership. However, to configure alerts for other users you must belong to one of the following user groups:

  • The master group

  • A user group that has the Alert Management capability that is associated with the object for which you want to configure the alert. For example, if you want to configure an alert for the file system iDataAgent or MediaAgent for another user, the user group with the Alert Management Capability must be associated with the file system iDataAgent or MediaAgent objects.

The master user group is assigned all Galaxy capabilities by default and is associated with all objects in the Galaxy hierarchy.

Configuring alert notification requires the Administrative Management or Alert Management capabilities on the Galaxy system.

To configure alert notifications

  1. In the CommCell tree, right-click the CommCell icon and click Properties.

  2. On the General tab, designate an e-mail server for alert message management and then select the events you want to configure from the Alert tab as follows:

    • Alert. The category of alerts. Alerts are displayed only at their appropriate level.

    • Event. The individual events or conditions that produce alert messages.

    • Users. List of users who receive an alert e-mail when the event occurs.

    • Edit. Displays the User Alert window where you assign users to events for notification.

    The User Alert window contains the following fields:

    • Users to be Notified. Listed users receive alert messages for the selected events.

    • Available Users. These users are candidates to receive alert messages for the selected events.

  3. Click Edit and select the user that you want to add to the Users to be Notified list by clicking the < button. To remove a user from the Users to be Notified list, click the > button.

  4. Click OK to confirm the users to be notified, and then click OK again.

Available Alerts

Table 4.16 identifies the alerts that can be displayed at each level of the CommCell.

Table 4.16 CommCell alerts

Alert

Comm-Cell

Client

iDataAgent

Instance

Media-Agent

Library (Tape)

Library (Magnetic)

Storage Policy

Scheduler

 

 

 

 

 

 

 

 

Added

X

 

 

 

 

 

 

 

Deleted

X

 

 

 

 

 

 

 

Failed to Schedule Job

X

 

 

 

 

 

 

 

Holidays Modified

X

 

 

 

 

 

 

 

Modified

X

 

 

 

 

 

 

 

Scheduled Job Ran Late

X

 

 

 

 

 

 

 

Skipped Due to Holiday

X

 

 

 

 

 

 

 

Skipped Scheduled Jobs

X

 

 

 

 

 

 

 

Archive Pruning

 

 

 

 

 

 

 

 

Completed With Warning(s)

X

 

 

 

 

 

 

 

Failed

X

 

 

 

 

 

 

 

Failed to Start

X

 

 

 

 

 

 

 

Job Aborted

X

 

 

 

 

 

 

 

Killed by User

X

 

 

 

 

 

 

 

Succeeded

X

 

 

 

 

 

 

 

Auxiliary Copy

 

 

 

 

 

 

 

 

Completed With Warning(s)

X

 

 

 

 

 

 

 

Failed

X

 

 

 

 

 

 

 

Failed to Start

X

 

 

 

 

 

 

 

Job Aborted

X

 

 

 

 

 

 

 

Killed by User

X

 

 

 

 

 

 

 

Succeeded

X

 

 

 

 

 

 

 

Synthetic Full

 

 

 

 

 

 

 

 

Completed With Warning(s)

X

 

 

 

 

 

 

 

Failed

X

 

 

 

 

 

 

 

Failed to Start

X

 

 

 

 

 

 

 

Job Aborted

X

 

 

 

 

 

 

 

Job Interrupted

X

 

 

 

 

 

 

 

Job Restarted

X

 

 

 

 

 

 

 

Killed by User

X

 

 

 

 

 

 

 

Resumed by User

X

 

 

 

 

 

 

 

Succeeded

X

 

 

 

 

 

 

 

Suspended by User

X

 

 

 

 

 

 

 

Express Recovery

 

 

 

 

 

 

 

 

Backup set(s) Pruned

X

 

 

 

 

 

 

 

Completed With Warning(s)

X

 

 

 

 

 

 

 

Failed

X

 

 

 

 

 

 

 

Failed to Start

X

 

 

 

 

 

 

 

Job Aborted

X

 

 

 

 

 

 

 

Killed by User

X

 

 

 

 

 

 

 

Succeeded

X

 

 

 

 

 

 

 

CommCell

 

 

 

 

 

 

 

 

Alert Modified

X

 

 

 

 

 

 

 

CommCell Database Disk Space Low

X

 

 

 

 

 

 

 

Forced De-configure

X

 

 

 

 

 

 

 

Properties Modified

X

 

 

 

 

 

 

 

Unauthorized Attempt to Alter Properties

X

 

 

 

 

 

 

 

Unauthorized Attempt to Modify Alerted Users

X

 

 

 

 

 

 

 

Backup

 

 

 

 

 

 

 

 

Failed

X

X

X

X

 

 

 

 

Failed to Start

X

X

X

X

 

 

 

 

Job Aborted

X

X

X

X

 

 

 

 

Job Interrupted

X

X

X

X

 

 

 

 

Job Restarted

X

X

X

X

 

 

 

 

Killed by User

X

X

X

X

 

 

 

 

Resumed by User

X

X

X

X

 

 

 

 

Succeeded

X

X

X

X

 

 

 

 

Suspended by User

X

X

X

X

 

 

 

 

Restore

 

 

 

 

 

 

 

 

Failed

X

X

X

X

 

 

 

 

Failed to Start

X

X

X

X

 

 

 

 

Job Aborted

X

X

X

X

 

 

 

 

Killed by User

X

X

X

X

 

 

 

 

Succeeded

X

X

X

X

 

 

 

 

Client Properties

 

 

 

 

 

 

 

 

New Content Added

X

X

X

X

 

 

 

 

Properties Modified

X

X

X

X

 

 

 

 

Unauthorized Attempt to Alter Properties

X

X

X

X

 

 

 

 

MediaAgent

 

 

 

 

 

 

 

 

Properties Modified

X

 

 

 

X

 

 

 

Switched On/Off-line

X

 

 

 

X

 

 

 

Unauthorized Attempt to Alter Properties

X

 

 

 

X

 

 

 

Library

 

 

 

 

 

 

 

 

Below Low Media Threshold

X

 

 

 

X

X

X

 

Duplicate Barcode/Label

X

 

 

 

X

X

 

 

Enabled/Disabled

X

 

 

 

X

X

 

 

Magnetic Library Out of Space

X

 

 

 

X

 

X

 

Properties Modified

X

 

 

 

X

X

X

 

Switched On/Off-line

X

 

 

 

X

X

X

 

Thresholds Exceeded

X

 

 

 

X

X

 

 

Unauthorized Attempt to alter properties

X

 

 

 

X

X

X

 

Tape

 

 

 

 

 

 

 

 

Media is Not in Library

X

 

 

 

X

X

 

 

Mount Error

X

 

 

 

X

X

 

 

No Spare Media

X

 

 

 

X

X

 

 

Unmount Error

X

 

 

 

X

X

 

 

Storage Policy

 

 

 

 

 

 

 

 

Properties Modified

X

 

 

 

 

 

 

X

Unauthorized Attempt to alter properties

X

 

 

 

 

 

 

X

Auxiliary Copy

For a full understanding of this feature, you should have some basic knowledge of storage policy configuration.

Auxiliary Copy Overview

Galaxy performs backups through the primary copy only. However, you can use the auxiliary copy operation to copy the backup data that was created on a primary copy from the primary copy to all secondary copies within a storage policy. This copies the data as a true image of the primary copy, archive file for archive file. After the data has been copied, it is available for the length of time specified by the copy's data retention period.

The auxiliary copy feature can be useful for creating hot standby backup copies. The primary and secondary copies use different media and often use different libraries, depending on the configuration. If the primary copy path becomes inoperative, perhaps due to a storage media failure, or a library or network malfunction, you can promote a secondary copy to become the primary copy. This allows you to continue operations as before and make repairs without interrupting backup and restore operations.

When you start an auxiliary copy operation, you select the storage policy for which you want the copy (or copies) created. The primary copy of the specified storage policy serves as source of the data. If the storage policy does not have a secondary copy, you must define a new one on that storage policy. Auxiliary copies cannot copy data to another storage policy.

When an auxiliary copy is started, Galaxy copies all unpruned data (that is, all data if pruning has not yet occurred, or the data remaining after a pruning operation) from the primary copy to all active secondary copies within the storage policy as shown in the Figure 4.9. (Secondary copies that are not in the active state do not participate in the auxiliary copy operation.)

Note: Pruning is the process of deleting all data that have exceeded their defined retention period.

Auxiliary Copies vs. Standard Backups

An auxiliary copy should not be confused with a standard backup operation. The two operations are unrelated, except of course that a backup must precede an auxiliary copy. In all other ways the two operations are distinct and must be initiated or scheduled individually. A backup operation is specific to a particular subclient, copying the subclient content from the client computer to the primary storage policy copy. An auxiliary copy however, does not involve subclients; instead, it copies backed up data from the primary copy to one or more secondary copies. If you want the auxiliary copy to capture the backup data of only one subclient, you must ensure that the subclient has a dedicated storage policy.

Retention Periods, Subclients, and Copies

Retention periods are defined on a copy basis. This is important for auxiliary copy operations, because it allows you to specify different retention periods for the primary backups and the auxiliary copies.

When you create secondary copies, you should set the corresponding retention period to be equal to or greater than the retention period of the primary copy. This arrangement helps to ensure that secondary copy data is not pruned before the corresponding primary data.

Note: To promote consistent data availability of the entire File System, it is recommend that all subclients within a backup set be associated either with the same storage policy or with storage policies whose primary copies have the same retention period.

Figure 4.9 demonstrates the relationships between retention periods and copies.

Figure 4.9: Retention periods and copies

Figure 4.9: Retention periods and copies

Using the example in Figure 4.9, we can make the conclusions displayed in the following table.

Table 4.17 Retention periods and copies conclusions

Storage Policy

Copy

Description

A

1

This is the primary copy for storage policy A. It has a retention period of two weeks and two full backup cycles. Being the primary copy, the backups from all subclients that are associated with this storage policy automatically use this copy. Furthermore, all backup data for this copy is retained according to the same criteria.

 

2

This is a secondary copy and is used to create auxiliary copies for storage policy A. For this copy, all subclients have an unlimited retention period. These retention periods are appropriate if you intend to store the media for some indefinite length of time.

B

1

This is a primary copy for storage policy B. In this example, it is used for the backup data of the default File System subclient on client computer ruby.

Promoting a Secondary Copy to be the Primary Copy

Should the primary copy become inoperative, perhaps due to a library or network malfunction, all backup operations originating from the parent storage policy are non-functional. Additionally, restore operations may not complete successfully. Galaxy enables you to secure and retrieve data using secondary copies, allowing you to make repairs without interrupting Galaxy operations. If the primary copy becomes inoperative, you may be able to promote a secondary copy to become the primary copy.

Note: To promote a secondary copy to be the primary copy, both copies must be synchronized—that is, the secondary copy must contain all unpruned data residing on the primary copy. If they are not synchronized, the promotion fails and Galaxy displays an explanatory message. To maintain synchronization between the primary copy and the secondary copies, it is strongly recommended that you perform an Auxiliary Copy operation after a backup job has completed.

Keep in mind that the data-retention period (and all defined attributes for that particular secondary copy) is retained when promoted. It is recommend that secondary copies have a retention period that is greater than or equal to that of the primary copy. Consequently, you may need to adjust the retention periods of your new primary and secondary copies after the promotion.

In the case of an inoperative primary copy, you can use secondary copies for restore operations or auxiliary copy operations.

Using Secondary Copies for Restore Operations

If your primary and secondary copies are not synchronized, you cannot promote the secondary copy to be the primary copy. You can, however, specify a secondary copy from which you want the data restored, by using the copy precedence feature.

Using Secondary Copies for Auxiliary Copy Operations

Secondary copies are components of storage policies that are used in Auxiliary Copy operations. This allows remote or multiple copies to be made of backup media for archival or disaster-recovery purposes. To keep it simple, consider an Auxiliary Copy to be an exact copy of the data stored on a storage policy. Any number of Auxiliary Copies can be created and in turn promoted to be the primary copy as required if they are in sync (current). Auxiliary Copies are updated in sequence and can be scheduled. Copy precedence determines which Auxiliary Copy is updated first. Auxiliary Copy allows you to create multiple redundant copies of backup data without making an impact on the client.

During Galaxy restore operations, Galaxy initially searches the primary copy for the requested data. If the data is unavailable through the primary copy (due to data pruning, for example), Galaxy attempts to retrieve the data from a secondary copy.

Note: Although a secondary copy can use the same library as the primary copy, it is recommended that you configure a secondary copy to use a different library. This will lessen the consequences of a single library failure.

Auxiliary Copy Summary

  • Secondary copies are components of storage policies that are used in Auxiliary Copy operations.

  • Selecting the Active check box in the Copy Name Properties dialog box enables storage policies.

  • In the Copy Name Properties dialog box, select the Hardware Compression check box to enable hardware compression for all data backed up through the storage policy copy.

  • Software compression, which can be enabled on either the client or MediaAgent computer, is only available when hardware compression is not enabled.

  • Any secondary copy of a storage policy can be promoted to become the primary copy by selecting the Primary Copy check box in the Copy Name Properties dialog box.

  • Secondary copies can only be promoted if they are synchronized with the primary copy (that is, they contain the same backup data).

  • During an Auxiliary Copy operation, secondary copies are synchronized with the primary copy in their assigned order of precedence.

  • Auxiliary Copy operations can be executed on-demand or can be scheduled to occur on a regular basis.

  • Galaxy will not allow you to delete primary storage policy copies.

  • After any secondary storage policy copy is deleted, the data contained in the copy will no longer be available for restore.

  • All media assigned to a deleted storage policy copy immediately becomes available for archive pruning.

Copy Precedence

When a copy is configured, Galaxy automatically assigns it a copy precedence number, which you can change at any time. When requesting a restore operation, you can specify a copy precedence number from which you want the data restored. This can be useful in several scenarios, including the following:

  • The primary copy is no longer available for restore operations due to a hardware failure.

  • The secondary copy restores from a magnetic disk, which is more efficient than the tape library from which the primary copy restores.

If you attempt to restore from a specific copy and the data is unavailable through the given copy, Galaxy does not search the remaining copies, and the restore operation fails. For example, assume a storage policy includes three copies. Two of the copies direct data to Library A, and the third directs data to Library B. Restoring from copy precedence 3 forces Galaxy to restore the data from Copy 3 without initially searching the primary copy. If File A is unavailable through Copy 3 (due to data pruning, for example) the restore operation fails.

When you restore from copy precedence, keep in mind that the restore data may have been secured through more than one storage policy, each one associated with more than one copy. If you specify a copy precedence for a restore operation, the data is restored from the specified copy precedence for all of the associated storage policies. If the data is unavailable through the specified copy for any of the storage policies, the restore operation will not complete successfully.

Auxiliary Copy Examples

To gain a better understanding of the nature of auxiliary copies, the following section looks closer at how auxiliary copies behave under several conditions. For practical reasons, this section focuses on simpler scenarios first and then builds on that knowledge to understand the more complex scenarios.

Single-Stream/Single Subclient Auxiliary Copy

The example in Figure 4.10 explains how auxiliary copies are performed when the storage policy serves only one subclient, and that subclient uses only a single data stream. In this example, a File System subclient backs up its data to a dedicated storage policy. Under such conditions, the primary copy writes the data to a single media group.

Additional assumptions:

  • The subclient backs up three times a week, with one full backup performed each week. (The full backups are marked F1 and F2.)

  • The subclient is new (therefore, it has no backup history).

  • The storage policy associated with this subclient has just one secondary copy: Copy 2 and it is active.

  • The retention periods relevant to this storage policy are:

  • Two weeks and three full backup cycles for the primary copies

  • Infinite for the secondary copy

Figure 4.10: Single-stream/single subclient auxiliary copy - starting point

Figure 4.10: Single-stream/single subclient auxiliary copy - starting point

For example, backups have occurred regularly over a two-week period. Prior to the scheduled time of the third full backup, we initiate an auxiliary copy (A1). This auxiliary copy copies all data from the primary backup media to secondary copy 2.

Figure 4.11 shows what happens to the data as time progresses. Two more weeks pass, during which two more sets of backups and auxiliary copies have occurred. At the end of the third week, a second auxiliary copy (A2) is initiated.

Figure 4.11: Single-stream/single subclient auxiliary copy - after three weeks

Figure 4.11: Single-stream/single subclient auxiliary copy - after three weeks

This time, the operation copies only the backups done since the previous auxiliary copy (the full backup F3 and the two subsequent incremental copies).

At the end of the fourth week, a third auxiliary copy (A3) is initiated. As before, the operation copies only the backups done since the previous auxiliary copy.

On the primary backup media, the first set of backups has expired and has been pruned. This data, however, remains available on the auxiliary copy media, subject to the terms of the retention period. The next set of examples examines some of the ramifications of expiring data with regard to auxiliary copies.

Multi-Stream/Single Subclient Auxiliary Copy

Figure 4.12 shows how auxiliary copies are performed when the storage policy serves one subclient that uses two data streams.

The ability of a subclient to support multiple streams depends on the iDataAgent to which the subclient belongs. Many iDataAgents, particularly those that secure File System data, do not support multiple stream backups. For details on any particular iDataAgent, see the applicable Galaxy Client Administration Guide.

In this example, a subclient backs up its data to a dedicated storage policy.

Some additional assumptions are as follows:

  • The subclient backs up three times a week, with one full backup performed each week. (The full backups are marked F1 and F2.)

  • The subclient is new (no backup history).

  • The subclient is configured to perform backups, using two data streams.

  • The storage policy associated with this subclient has only one secondary copy: copy 2.

  • The retention periods relevant to this storage policy are as follows:

    • Two weeks and three full backups for the primary copies.

    • Infinite for the secondary copy.

    Figure 4.12: Multi-stream/single subclient auxiliary copy

    Figure 4.12: Multi-stream/single subclient auxiliary copy

    For example, backups occurred regularly over a two-week period. Prior to the scheduled third full backup, we initiate an auxiliary copy (A1). This auxiliary copy copies the data of both data streams from the primary backup media to secondary copy 2.

    Starting an Auxiliary Copy

    To avoid possible media contention, which can affect performance, it is recommended that you do not start an auxiliary copy operation if the selected storage policy is already participating in a backup or restore operation. In such a case, the auxiliary copy would fail to copy any files from primary storage to secondary storage. To identify the participating storage policy for any job, use the Detail option from the Job Controller window.

    Note: You cannot conduct an auxiliary copy from a library attached to a MediaAgent for Windows to a library attached to a UNIX MediaAgent. Similarly, you cannot conduct an auxiliary copy from a library attached to a UNIX MediaAgent to a library attached to a MediaAgent for Windows.

    To perform the following procedure you must have Administrative Management capability on the Galaxy system.

    To start an auxiliary copy immediately

    1. In the CommCell Browser, right-click the storage policy for which you want to start an auxiliary copy and then click Auxiliary Copy.

    2. In the Auxiliary Copy window, if you want to copy the data to a different backup tape, select Start New Media; otherwise, leave this option blank. Then click OK.

    3. When the auxiliary copy is completed, a message window appears, indicating that the job is complete. Click OK.

    Auxiliary copies can also be scheduled. To perform the following procedure, you must have Administrative Management capability on the Galaxy system.

    To schedule one or more auxiliary copies

    1. In the CommCell Browser, right-click the storage policy for which you want to schedule an auxiliary copy and then click Auxiliary Copy.

    2. In the Auxiliary Copy window, if you want to copy the data to a different backup tape, select Start New Media; otherwise, leave this option blank. Then click Schedule.

    3. When the Schedule Details dialog box appears, select the scheduling options you want, and then click OK when finished. The auxiliary copy is scheduled.

    4. When the auxiliary copy runs, a message window will appear when the job is complete. Click OK.

    Creating a Secondary Copy

    Secondary copies allow you to establish unique configurations for multiple copies of backup data. This configuration may include unique retention parameters or media assignment for a specific copy of backup data. Galaxy refers to all storage policy copies that are created beyond the primary copy as secondary copies, regardless of the number of copies created.

    Note: It is recommended that the retention parameters of all secondary copies be greater than or equal to the retention parameters of the primary copy.

    To create a secondary copy

    1. In the CommCell Browser, double-click the CommCell root until the storage policy is shown. Right-click the storage policy and select New Copy Name.

    2. In the Copy Name Properties dialog box, enter the following information:

      • In the Name field, enter a name for your secondary copy.

      • In the Library field, select the library that you would like the storage policy copy assigned to. If you chose magnetic storage for the primary copy, select a tape storage device for this secondary copy. If the selected library is a tape library, select the library drive pool and scratch pool.

      • When the Primary Copy Name check box is selected, the storage policy copy is identified as the primary copy. When any subclient backups are performed that are assigned to the storage policy, the backup data is written to the primary copy. When the Primary Copy Name check box is cleared, the copy is identified as a secondary copy. Data is written to secondary copies during the Auxiliary Copy operation.

      • When the Hardware Compression check box is selected, hardware data compression is enabled for all data that is backed up through the storage-policy copy. When the Hardware Compression check box is cleared, hardware compression is not enabled, allowing you to select either MediaAgent or client-level software compression for the storage-policy copy. Software compression is configured at the iDataAgent level. Additional information on software compression can be found in any iDataAgent training module.

      • When the Active check box is selected, the storage policy copy is enabled, allowing the storage policy copy to transfer data to and from its assigned media. When the Active check box is cleared, the storage policy copy is disabled, not allowing the storage policy copy to transfer data to and from its assigned media.

      • Ensure that the Active box is selected, set the retention parameters to 180 days and 6 cycles, and click OK to complete the creation of your secondary copy.

    Promoting a Storage Policy Copy

    Galaxy enables you to promote a secondary copy of a storage policy to be the primary copy. This feature can be useful if a hardware failure has occurred in the primary copy path (for example, MediaAgent, library, and so on) and you need to continue operations with the storage policy while you make repairs. After you have promoted the copy, all backup operations for the storage policy are conducted through the new primary copy. Galaxy automatically redesignates the former primary copy as a secondary copy. Any current secondary copy of a storage policy can be promoted to become the primary copy. When a secondary copy is promoted to the primary copy, the previous primary copy is automatically demoted to secondary copy status. When a secondary copy is promoted, its configuration settings do not change. This includes the copy's retention parameters.

    Before promoting a secondary copy, note the following:

    • In order to promote a secondary copy to be the primary copy, both copies must be synchronized (that is, they must contain the same data). If they are not synchronized, the promotion fails and Galaxy displays an explanatory message. If you need to synchronize the copies, you should perform an auxiliary copy operation as described in the Galaxy CommServe Administration Guide.

    • It is recommended that you not change copy configuration while the parent storage policy is conducting a backup, restore, or auxiliary copy operation.

    • It is also recommended that secondary copies have a retention period that is greater than or equal to that of the primary copy. Consequently, you may need to adjust the retention periods of your new primary and secondary copies after the promotion.

    To promote a secondary copy to be the primary copy

    1. In the CommCell Browser, right-click the copy that you want to promote and then click Properties.

    2. In the Copy Name Properties dialog box, on the General tab, select the Primary Copy Name checkbox.

    3. Galaxy prompts you to confirm your selection. Click OK to proceed.

    4. Galaxy promotes the selected copy to be the primary for the storage policy.

    You can confirm the copy promotion by examining the Primary Copy check box settings for the copies listed in the right pane of the CommCell Browser.

    Setting the Copy Precedence of Storage Policy Copies

    When an auxiliary copy operation is initiated, the backups contained in the primary copy that have not been copied since the last auxiliary copy operation are copied to the storage policy's secondary copies in order of precedence. Setting precedence allows you to establish the order in which secondary copies are synchronized with the primary copy.

    To establish the copy precedence

    1. In the CommCell Browser, double-click the CommCell root until the storage policy you want is shown. Right-click the storage policy and then click Properties.

    2. In the Storage Policy Properties dialog box, click the Precedence tab.

    3. Click the copy whose precedence you want to change and then click either the Up or Down button to increase or decrease the copy precedence. After you have set the new copy-precedence order, click OK to register the changes.

    Deleting a Secondary Storage Policy Copy

    Galaxy does not allow you to delete primary storage policy copies. The only way to delete a primary copy is to delete the storage policy itself. After a storage policy copy has been deleted, the data contained in the copy will no longer be available to be restored. All media assigned to a deleted storage policy copy immediately becomes available for archive pruning.

    Note: Deleting a secondary copy also deletes any unpruned data on that copy.

    To delete a secondary copy

    1. In the CommCell Browser, right-click the secondary copy that you want to delete and then click Delete.

    2. Galaxy prompts you to confirm the deletion. Click OK to proceed. Galaxy deletes the selected copy and removes it from the CommCell Browser.

Archive Pruning Overview and Procedures

Data secured by Galaxy (that is, backups, auxiliary copies, and Synthetic Full backups) remains available for restoration for a period of time known as the retention period. You can set the length of the retention period by modifying certain parameters, generally a number of days and the number of full backup cycles that must be available.

The Archive Pruning operation, which you either schedule or initiate manually, deletes data that has exceeded its retention period. Data that has not been deleted is fully accessible to the system and can be restored. If you never prune your data, it all remains available, regardless of retention settings.

Archive Pruning operations cannot run concurrently with restore, auxiliary copy, or Synthetic Full operations. If archive pruning is in progress and you attempt to start an incompatible operation, or vice versa, a message appears in the Event Viewer informing you that the second operation could not start because the first was running.

If data stored on tape exceeds its retention period and the archive pruning utility is run, the data is logically deleted; meaning, it is removed from the Galaxy database. If all of the data on a medium is pruned, the medium is recycled; that is, it is returned to the scratch pool that is currently associated with the storage policy copy that writes to the medium.

The following procedures are described in this section:

  • Viewing backups that are candidates for pruning and media that are candidates for recycling

  • Scheduling a pruning job

  • Starting a pruning job

To view backups that are candidates for pruning and media that are candidates for recycling

  1. In the CommCell Browser, right-click the CommServe, and then click Archive Pruning.

  2. In the Archive Pruning Option dialog box, select the Forecast dialog box.

  3. In the Archive Pruning dialog box, the Prunable Backups tab displays a list of those backups that have exceeded their retention periods. For each backup, the following are displayed: the computer from which the backup originated, iDataAgent, software instance (where applicable), backup set, subclient, and backup time.

  4. In the Archive Pruning dialog box, the Media Recycled tab displays a list of media that will be recycled the next time backup data is pruned. The following information is displayed: the storage policy and copy through which the data was backed up and to which the media are assigned, the scratch pool to which the media will be reassigned, and the number of media on this storage policy and copy that are to be recycled.

  5. To initiate an immediate pruning operation, click Prune Now.

  6. A message that the archive pruning is complete is displayed, click OK.

Note: After data is pruned, it cannot be restored.

To schedule a pruning job

  1. In the CommCell Browser, right-click the CommServe, and then click Archive Pruning. In the Archive Pruning Option dialog box, select the Schedule option, and then click OK. In the Schedule Details window, the Schedule Details tab appears.

  2. Set the schedule details.

  3. If you want to view the job summary for the pruning job that you have scheduled, on the Schedule Details window click the Job Summary tab. Otherwise, click OK.

Note: After data is pruned, it cannot be restored.

To starting a pruning job

  1. In the CommCell Browser, right-click the CommServe, and then click Archive Pruning.

  2. In the Archive Pruning Option dialog box, select the Prune Now option, and then click OK.

  3. If you are sure that you want to prune, in the Warning prompt that appears click Yes. (If you want to see which backups will be deleted, click No, and then select Forecast and continue).

Rules for Archive Pruning

Each iDataAgent within Galaxy follows a set of Archive Pruning rules. Moreover, some iDataAgents share the same set of rules; in other words, one set of Archive Pruning rules may apply to several iDataAgents.

The following iDataAgents share the same set of Archive Pruning rules:

  • File System

  • The Windows NT® operating system

  • Windows 2000

  • Exchange 5.5

  • Exchange 2000

  • Netware

The following iDataAgents have their own unique set of Archive Pruning rules:

  • Microsoft SQL Server 7.0

  • Microsoft SQL Server 2000

  • Celera (NAS)

  • Oracle

  • Network Appliance (NAS)

For details on specific Archive Pruning rules, see the appropriate Galaxy Client Administration Guide.

Galaxy Reports

The Galaxy system allows you to generate a variety of reports, each tailored to a particular aspect of data management, such as scheduling, event management, media management, and archive pruning. For a list of the Galaxy reports, see the Galaxy CommCell Administration Guide.

Note: The appearance of some Galaxy reports may be affected by the browser package or version. Also, some Galaxy reports may be truncated when they are printed.

Report Filters

On the CommCell Console, on the standard toolbar, click the Reports icon to display the Report Filter window.

Galaxy reports can be customized by filtering various sort criteria, depending on the report type selected. For example, some reports can include all job IDs (by default) or be customized to report information on only one job ID.

Select the report that you want to generate from the Report Filter. Specify its filter criteria, and then generate the report. The Report Filter window varies, depending on the report type selected.

Web Browser Requirement

Reports are displayed in the default Web browser. If you are running the CommCell Console from a Web browser, the report will be displayed using the same browser.

Note: To view reports remotely, either through a Web browser or from a remotely based CommCell Console, you must install and configure Microsoft Internet Information Services (IIS) on the CommServe computer. For all CommServe installation details, see the Galaxy Quick Start Guide.

Report File Pruning

Each generated report creates an HTML file that is saved for at least two days after the report is generated. After the two-day period has lapsed, the HTML files are deleted automatically whenever another report (of any type) is generated.

Report Types

Galaxy provides the following range of report types:

  • Archive Pruning Report. Reports on aged backups (that can be pruned) and media that can be recycled.

  • Auxiliary Copy Report. Lists the status of all archive files copied in the last auxiliary copy operation, indicating whether they were successfully copied.

  • Backup History Report. Provides a history of backup operations for the CommCell.

  • Backups On Media Report. Provides information on backups and their associated media and libraries.

  • Event Report. Lists Galaxy system events.

  • Job Schedule Report. Lists jobs scheduled to begin within a specified time frame.

  • Library and Drive Report. Provides information on media drives and storage libraries.

  • Media in Library Report. Provides details on individual media contained in an entire library.

  • Media in Storage Policy Copies Report. Provides details on individual media associated with selected storage policies and copies.

  • Media Management Housekeeping Report. Provides information on tapes and drives in need of maintenance.

  • NAS NDMP Backup Archives Report. Provides information on backup archives and their associated storage policies.

  • Restore History Report. Provides a history of restore operations for the CommCell.

  • Scratch Pool Report. Indicates the status of the CommCell's scratch pools.

  • Storage Policy Report. Lists properties and media associated with the CommCell storage policies.

Creating Galaxy Reports

See the appropriate procedure in the Galaxy CommCell Administration Guide to generate the report you want to create.

Recovering a CommServe

For detailed information on disaster-recovery operations on a CommServe, follow the procedures outlined in "CommServe Recovery Procedures," found in Appendix A of the Galaxy CommServe Administration Guide. See the topic applicable to your configuration, in this case "Recovering a CommServe/MediaAgent." This topic outlines the process, and provides information on the Disaster Recovery tool used as part of the recovery operation. You must ensure that all storage devices (tape devices) are configured before performing the CommserveER restore.

Note: Galaxy 3.1 GSP1 requires an additional step after performing CommserveER. Before running the Galaxy Drive and Library Configuration, as instructed in the Administration Guide, change the properties on the task bar from 'backup01' to BACKUP01.

To recover a CommServe

  1. Click Start, point to Programs, click Galaxy, right-click Drive and Library Configuration, and then click Properties.

  2. Change the hostname in the startup command from 'backup01' to BACKUP01, and then click Apply.

  3. To confirm that this fix has been successfully installed, click Start, point to Programs, click Galaxy, click Drive and Library Configuration and then make sure that all of the text in the window in bold rather than being shaded.

The method used to recover the CommServe will depend on the status of the CommServeER backup data:

  • If the magnetic copy of the CommServeER backup data is lost, or has been damaged, you must retrieve the data from the tape prior to running CommServeER. Locate the CommServeER subclient tape, as described in the Deployment Guide, and restore the data by following the procedures outlined in "DRRestoreGUI". You must first install the CommServe (and MediaAgent) as outlined in CommServe Recovery Procedures found in Appendix A of the Galaxy CommServe Administration Guide. Then run the DRRestoreGUI to retrieve the CommServeER data, and continue with CommServe Recovery Procedures.

  • If the magnetic copy of CommServER backup data is available, skip DRRestoreGUI procedures and follow the procedures outlined in the Galaxy CommServe Administration Guide.

Note: Each original storage device must be properly installed and configured before carrying out the CommserveER restore.

DRRestoreGUI

The Disaster Recovery tool (DRRestoreGUI.exe) allows you to retrieve previously backed up Galaxy data in the case of a disaster. It can retrieve File System and ExpressRecovery backup data from tape, optical, or magnetic media. The DRRestoreGUI allows you to restore data from media to a user-defined destination.

To restore media using the DRRestoreGUI

  1. Make sure that there are no tapes loaded on any of the tape drives.

  2. In the Galaxy\Base\SystemTools directory on the newly installed CommServe, double click DRRestoreGUI.exe. The Galaxy Disaster Recovery window is displayed.

  3. Using a non-RSM tape or optical library, click Tape Detect. When detection is complete, the Tape Mount Path will list the available drives.

  4. Click Library Detect. An inventory of the library will begin. When detection is complete, the tape and barcode should appear in the windows.

  5. Select the barcode that contains the CommServeER data. (It is recommended that you note the barcode of the 'CSER' tape during deployment of the CommServe.)

  6. Click Catalog Tape. The catalog operation reads the archive file information from the media. A dialog box appears with the message, "Operation Finished. Check DRRecovery.log for details," and then click OK.

  7. An archive file was created during the previous step. This file is saved in the directory Galaxy\Base\SystemTools. The Archive file number is represented by x in this file name, Archive File ID x Catalog.txt; for example if the file name is Archive File ID 1 Catalog.txt, the Archive File ID is '1'. Note the Archive File ID from the file name.

  8. Close the DRRestoreGUI. This will dismount the tape.

  9. Open the DRRestoreGUI. Click Tape Detect. Click Library Detect. Select the barcode. Do not select Catalog Tape.

  10. Select the Archive File To Restore check box and type the ID of the archive file. The ID can be found in the name of the archive file created in Step 5.

  11. If the directory path in the archive file is C:\CSER, this data will be restored to C:\CSER on this CommServe. Select Optional Restore Path and enter a new directory location if desired.

  12. Click Start Restore. This will mount the tape and restore the files to the location listed in the archive file. A dialog appears with the message, "Operation Finished. Check DRRecovery.log for details," click OK.

  13. Check the location where the restored files were stored and verify your data.

You are now ready to complete the CommServe Recovery Procedures, as found in Appendix A of the Galaxy CommServe Administration Guide.

MediaAgent

Many aspects of the MediaAgent either require configuration or can be configured according to your specific backup and restore solution.

Managing Media

The best way to manage Media is by creating a closed media management cycle. Regular Archive Pruning is essential to a closed media management cycle. Media rotation is essential for good media management because:

  • It allows demarcation points between media sets, which facilitates media re-use.

  • It minimizes the impact on data recovery caused by the failure of one or more media (tapes, for example).

  • It optimizes costs and administrative overheads, while still providing data protection.

Understanding the Closed Media Management Cycle

A media management cycle describes the various states of a medium as it is used. There are four basic states:

  • Spare. Available for storing data; member of a scratch pool.

  • Active. The media is available for writing. In other words, when data is sent to the storage policy copy associated with the media group containing this media, the data is written to this media.

  • Used. Holds needed data, but is no longer being written to.

  • Expired. No longer holds needed data, and is eligible for re-use.

A closed media management cycle provides for the automatic re-use of media by ensuring media moves automatically through all states. Without a closed media management cycle, the administrator must constantly provide an external source for spare media and intervene manually to move the medium between various states.

Often administrators will plan backups and retention without regard to the number or source of media required to support the stored data. This usually manifests itself in unplanned budget expenditures, extra media administration, or failed data protection.

How Archive Pruning fits in

The primary purpose of Archive Pruning is to re-use the medium. It is the key function that enables an administrator to create a closed media management cycle. Without it you would never recycle media.

With a tape medium, Archive Pruning removes the metadata information pointing to the backed up data. When all pointers to a specific tape have been pruned, the tape is moved to the appropriate scratch pool and marked for re-use. No backup data on the tape needs to be erased because it is automatically written over when the tape is re-used. However, after Archive Pruning, the existing data on it still cannot be retrieved by Galaxy without the metadata pointers.

Magnetic disk libraries work differently in that, in addition to the metadata pointers being removed, the backup data is actually erased when you perform Archive Pruning. This is because magnetic disk does not support writing over existing data without erasing it first. This process provides for the automatic recovery of disk space for re-use by Galaxy.

The pointers to backup data that are eligible for pruning are those that exceed retention criteria. Which metadata pointers are pruned depends on the retention parameters of the associated storage policy's copy name. It is important to note that Galaxy can still retrieve it until you prune the pointers to the backup data. Also note that pruning is done for the entire CommCell and cannot be selectively applied to a specific storage policy.

There are several additional things that should be observed when determining pruning eligibility. First, if you have more than one active copy name in a storage policy, Galaxy rightly assumes you intend to do an Auxiliary Copy within that Storage Policy. Until you perform that auxiliary copy, no data for that storage policy can be pruned. Optionally, you could inactivate the other copy names and then prune. When you do that, however, you lose the synchronization of backup data between copy names and may jeopardize your ability to correctly restore data from those copies.

Second, Galaxy has certain requirements that ensure the continuity of data recoverability for a cycle set. A cycle set is defined as a full (or Synthetic Full) backup and all of its associated incremental or differential backups. Galaxy will not orphan data within a cycle set. This means that incremental or differential backups must have an associated full backup. Galaxy requires that all backup data within each cycle exceed retention parameters before any data within that cycle can be pruned.

Third, Archive Pruning should not be scheduled while backups are in progress. Archive Pruning will consider the backup in progress in its determination of eligibility without knowing whether that backup will eventually succeed or fail. This can yield undesirable results.

How often should you perform Archive Pruning? That depends on your remaining backup storage capacity, retention parameters, and backup schedule. Administrators should schedule Archive Pruning at least on a weekly basis because the more common cycle sets last one week.. Archive Pruning will not prune data sets if there are none eligible to prune, so it does no harm to run Archive Pruning more often, even daily. While this may be more pro-active in freeing up spare media, it does not give the administrator any room for error should a reason occur to delay Archive Pruning.

Media Rotation

Media rotation is a planned methodology of using separate media (or medium sets) and backup types over a period of time to store data. Media rotation is used to minimize the impact to data recoverability from the loss of one or more backup storage mediums.

Risks to storage media are many. A removable tape or magnetic-optical medium can become lost, damaged, worn, or deteriorated to the point of being unrecoverable. Magnetic media can experience various hardware failures, which can be compensated for by use of redundant array of independent disks (RAID) configurations. Using a single medium for storing data increases the risk of these failures happening to your backup data by introducing the medium as a single point of failure.

With Media rotation, each medium or medium set is self-recoverable; it does not require any of the other media used in order to restore data. This is accomplished by making each backup set independent of the other. These sets are then used alternately over a period of time. Multiple backup sets with varying usage times and rates can be combined to provide the degree of protection desired.

Although rotating media reduces risk, it results in added costs for media and administrative overhead. As a result, various methods of media rotation have been developed that optimize the ratio of overhead to risk reduction.

There are different rotation schemes to suit different systems, different environments, and different organizational needs.

Media Rotation Systems

At a minimum, you should have two media sets that you rotate on alternate backups. This protects you against relying on a single backup media set, and eliminates the chance that a hard disk crash during backup would leave you with nothing at all. It is not the ideal level of protection, because there is no provision for off-site media storage.

If you use two media sets, you need to decide how often to do the backup. The longer you go between backups, the longer the changes that you made since the last backup are at risk. For many users who use their systems little enough that this minimum scheme makes sense, doing backups weekly is more than sufficient. For others, daily backups make more sense, which means that a more comprehensive rotation scheme is required.

Good media rotation schemes provide multiple media sets and a depth of file versions that a file to be restored to a particular point in time, such as prior to a virus attack. Grandfather-father-son (GFS) and Tower of Hanoi are two well-established rotation schedules that provide a long and varied history of file versions and comprehensive recovery capabilities.

Implementing Media Rotation Schemes

Galaxy's support of media rotation schemes depends on iDataAgents. Table 4.18 lists the media rotation support for each iDataAgent.

Table 4.18 Supported media rotation systems

iDataAgent

Media rotation support

Comments

File System (Windows NT and Windows 2000, Netware, and UNIX)

Multiple backup sets and Synthetic Full backups

Each set has identical subclients and different storage policies

Transaction log-based (Microsoft Exchange, Microsoft SQL Server, IBM Lotus Notes, Oracle Server)

Auxiliary copy

Continuity of transaction logs is critical

NAS (NetApps and EMC Celera)

None

Auxiliary copy, or multiple backup sets, are not supported

Multiple Backup Sets

Galaxy's file system iDataAgents support the use of multiple backup sets, which allows you to configure duplicate subclients assigned to different storage policies and, therefore, different media sets. You should create a backup set for each set in a media rotation schedule and schedule the associated subclients in accordance with the media-rotation timetable. Restoring requires you to select which backup set or media you want to use.

Synthetic Full Backups

Synthetic Full backups enable you to do a full backup to new media without involving the client. This restore-to-backup function consolidates your previous backups onto a new tape. Be aware that a Synthetic Full backup does not collect any data from the client and, therefore, is not a substitute for your regularly scheduled backup. If you schedule a Synthetic Full backup followed immediately by a normal full backup to new media, you can isolate a full backup on a single set of tapes for export and offsite storage. Restoring requires you to specify a point in time between the last backup before the Synthetic Full backup and the time of the Synthetic Full backup.

Auxiliary Copy

Auxiliary copy synchronizes backup data between multiple copy names and media. With applications that depend on transaction logs for recovery, making an auxiliary copy is the only way to support the use of multiple media sets to minimize risk of data loss from a single media failure. Inactivating and taking a copy name offsite is an option for disaster recovery.

Migrate Media Between Storage Policy Copies

Media migration provides you with a great deal flexibility in media management. For example, if a library is destroyed, you can simply change the metadata pointers at the CommServe to point a storage policy's media to a different library.

The following restrictions apply to media migration:

  • Media must be compatible between libraries.

  • Media cannot be migrated from a MediaAgent for Windows to a UNIX MediaAgent, nor vice-versa.

  • You can migrate from a library to a stand-alone drive, but cannot migrate media from a stand-alone drive to a library.

To migrate media

  1. Manually remove the media from the source library and insert it into the destination library.

  2. In the CommCell Browser, right-click the storage policy copy whose media you want to migrate, and select Migrate Media.

  3. Galaxy lists the media owned by the storage-policy copy and again prompts you to remove the media from its original library. Click OK to continue.

  4. Select the destination MediaAgent, Library, Master Drive Pool, Drive Pool, and Scratch Pool. Click OK when finished.

  5. A dialog box prompts you to indicate whether the destination library and drives are compatible. Click OK.

  6. When you receive the message that the media has been successfully migrated, click Close to complete the operation.

Media Expiration

It is necessary to replace media before they begin to degrade. Galaxy helps you do this by keeping track of various types of media events (for example, software error, mount operation). For each medium, the system tracks the number of times each event occurs. When the number of events exceeds a preset threshold, the system lists the medium in the Media Management Housekeeping report, notifying you that it is time to replace the medium.

You can set event thresholds for each media type. In other words, you can decide how many events of each event type can occur before a medium of a particular media type exceeds its capacity for reliable operation. When an event exceeds its threshold value, Galaxy sends a message to the event log and generates the Threshold Exceeded alert, if configured.

Note: See the manufacturer's documentation for the recommended maintenance criteria for each media type.

Galaxy allows you to set various media expiration thresholds. As shown in Table 4.19.

Table 4.19 Media expiration thresholds

Threshold

Description

Number of mounts

The number of times the medium can be mounted in a drive before it must be replaced.

Number of soft errors (since cleanup)

The number of software errors that can be encountered while writing to or reading from the medium before the medium must be replaced.

Number of years

The length of time the medium can remain in use.

Number of writes

The number of times data can be written on the medium before it is marked as expired.

Number of reads

The number of times data can be read from the medium before it is marked as expired.

Number of reuses

The number of times the medium can be recycled before it is marked as expired.

Number of hard errors

The number of hardware errors that can be encountered while writing to or reading from the medium before it is marked as expired.

For information on the procedure for modifying media maintenance thresholds see online Help, under the topic "Media Expiration Parameters."

Managing the Index Cache

Each MediaAgent maintains an index cache, which is a designated portion of the Media Agents' hard drive in which Galaxy index data resides. Index data is a valuable resource because it provides Galaxy with an efficient mechanism for locating user files for browse and restore operations. Although this index data is stored on the backup media for safekeeping, Galaxy writes an additional copy to the index cache of the MediaAgent that manages the backup. Data maintained in the index cache can be accessed more quickly than data stored on backup media if the corresponding user data is needed for browsing or restoration.

Galaxy manages the cache on a least-recently-used (LRU) basis. As the capacity of the cache is reached, Galaxy overwrites those index data files that have been least recently accessed with the new index data. If a restore operation requires index data that is no longer in the cache (that is, a cache miss), Galaxy recovers the index data from the backup media.

The index-cache directory is the directory in which index data resides. The amount of index data that can be cached is the amount of storage space available to the directory. This is determined by the size of the partition that contains the index-cache directory and by the amount of storage space occupied by other data (if any) within the same partition. (A partition is a logically designated portion of the hard disk.)

To ensure that other files do not use up disk space that is needed for index data, you can create a new partition specifically for the index cache directory. The partition should be large enough to accommodate four percent of the amount of data managed by the MediaAgent. Specifically, this means four percent of the maximum amount of backed-up data that can be available for restoration by using this MediaAgent.

Note: Do not specify or relocate a MediaAgent's index cache to a directory residing on a compressed drive.

Calculating the Storage Space Required for the Index-Cache Directory

To calculate the amount of disk space needed, you must consider:

  • Which clients use the MediaAgent in question for backup and restore operations.

  • The approximate amount of storage space required for a full backup of each client.

  • The approximate amount of storage space required for incremental or differential backups of each client.

  • The maximum number of full and partial backups that are retained for each client.

For example, assume that you have a MediaAgent that serves the backups of five file system clients. Each client has a 2-GB hard drive containing file system data. You run one full and two incremental backups for each client every week, and the retention period for these clients is 21 days and three full backup cycles. (For more information on retention periods, see the Overview chapters of the Galaxy Client Administration Guides for individual iDataAgents). You would calculate the storage space needed for the index cache as follows:

  • The maximum storage space required for a full backup of all clients is 5 * 2 GB = 10 GB.

  • If you estimate each incremental backup at 100 MB, the storage space required for an incremental backup of all clients is 5 * 100 MB = 500 MB, which is equivalent to 0.5 GB.

  • Each backup cycle includes one full and two incremental backups. Consequently, a single full backup cycle for all the clients that are using the MediaAgent requires an estimated 11 GB of storage space (10 GB for the full backup, and 0.5 GB * 2 = 1 GB for the incremental backups).

  • The retention period requires that three full backup cycles be available for restoration at all times, so the total storage space required for File System backups is 3 * 11 GB, or 33 GB. This is your estimate of the maximum amount of data that can be available for restoration by using the MediaAgent.

  • Four percent of the total is 0.04 * 33 GB = 1.32 GB.

Consequently, you should ensure that approximately 1.32 GB of storage space is available for the index cache directory.

This example describes a very simple configuration, with just one iDataAgent and uniform requirements across client computers. In reality, client computers can have more than one iDataAgent, and the storage space required by each type of data must be added into the total. Different computers can have widely varying storage requirements. For example, an Exchange server might require much more storage space than a desktop computer. If different clients have different retention periods, this must also be considered in the calculation.

Library Sharing

To help you get the most out of your tape and/or optical libraries, Galaxy allows you to allocate the medium changer and drives within a library to different MediaAgents within the CommCell. The system creates a Master Drive Pool for all of the drives within a given library that are controlled by a specific MediaAgent. (Although the library's medium changer is attached to one MediaAgent, all MediaAgents that are attached to the library have access to the medium changer through centralized software). The following are some applications of library sharing:

  • Libraries can be shared directly using different SCSI cards, or using a SAN. Drives within a shared library can also be shared by using Dynamic Drive Sharing within the SAN. For more information on the interaction between Galaxy and SANs, see the Galaxy Pre-Installation Checklist.

  • More MediaAgent processing power is available for a shared library. If you run multiple jobs simultaneously, you can improve job performance by distributing the load among MediaAgents.

  • In certain cases, you may want to eliminate network traffic by sending large backups from a client computer directly to a library. For example, if you have a very large database on a client computer, you can install the MediaAgent software on the client, attach the client or MediaAgent to a library, and send backups directly without using the network. Library sharing allows you to use some drives within a library in this fashion while keeping other drives available for normal network operations.

The Master Drive Pool contains all the physical drives in the library, which can be shared among all the MediaAgents that are connected to this library. The logical group of drives within a single tape library that are actually controlled by a specific MediaAgent is referred to as a drive pool.

Figure 4.13 shows a directly-attached shared library, shared by three MediaAgents. Note that any of these MediaAgents can also be attached to additional libraries.

Figure 4.13: Directly-attached shared library

Figure 4.13: Directly-attached shared library

The functions of the MediaAgents shown in Figure 4.13 are:

  • MediaAgent 1. Controls the library's medium changer and Drive 1 and Drive 2, which are assigned to Master Drive Pool 1.

  • MediaAgent 2. Controls Drive 3 and Drive 4, which are assigned to Master Drive Pool 2. This MediaAgent is also the host of a large SQL Server database, and a SQL Server Galaxy client.

  • MediaAgent 3. Controls Drive 5, Drive 6, and Drive 7, which are assigned to Master Drive Pool 3.

Dynamic Drive Sharing

Figure 4.14 shows a library shared by using a SAN with Dynamic Drive Sharing. Three MediaAgents share a tape library with four drives. Note that any of these MediaAgents can also be attached to additional libraries.

Figure 4.14: Dynamic Drive Sharing

Figure 4.14: Dynamic Drive Sharing

Note the following in Figure 4.14:

  • All the MediaAgents share the same four drives (Dynamic Drive Sharing).

  • MediaAgent 1 controls the library's medium changer.

  • Each MediaAgent has a drive pool that is grouped under one master drive pool for the library.

If you divide control of a library's drives among multiple MediaAgents, you must take the following into account to avoid resource contention:

  • When a library's resources are divided among MediaAgents, and if resource availability is limited, resource contention is more likely than if the library were not shared.

  • When you configure storage policies, the number of drives in the smallest drive pool associated with any copy of the storage policy determines the maximum number of streams that can be created simultaneously by any copy of the storage policy. For additional information on storage policies, copies, and resource contention, see the Galaxy Client Administration Guide of your iDataAgent.

RSM-Controlled Libraries

Galaxy can use the Windows 2000 Removable Storage Manager (RSM) service to support operations in your library. RSM enables multiple applications to share a library. Before you configure Galaxy to use RSM, verify the following:

  1. All Galaxy libraries in your MediaAgent computer use RSM. RSM libraries should not be mixed with non-RSM libraries.

  2. Your libraries and drives are correct. To verify your libraries and drives:

    • From Device Manager, make sure the attached medium changer, tape, or optical drives for the library are listed.

    • If drives are not listed, detect the device and install the appropriate driver. For more information on this task, see the user manual provided by the manufacturer of your library and drive.

  3. The RSM service is on. To do this:

    • In the Computer Management window click the Services icon and make certain that the Status field shows Removable Storage as Started.

    • If it does not show as Started, right-click Removable Storage and click on Properties. Under Startup type select Automatic. Click Apply then right-click Removable Storage and then select Start.

  4. The medium changers are not disabled and all target libraries are working (media and drives are shown in the Removable Storage/Physical Locations folder when using the Removable Storage Microsoft Management Console (MMC) Snap-in.

    Note: For Windows 2000 RSM, auto configuration requires that all drives in the library have to be on one SCSI bus. Otherwise, manual configuration procedures are needed.

  5. Unrecognizable and/or import media have been moved into the free media pool. To do this using the Removable Storage MMC Snap-in, right-click the media available in the /Removable Storage/Media Pools/Import or /Unrecognized folder, then click Prepare.

  6. Click Yes to confirm in the Media Preparation window and click Yes again to confirm each individual media label.

  7. After the selected media are in the free pool they have an Available status and are ready for allocation by Galaxy.

To configure a library that uses the RSM service for Galaxy

Before you begin, ensure that the libraries used by Galaxy work under the RSM service. (If the libraries function under the RSM service, Galaxy automatically recognizes the RSM-enabled devices when you detect the RSM devices using the Galaxy Library and Drive Configuration window.) Also, verify that the required manual preparation for free media is done.

Note: You can use libraries with or without barcode scanners.

  1. Display the Galaxy Library and Drive Configuration window.

  2. Detect the devices that are controlled by the MediaAgents that will access the library. Galaxy detects the devices and displays them in the Galaxy Library and Drive Configuration window, with their detection status displayed as one of the following: not configured, RSM enabled, or RSM detect success.

  3. If you want to modify the library properties, right-click the library and then select Properties.

  4. In the Galaxy Library Properties dialog box, you can change the following properties:

    • Alias. The user-defined name for the library. Galaxy displays this name in the CommCell Browser for the library. It is recommended that you give each library a descriptive name as its Alias, for easier system administration.

    • Door Check Seconds. This interval, expressed in seconds, determines how frequently the system checks to see whether the library door is open. If the door is open during a check, the system conducts a full inventory of the library after the door is closed. This brings the inventory up to date way, if media were manually inserted or removed from the library while the door was open, the inventory is brought up to date. If you open and close the door in the interval between checks, the system does not detect the opening and closing, and does not update the library's inventory.

  5. When you are satisfied with your changes, click OK.

  6. In the Galaxy Library and Drive Configuration dialog box, right-click the library that you want to configure, and then click Configure.

  7. A prompt appears, asking if you are sure that you want to configure the library. Click Yes to continue with the configuration.

  8. A prompt appears, asking if you want to configure all of the drives within the library.

    • If you want to configure the drives individually, click No.

    • If you want to configure all of the drives within the library (for example, if you are doing a typical library installation), click Yes.

    The status of the library changes to RSM configured. If you chose to configure all associated drives, the status of the drives (and of the drive pool that contains them) also changes.

To protect the RSM database from corruption

  1. On the MediaAgent computer containing the RSM database, create a new backup set exclusively for the RSM database.

  2. If necessary, reset the default subclient content to avoid backing up the entire computer. This is because the default content entry of the default subclient is "\", which means back up everything on the computer that is not defined or filtered by other subclients. To avoid backing up the entire computer, reset the default subclient content to be a small folder or a file on the computer.

  3. Use a storage policy associated with a library that is not controlled by this RSM.

  4. Schedule frequent backup schedules for the backup set that contains the RSM database; alternately, you can manually back up this backup set at frequent and regular intervals.

To restore the RSM database

  1. On the MediaAgent computer that contains the RSM database, right-click the backup set and choose Restore System Databases. In the Restore System Databases Options window, select only the RSM database option and click OK.

  2. After a successful restore operation, restart the RSM service or restart the computer, if necessary.

Recovering a MediaAgent

For information on disaster-recovery operations on a MediaAgent, see the Galaxy CommServe Administration Guide.

Libraries and Drive Operations

You can manage libraries, drive pools, and stand-alone drives within your backup and restore solution.

Master Drive Pool

The Master Drive Pool contains the total number of drives in the library, which can be shared among all the MediaAgents that are connected to this library.

The following procedures on the Master Drive Pool are available in the Galaxy MediaAgent Administration Guide:

  • Configuring a Master Drive Pool

  • Validating the SCSI mapping of drives within a Master Drive Pool or Drive Pool

  • Viewing Master Drive Pool Properties

  • Deconfiguring a Master Drive Pool

Drive Pool

A Drive Pool is a group of drives within a single tape library that are controlled by a specific MediaAgent.

The following procedures on Drive Pools are available in the Galaxy MediaAgent Administration Guide:

  • Configuring a Drive Pool

  • Viewing Drive Pool properties

  • Deconfiguring a Drive Pool

Library Inventory

Galaxy maintains an inventory of all media associated with each library. It assesses the contents of the inventory using the inventory operation, which identifies the slot location and barcode or On Media Label (OML) of every medium detected within the library. A medium that is mounted in a drive is not included in the inventory. After the medium is removed from the drive and returned to a storage slot, Galaxy updates the inventory with the medium's barcode (or user name), and location.

Note: The inventory operation finds out which media are contained within a library. However, in order to use new media, Galaxy requires additional information, which is collected by the discovery operation.

The inventory operation, which may take a few minutes depending on the settings in the individual library, usually takes place when any of the following occurs:

  • The door of the library is opened and then closed.

  • The library's power is turned on.

  • A Reset Library operation is requested, although not all libraries invoke the full inventory command on a reset library command.

In addition, many library models conduct a full inventory operation when any of the following occurs:

  • You install and configure the library for the first time.

  • The CommServe's Library and Media Manager service is restarted (this happens when you restart the CommServe).

  • The library's Library Management Service (LMS) is stopped and then restarted (this happens when you restart the MediaAgent).

In addition, the inventory is updated when media are imported or exported through a library's mail slot.

Note: Inserting media in and closing the mail slots of some libraries may trigger a full inventory operation (rather than an inventory update).

When an inventory operation or update is performed for a library, Galaxy takes the library offline until the procedure completes successfully. This means that new backup or restore operations that access the library cannot start until the inventory completes. Because the inventory does not affect media that are already mounted in drives, a backup or restore that is in progress when the inventory begins can continue as long as it does not need to access unmounted media.

For details on viewing the inventory of a library, see "Library Inventory" in online Help.

Importing Media

Note: Ensure that the barcode used in the media is compatible with the library's barcode reader (see the library manufacturer's documentation for a list of compatible label formats). Importing media with an incompatible barcode may cause all operations in the library to fail.

Importing is the process by which you move media that are outside a library into storage slots within the library. There are two ways of importing media:

  • You can import media through the library's mail slot (if one is available).

  • You can open the library door and insert media into storage slots by hand.

Importing media through a mail slot offers the following advantages: The inventory update that is triggered by a mail slot import is much less time-consuming than the full inventory operation that is triggered when you open and then close the library door. In addition, if you import new media through a mail slot by using the Galaxy import operation, Galaxy automatically discovers the media.

If you open the door and insert media, you must initiate a discovery operation. You must also initiate a discovery operation if you import through a mail slot, without using the Galaxy import operation. However, under certain circumstances you may want to open the library door even though a mail slot is available. For example, if you want to add many media to a library at once, it may be faster to open the door than to use the mail slot.

For libraries using the RSM services, media should be imported using the RSM MMC Snap-in window.

Note: If you are not using a mail slot, be careful not to open the library door while media are mounted in drives within the library. In some library models (for example ATL 200 and ATL 500) opening the door causes the library to unmount all media, even those that are in active use. This can cause database inconsistency and failure of the running job(s).

For details on importing media into a tape or optical library, see "Library Operations" in online Help.

Discovering Media

Before Galaxy can use a new, unrecognized medium, it must collect certain information about it through a process known as discovery. When a medium has been discovered and its information is entered into the Galaxy database, the medium is catalogued. Galaxy retains media information permanently; a medium does not have to be rediscovered if it is exported from the library and reimported.

Note: Because Galaxy retains media information, a given barcode can only be used on a single medium within a CommCell. Do not reuse a barcode even if the medium to which it was attached is removed from the CommCell permanently.

If new media are imported through a library's mail slot, the import operation automatically discovers them. If you import new media by opening the library door and inserting them, you must initiate a discover operation.

Note: Although only uncataloged media must be discovered, it is recommended that you initiate a discovery operation every time you open the library door and insert media.

When a medium is imported, the system assigns it in one of the following ways:

  • The medium is already catalogued. The medium belongs to the scratch pool, or to a storage policy copy to which it was assigned before it was exported.

  • The medium is not already catalogued, and is successfully discovered. The system assigns the medium to the scratch pool that you select.

  • The medium is not catalogued, and is not successfully discovered. The system assigns the medium to the unidentified media group.

For details on discovering media within a library, see "Library Operations" in online Help.

Exporting Media

Exporting is the process by which you physically remove one or more media from a library. When you export a medium, the data that it contains is no longer at the immediate disposal of the Galaxy system. If an operation (for example, restore or auxiliary copy) requires data from an exported medium, you will have to re-import the medium in order to complete the operation. Galaxy retains information about exported media; they do not have to be rediscovered if they are re-imported.

There are two ways to export media:

  • You can export media through the library's mail slot (if one is available).

  • You can open the library door and remove media from the storage slots by hand.

Exporting media through a mail slot offers an advantage. The inventory update that is triggered by a mail slot export is much less time-consuming than the full inventory operation that is triggered when you close the library door. However, under certain circumstances you may want to open the library door even though a mail slot is available. For example, if you want to remove many media from a library at once, it may be faster to open the door than to use the mail slot. Media that are being written to or read from cannot be exported. It is recommended that you enter a description of the storage location and appropriate reference information when you export a medium.

Note: Removing media from and closing the mail slots of some libraries may trigger a full inventory operation (rather than an inventory update).

For details on exporting media from a tape/optical library, see the "Library Operations" topic in online Help.

Resetting a Library and Drive

Resetting a library unmounts all tapes from the drives in the library, and resets all the drives and the library so that they are ready for use.

Resetting a drive unmounts the tape from the drive, and resets the drive so that it is ready for use. You can also perform this operation on a stand-alone drive.

For details on resetting a library, see "Library Operations" in online Help.

Cleaning Drives

Ensure that you have imported or moved a cleaning medium into the Cleaning Media Pool before you perform the drive cleaning operation.

If a job is in progress in the drive you want to clean, the drive cleaning operation will fail. Ensure that the drive is free before you start the operation.

The drive cleaning operation is not available for stand-alone drives, Optical libraries, or RSM-controlled libraries.

For Galaxy to perform the Clean Drive function, the library's auto-cleaning feature must be disabled from the library's front panel menu. For example, in the Exabyte X80 library you can use the following steps to disable the autoclean function:

  1. Switch to LCD mode: On the main menu, select RobotControl, select LCD, then click Save.

  2. Change the Autoclean Mode: On the main menu, select ConfigMenu, then select AutoclnSetup, then click DisableAutocln

  3. Switch to SCSI mode: On the main menu, select RobotControl, then select SCSI, then click Save.

Additional information on drive cleaning is available in the CommVault Galaxy CommCell Media Management Administration Guide.

Media Groups and Scratch Pools

A scratch pool is a repository of media that are available for use. When a backup, synthetic full, or auxiliary copy operation requires a new medium, the system takes one from a scratch pool.

Media arrive a scratch pool when they are:

  • Assigned to a scratch pool. Media are assigned to a scratch pool when they are physically imported from outside the library.

  • Logically reassigned between scratch pools. Media can be reassigned from one scratch pool to another scratch pool.

  • Returned to a scratch pool. When data is pruned or deleted the system returns media to a scratch pool.

Every library has a default scratch pool, which Galaxy creates when the library is configured. When the system creates a storage policy for the library (for example, when the library or one of its drive pools is configured), the primary storage policy copy is associated with the default scratch pool. In addition, when you import new media into the library, this is the scratch pool to which they are assigned (unless you specify otherwise). You can create any number of additional scratch pools, and assign these to different storage-policy copies that access the library. You can also designate a user-defined scratch pool as the default for the library. (For information on storage policies, storage-policy copies, and changing the scratch pool associated with a storage policy copy, see the Galaxy Client Administration Guide for individual iDataAgents.)

The ability to create scratch pools and assign them to specific storage policy copies enables you to ensure that critical operations always have the media that they need. For example, assume that you regularly back up both a file server containing mission-critical data and a number of user computers. You may want to prevent situations in which less important computer backups use up all available media, causing vital file server backups to fail. You can do this by creating a scratch pool specifically for the storage-policy copies that conduct file-server backups.

Galaxy also allows you to move media between scratch pools. In the preceding example, if you noticed that the supply of media in the scratch pool dedicated to the file server was getting low, you could logically reassign media from another scratch pool to the file-server pool.

The following procedures are available under the "Scratch Pools" topic in online Help:

  • Creating a Scratch Pool

  • Viewing or Changing Properties of a Scratch Pool

  • Viewing the Inventory of a Scratch Pool

  • Importing Media into a Scratch Pool

  • Moving a Specific Medium from One Scratch Pool to Another

  • Moving a Number of Unspecified Media from One Scratch Pool to Another

  • Deleting a Specific Medium from a Scratch Pool

  • Exporting a Specific Medium from a Scratch Pool

  • Deleting a Scratch Pool

Galaxy allows you to establish a low watermark for every scratch pool. This parameter represents the minimum number of media that should be available from the scratch pool at all times. If the number of available media falls below the low watermark, Galaxy logs a message to the event log and adds an entry to the Scratch Pool Report.

When you establish a low watermark, consider the media requirements of all operations (for example, backups, auxiliary copies, and Synthetic Full backups) that draw from the scratch pool. The low watermark should be high enough to ensure that you will be notified of the need for more media while there are still enough media available to allow running operations to complete. For example, if the operations that access a particular scratch pool regularly fill two media every week, you might set the low watermark at three. This way, Galaxy advises you every week to add more media to the scratch pool while it still contains sufficient media to handle its normal operational load.

For information on media groups, storage policy copies, and other Galaxy entities that determine the load placed on a particular scratch pool, see the Galaxy Client Administration Guide.

Assigned Media Group

The assigned media group is a repository of media that are used by Galaxy. When a backup, Synthetic Full, or auxiliary copy operation requires a new medium, the system takes one from a scratch pool and adds it to the assigned media group. As soon as the media is in use, its status is displayed as Active. If the medium is full or marked as full, the status is displayed as Full. Galaxy no longer writes to the media; media marked as full can only be used for restoring data.

Cleaning Media Pool

The cleaning media pool is the logical repository for the cleaning media. When you configure a library for the first time, the system creates a cleaning media pool for each library.

Galaxy will use the catalogued cleaning media during the drive-cleaning operation, if auto drive cleaning is not available for a library.

If you do not identify the media as a cleaning media, Galaxy considers it to be regular media and attempts either to validate the drive or write on the media when you run a backup. Such an attempt would fail. The ability to identify cleaning media ensures that the validate and backup operations will not use them.

Note: If your library manufacturer provides you with a special barcode labels for cleaning media, use these labels on your cleaning media. For example, cleaning media labels for some libraries start with the letters CLN. Because RSM supports the auto drive-cleaning function, Galaxy does not need the drive-related operations for RSM-controlled libraries. Clean Drive Option is not available for stand-alone drives.

The following procedures are available under the topic "Cleaning Media Pool" in online Help.

  • Importing Cleaning Media to the Cleaning Media Pool

  • Discovering Cleaning Media within a Library

  • Moving a Cleaning Medium from Scratch Pool to Cleaning Media Pool

  • Exporting Cleaning Media from the Cleaning Media Pool

  • Deleting Cleaning Media

Exported Media Group

Whenever media are exported from the library, which includes the spare media, used media, or cleaning media, the media are listed in the exported media group. All the media used in stand-alone drives are listed in the exported media group.

Unidentified Media Group

The unidentified media group is a logical repository for media within a library that cannot be used by the Galaxy system. When you configure a library for the first time, the system creates one unidentified media group for the library.

A medium may be placed in the unidentified media group for the following reasons:

  • The medium contains data and had been used by other applications.

  • The system encountered an error when it tried to discover the medium.

  • The system encountered an error while initializing the medium (for example, the medium was damaged or write-protected).

The following procedures are available under the topic "Unidentified Media Group" in online Help.

  • Viewing the Properties of an Unidentified Media Group

  • Moving Media from an Unidentified Media Group to a Scratch Pool

  • Moving Several Media from an Unidentified Media Group to a Scratch Pool

  • Exporting all Media from an Unidentified Media Group

Stand-Alone Drive Operations

A stand-alone library is a one-drive storage unit with no media storage capability, no medium changer, and no barcode reader.

Note: Because stand-alone drives do not have the facility to store used media, it is your responsibility to label and store all used media in a secure and accessible location. It is strongly recommended that you physically label each stand-alone drive using the library name shown in the configuration window. This will help you identify the proper drive when Galaxy prompts you to insert a medium into a drive.

The following procedures are available in the online Help, under the topic "Stand-Alone Drive Operations":

  • Viewing or Modifying Properties of a Stand-alone Library

  • Viewing or Modifying Properties of a Drive Pool

  • Viewing or Modifying Properties of a Stand-Alone Drive

  • Viewing or Modifying Properties of a Medium

  • Making a Stand-Alone library Online or Offline

  • Overwriting Tapes in Stand-Alone Drives

Media Operations in Stand-alone Drives

Stand-alone libraries do not have an initial list of spare media. The system prompts you to insert a new medium whenever it is required. Galaxy creates an On Media Label (OML), which is a unique internal identifier (unique ID) for each medium, the first time you insert the media in the stand-alone library. Subsequently, you can provide your own unique ID for the medium. Whenever you insert a new medium, Galaxy prompts you to enter the unique ID and the storage location for the medium. This prompt is in the form of a pop-up message.

You can run a backup or restore operation on a stand-alone drive by doing one of the following:

  • Insert the correct medium in the stand-alone drive before starting an operation. Galaxy identifies the medium by using the OML and proceeds with the operation. Galaxy does not display any messages or prompts when it finds the correct medium in the stand-alone drive.

  • Leave the stand-alone drive empty and wait for Galaxy to prompt you to insert the appropriate medium. After the medium is inserted, Galaxy uses the OML to identify the medium and proceeds with the operation when it finds the correct medium.

  • Insert or have an incorrect medium in the stand-alone drive. After the medium is inserted, Galaxy uses the OML to identify the medium and proceeds with the operation when it finds the correct medium.

Note: If an operator is not available to insert the required media in a stand-alone drive, it is recommended that you avoid scheduling jobs that use different storage policies. If you want to schedule jobs for a stand-alone drive, make sure that all of the jobs use the same storage policy. If a scheduled job uses a different storage policy from the one to which the medium in the drive belongs, the job cannot start until someone removes that medium and inserts another. This may defeat the purpose of scheduling the job.

All media available in a stand-alone drive are displayed in the CommCell Browser under the Exported Media pool except the currently used medium, which is displayed under the stand-alone drive.

Pop-Up Messages

Galaxy displays a pop-up message for every operation in the stand-alone drive. You do not have to respond to the pop-up messages generated by Galaxy for stand-alone drives. These messages are displayed for four minutes and automatically disappear after that time.

When you insert a new medium Galaxy displays a pop-up message prompting you to enter a unique ID and the storage location for the medium. You can either:

  • Enter the information and click OK.

  • Click OK without entering the information.

  • Do nothing. The message is displayed for four minutes, and after four minutes it automatically disappears.

You can however, add the information in the CommCell Browser, by using the Media Properties dialog box. If you do not subsequently add the information, the pop-up message will be displayed whenever you re-insert the medium, until you provide a unique ID for the medium.

When you perform a backup or restore operation, Galaxy displays a pop-up message if it finds the stand-alone drive empty, or if does not find the correct media.

Galaxy displays these messages on the MediaAgent computer to which the stand-alone drive is attached, and on all computers that have the CommCell Console (both MMC and/or Java GUI) open. For example, on the MediaAgent computer, if both the Java GUI and MMC are open, you will see three pop-up messages with the same message. You can click OK in any one of these messages. However, only a response on the MediaAgent computer will take effect. If you do not respond to the message, the message displays for four minutes and after four minutes it automatically disappears. The message displays again when Job Manager re-tries the job and does not find the required medium.

Migrating a Magnetic Library

You can use the CommCell Browser to view the properties of magnetic libraries and mount paths, to take these entities online and offline, and to configure magnetic library alerts (e-mail notification). For a detailed explanation of Galaxy alerts, see the Galaxy CommServe Administration Guide. The user has the option of migrating a magnetic library to another MediaAgent. This may be helpful if the user wants to release the MediaAgent so that it can be used for a non-backup purpose. The migration is a logical rather than a physical operation.

To use this feature, the MediaAgent that is being migrated to must have access to the same mount path as the MediaAgent that is being migrated from. Therefore, it is recommended that the MediaAgents within the user's backup system have mirroring. Mirroring allows one MediaAgent (purple, for example) to be set up identically as another MediaAgent (green, for example). Using this example, purple, as a mirrored version of green, would be able to perform all of the MediaAgent functions that green performs.

Magnetic Library Migration to another MediaAgent is supported for UNC paths and local paths for the Windows and UNIX File Systems. If mirroring is not an option, the user must have mount paths containing UNC paths for Windows or the Network File System (NFS) mounted File System for UNIX. Also, before performing any operation, you should ensure that all mount paths are online or accessible.

Cross-platform migrations are not allowed (that is, you cannot migrate a magnetic library from a MediaAgent for Windows to a UNIX MediaAgent, or vice versa).

The following procedures are available in the online Help, under the topic Magnetic Disk Library Administration Procedures:

  • Viewing or Changing Magnetic Disk Library Properties

  • Viewing or Changing Mount Path Properties

  • Migrating a Magnetic Library

Client Job Results

Job results are viewed by using the Backup History and Restore History features. You can specify the job results directory to which the client computer's backup and restore job results are written. Galaxy provides the following options to administer the job results directory from the subclient's Properties dialog box.

  • Change the job results location. If you change the job results location path, Galaxy copies all existing job results to the new path as well.

  • Set a job results save period. You can establish a time period (days) for which backup and restore job results are maintained.

  • Specify a disk capacity threshold to initiate pruning of job results. You can specify a disk capacity threshold that, if exceeded, causes Galaxy to prune job results. The disk is that disk on which the job results of the client computer are stored (probably a local disk). Note that capacity utilization refers to the combined disk usage of all data (including applications) stored on the disk; not just that portion used for job results.

Note: Do not specify or relocate the job results directory to a directory that resides on a compressed drive.

Using Pipeline Pairs to Configure for Multiple Network Interfaces

Many companies do not want backups to saturate their production network. The solution is to install a second, high-speed network on the servers for backup and restore data only. In some cases, multiple networks may be assigned for backup use. You can use Pipeline Pairs to configure Galaxy subclients to take advantage of these additional networks.

Pipeline Pairs are configured at the subclient level.

To configure pipeline pairs

  1. Open the subclient's Properties dialog box and click the Storage Device tab.

  2. Click Advanced and add or delete pipeline pairs in the bottom half of the window. When you click Add, each network connection available between the MediaAgent and the Client appears in a set of dropdown boxes.

  3. Select a combination to create a Pipeline Pair.

Moving Data Within Pipeline Pairs

If there are no Pipeline Pairs added, backup/restore data is moved across the default network connection. When you add Pipeline Pairs, the default network connection will relegate itself to handle only coordination data exchange between the CommServer, MediaAgent, and Client. All backup/restore data movement between the client and the MediaAgent will be on the added Pipeline Pairs.

If more than two network connections are available between the MediaAgent and the client, additional Pipeline Pairs can be added. For example: If the Client-MediaAgent combination has three network connections available in total, you can have the default connection plus two Pipeline Pairs. Each backup/restore stream initiated between the Client-MediaAgent will use the Pipeline Pairs alternately in a round-robin fashion. Stream 1 will use the first pair, Stream 2 the second, Stream 3 the first, and so on. Note that you cannot split a data stream over two different Pipeline Pairs.

To use Pipeline Pairs, both the MediaAgent and the Client must have multiple adapters installed and properly configured. The connections should not share the same data path (routers, for example) in order to take full advantage of the additional bandwidth. You must also have correct IP Address/Name resolution before you can add Pipeline Pairs.

Configuring Multiple Adapters

A multi-homed computer is one that has two or more network interface cards (NICs). To ensure proper name/IP address resolution within Galaxy, it is necessary to uniquely name each NIC in the domain name system (DNS). An example of this is a computer named amber, with fully qualified host names of amber1.nwtraders.com and amber2.nwtraders.com, and the computer has two NICs with the following IP addresses:

  • First NIC: 150.128.4.78

  • Second NIC: 150.128.6.32

To ensure that both interfaces can be resolved, you would need to define unique names within DNS, such as:

  • amber1.nwtraders.com 150.128.4.78

  • amber2.nwtraders.com 150.128 6.32

With Windows 2000, the DNS tab allows you to assign only a unique domain name. This is because identifying each network connection uniquely should be accomplished by providing unique domain names appended to the computer name. On the DNS tab, you can use the DNS suffix for this connection value to define a unique domain name. If you follow this convention, do not select the Register this connection's addresses in DNS check box. Because of a feature in the Windows 2000 DNS, you will get two identical name entries in your DNS database under the same primary Forward lookup zone regardless of which domain the second adapter was assigned to. If this happens, all Pipeline Pairs will appear identical to Galaxy. To overcome this, you must manually enter the host and pointer records into the appropriate Forward and Reverse lookup zones on the DNS server.

The Windows 2000 client DNS Resolver service caches both negative and positive responses received from a DNS server. This means that if you make a change to DNS server database or hosts file to remedy a negative response, you might not see the positive change because the DNS client continues to draw its response from the cache. When working with DNS changes and a Windows 2000 system, you should always run ipconfig /flushdns on the client to clean out the local DNS cache. It is also important to note that with Windows NT and Windows 2000 the local hosts file is always pre-loaded into the DNS cache and is, therefore, checked first during name resolution.

iDataAgents

The Galaxy system includes iDataAgents for Windows 2000, Exchange 2000, and SQL Server 2000, as well as subclients for each backup set.

Managing Subclients

Subclients are used to back up different portions of the file system on a client computer. Initially, the Galaxy system defines a default subclient for each backup set. At that time, the default subclient contains the entire file system and the system state. If you define other subclients within the same backup set, the default subclient contains the entire file system, except for those portions that have been assigned to the other subclients.

When you define a subclient, you need to:

  • Provide a subclient name.

  • Define the content of the subclient.

  • Associate a storage policy to the subclient

You can use the Subclient Properties dialog box to enter this information. Although this information alone is sufficient to declare a subclient, you can establish other subclient properties as well. For example, you can:

  • Create a backup filter.

  • Select the subclient's data-compression scheme.

  • Declare backup-triggered processes.

To create a new subclient within a backup set

Before you begin, it is important not to create a subclient while the parent backup set or any sibling subclient is backing up.

  1. In the CommCell Browser, right-click the backup set for which you want to create the subclient, and then on the shortcut menu, click New Subclient.

  2. In the Subclient Properties dialog box, on the General tab, type the name (up to 32 characters) of the subclient that you want to create. The system state backup is only triggered on the default subclient. (The default subclient always backs up the system state. It is not optional.)

  3. On the Contents tab, type the subclient's content in the Enter New Content field. Optionally, you can use the Browse button to enter the content.

  4. When specifying a UNC data path, click As User, and enter the user account information for the domain user with permissions for that path.

  5. On the Subclient Properties dialog box, on the Storage Device tab, select a storage policy that you want to associate with this subclient from the storage policy menu.

  6. Click Add. Optionally, you can establish other subclient properties, such as creating a backup filter, declaring backup-triggered processes, or selecting the subclient's data-compression scheme and pipeline configuration.

  7. Click OK.

Renaming a Subclient

You can rename any user-defined subclient at any time. However, Galaxy does not allow you to rename a default subclient. Do not attempt to rename a subclient that is being backed up.

To rename a subclient

  1. In the CommCell Browser, right-click the subclient that you want to rename, and then on the shortcut menu click Properties.

  2. On the Subclient Properties dialog box, on the Storage Device tab, type the new name in the Subclient name field, and then click OK. The CommCell Browser updates the subclient with its new name.

Changing the Content of a Subclient

The portion of a File System that is assigned to the subclient is called the subclient content. You can view and change the content of any subclient from the Subclient Properties dialog box.

Do not change the content of the default subclient from its initial setting (that is, \). This setting ensures that the subclient content contains all portions of the File System not contained by other subclients. If you change the setting to some path, the default subclient will back up only the data pertaining to that path. The Subclients within the backup set will no longer back up the File System in its entirety. Do not change the content of a subclient that is being backed up.

To change the content of a subclient

  1. In the CommCell Browser, right-click the subclient whose content you want to change, and then on the shortcut menu click Properties.

  2. Click the Contents tab of the Subclient Properties dialog box.

  3. To include a file or folder in the content of the subclient, do one of the following:

    • In the Enter New Content field, manually enter the path (including the drive letter) of the file or folder that you want to add and then click Add. Repeat this step if you want to add more files or folders to the content.

      or

    • Clicking Browse to browse and select the path. In the Browse dialog box, double-click the file system of the client computer, click the file or folder that you want to include, and then click Add. Repeat this step for each additional entry.

    • When specifying a UNC data path, click As User, and enter the user account information for the domain user with permissions for that path.

  4. To save your content changes, on the Content tab of the Subclient Properties box, and then click OK.

Using On-Demand Backups

On-demand backups allow you to secure data and the system state immediately without having to wait for the scheduled backup time. This capability can be useful if the following applies:

  • You have some particularly valuable data that you need to secure immediately.

  • Your data is not routinely secured through a backup schedule and you want to back up your data.

Using on-demand backups, you can initiate full, incremental, and differential backups. You can initiate an on-demand backup on the following levels:

  • A selected subclient

  • A selected backup set

  • The default backup set

Selecting a backup set backs up the entire File System on the client computer. Selecting a subclient backs up only that portion of the File System that is mapped to that subclient.

Starting a backup on a backup set causes Galaxy to start individual backups for each subclient contained therein. If the subclients are associated with the same storage policy, their backups will run serially, unless that storage policy is configured to accommodate multiple data streams.

The Windows 2000 system state backup is initiated from the default subclient in the backup set. The system state is always backed up using a full backup, even if that subclient runs a different kind of backup on the file system portion of the data.

To start an on-demand backup of a selected subclient

  1. In the CommCell Browser, right-click the subclient that you want to back up and then on the shortcut menu, click Backup.

  2. In the window, select the type of backup that you want to initiate.

  3. After selecting the backup type and any advanced options, click OK. You can track the progress of the backup operation from the Job Controller window.

To start an on-demand backup of a selected backup set

  1. In the CommCell Browser, right-click the backup set that you want to back up, and then on the shortcut menu, click Back up All Subclients. The system prompts you to confirm that you want to back up all the subclients contained within the selected backup set. Click OK to proceed.

  2. In the window, select the type of backup that you want to initiate. Do not select Synthetic Full; it is a special type of backup.

  3. After selecting the backup type and any advanced options, click OK. You can track the progress of the backup operation from the Job Controller window.

To start an on-demand backup of the default backup set

  1. In the CommCell Browser, right-click the File System icon corresponding to the client computer that you want to back up, and then on the shortcut menu, click Back up Default Backup set.

  2. The system prompts you to confirm that you want to back up all the subclients contained within the backup set. Click OK to proceed.

  3. After selecting the backup type and any advanced options, click OK. Galaxy starts the backup operation. You can track the progress of the backup operation from the Job Controller window. When the backup completes, Galaxy displays a confirmation message.

iDataAgent for Windows 2000: Browse and Restore Operations

Browse operations allow you to view the data that has been backed up for a client computer without actually restoring the data.

Restore operations retrieve the data from the backup media and restore it to a specified location. Although you can restore data without first browsing, in practice the two operations often go hand-in-hand.

Browse and restore options allow you to do the following:

  • Restore one or all versions of a file.

  • Restore data to a mapped network drive.

  • Restore data without browsing.

To browse and restore file system data to the client computer

  1. In the CommCell Browser, right-click the backup set whose data you want to browse, and then on the short-cut menu, click Browse Backup Data.

  2. In the Browse Options dialog box, select the browse options that you want to use.

  3. In the Advanced Browse Options dialog box, select any additional browse options.

  4. In the Browse dialog box, use the File System tree to open the structure of the file system.

  5. In the Browse dialog box, select the files and/or directories that you want to restore and then click Restore All Selected.

  6. In the Restore Options dialog box, select the restore options that you want to use.

  7. If you want to select any additional restore options, click Advanced and select the options that you want.

  8. After you have selected the restore options, the system displays the progress bar and starts to restore the data. Observe the progress bar to monitor the restore process. If you want to browse the same backup set again, perhaps using different browse-time thresholds, in the Browse dialog box click New Browse.

Restoring System Databases

The system state is always backed up in its entirety as a full backup, regardless of the type of file backup being performed. For example, an incremental backup of the default subclient will perform an incremental backup of the file system and a full backup of the system state. Included with the system state backup data are several other databases. Because these other databases are separate elements, they can be selectively restored, without performing a full system-state restore. These database elements include the following:

  • Event logs

  • RSM database

  • Terminal Server database

  • Quota information

  • Content indexing catalogs

You have the choice of restoring these items when you perform a restore operation of the system databases. These databases are only available for restoration if they have been installed and backed up.

To restore the system databases

  1. In the CommCell Browser, right-click the backup set that contains the System Databases to restore, and then click Restore System Databases.

  2. In the Restore System Databases Options dialog box, accept the defaults or change the option selections.

  3. Click OK. Galaxy initiates the system state restore job. Some services may be interrupted during the time that the databases are restored. After the restore operation is complete, ensure that the services are returned to the online state.

Browsing and Restoring File Versions

The Browse/Restore dialog box allows you to browse different backed up versions of the same file and then restore either any one version of the file or all versions of the file. When you restore all file versions simultaneously, Galaxy appends a different number to the file name so that each version remains unique.

Before you begin browsing and restoring file versions, note the following:

  • If you plan to restore more than one version of the same file by restoring each version individually, be sure to restore them to different locations to prevent overwriting your files.

  • If full backup transparency is enabled, browsing will return all versions of the selected files. However, by default, browse returns only those files that exist back to the most recent full backup (full backup transparency is disabled). If you need to obtain earlier versions, set the Browse To date of the browse operation to a date prior to the most recent full backup.

  • Windows 2000 includes a directory called Tombstone Lifetime, which uses Active Directory® directory service and has a default setting of 60 days. If you attempt to restore Active Directory data after this date has passed, the system will reject the data. Do not attempt to restore data that has exceeded its lifetime.

To restore one version of a file

  1. In the CommCell Browser, right-click the backup set that contains the file(s) you want to browse, and then on the shortcut menu, click Browse Backup Data.

  2. In the Browse Options dialog box, select the browse options that you want to use.

  3. In the Advanced Browse Options dialog box, select any additional browse options.

  4. In the Browse dialog box, use the File System tree to open the structure of the file system.

  5. Right-click the file whose versions you want to browse, and then click View All Versions.

  6. In the window, click the file version that you want to restore and then click Restore.

  7. In the Restore Options dialog box, select the restore options that you want to use.

  8. If you want to select any additional restore options, click Advanced and select the options you want.

  9. After you have selected the restore options, the system displays the progress bar and starts to restore the data. Observe the progress bar to monitor the restore process.

If you want to restore another version of the same file, repeat this procedure starting with Step 6. If you want to browse the versions of other files, repeat the entire procedure.

To restore all versions of a file

  1. In the CommCell Browser, right-click the backup set that contains the file(s) that you want to browse, and then on the shortcut menu, click Browse Backup Data.

  2. In the Browse Options dialog box, select the browse options that you want to use and click OK.

  3. In the Advanced Browse Options dialog box, select any additional browse options.

  4. In the Browse dialog box, use the File System tree to open the structure of the file system.

  5. Right-click the file whose versions you want to restore, and then click Restore All Versions.

  6. In the Restore Options dialog box, select the restore options that you want to use.

  7. If you want to select any additional restore options, click Advanced and select the options you want.

  8. After you have selected the restore options, the system displays the progress bar and starts to restore the data. Observe the progress bar to monitor the restore process.

Restoring Data to a Mapped Network Drive

Galaxy allows you to restore data to a client computer's mapped network drives. The restored data assumes the access characteristics of the destination share.

Before you begin, remember that mapped network drives exist as Windows share directories (that is, shares) on some other computer on the network. For data security reasons, these shares possess access privileges that determine who can access the share and the rights under which access is permitted. If your Windows account does not have privileges to write data to the share, you must be able to provide the user name and password of a Windows account that does have these privileges. Also ensure that the Windows share to which you intend to restore the data is accessible as a mapped network drive from the destination computer.

To restore data to a mapped network drive

  1. In the CommCell Browser, right-click the backup set whose data you want to browse, and then from the shortcut menu, click Browse Backup Data.

  2. In the Browse Options dialog box, select the browse options that you want to use.

  3. In the Advanced Browse Options dialog box, select any additional browse options.

  4. In the Browse dialog box, use the File System tree to open the structure of the file system.

  5. In the Browse dialog box, select the files and/or directories that you want to restore, and then click Restore All Selected.

  6. In the Restore Options dialog box, select the restore options that you want to use.

  7. Ensure that the destination computer is the computer that has the mapped drive, not the computer that has the share. Also, if the data did not originate from the mapped drive, type the destination path starting with the mapped drive letter in the Restore to Same Paths field (for example, H:\Sales\Monthly Reports).

  8. If you want to select any additional restore options, click Advanced and select the options you want.

  9. If you do not have Change permissions for the share that you intend to restore the data to, you must go to the Advanced Restore Option dialog box, select Impersonate NT User and then provide the logon and password of a Windows account that does have these permissions; otherwise, the data cannot be restored to the selected share. If you can copy or create a file in the share, you should be able to restore data to that share without having to select this option.

    Note: If the user account is established as a domain user account, you must enter a fully qualified user name (for example, domain_name\user_name where domain_name is the name of the domain and user_name is the user name) and password.

  10. After you have selected the restore options the system displays the progress bar and starts to restore the data. Observe the progress bar to monitor the restore process.

Restoring Data Without Browsing

If you know the path of the data that you want to restore, you can restore it without browsing. This procedure is most appropriate when you want to restore data from a single path. If you want to restore data from multiple paths, you should select the data from the Browse window.

To restore data without browsing

  1. In the CommCell Browser, right-click the backup set that contains the data you want to restore and then click Restore.

  2. In the Restore dialog box, type the path of the data that you want to restore. Note that Galaxy does not back up multiple copies of mounted data. If a backup includes more than one mount point to the same drive, Galaxy backs up the data only one time. To restore data in mounted volumes, you must type the path of the first point that is mounted to the drive.

  3. In the Restore Options dialog box, select the restore options that you want to use.

  4. If you want to select any additional restore options, click Advanced and select the options you want from the dialog box.

  5. After you have selected the restore options, the system displays the progress bar and starts to restore the data.

Finding a File or Directory

The Find operation allows you to search the backup archives for any file or directory name or name pattern. It is a type of browse operation. The Find operation lets you use the system to locate files or directories with specific names or naming patterns.

The Find operation supports a number of wild card characters (for example, * and ?) to broaden or narrow the scope of your searches. The supported wild card characters are provided and discussed in "Restoring Data Using Wildcard Expressions" later in this chapter.

To find a file or directory

  1. In the Commcell Browser, right-click the backup set that contains the data you want to find, and then click Browse Backup Data.

  2. In the Browse Options dialog box, select the browse options that you want to use.

  3. In the Advanced Browse Options dialog box, select any additional browse options.

  4. In the Browse dialog box, right-click the backup set, and then click Find.

  5. In the Find dialog box, type the name or wildcard pattern of the file or directory that you want to find. By default, the Look In field is set to the backup set that was selected in Step 1. If you want to search the backups of a different backup set on the same client computer, you can choose another backup set in this field.

  6. For optional features, select the TimeRange tab. From this tab you can select the following options:

    • Search from the latest backup data. When selected, Galaxy searches all backups, up to the most recent backup, for the specified data. (This option is selected by default.) When cleared, Galaxy searches all backups for the specified data up to the specified time.

    • Image Browsing. If selected, Galaxy searches for the specified data based on the image of the data as it existed as of the specified browse times. If cleared (No Image Browse), Galaxy searches for the specified data based on all the data that was ever backed up as of the specified browse times.

    • Advanced. Provides access to the Advanced Browse Options dialog box, which allows you to narrow the scope of the Find operation.

  7. After you have selected your Find options, click Find Now.

  8. After the files or directories that match the specified name or pattern are displayed, right-click the file or directory name that you want and perform one of the following operations:

    • Restore the file or directory.

    • View all Versions of the selected file (Not available for directories.)

    • Restore all Versions of the selected file (Not available for directories.)

Filtering Data from Restore Operations

In the Advanced Restore Operations dialog box, you can specify the files, directories, and file name patterns that you want to filter from the restore data.

To filter data from a restore operation

  1. You can access the Restore Option dialog box by performing either a browse operation or a restore operation on a backup set.

  2. In the Restore Option dialog box, click Advanced.

  3. From the window, type the files, directories, and file name patterns that you want to filter in the Filter Paths pane. Click Add to specify your filter entries. Each entry must be specified as a complete path and must be a child of the Source Paths pane. Wildcard entries must be expressed as complete paths (for example, C:\Test\*.dll).

  4. The restore filter supports the following wildcard characters. To broaden the scope of your filtering, you can use the character *, which stands for any number of characters, or the character ?, which stands for any one character. You can also use a combination of wildcards in a single expression (for example, access?.h*).

Using Wildcard Expressions to Restore Data

Galaxy allows you to restore data using wildcard expressions. You can restore the data directly or browse it first and then restore it. This functionality gives you the ability to restore files and/or directories that have a common naming convention (for example, Msde2.doc and Msj4j.doc). The supported wildcard characters are listed in Table 4.20.

Table 4.20 Supported Wildcard Characters

Wild card

Signifies ...

*

Any number of any characters. For example:*.doc
Any file name with the extension ".doc" (for example, status.doc, mission.doc)
Any file name that begins with the letter a, and has the extension .dll (for example, alsvc.dll, advdcc.dll)

?

Any one character. For example: access?
Any file name that begins with the word access, followed by any one character (for example, access1, access5)

[ ]

Any range of characters. For example:
[ei]nsure.doc
Any file name that ends with the term nsure.doc, and begins either the letters e or i. (for example, ensure.doc, insure.doc)
[a-m].doc
Any file name that ends with the extension .doc and begins with the letters a through m, inclusive.

[! ]

The negation of a range of characters. For example:
[!ei]nsure.doc
Any file name that ends with the term nsure.doc, but does not begin with the letter e or the letter i. (for example, unsure.doc)

**

Any directory level. For example:
C:\**\Move.cpp
The file named Move.cpp located at any directory level under the c: drive. (for example, C:\info\com\Move.cpp)

If you specify the expression by itself without a path (for example, *.doc), Galaxy searches for and returns all data within the backup set that satisfies the expression. By preceding the expression with a path, you can narrow the scope of the restored data. For example, specifying C:\My documents\*.doc would restore only those files and directories within the C:\My Documents directory with the extension .doc.

When restoring directories, if you specify a wildcard pattern that matches the name of a directory, Galaxy restores the directory, but none of the directory's contents. For example, if your wildcard restore string is tem?, Galaxy restores any and all data named with a four-character string starting with the letters t, e, and m. If there is a directory whose name satisfies that criterion (for example, C:\Temp) only the directory would be restored; however, none of the files or any subdirectories contained therein would be restored.

Galaxy allows you to select specific data to be restored in addition to specifying the data through the wildcard expressions. This is known as mixed mode restore. The general result of a mixed mode restore is that Galaxy restores the selected data as well as the data that satisfies the wildcard expression(s), with one important exception: all directories that are to be restored, whether they were specifically named or selected, or merely satisfy the wildcard expression(s), are restored without their content (that is, any directory to be restored is handled in the same way as if the directory were being restored as a result of a wildcard expression).

Using Wildcards to Restore Data Directly

This method of restoring data is the fastest because you need not browse the backup data first. However, you may need to have a better working knowledge of the organization of the data that you want to restore.

To directly restore data using wildcards

  1. In the CommCell Browser, right-click the backup set that contains the data that you want to restore, and then click Restore.

  2. In the Restore dialog box, type the wildcard expression that corresponds to the data that you want to restore. For the broadest restore, omit the path. To narrow the scope of the restore operation, you should precede the expression with a path.

  3. In the Restore Options dialog box, select the restore options that you want to use.

  4. Optionally, click Advanced if you want to access the dialog box to enable additional capabilities (for example, specify another restore wildcard expression or some specific path). If you enter both specific data paths and wildcard expressions (that is, a mixed mode restore), Galaxy informs you that any directories that are to be restored in the operation will be restored empty.

  5. After you have selected the restore options, the system displays the progress bar and starts to restore the data.

Using Wildcards to Browse and Restore Data

This method for restoring data uses the browse data feature. This feature can be helpful when you are uncertain of the organization of the data that you want to restore.

To browse and restore data using wildcards

  1. In the CommCell Browser, right-click the backup set that contains the data that you want to restore, and then click Browse Backup Data.

  2. In the Browse Options dialog box, select the browse options that you want to use. In this procedure, the Client Computer field is unavailable because it was already determined when the backup set was selected in Step 1.

  3. In the Advanced Browse Options dialog box, select any additional browse options.

  4. In the Browse dialog box, use the File System tree to open the structure of the file system.

  5. In the Browse dialog box, select the data that you want to restore, and then click Restore All Selected. You must select data from the Browse dialog box, even if you want to restore data by using only a wildcard expression. If you do not select any data (even one file), Galaxy cannot provide you access to the Advanced Restore Option dialog box, which you need in order to enter the wildcard expression. If desired, you can always clear the data as described later in this procedure.

  6. In the Restore Options dialog box, select the restore options that you want to use and then click Advanced. In the Advanced Restore Option dialog box, the Source Paths pane shows the path of the data that you selected in Step 5.

  7. In the Advanced Restore Option dialog box, do one or both of the following:

    • To clear the data that you selected in the Browse dialog box, select the entry in the Source Paths pane and click Delete.

    • To specify a restore wildcard expression or some specific path, in the Source Paths pane, click Add, enter the expression or path in the Enter Path dialog box, and click OK.

    • Repeat these steps to enter additional wildcard expressions.

  8. In the Advanced Restore Option dialog box, select any other advanced restore features as desired and click OK. If you enter both specific data paths and wildcard expressions (that is, a mixed-mode restore), Galaxy informs you that any directories that are to be restored in the operation will be restored empty.

  9. In the dialog box, click OK.

  10. After you have selected the restore options, the system displays the progress bar and starts to restore the data. Observe the progress bar to monitor the restore process.

Database iDataAgent for Exchange 2000 Server

You can use iDataAgent for Exchange 2000 Server to backup and restore your data in a variety of ways.

Using Subclients to Establish Parallel Backups

You can back up an entire instance more quickly by scheduling multiple subclients for simultaneous backup, so that the backups proceed in parallel and take less time than if the instance client were not divided into separate subclients. However, in order for the subclient backups to run in parallel, they must either be configured to use different storage policies, or to use a storage policy configured to have at least as many data streams as the total required for all the subclients that you want to back up in parallel. If any of the subclients are configured to use the same storage policy, and that storage policy is not configured for enough data streams, then there will be contention for media group resources, and the competing subclients will back up serially.

Restore Operations

Restores are one of the primary functions of the Galaxy system. Galaxy provides two general operations that help you retrieve backed up data: browse and restore. A browse operation allows you to view the database elements that have been backed up for a client computer running Exchange 2000 before you restore the data. This enables you to easily identify the elements that you want to restore. The restore operation then retrieves the database elements from the backup media and restores them.

Browsing Data

A browse operation provides a snapshot of the databases that been backed up by iDataAgent for Exchange 2000 Server. It does this by retrieving the index file(s) of the related subclient(s). The results are returned to the CommCell Console, which graphically displays those databases that are within the selected subclient that has been backed up. From the CommCell Console display, you can select some or all of the data and restore it using a restore operation.

Restoring Data

The restore operation retrieves the data that you select in the CommCell Console. The Galaxy system provides a powerful set of restore options that enable you to specify and restore only the data that you need. To properly specify the data, you should have a basic understanding of how the Galaxy system restores databases. The restoration process can take place under a variety of circumstances, as described in the following paragraphs.

Browse and Restore Scenarios

The database iDataAgent for Exchange 2000 Server allows you to browse and restore the content and organization of data that is secured through standard backup operations. A browse operation displays all of the database backups for the iDataAgent as of a specified time; a restore operation restores some or all of the selected databases.

Database Retrieval

When you browse or restore data, by default the system returns the requested data based on the latest backups available. This is usually the information that users are interested in. The system uses the current date and time as the effective date.

Limitations of the Default Settings of Browse and Restore Operations

The default settings of the restore operation (that is, restoring data from the current full backup cycle) may not meet your needs in all circumstances. It can restore only the latest version of a database. Further, if the requested data was deleted before the most recent full backup, it cannot be restored by the default mode of operation.

The Galaxy system provides various restore options that extend its restore capabilities and allow you to control the search and retrieval process. These options are discussed in the following sections.

Controlling the Browse Time Interval

The browse operation provides you with the To option, which allows you to control the starting point of the browse retrieval process. Browse searches extend backwards in time starting with the To option. This feature can be useful if you need to restore any of the following:

  • A previous version of a database

  • The contents of a database from an earlier date

  • Data that was deleted prior to the most recent backup

The Time-of-Day Element

The specification for the To option includes not only the date, but the time-of-day (that is, hours and minutes) as well. You should specify the time when isolating a backup on a date on which two or more backups occurred. (Note that this condition can occur even if backups are scheduled only once a day. For example, someone may have launched an on-demand backup in addition to a scheduled backup. Also, depending on the size of a backup and the time it is scheduled to begin, a backup can start before midnight on one date and finish on the next date. In determining whether to include a backup in a search, the Galaxy system uses the time that a backup completes. The To option causes the Galaxy system to start its browse search using the most recent backup that completed before the specified date and time.

Scheduled Restore Operations

When you want to restore data, you usually need it immediately. However, there may be times when you do not need the data right away.

Using the scheduling feature, you can schedule a restore operation. As with scheduled backups, a scheduled restore operation relieves you of having to manually initiate the operation. This feature can be particularly useful if you want to restore a large amount of data, but would prefer to do so at a time when either the client computer (that is, the Exchange 2000 Server) is not in use or network utilization is low (assuming the data must traverse a network).

Restoring Data to Exchange 2000 Server

Before you start restore operations, ensure that you have met the following requirements and performed the following operational procedures.

Restoring SystemState First

If you delete or change the properties of any Exchange 2000 object that is related to Active Directory, you must first restore the system state before you can restore data to the Exchange 2000 database and complete the retrieval of the container. Perform a non-authoritative restore. This will prevent the restore from overwriting the current system state data. (The system state restore restores Exchange components and information to Active Directory).

Backing Up after a Restore

After you perform a restore operation on the Exchange 2000 database, a full backup is required before a scheduled pre-selected backup (incremental or differential) can successfully occur.

To browse and restore data to Exchange 2000

  1. In the CommCell Browser, right-click the Exchange 2000 database subclient whose data you want to browse, then click Browse Backup Data.

  2. In the Browse Options dialog box, select the browse options that you want to use.

  3. If specifying a browse time, click Advanced for the dialog box.

  4. In the Browse/Restore dialog box, double-click Microsoft Information Store and select the storage group(s) or specific information store(s) that you want to restore.

  5. When you are finished selecting items to restore, click Restore All Selected. (Click New Browse to edit the Browse selection.)

  6. In the Restore Options dialog box, select the restore options that you want.

  7. Click Advanced if you want to restore using a selected copy precedence. This brings up the Advanced Restore Options dialog box.

  8. When the data is restored, the system displays a confirmation message. In the confirmation window, click OK. You can click Detail to review information on the restore operation.

  9. Perform a full backup of the database. This is required before a scheduled pre-selected backup (incremental or differential) can occur.

Mailbox iDataAgent for Exchange 2000 Server: Restore Operations

Galaxy provides two general operations that help you retrieve backed-up data: browse and restore. These operations are performed at the backup-set level, which allows you to browse and restore Exchange 2000 data for an entire server. The mailbox iDataAgent for Exchange 2000 Server allows you to browse and restore both complete mailboxes and individual messages.

Browsing Data

A browse operation provides a view of the data that has been backed up for a client. It does this by retrieving the index file(s) of the related subclient(s). The results are returned to the CommCell Console, which displays those mailboxes that have been backed up and are within the selected backup set. From this structure, you can select a mailbox folder and browse individual backed-up messages. From the CommCell Console display, you can select some or all of the data and restore it using a restore operation.

Restoring Data

The restore operation retrieves the data that you select in the CommCell Console. The mailbox iDataAgent for Exchange 2000 Server does not require that you browse the data first when you are restoring a complete mailbox. If you know the path of the mailbox that you want to restore, you can type it in the Restore dialog box and perform the restore operation directly.

The Galaxy system provides a powerful set of restore options that enable you to specify and restore only the data you need. To properly specify the data, you need a basic understanding of how the Galaxy system restores mailboxes and messages. The following sections describe the restoration process under a variety of circumstances.

Browse and Restore Scenarios

The Image Mode is the default for browse and restore operations. An Image refers to the content and organization of Exchange 2000 mailbox data that is secured through standard backup operations. An "image browse" operation displays the Exchange 2000 mailbox structure, as it existed at a specified time. An image restore operation restores Exchange 2000 mailbox data or a specified portion thereof.

You can browse the mailboxes within a backup set, the folders within a mailbox, or the messages within a folder:

For full mailbox restores a browse operation displays the mailbox backups that existed for the backup set as of a specified time and the restore operation restores some or all of the backup set's mailboxes.

For folder restores, a browse operation displays the folder backups that existed within the mailbox as of a specified time, and the restore operation restores some or all of the mailbox folders.

For message restores, a browse operation displays the message backups that existed within the folder as of a specified time, and the restore operation restores some or all of the folder's messages.

When you browse or restore data, by default the system returns the requested data based on the latest backups available. The system uses the current date and time as the effective date. The following examples show how single mailboxes, folders, and messages are restored.

Single Mailbox Retrieval

Assume that on a given day you request the most recent version (that is, the default) of a mailbox. In response, Galaxy retrieves the most recent index file. It searches the index for the most recent version of the mailbox, retrieves the mailbox from the backup media and restores it to the client computer.

Folder Retrieval

Assume that on a given day you request the restoration of an entire mailbox, as it existed in its most recent state (that is, the default). Using the latest index file, Galaxy retrieves the most recent copy of each folder until all the folders have been restored.

Message Retrieval

Assume that on a given day you request the most recent version of a specific message. In response, Galaxy retrieves the most recent index file, searches the index for the most recent version of the message, retrieves the message from the backup media, and restores it to the client computer.

Limitations of the Default Settings of Browse and Restore Operations

The default settings of the restore operation (that is, restoring data from the current full backup cycle) may not meet your needs in all circumstances. It can restore only the latest version of a mailbox, folder or message. Furthermore, if the requested data was deleted before the most recent full backup, it cannot be restored by the default mode of operation.

The Galaxy system provides various restore options that extend its restore capabilities and allow you to control the search and retrieval process. These options are discussed in the following sections.

Controlling the Browse Time Interval

The browse operation includes the To option button, which allows you to control the starting point of the browse retrieval process (remember, browse searches extend backwards in time starting with the time that is specified using To option button). This feature can be useful if you need to restore any of the following:

  • A previous version of a database

  • The contents of a database as of an earlier date

  • Data that was deleted prior to the most recent backup

The Time-of-Day Element

The specification for the To option button includes the date and the time of day (that is, hours and minutes). Specifying the time is necessary when isolating a backup on a date in which two or more backups occurred. (Note that this condition can occur even if backups are scheduled only once a day. For example, someone may have launched an on-demand backup in addition to a scheduled backup. Also, depending on the size of a backup and the time it is scheduled to begin, a backup can start before midnight on one date and finish on the next date.) In determining whether to include a backup in a search, the Galaxy system uses the time that a backup completes. The To option button causes the Galaxy system to start its browse search using the most recent backup that completed before the specified date and time.

Browsing Data from Before the Most Recent Full Backup

In the browse operations described previously, the most recent full backup bounds the searches. There may be times, however, when you want to browse data that is older than the most recent full backup. The way to access that data is to specify a To date that pre-dates the full backup. Remember, the To date establishes the starting point of the search. Consequently, using a To date that pre-dates the most recent full backup starts the search in the previous full backup cycle. This is only valid if the data in that full backup cycle has not expired.

Cross-Client Restore Operations

By default, Galaxy restores data to the client computer (the Exchange 2000 Server) from which it originated. If you want, you can also restore the data to a different client computer, as long as the mailbox iDataAgent for Exchange 2000 Server is installed on the target system. This is called a cross-client restore.

  • The restore destination must be on another server running Exchange 2000 on which the mailbox iDataAgent for Exchange 2000 is installed and operational.

  • The destination server must reside in the same CommCell as the server that is being backed up.

  • The mailbox must exist or be created on the destination server running Exchange 2000 before the restore operation is started.

  • You must have user-management capabilities for Galaxy restores on both the source and destination computer to perform a cross-computer restore.

When you perform a cross-client restore, the restored data assumes Exchange 2000 permissions that it had originally and the Windows NT security attributes (permissions) of the parent directory.

Scheduled Restore Operations

When you want to restore data, you usually need it immediately. However, there may be times when you do not need the data right away.

You can use the scheduling feature to schedule a restore operation. As with scheduled backups, a scheduled restore operation relieves you of having to manually initiate the operation. This feature can be particularly useful if you want to restore a large amount of data, but would prefer to do so at a time when either the client computer (that is, the Exchange 2000 Server) is not in use or at a time when network utilization is low (assuming the data must traverse a network).

Restoring Mailbox Data to Exchange 2000

Restores are one of the primary functions of the Galaxy system.

Browse operations allow you to view the backup data (backed up at the backup-set and subclient levels), giving you access to the Exchange 2000 mailboxes. This enables you to easily identify the mailboxes, folders and messages that you want to restore.

The Browse/Restore window is the central window from which you browse and restore data. Restore operations retrieve the data from the backup media and restore it to the desired location.

The Find Message feature is a powerful search tool that searches the backup archives for any messages that match the pattern used in the search. The Find operation lets you locate messages with specific naming patterns.

Before starting restore operations, ensure that you have met the following requirements and performed the following operational procedures:

  • Restore Failure Housekeeping. If a restore job fails in progress, and there are entries in the restore list, there may be leftover items in the GalaxyAdmin mailbox (which is associated with the required GalaxyAdmin profile on the Exchange 2000 Server). If so, open the GalaxyAdmin mailbox and remove any mailboxes, folders, or messages left over. Be sure that there are no restores in progress or scheduled during this procedure.

  • Disabling Storage Limits. Before performing a mailbox, mailbox folder, or mailbox message restore, ensure that the storage limits are disabled. Otherwise the storage limit may prevent the entire list of items from being restored, even though the restore job may report success.

The following procedure describes how to remove or disable any storage limit before performing a restore operation.

To disable storage limits

  1. In the Exchange 2000 Server software hierarchy view, under the server running Exchange, right-click a mailbox store or public store and then click Properties.

  2. On the Limits tab, remove or disable any storage limits.

Note: Storage limits can be set from an individual mailbox, or use the value taken from the Store Properties dialog box. If any individual mailboxes have set storage limits, disable them as well.

To perform this procedure you must have User-Management permissions on the Galaxy system. User Management permissions for Galaxy restore operations are required on both the source and destination computer to perform a cross-computer restore.

To browse and restore mailbox data

If you are trying to restore a large amount of data (so that backing up the subclient takes longer than the time allotted for the specified backup window), you should either break up the restore into many smaller restores, or perform an Exchange Server database restore.

  1. In the CommCell Browser, right-click the backup set whose data you want to browse, and then click Browse Backup Data.

  2. In the dialog box, select the browse options that you want to use.

  3. If specifying a browse time, click Advanced to open the Advanced Options window.

  4. In the Browse dialog box, use the mailbox/folder tree to open the Exchange 2000 structure. Select the mailboxes, folders, and/or messages that you want to restore. Display further pages of specific folder objects by clicking the Next and Previous (the number of objects specified for Page Size in the Browse dialog box).

  5. When you are finished selecting items to restore, click Restore All Selected.

  6. Click New Browse to initiate a fresh Browse dialog box. Use new browse option settings, if you want. To search for a particular item(s), see "Finding and Restoring an Exchange 2000 Object" later in this chapter for instructions.

  7. The system displays the window. Select the options that you want, and then click OK to continue.

  8. When the data is fully restored, the system displays a confirmation message. Click OK to close the message window or click Detail to review information on the restore operation.

Finding and Restoring an Object in Exchange 2000

The Find feature can be used to locate mail messages or other Exchange 2000 objects (for example, contacts).

  1. Browse (as described in "Restoring Mailboxes" earlier in this chapter), selecting any browse options desired.

  2. From the Browse dialog box, right-click the backup set, and then click Find. You can also start the Find operation from any mailbox or folder.

  3. From the Find dialog box, type in your search criteria in the Subject, From, and To fields (and check the box next to that field).

  4. For optional features, select the TimeRange tab.

  5. After you have selected your Find options, click the Find Now button. As the Find operation proceeds, Galaxy displays a searching message at the bottom of the window. Then, any items that match the specified name or pattern are displayed in the lower pane of the Find window.

  6. From the Find Results list, right-click the object that you want, then click Restore.

iDataAgent for SQL Server

iDataAgent for SQL Server 2000 operates in the same manner as the other iDataAgents, with a few exceptions.

Databases and Subclients

Databases and Subclients are similar for iDataAgent for SQL Server in that there is one subclient for each database. Each database contains a default subclient. Because each database contains one subclient, these two levels of the tree are similar. The main differences are in the functionality that is available at the different levels and the configuration options that affect any lower levels. The configuration options can be accessed in the Properties dialog box for each particular level.

Installation Defaults

During installation, Galaxy automatically configures the three system databases: master, msdb, and model. During installation, you can also select user-defined databases to be configured. A database icon is created in the CommCell Browser to represent each configured database. Each database contains one subclient named Default.

A subclient is also created during installation for each database. The subclient backs up all data associated with each particular SQL Server database that is secured by Galaxy, which is represented by the database icon. This means that, with a minimum of configuration, you can run backups that include all of the data that you want to secure. Through the subclient, the database knows which storage policy to use. There is one database per subclient. You can back up a database to a different library by changing the associated storage policy. This is useful for making backups for off-site storage.

The subclient is also where you specify the number of streams to use for backup operations.

Tree Levels for iDataAgent for SQL Server

In the CommCell browser tree, there is a node for each client computer and each iDataAgent on each client computer. Under this iDataAgent level is the Instance level. The configuration settings at each level affect all lower levels. This means that configuration settings at the iDataAgent level affect the Instance level, and configuration settings at the Instance level affect all databases below the Instance level.

Support for Multiple Instances of SQL Server 2000

SQL Server 2000 supports multiple instances of SQL Server on one client computer.

iDataAgent for SQL Server supports configurations with both SQL Server 7.0 and SQL Server 2000 on the same client computer. Multiple instances of SQL Server 2000 on the same client computer (with or without SQL Server 7.0) are also supported. A SQL Server 7.0 instance is identified by a SQL Server instance icon beneath an iDataAgent icon in the CommCell Browser. Each SQL Server 2000 instance is identified by an instance icon beneath the iDataAgent icon in the CommCell Browser. Figure 4.15 illustrates these icons.

Figure 4.15: Instance icons for iDataAgent for SQL Server

Figure 4.15: Instance icons for iDataAgent for SQL Server

Using Subclients to Establish Parallel Backups

You can back up an entire instance more quickly by scheduling multiple subclients for simultaneous backup so that the backups proceed in parallel and take less time than if the instance client were not divided into separate subclients.

However, for the subclient backups to run in parallel, they must be configured to use different storage policies, or the storage policy must be configured to have at least as many data streams as the total required for all subclients to be backed up in parallel. If any of the subclients are configured to use the same storage policy, and that storage policy is not configured for enough data streams, contention for media group resources will result, and the competing subclients will back up one after the other in a serial manner.

Archive Pruning Rules for iDataAgent for SQL Server

Galaxy software provides for a data retention period. When data is backed up through a storage-policy copy, it remains valid for some period of time in accordance with the criteria of the associated retention period. After the retention thresholds are exceeded, the data becomes a candidate for pruning by the archive pruning utility.

The archive pruning utility is a Galaxy utility that enforces the data retention period for all backed up data in the CommCell. Under your direction (either scheduled or manually initiated), the archive pruning utility compares all data with the related retention periods. If you do not run the archive pruning utility, retention periods are not enforced and backup data remains valid indefinitely. (Administration of archive-pruning utility is discussed at length in the Galaxy CommCell Media Management Administration Guide.)

The pruning of data enables the Galaxy software to automatically recycle the backup media. When all the data on a given backup medium has been pruned, the archive pruning utility, in accordance with its schedule, re-assigns the medium to a scratch pool for later reuse.

For SQL Server subclients, the retention period is defined by two parameters:

  • The length of time the data is to be retained.

  • The number of full backup cycles. (A full backup cycle begins with a full backup and includes all other backups up to, but not including, the next full backup.)

Data becomes a candidate for pruning only when both of these thresholds are exceeded for all backups within a full backup cycle. This means that data is pruned only on full backup cycle boundaries and not on an individual backup basis.

In the scenarios that follow, F means a full backup, D means a differential backup, L means a transaction-log backup, and P indicates when the archive pruning utility executes. A dashed diagonal line across a backup means that the backup data is removed during archive pruning.

Figure 4.16: Scenario 1

Figure 4.16: Scenario 1

This scenario shows data backed up over two days and two cycles. The archive pruning utility prunes F1 and L1. The F2 and L2 cycle are kept.

Figure 4.17: Scenario 2

Figure 4.17: Scenario 2

Suppose you perform a full backup and a transaction-log backup as the first backup cycle, then another full backup and another transaction-log backup as the second backup cycle. Next, you restore to the transaction-log backup that is part of the first backup cycle. At this point, the archive pruning utility still prunes F1 and L1, even though you have restored L1.

Figure 4.18: Scenario 3

Figure 4.18: Scenario 3

Continuing from Scenario 2, to make the first backup cycle F1 active again so that the archive pruning utility will not prune that data, you need to perform a transaction log or differential backup after the restore operation. In other words, if you want to keep F1 data, perform a transaction log or differential backup before archive pruning.

Figure 4.19: Scenario 4

Figure 4.19: Scenario 4

In this scenario, there are four backup cycles. When you restore to L2 and then perform a transaction-log backup, the F2 cycle becomes the current cycle. The archive pruning utility prunes the F1, F3, and F4 cycles only. If you want to keep the F4 cycle you need to define the retention period for a minimum of two cycles.

Figure 4.20: Scenario 5

Figure 4.20: Scenario 5

If a full backup is performed after restoring to a previous backup cycle, the new full backup becomes the current backup cycle and earlier backup cycles are pruned.

An additional scenario 6 would be if a database is deleted from Galaxy. The next time the archive pruning utility executes, existing backup sets are pruned regardless of their retention periods.

Browse and Restore Operations

The Galaxy system provides two operations to retrieve backed up databases: browse and restore. Browse can be performed at the client computer, iDataAgent, and instance levels. Restores can be performed from the instance or database levels. Browsing and restoring from the instance level, and browsing from the application level, allow you to browse and restore all databases within a single SQL Server instance which have been backed up at the same time.

Browsing Data

A browse operation provides a list of databases that have been backed up at a specified browse time. You can use this display to select some or all of the databases and restore them using a restore operation.

When restoring databases you control two main parameters:

  • Browse time interval

  • Restore type

Controlling the Browse Time Interval

The browse operation provides you with the ability to browse the latest backup data or specify a particular time to include in the browse. The Browse the Latest Backup Data option is selected by default. This option returns a list of databases that have been backed up prior to the time that the browse command was issued.

You can specify the browse time span by selecting a time in the Browse To dialog box. The list of databases returned in the Browse dialog box includes all databases that were backed up prior to the selected Browse To time. The Browse From option is also available. However, in this context it does not offer any functionality.

Restoring Data

The restore operation retrieves the data that you select in the Browse dialog box. Galaxy offers a variety of restore options, and does not require that you first browse the data. You can right-click the database or SQL Server instance that you want to restore, choose Restore and perform the restore operation directly.

Restoring the Master and msdb Databases

When restoring the master database, the SQL Server service must be stopped and restarted in single-user mode. Galaxy informs you of this and gives you the option to continue (that is, stop and restart the SQL Server service at this point) or to cancel the restore operation. If you continue the restore operation, Galaxy stops and restarts the SQL Server service in single-user mode as part of the restore operation.

When restoring the msdb database on an SQL Server, Galaxy displays a message stating that the SQLAgent service cannot be running during the restore. To shut down the SQLAgent and continue, click Yes. To abort the operation, click Cancel. To continue the operation without shutting down the SQLAgent service, click No. If you click No and the SQLAgent service is running, the job fails; if it is not running, the job continues normally. In a clustered environment, the SQLAgent service should be stopped from the Cluster Administrator dialog box.

Cross-Client Restore Operations

By default, Galaxy restores data to the client computer from which it originated. You can also restore databases to another SQL Server computer that has the SQL Server iDataAgent installed. This is called a cross-client restore. Changing the SQL Server listed in the SQL Database Restore Options dialog box initiates a cross-client restore.

Hot Server Restore

Galaxy allows you to perform hot server restores on any secured database in the SQL Server. This functionality enables you to easily maintain a hot server spare of one or more databases in the event of a server failure of the main SQL Server computer. You can also schedule hot server restores so that they automatically occur at a specified interval. Matching a hot server restore schedule with a backup schedule on the source database keeps your hot-server databases up-to-date automatically. See online Help for a full description of Hot Server Restore.

Scheduled Restore Operations

When you want to restore data, you usually need it immediately. However, there may be times when you need the data by some specific time, but not necessarily right away. Using the scheduling feature, you can schedule a restore operation. As with scheduled backups, a scheduled restore operation relieves you of having to manually initiate the operation. This feature can be particularly useful if you want to restore a large amount of data, but would prefer to do so at a time when either the client computer is not in use or at a time when network utilization is low (assuming the data must traverse a network).

Understanding Restore Options

While browse and restore operations often go hand in hand, a restore can be performed on demand. The previous section discussed the Browse dialog box and the available browse options. This section discusses the available restore options.

A restore operation recovers the data that you want and restores it to the desired location. The Galaxy system offers a variety of restore options that allow you to control how the data is restored.

Note: Do not attempt to perform backup or restore operations on the master or CommServe databases on the Galaxy CommServe computer. Galaxy Services depend on SQL Server services and will not function if SQL Server is shut down.

The options available on the SQL Database Restore Option dialog box differ slightly depending on whether the restore operation is for a single database or multiple databases. Multiple database restore options also apply when restoring the entire instance.

SQL Server does not allow restores on databases that are in use. Before you attempt a restore operation, make sure that all the databases that you want to restore are not in use.

When you restore the msdb database, the SQLAgent service must be stopped. Galaxy displays a confirmation message when you attempt to restore one or both of these databases. Click OK to stop the service and continue the restore or Cancel to abort the operation.

To browse and restore data

  1. In the CommCell Browser, right-click the SQL Server instance whose data you want to browse, and click Browse SQL Server.

  2. In the Browse Options dialog box, select the browse options that you want to use.

  3. If specifying a browse time, click Advanced.

  4. From the Browse/Restore dialog box, select the databases that you want to restore, and click Restore All Selected.

    Note: If the master database or all available databases in the browse window are selected, then when you click Restore All Selected, Galaxy displays a message stating that the master database has been selected for restore and that the SQL Server will be shut down and restarted in single-user mode. Click Yes if you want to continue with the restore, or No to cancel without shutting down the server.

  5. In the Restore Options dialog box, select the restore options that you want. If you want to restore the database to another SQL Server, select the server in the SQL Server drop-down menu.

  6. Click Advanced if you want to copy or move a database.

  7. When the data is restored, click OK on the confirmation window. You can click Detail to review information on the restore operation.

It is highly recommended that you perform a full backup after a point-in-time or discreet restore, or after restoring from an auxiliary copy.

To restore a database without browsing

You can restore a database or instance without browsing first. This procedure is most appropriate when you want to restore to the latest backup version.

  1. In the CommCell Browser, right-click the database that contains the database that you want to restore, and then click Restore Database.

  2. In the Restore Options dialog box, select the restore options that you want to use.

  3. On the Restore Time menu, select the backup that you want to restore. Galaxy automatically restores all necessary backups based on your choice of Restore Time.

  4. If you want to select any additional restore options, click Advanced and select the options you want from the dialog box.

  5. After you have selected the restore options, click OK. The system displays the progress bar and starts to restore the data.

To restore a SQL Server instance without browsing

  1. In the CommCell Browser, right-click the instance, and then click Restore SQL Server.

  2. In the Restore Options dialog box, select the restore options that you want to use.

  3. If you want to select any additional restore options, click Advanced and select the options you want from the dialog box.

  4. After you have selected the restore options, click OK. The system displays the progress bar and starts to restore the data.

Managing Disaster Recovery

Here you can read about various options for restoring the full system, including:

  • Recovering a Windows 2000-based computer

  • Recovering a server running Exchange Server

  • Recovering a server running SQL Server

In the case that you have to recover from a total enterprise disaster, please read the following information. For steps in recovering a server running Windows 2000, begin with "Full System Restore Procedures."

Total Disaster Recovery Overview

In the case of a total enterprise disaster, the order in which you complete the restore is important. In general, the proper order is as follows:

  1. Deploy the CommServe and MediaAgent server(s).

  2. Recover the CommServe and MediaAgent by following procedures for recovering a CommServe/MediaAgent in the CommServe Administration Guide.

Because the domain controllers will not be functioning before the restore, the enterprise computers that are not domain controllers will fail to join the domain, and will instead automatically default to a workgroup member. For this reason, the domain controllers must be deployed and restored before the remaining enterprise computers are deployed, as follows:

  1. Deploy the domain controllers. The domain controller(s) are built using the Galaxy Disaster Recovery Phase. This builds the domain controller computers as Workgroup members, in preparation to be restored and recovered as fully functional domain controller(s) from the backup.

  2. Restore the domain controllers.

  3. Deploy the remaining enterprise computers (which can now join the domain).

  4. Restore the enterprise.

Total Disaster Recovery Steps

First recover the CommServe, using the procedures outlined in "Recovering a CommServe" in this chapter and in "CommServe Recovery Procedures," found in Appendix A of the Galaxy CommServe Administration Guide. The procedures include those for recovering the MediaAgent.

After the CommServe and MediaAgent are restored, you are ready to deploy and restore all Galaxy clients in the enterprise in the following order:

  1. The domain controllers (Active Directory and DNS) need to be recovered first, to establish proper connectivity throughout the enterprise:

    • Because there is no naming resolution until the domain controller is restored, the domain controllers name must be added to the CommServe and MediaAgent host files. The names of the CommServe and MediaAgent must also be added to this domain controller's host file. The entry should match what will be restored in DNS: IP address, fully qualified domain name (FQDN, short name. These entries will be overwritten after a full system restore is performed on each computer.

    • In the Windows Full iDataAgent Restore Options dialog box, select Primary to recover the first domain controller. All other full restores of iDataAgent for Windows in the enterprise can be recovered by accepting the default selections.

    • Domain controllers are installed as Workgroup members to avoid security ID (SID) conflicts. Galaxy will restore this FQDN to the domain controller, but will have its own naming resolution conflict if the name changes from Short to FQDN during the restore. Therefore, the FQDN must be added to the computer properties before the restore is implemented.

  2. The SQL Cluster and SQL Servers need to be recovered next, so that their dependent servers will start:

    • Deploy the cluster nodes and follow Internet Data Center guidance to configure the EMC storage and install clustering.

    • Review the steps in "Restoring a Cluster Server Node."

  3. Deploy and restore the remaining computers in the enterprise. If there are other servers that have other servers dependent on them, such as Microsoft Commerce Server 2000 or Microsoft SQL Analysis servers, they should be restored next. For example, if a retail site is to be restored, the SQL Server cluster databases have to be available before the Commerce Server can start, and Commerce Server usually has Microsoft SQL Analysis server running on it as well; both these services need to be restored and running before for Web servers can be restored.

The number of clients to be restored after the foundation has been recovered depends on the number of drives available in the tape library. Because restores are cannot be interrupted, you can invoke the remaining full iDataAgent restores for the enterprise at that time. The jobs will be queued until a drive is available.

Recovering a Computer Running Windows 2000

Here you can read about the various procedures used to restore a computer running Windows 2000, including the steps required for particular server roles, such as domain controller and Web server.

Recovering iDataAgent for Windows 2000

A full iDataAgent restore operation includes a full restoration of a Galaxy client's file system and system state. Full iDataAgent restores can be helpful or even necessary, depending on circumstances. The following are some examples:

  • Creating a computer that duplicates the data and configuration from another computer

  • Re-establishing a computer's data and configuration after a catastrophic system failure

The difference between a full iDataAgent restore and a typical restore is in the type of data that is to be restored. A full iDataAgent restore recovers not only regular data files and directories to their original paths, but also the system state (if required). The file system and system state can be restored at the same time without an intervening restart.

By default during full iDataAgent restores of file system data, the Galaxy system restores all data by unconditionally overwriting the corresponding files to the system being established. Galaxy also provides several options for replicating the restored data across the domain.

The system-state restore allows the hardware on the target to take precedence over the hardware settings that were backed up, so it is important that hardware devices are properly configured on the target prior to restoring.

What Should Be Restored

As part of the full iDataAgent restore, you can restore any or all of the following:

  • File system

  • System state

  • System databases

File System Restores

Files and directories are restored in-place; however, if any files are locked at the time of restore, the Galaxy system automatically writes each locked file to another file name within the same directory and records the instance in the Windows 2000 registry. When a full iDataAgent restore is performed, the system will restart once to restore the registry and overwrite the locked files.

SystemState Restores

The system state consists of components that are backed up as a unit and can be restored individually or as a unit. The system state is automatically backed up with the default subclient, which should be backed up frequently.

The procedures for restoring system state differ, depending on whether you are restoring to a domain controller or to a non-domain controller. If you are restoring on a domain controller, the domain controller must be started in the directory services restore mode, in order to restore certain database objects, such as Active Directory. During a system-state restore on a non-domain controller, no databases need to be offline. Therefore, there is no need to start in a special mode when performing a system state restore on a non-domain controller.

System Database Restores

The system databases are backed up with the system-state backup on the default subclient. These databases can be restored as part of the full iDataAgent restore. It is possible to restore a specific system database; however, the services associated with the restored database must be installed and functional.

Domain Controller Restore Types

Domain controllers communicate with each other across the network and replicate data and network information. This replication takes place automatically, according to the schedule you established during Windows installation. When restoring the system state to a domain controller, Galaxy allows you to decide how you want the restored data to be replicated across the domain. The restore types are non-authoritative, authoritative, and primary.

When Active Directory or System Volume (SYSVOL) is restored to a domain controller, by default it is restored in a non-authoritative mode. Newer data on the network is then propagated to the restored computer, updating it with any newer information.

When the restored data is meant to override the data on other domain controllers, it should be restored using the authoritative mode. After this data is restored to the domain controller, it is propagated to the other domain controllers and overwrites any newer data on those computers. The authoritative mode is used if critical SYSVOL or Active Directory data has been deleted and the deletion has been propagated throughout the domain.

Note: Authoritative restores must be performed with caution, as the system state will be rolled back to the point of the backup, possibly resulting in a loss of data that cannot be restored after it is overwritten.

A primary restore marks the restored data as the primary data for all of the replicas within the domain. This creates a new File Replication service (FRS) database, and pushes the replicated SYSVOL data to any domain controllers that are added to the replication system.

Note: A primary restore should be used only when all other domain controllers are non-functional and you want to rebuild the domain from the last backup. Do not perform a primary restore if any other working domain controller from this domain is available.

Restore Options for SystemState Data

System state restore operations restore several objects, including SYSVOL and Active Directory. Here you can read about the options available for restoring these system state objects.

SYSVOL Restores

The SYSVOL restore type may be chosen directly in the Full iDataAgent Restore Options dialog box. The following restore types are supported for SYSVOL:

  • Authoritative

  • Non-authoritative

  • Primary

The chosen restore type for SYSVOL applies only to the SYSVOL restore operation, and will not effect the restore operations of other domain controller components. For example, if you choose authoritative restore for SYSVOL, Active Directory is restored non-authoritatively by default.

Active Directory Restores

Galaxy performs a non-authoritative restore of Active Directory by default. To force an authoritative restore, run the NTDS utility (ntdsutil) after running a Galaxy full iDataAgent restore.

Cluster Database Restores

The cluster services and quorum databases are restored with the system state restore of the physical node owning the quorum databases. Program files are restored with the file system. Restoring both the system state and the file system will restore the files on the physical node, and the cluster databases to a temporary directory. In order to complete the restore of the cluster databases, enter the following: authorutil –cluster. For more information about cluster database restores, see "Restoring the Cluster Server" later in this chapter.

Specific Boot Modes

When you restore the SYSVOL, Active Directory, and system databases on a domain controller, you must restart the computer in the directory services restore mode. Restart the computer and press F8 upon system startup, then select Directory Services Restore Mode.

You may also restore file system data on a domain controller that is in the Directory Services Restore mode. The restore process will restore the system state data and the file system data in one restore operation. When complete, the computer must be restarted into the normal operation mode.

If the computer is not a domain controller, it is not necessary to restart it in the Directory Services Restore mode, because there is no Active Directory present. You can fully restore all components with one operation.

Performing Full iDataAgent Restore Operations

Table 4.21 provides a broad overview of the components and information required to fully restore your Windows 2000-based computer.

During the system rebuild, you will be prompted for system information, depending upon the system setup. Because the computer will be down during the operating system rebuild, you may not be able to access necessary information about the system. It is important to record such information before a disaster occurs.

Table 4.21 Installation components for system rebuilding

Component

Description

Software

Windows 2000 installation discs, compact disc, and required service packs
iDataAgent for Windows 2000.

Drives

Use the Disk Management utility to record the volumes and sizes of the hard drives in the system. This information is needed to recreate the disk configuration in case of hard drive failure. Hard drives must be configured before system state or file system data is restored.

Computer name

Use the same computer name and avoid changing other configuration settings.

TCP/IP

Record the fully qualified network name and IP address if the computer uses a static IP address.
Subnet mask for your network
IP address of the network router used by the client computer
TCP/IP domain name for the network (for example, ad01.nwtraders.com)
IP address of the DNS server

Video settings

Record the video settings if the resolution and color depth are important.

Domain information

Record the domain this computer resides in, and set up a new computer account when ready.

Local administrator password

Record this information or you will not be able to log on to the computer after it is restored.

Galaxy Install Directory

Record the directory in which Galaxy was installed.

The restore process is performed at the backup set level. If the client computer has two or more backup sets, be prepared to identify the backup set whose data you want restored during the restore process. (In general, all backup sets of a given client computer encompass the entire file system; however, backup filters, which can be unique, can introduce differences.)

Full System Restore Procedures

If the operating system of your Windows 2000-based client has been corrupted, follow this procedure manually or use deployment scripts to restore the full system.

Rebuilding the operating system

  1. If required, rebuild the system hardware.

  2. Install the Windows 2000 operating system. Windows 2000 must be installed in the same directory as that of the original computer. Be sure to enter the correct time and select the proper time zone. You should leave the server in a workgroup and not include it in the domain.

  3. Install required Service Packs. For Service Pack requirements, see the iDataAgent for Windows 2000 release notes.

  4. Configure hardware devices, such as disk arrays, and confirm connectivity to all drives.

  5. Confirm connectivity to and from the CommServe, MediaAgent, and Galaxy client to be restored (using forward and reverse DNS lookup or ping). All computers should have successful TCP/IP connections to the CommServe.

  6. If DNS is not available, add all computer names to the CommServe's host file; address FQDN shortname or alias, for example, 192.168.123.123 ad01.nwtraders.com ad01.

    Web Tier servers should bind the back-end network interface card first.

  7. Web tier servers, CommServe, and MediaAgents should be enabled for Galaxy to allow traffic through the firewall; that is, the Galaxy firewall configuration files must be properly set up.

  8. Cluster servers should bind the public network interface card before the private network interface card.

  9. Cluster servers should have the Microsoft Hotfix (pre-Service Pack 3) 19425 gethostbyaddress applied to all nodes. Please contact Microsoft Product Support Services to obtain this patch.

  10. Cluster Servers should have all disk-array devices configured with access to the shared array, and cluster software should be installed and running.

  11. iDataAgent for Windows 2000 should be installed to all Galaxy clients in the enterprise. The client name and interface names should be installed using the same information provided during the initial installation to the CommServe. It is only necessary to install iDataAgent for Windows 2000 to the computer. After the file system is restored, additional iDataAgents, such as iDataAgent for SQL Server, will be restored to the target from the backup data and accessible by the CommServe. For details on installing the iDataAgent for Windows 2000, see Chapter 2, "Backup and Restore Deployment."

  12. Apply Galaxy patches. Domain controllers need Galaxy 3.1 GSP1 patches 4, 11, and 23. To install iDataAgent for SQL Server, use Galaxy 3.1 GSP1 patch 28.

  13. Shut down and restart the Windows 2000-based computer so that the changes take effect.

  14. After the installation is complete, open the CommCell Console.

  15. Ensure that backup jobs are disabled for the client computer that you intend to restore. This prevents any backups that may have been previously scheduled for the client computer from starting while the restore is in progress.

Restoring a Domain Controller

Before you begin:

  • Make sure that you have completed all the steps listed in "Rebuilding the operating system" before continuing.

  • Make sure the correct FQDN has been configured for the computer that will be restored as a domain controller.

  • If you are rebuilding a DNS server, add the CommServe, MediaAgent and CommClient names and IP addresses to the host file of the client and CommServe for name resolution until the DNS server is restored.

  • Enable and configure TCP/IP support. Configure the network interface card(s) for connectivity to the CommServe.

  • Implement Compaq teaming, if the computer was backed up in a teamed configuration.

  • Apply Galaxy 3.1 GSP1 patches 4, 11, and 23 (required for domain controllers).

    Note: For domain controllers, Galaxy 3.1 GSP1 requires that patches 4, 11, and 23 be applied. You may receive an error message during patch installation that states that the client was unable to communicate with the CommServe. This error may occur if the path to the Galaxy installation directory has not been applied to the environment. You can correct the error by applying the path to the environment (MyComputer\Properties\Advanced\Environment variables\System Path) and restarting the Galaxy Services. Or you can ignore the error and continue with the patch installation. The patch will still apply to the client computer. This is a Galaxy 3.1 GSP1-specific issue and has been corrected.

To restore a domain controller

  1. To restore the system state data, the domain controller must be in the Directory Services Restore mode. file system data and System databases can also be selected during this operation. To do this, follow these steps:

    1. Restart the computer.

    2. As it restarts, the following message appears: "For troubleshooting and advanced startup options for Windows 2000, press F8."

    3. Press F8. Then select Directory Services Restore Mode.

    The system will start in the Directory Services Restore mode and display "Safe Mode" on all four corners of the screen.

  2. From the backup server, start the CommCell Browser.

  3. Expand Client Computers. You will see a list of client computers.

  4. Select the client that will be restored and expand it. A list of installed iDataAgents on the client computer will be listed.

  5. Expand the File System iDataAgent tree. A list of backup sets will be displayed if the client was configured with more than one backup set. There will be at least one—the default backup set called defaultbackupset.

  6. Select and right-click the backup set that contains the data that you want to be restored. From the menu, click Full iDataAgent Restore.

  7. The system prompts you to confirm the selection. Click OK to continue.

  8. In the Full iDataAgent Restore Options dialog box, make selections based on whether you are restoring a stand-alone domain controller or a non-stand-alone domain controller.

    • Click Exclude Files/Folders and add the SYSVOL path. The system state will restore the SYSVOL. Filter this directory from the restore. Filtering will prevent the file system from additionally restoring the SYSVOL. (Computers deployed using MSA scripting default to C:\Ad\Sysvol. The standard default location is C:\WINNT\Sysvol).

    • In the dialog box, select primary for a stand-alone domain controller or the first domain controller being restored to the enterprise.

    • For a networked domain controller or if this is not the first domain controller being restored to the enterprise, select the SYSVOL restore option that you want to apply.

    • To render the domain controller operational again without replicating any changes to the other domain controllers on the network, in the SYSVOL field set the Restore option to Non-Authoritative.

    • To render the domain controller operational again and replicate the restored data to the other domain controllers on the network, set the Restore option for SYSVOL field to Authoritative and complete the restore by running the NTDS restore utility (ntdsutil) from the command prompt after the restore completes.

  9. Click OK to start the restore process. As the restore proceeds, the system displays a restore progress bar. It may take several minutes before you see the progress bar.

  10. You will be notified that the restore has been completed successfully. Click OK.

  11. You will be prompted to restart the computer.

    1. If you are performing a primary or a non-authoritative restore, click OK and restart in normal mode.

    2. If you are performing an authoritative restore of the SYSVOL and Active Directory, click OK, but restart the computer in Directory Services Restore Mode to continue with the Authoritative Restore procedures.

    Restore the Active Directory using an Authoritative Restore:

    1. Click Start, point to Programs, click Accessories, and then click Command Prompt.

    2. At the command prompt, type ntdsutil.

    3. At the ntdsutil prompt, type Authoritative Restore.

    4. At the Authoritative Restore prompt, type Restore Database.

    5. Click Yes to restore the database.

    6. When done, exit the Authoritative Restore prompt by typing quit and then end the ntdsutil session by typing quit again. Exit the command prompt by typing exit.

    7. Restart the computer and allow time for replication to complete.

    8. To restore the SYSVOL Authoritatively, manually copy the data from the \WINNT\Temp directory to the existing SYSVOL directory (shown in the following example as \WINNT\SYSVOL). (This will move the restored SYSVOL information from the \WINNT\Temp directory to the existing SYSVOL directory).

      Copy \WINNT\Temp\Sysvol\Domain Scripts to \WINNT\SYSVOL\Sysvol\Domain\Scripts and \WINNT\Temp\Sysvol\Domain\Policies to \WINNT\SYSVOL\Sysvol\Domain\Policies

  12. If Microsoft Certificate Services is installed, ensure that Certificate Services is back online after the previous restart step. Certificate Services will not accept any certificate requests until it completes its restore functions.

Restoring a Non-Domain Controller or Member Server

If you are restoring a non-domain controller, follow this procedure. Make sure that you have completed all of the steps in "Rebuilding the operating system" prior to continuing.

If restoring more than one computer, review "Total Disaster Recovery Steps," earlier in this chapter, and evaluate any dependencies that might affect the order of the computer restore operations. If you are restoring a cluster server or cluster node, review the cluster information later in this chapter.

To restore a non-domain controller or member server

  1. Start the CommCell Browser.

  2. Expand Client Computers. You will see a list of client computers.

  3. Select the client that will be restored and expand it. A list of installed iDataAgents on the client computer will be listed.

  4. Expand the File System iDataAgent. A list of backup sets will be displayed if the client was configured with more than one backup set. There will be at least one—the default backup set called defaultbackupset.

  5. Select and right-click the backup set that contains the data that you want to be restored. On the menu, click Full iDataAgent Restore.

  6. The system prompts you to confirm the selection. Click OK to continue.

  7. In the Full iDataAgent Restore Options dialog box, select the restore options that you wish to apply.

  8. Clear the SystemState option.

  9. Click OK to start the restore process. As the restore proceeds, the system displays a restore progress bar.

  10. You will be notified that the restore has been completed successfully. Click OK.

  11. You will be prompted to restart the computer. Click Cancel. Do not restart the computer.

  12. Repeat Steps 5-9, this time selecting the SystemState option. Clear all other defaults.

  13. Click OK to start the restore process. As the restore proceeds, the system displays a restore progress bar.

  14. You will be notified that the "Windows 2000 file system restore for client name completed partially". This indicates success for this stage of the restore. Click OK.

  15. The following message appears: "To perform an authoritative restore of Active Directory, please run ntdsutil. To complete the authoritative restore of sysvol, please copy over the contents of sysvol from the temporary restore directory." Click OK. This message is informational and only relevant when you are performing an authoritative restore of a domain controller. If the computer being restored is part of a cluster, the message above will include, "To complete the restored cluster database, please run clustrest.". Ignore this message and review the cluster information later in this chapter.

  16. You will be prompted to restart the computer. Click OK to do so.

After a full iDataAgent restore, the SID for Windows 2000 for the rebuilt system may not match the corresponding SID on the primary domain controller. To resolve this conflict, remove the system from the Windows 2000 domain by logging in locally, and joining a workgroup. Then add the rebuilt system back into the Windows 2000 domain by joining the domain.

A full iDataAgent restore operation restores only certificates issued before the last backup. You can leave the remaining certificates orphaned, or you can revoke and reissue them.

Restoring Commerce Server

Preliminary information is available in "Restoring a Non-Domain Controller or Member Server." Servers with SQL Server will also need a SQL Server database restore as described in "Recovering SQL Server," later in this chapter.

You should stop the Commerce Server 2000 services when you restore the server running SQL Server and Commerce Server 2000.

Restoring ApplicationCenter

Preliminary information is available in "Restoring a Non-Domain Controller or Member Server" earlier in this chapter. Before you restore a member server, evict the node from the cluster. Re-join the cluster after the restore has been completed.

Restoring Internet Information Services

Preliminary information is available in "Restoring a Non-Domain Controller or Member Server" earlier in this chapter.

Restoring the Cluster Server

Before you begin, make sure that you have completed all the steps in "Rebuilding the operating system."

In the case of a total loss of the cluster, the following process is most efficient. It includes a SQL Server restore as described in "Recovering SQL Server." later in this chapter. The cluster service and SQL Server service must be running before you restore SQL Server.

To restore the cluster server

  1. Install the Windows 2000 operating system software on both physical nodes.

  2. Install the Microsoft (pre-Service Pack 3) WINSE19425 patch.

  3. Shut down node2.

  4. On node1, configure the EMC drives, and change drive letters and Emulex settings (For more information, see the Internet Data Center documentation on TechNet). When prompted to re-start your computer, click Yes.

  5. After the computer restarts, new hardware will be discovered, and you will be prompted to restart the computer again. Click No. Join the domain, restart the computer, and then log on to the domain.

  6. Install cluster software on node1 as the first node in the cluster, but do not restart the computer. After the cluster software is installed, shut down node1.

  7. Power on node2.

  8. On node2, configure the EMC drives, and change drive letters and Emulex settings (For more information, see the Internet Data Center documentation on TechNet). When prompted to re-start your computer, click Yes.

  9. After the computer restarts, new hardware will be discovered, and you will be prompted to restart the computer again. Click No. Join the domain but do not restart the computer. Shut down node2.

  10. Turn on node1 and log on to the domain.

  11. Turn on node2 and log on to the domain.

  12. Install cluster software on node2 as a secondary node to the cluster.

  13. Using Cluster Administrator, configure the disk groups. (For more information, see the Internet Data Center documentation on TechNet.) The Cluster Group should own the quorum disk. Set the disk group properties to allow failback.

  14. Install SQL Server 2000 and Service Pack 1 to both SQL Server 2000 instances. The server and instance name should be the same as they were when there were installed previously. If this is not recorded anywhere, use the CommCell Browser and browse the computer you need to restore. The SQL instance name is listed under the SQL iDataAgent in the CommCell console. You can see the location of the data and log file directories by browsing iDataAgent for Windows 2000.

  15. Install Galaxy to the same location where it was previously installed. Install iDataAgent for Windows 2000 on both SQL Server physical nodes. Then, install iDataAgent for Windows 2000 on the virtual servers. During the installation on a virtual server, type the full path, including drive letter, for the Galaxy installation in the folder window. If this is not recorded anywhere, use the CommCell Browser and browse the virtual server that you need to restore. You can see the location of the previous Galaxy installation directory by browsing the iDataAgent for Windows 2000.

  16. Install iDataAgent for SQL Server using Patch 28 to the virtual servers. The iDataAgent's for each virtual server must be installed from node that currently owns the virtual server resources.

  17. Restore the server running SQL Server to both virtual servers by following instructions in "Restoring SQL Server," later in this chapter.

  18. Restore any desired non-database files to the virtual servers.

This completes the recovery of the SQL Server cluster.

Restoring a Cluster Server Node

If the cluster server is functioning in a fail-over mode, and one cluster node is functioning and the other is not, you can recover the failed node by following instructions described in "Restoring a Non-Domain Controller or Member Server." The cluster service must be running on the node that you are recovering prior to the restore operation.

  1. When you restore a single cluster node, you must evict the node from cluster administrator before rebuilding the node. From the cluster administrator, highlight the node that has failed, right-click it, and select evict node.

  2. Rebuild the operating system. Make sure that you have completed all the steps in "Rebuilding the operating system" prior to continuing.

  3. Configure TCP/IP for private and public network interface cards.

  4. Confirm that the public network interface card binds before the private network interface card.

  5. Join the computer to the domain, but do not restart yet.

  6. From Device Manager, configure the EMC drives, change drive letters and Emulex settings. For more information, see the Internet Data Center documentation on TechNet.

  7. Restart the computer in safe mode by pressing F8 during restart. Apply the Microsoft (pre-Service Pack 3) WINSW 19425 patch and then restart the computer in normal mode.

  8. Install Microsoft cluster software and configure as secondary node.

  9. Install iDataAgent for Windows 2000 on the physical node.

  10. Perform a Full System iDataAgent restore of a non-domain controller. For details, see "Restoring a Non-Domain Controller or Member Server," earlier in this chapter.

  11. Confirm that each Microsoft resource in cluster administrator has both nodes listed as available nodes on the general properties tab. When a cluster node is evicted, the evicted node gets removed from each Microsoft cluster resource as an available node. In the cluster administrator, double-click each Microsoft cluster resource to view the general properties tab. If all nodes are not listed as possible owners, click Modify and move the node from the left pane ("available") to the right pane ("possible") and then click OK. In order for a group to fail over to a desired node, every resource within the group must list that node as a possible owner.

  12. Confirm failover and failback capability.

Restoring the Cluster Databases

Cluster databases should be restored only if the existing databases are corrupt or missing cluster resource information that can be retrieved from the backup data. The cluster services and quorum databases are restored with the system state. The program files are restored with the file system. Restoring both the system state and the file system will restore the cluster information. However, the quorum databases are always restored in authoritative mode and require a manual, non-authoritative restore process.

A system state restore will place the quorum (drive) databases in a temporary location, \WINNT\Temp. If the quorum disk was lost or corrupted, the data can be restored using the authoritative restore utility (authorutil). The cluster services must be online during the authoritative restore. If the existing quorum data is corrupt, the cluster services will not start. You will need to uninstall and re-install the cluster service before running authorutil – cluster (or install the cluster service prior to the restore operation).

To restore the cluster databases

  1. From the command prompt of the node that owns the quorum database, type: authorutil –cluster

  2. Stop the cluster service on all nodes, except the one that is performing the restore. You should perform the restore on the node that owns the cluster group/quorum database during backup operations. (If you do not follow this process, and another node with a more current database takes ownership of the quorum before you update the database from the restored node, the restore will not work.)

  3. A successful restoration will prompt you to restart the services on the paused nodes.

  4. After you complete the process and the Cluster service has started successfully on the newly restored node, restart the other nodes. If clusdb was not restored, perform the procedure described in the following Microsoft Knowledge Base article: 224999, "How to Use the Cluster TMP File to Replace a Damaged Clusdb File."

You can use cluster service commands to troubleshoot or debug the cluster service from the command prompt. The cluster service command line can only be run locally from the cluster directory: systemroot\cluster

The clussvc command should not be used under typical conditions; rather, it should be used only as a temporary diagnostic tool if the cluster service fails to start (for example, after a system-related error).

The following rules apply when entering commands from the command prompt:

  • When entering commands from the command prompt, you can specify multiple options for one command line. Clussvc.exe processes options from left to right. If an option fails, the command stops running at the failed option.

  • To use the cluster service commands, you must be logged on with administrative rights.

  • To stop the cluster service, press CTRL+C at the command prompt.

The command line for starting the cluster service has the following syntax:

clussvc -debug [command]

where command is:

fixquorum

This allows the cluster service to start up, even if there are problems with the quorum device.

resetquorumlog

Creates a new quorum log file if the quorum log file is not found or is corrupted; it is based on information in the local node's cluster database file. If the quorum log file is found and is not corrupted, this command has no effect.

The cluster service runs in the command prompt window and displays all output recorded in the cluster log in the window.

Other Restore Scenarios

The full iDataAgent restore function can also be used in the following disaster recovery situations.

When restoring to a rebuilt or new system:

  • Make sure the target computer is as similar to the original as possible.

  • Make sure the target computer has the same fully qualified network name as the original.

  • Try to match the general hardware configuration (that is, IDE, SCSI) of the original computer.

  • Match the local disk drive configuration as closely as possible to that of the client being restored.

  • Make sure the computer's disk(s) can accommodate the quantity of data being restored.

  • If possible, use the same network interface card (NIC) as that of the client being restored.

If you are performing a full iDataAgent restore to a computer with a different hardware configuration (for example, network interface card, video card) from the backed up client, perform the following procedure.

To perform a full iDataAgent restore to a computer with a different hardware configuration from the backed up client

  1. Perform the full iDataAgent restore as described in this chapter with the unconditional overwrite option cleared.

  2. Check the TCP/IP and video configuration. If they are incorrect, perform the following steps.

    1. Re-install the appropriate network interface card drivers.

    2. Uninstall the Network Adapters and Display Adapters (using the Hardware Uninstall Wizard or Windows Device Manager).

    3. Restart the computer when prompted.

    4. Your hardware should be re-discovered by Windows and the appropriate drivers restored.

  3. Reconfigure your TCP/IP and Display Adapter settings.

Windows 2000 supports basic and dynamic hard drives. When you perform a full iDataAgent restore, the target hard drive should be configured as a dynamic hard drive if the backed up drive was a dynamic hard drive.

Note: If the drive type does not match during a restore, the rebuilt drive will be marked as foreign and the restored data will be inaccessible. If this happens, the drive must be converted from foreign, to basic and then to dynamic, using Windows 2000 disk management tools. The restore should then be run again.

For a full iDataAgent rebuild of a domain controller, the Galaxy installation directory must be on the same drive on the target computer as it is on the backup data. In addition, it is strongly recommended that the directory be in the same location on the target as on the backup.

Whenever you restore NTDS and SYSVOL, the data is moved into a temporary directory. The temporary path uses the Galaxy install directory path from the backup data and tries to put the data in the same place on the target.

If you are going to restore a domain controller, and if the location of the Galaxy install directory on the target is different from its location on the backup, rename the following data path before you restart:

D:\GalaxyNew\iDataAgent\FileSystemAgent\2\2\RESTORE\GALAXY\iDataAgent\FileSystemAgent\2

The first part of the path starting with GalaxyNew is the current Galaxy installation on the target; the second part of the path starting with GALAXY is the Galaxy installation on the backup.

Before you restart, change the second path to match the first path. This will allow the necessary restored data in the temporary directory to get moved to the new Galaxy installation directory on the target.

Full iDataAgent Restore Options Window

As part of the full system restore, you must select which options you want to be in the options window for the full-system restore. The following tables describe the options available from this window.

Table 4.22 Restore Time options

Option

Description

Restore from the
Latest Backup

Restores the client computer using the most recent backup data.

Restore from a Backup That Occurred Before
This Date

Allows you to restore the client computer using a backup from a specified date and time.
This option allows a file system restore with the corresponding options described in the next table.

Table 4.23 File System Restore options

Option

Description

File System

This option includes file system data in this restore with the corresponding options described in this table.
Note If you are restoring to a domain controller and have started in the Directory Services Restore Mode, you may also restore the file system data at this point.

Restore Deleted Files/ Folders
(no-image)

If this option is cleared:
Galaxy restores the computer by using the image of the data as it existed as of the specified backup time.
If this option is selected:
Galaxy restores the client computer with all the data that was ever backed up as of the specified backup time. This is called a no-image browse.

Unconditional Overwrite

If this option is selected:
All data being restored is unconditionally written to the specified location.
If this option is cleared:
Files/directories whose names are the same as those in the restore path and for which the backed up data is as old or older than those in the restore path are not restored.
Files/directories whose names are the same as those in the restore path and for which the backed up data is newer than those in the restore path are restored.
Files/directories whose names are different from those in the restore path are restored.

Restore ACLs

If this option is selected:
All data being restored retains its original access control lists (ACLs) and therefore its original security attributes.
If this option is cleared:
The data is restored without the ACLs. Consequently, the restored data assumes the ACLs of the parent directory.

Recreate
Mount Points

If this option is selected:
Any mount points that have been deleted or that have had a change in the configuration are recreated during the restore operation.
If this option is cleared:
Any mount points that have been deleted or whose configuration has changed will not be restored.

Exclude Files/Folders
Button

Allows you to specify files and/or folders that you want to filter from the restore. To add a file or folder to the filter, use the Add button. To delete a file or folder from the filter, highlight the path in the window and click the Delete button.

Table 4.24 SystemState Restore options

Option

Description

system state

This option includes system state in this restore with the corresponding options described later.
There are several objects included in a system state restore. Galaxy provides a choice of restore type only for SYSVOL. For Active Directory, Galaxy performs a non-authoritative restore without offering restore type options. To force an authoritative Active Directory restore, you must use the ntdsutil utility.

Primary

A primary restore marks the restored data as the primary data for all of the replicas within the domain. This creates a new FRS database, and pushes the replicated system state data to any domain controllers added to the replication system.
Note A primary restore should be used only when all other domain controllers are non-functional and you want to rebuild the domain from the last backup. Do not perform a primary restore if any other working domain controller from this domain is available.

Authoritative

When the restored data is meant to override the data on other domain controllers, it should be restored using the authoritative mode. After this data is restored to the domain controller, it is propagated to the other domain controllers and will overwrite any newer data on those computers. The authoritative mode is useful if critical system state data has been deleted and the deletion has been propagated to other servers.
Note Authoritative restores must be performed with caution, as the system state will be rolled back to the point of the backup, possibly resulting in a loss of data that cannot be restored after it is overwritten.

Non-Authoritative
(default)

When system state data is restored to a domain controller, by default it is restored in a non-authoritative mode. After the system state is restored in a non-authoritative mode, newer data on the network is propagated to the restored computer, updating it with any newer information.

Table 4.25 System Database options

Option

Description

System Databases

This option includes system databases in this restore with the corresponding options described in this table.

Event Logs

Restores the system event logs when selected.

RSM Database

Restores the RSM database when selected.

Terminal Server
Database

Restores the Terminal Services database when selected.

Quota Information

Restores quota information when selected.

Content Indexing Catalogs

Restores the content indexing catalogs when selected.

Advanced Option

Displays the Choose Copy Precedence window, which allows you to select the precedence of the copies from which you want to restore data. By default, Galaxy restores the data from the copy that has the highest precedence and has the data. Usually this will be the primary copy (precedence of 1). If, however, the data is distributed to multiple copies (using the auxiliary copy feature) whose retention periods are greater than that of the primary copy, then the data (if it comes from an older backup) will restore from a secondary copy.

Keep in mind that restore operations are conducted at the backup-set level and therefore transcend subclient boundaries. If the data being restored was backed up from different subclients, each associated with a different storage policy, then the restore data will be restored from those copies whose precedence matches the one that is specified.

If the specified copy is not available for a given subclient, the restore operation will not be completed successfully.

Restoring Exchange 2000 Server

In some cases, an Exchange 2000 database may become corrupted. In that event, the Exchange 2000 Server software must be reinstalled before the database is restored. The procedures in this section describe this type of rebuild.

Considerations When Restoring the Entire Computer

The system state or file system must be restored on the system where the Exchange 2000 Server resides. See the procedures in the Galaxy Client Administration Guide (Windows 2000 Server Family). After the computer is operational, continue to "Restoring Exchange Databases" later in this chapter. The computer may need a full system rebuild, including the system state and file system, before the Exchange 2000 Server is recovered.

Active Directory is corrupted and resides on the Exchange 2000 Server. See the Galaxy Client Administration Guide (Windows 2000 Server Family), (Full System Restore Procedures). If the Exchange 2000 Server is the only object that is missing or corrupt in Active Directory, follow the procedures for restoring Exchange later in this chapter.

Active Directory is corrupted and does not reside on the Exchange 2000 Server. See the Galaxy Client Administration Guide (Windows 2000 Server Family), (Full System Restore Procedures) to rebuild the domain controller on which Active Directory resides. If Exchange 2000 Server is the only object that is missing or corrupt in Active Directory, you can restore the Exchange 2000 Server objects by using a non-authoritative system state restore.

Exchange 2000 Server requires an SRS database recovery. The Site Replication Service (SRS) must be functional before the database is restored. SRS is backed up as part of the system state. See the Galaxy Client Administration Guide (Windows 2000 Server Family) for information on this topic.

Exchange 2000 Server requires a key management system database recovery. See the Galaxy Client Administration Guide (Windows 2000 Server Family), Full System Restore Procedures to restore the file system and system state. If the Exchange 2000 Server was the certificate authority, this will be included with the key management system (KMS) when the system state is restored. If the KMS application data is missing or corrupt, restoring the file system data will include this. The default location of the program data is \Program Files\Exchsrvr\KMS\Data.

Exchange 2000 Server resides on a Cluster Server and the Cluster Server is corrupt. See Galaxy Client Administration Guide (Windows 2000 Server Family), (Full System Restore Procedures).

The Cluster Server is operational and only the Exchange 2000 Server needs recovery. In that case, follow these procedures.

To perform Exchange 2000 Server Recovery

  1. Review "Considerations" earlier in this chapter to determine if a full restore of the Windows 2000 system state and file system is required. For procedures and supporting information, see the Galaxy Client Administration Guide (Windows 2000 Server Family).

  2. If Active Directory contains the Exchange 2000 Server Objects, run Exchange setup in disaster recovery mode (setup/disasterrecovery). If the Exchange 2000 Server objects are not present in Active Directory, see "Restoring System State First." You can choose to reinstall Exchange 2000 Server, but you must use the identical information structure and hierarchy as were used in the original Exchange 2000 Server. In either instance, you must install Exchange 2000 Server to the same location where it was originally installed. If you choose to set up in disaster recovery mode, do not restart the computer when the setup is complete. Continue to the next step.

  3. Verify that Circular Logging for all storage groups is disabled.

  4. If there is software currently running on the server that may attempt to access the Exchange 2000 database, such as Virus Scan, disable it at this time.

  5. Perform a full restore of the Exchange 2000 database, selecting all Exchange 2000 Databases requiring a restore.

  6. You can now enable any software that was disabled in a previous step.

  7. Verify that the server is operational.

  8. Perform a full backup of the Exchange 2000 database to ensure the existence of a current archive.

To restoring single or multiple Exchange databases

This procedure describes how to restore the Exchange 2000 Server database(s). Do not perform this procedure unless you intend to overwrite your existing Exchange 2000 Server database with the backed up version.

  1. Dismount any databases that will be restored. If you are restoring the entire Exchange 2000 Server, dismount all stores.

  2. If you are restoring the KMS database, verify that the key management server data directory is empty (typically \Program Files\Exchsrvr\Kmsdata), and make sure that the Microsoft Exchange KMS is started.

  3. If you are restoring the site replication service (SRS) database, verify that there are no *.ebd , *.log or *.chk files in the Exchsrvr/Srsdata folder, and verify that the Microsoft Exchange Site Replication Service is started.

  4. On the Windows taskbar, click Start, point to Programs, click Galaxy, and then click Galaxy CommCell Console.

  5. In the CommCell logon window, log on by entering your Galaxy user name and password. Galaxy displays the CommCell console window.

  6. In the CommCell browser tree, select and double-click the client.

  7. In the CommCell browser tree, right-click the Exchange Database iDataAgent icon and then click Browse Backup Data.

  8. In the Browse Options dialog box, click OK (assuming the default settings are being used).

  9. Galaxy displays the Browse dialog box, which shows the Exchange 2000 Server databases.

  10. In the Browse dialog box, select the database(s) to be restored.

  11. Click the Restore All Selected button.

  12. Verify the contents of the Restore Summary dialog box.

  13. To automatically mount the stores after the restoration, check the Mount database after restore option. Note that this option will be disabled if only KMS or SRS databases have been selected for restore.

  14. Click OK.

  15. Galaxy starts a full restore of the items selected. After the data is fully restored, Galaxy displays a confirmation message. Click OK to acknowledge the message.

  16. If you restored the KMS database, make sure that you stop and then restart the KMS after the restore has successfully completed.

  17. If you restored the SRS database, make sure that you stop and then restart the SRS after the restore has been successfully completed.

Restoring SQL Server 2000

Here you can find information on and procedures for fully restoring SQL Server and its databases that are secured by Galaxy.

Performing a Full System Restore

A full system restore operation restores all files (including the operating system) and SQL Server databases on a client computer after a catastrophic event.

Before beginning a SQL database restore operation, determine if a full restore of the Windows 2000 system state and file system is required. For procedures and supporting information, see the Galaxy Client Administration Guide (Windows 2000 Server Family).

The full system restore is a two-step process:

  1. The computer must be fully functional with the Microsoft SQL Server application installed. A Full iDataAgent Restore will accomplish this. If a full system restore has been performed, uninstall and reinstall Microsoft SQL Server on the computer after performing a full system rebuild. Uninstall and re-install Microsoft SQL Server 2000 and Service Pack 1. The server and instance name should be the same as in the previous installation. If this is not recorded anywhere, use the CommCell Browser and browse the computer you need to restore. The SQL Server instance name is listed under the SQL iDataAgent in the Commcell console. You can see the location of the data and log file directories by browsing the file system iDataAgent.

  2. The SQL Server databases must be restored. Follow the procedures given in "Performing Full SQL Server Instance Restores." When you restore the SQL Server with Commerce Server 2000 installed, you should stop Commerce Server 2000 services before you start the restore operation.

Performing a Full SQL Server Restore

A full SQL Server instance restore is the process of fully restoring all databases of a SQL Server instance, either to the same computer or to a different one. Full SQL server instance restores can be helpful or even necessary, depending on circumstances. Some examples are as follows:

  • Creating a server running SQL Server that duplicates the data and configuration from another server running SQL Server.

  • Re-establishing a SQL Server's databases after a catastrophic server failure.

Restoring the Entire Computer

If a system state or file system restoration is necessary on the system where the SQL Server resides, see the procedures in "Restoring a Non-Domain Controller or Member Server." After the computer is operational, continue to "Performing Full SQL Server Instance Restores." The computer may need a full system rebuild before the SQL Server is recovered. The particular steps required for the restore depend on the state of the SQL Server computer:

The computer has been rebuilt and restored using full file system iDataAgent Restore. Uninstall and re-install SQL Server on the computer after performing a full system rebuild. The server and instance name should be the same as those that were used when SQL Server was installed previously. If this is not recorded anywhere, use the CommCell browser and browse the computer you need to restore. The SQL instance name is listed under SQL iDataAgent in the CommCell console. After you complete the steps for the restore operation, you will also need to perform a SQL Server restore operation on servers that are running SQL Server, as described in "Recovering SQL Server."

The SQL Server resides in a cluster. Restoring SQL Server to a cluster requires that the Microsoft cluster services and SQL Server be functional prior to the restore. If necessary, install Microsoft cluster software and Microsoft SQL Server 2000 and Service Pack 1.

Data or registry information on the physical node is missing. Perform a full system iDataAgent restore on the physical node; then uninstall and re-install Microsoft SQL Server to the virtual server.

Cluster database information, such as SQL cluster resources, is missing. Run authorutil –cluster after performing a full system iDataAgent restore on the physical node that owns the cluster group/quorum drive.

Program files are missing from the virtual drive. Perform a file system restore for the virtual server that owns the program drive.

Performing Full SQL Server Instance Restores

When performing a full SQL Server instance restore, you must select Unconditionally overwrite existing databases or files in the SQL Server Restore Options dialog box.

There are two methods you can use to perform a SQL Server instance restore. The first method is the recommended method.

  • Method 1 allows you to restore the system databases (master, model, and msdb) as one restore operation, and then restore user-defined databases one by one. By using Method 1, you can get your instance up and running before you attempt to restore your user databases. This method also allows you to determine the order in which databases are restored. You can even restore user databases in parallel as long as the databases are properly configured.

  • Method 2 allows you to restore the whole instance, both system and user defined databases, as one job.

Method 1: To restore full SQL Server instances

  1. The SQL Server service must be started. If the SQL Server is started, begin with step 2. If the SQL Server will not start, see "Rebuilding the Master Database (Rebuild Master Utility)."

  2. Perform either a single or multiple database restore of the system databases (master, model, msdb).

  3. If you are restoring to a different SQL Server, the data directory where the SQL Server system databases (master, msdb, model) reside must be identical on both SQL Server computers.

  4. Restore the user databases in the order you want.

  5. If the master database has been restored to a different SQL Server, execute the following stored procedures on the new host SQL Server:

    sp_dropserver ` oldservername '
     sp_addserver ` newservername ', `LOCAL'
    

Method 2: To restore full SQL Server instances

  1. The SQL Server service must be started. If the SQL Server is started, begin with step 2. If the SQL Server will not start, see "Rebuilding the Master Database (Rebuild Master Utility)."

  2. In the CommCell browser, right-click on the SQL Server instance that you want to restore, and select Restore SQL Server.

  3. In the SQL Server Restore Options dialog box, select Overwrite existing databases and files, and any other restore options that you want.

  4. If you are restoring to a different SQL Server, the data directory where the SQL Server system databases (master, msdb, model) reside must be identical on both SQL Server computers.

  5. Click OK.

  6. If the master database has been restored to a different SQL Server, execute the following stored procedures on the new host SQL Server:

    sp_dropserver ` oldservername '
     sp_addserver ` newservername ', `LOCAL' 
    

Rebuilding the Master Database (Rebuild Master Utility)

If the SQL Server will not start, run the SQL Server utility Rebuildm.exe (at a command prompt) to rebuild the master database. This utility re-creates the system databases (master, msdb, model) and default databases (pubs and northwind) in the SQL Server data directory so that the SQL Server service can be started.

To rebuild the master database

  1. Shut down Microsoft SQL Server 2000, and then run Rebuildm.exe. This is located in the Program Files\Microsoft SQL Server\80\Tools\Binn directory.

    If you use the SQL Server installation compact disc, copy all the files from the compact disc to a local hard drive. Remove the read-only attribute from the files after you copy them to the hard drive. For more information, see the following article in the Microsoft Knowledge Base: "273572 BUG: Rebuildm.exe Utility Stops Responding When Source Directory is on a CD." You will then need to execute Rebuildm.exe and point it either to the original shared installation files or to the files that you copied from the compact disc to the local hard drive.

  2. In the Rebuild Master dialog box, click Browse.

  3. In the Browse for Folder dialog box, select the \Data folder on the SQL Server 2000 compact disc or in the shared network directory from which SQL Server 2000 was installed, and then click OK.

  4. Click Settings. In the Collation Settings dialog box, verify or change settings used for the master database and all other databases.

  5. Initially, the default collation settings are shown, but these may not match the collation selected during setup. You can select the same settings used during setup or select new collation settings. When done, click OK.

  6. In the Rebuild Master dialog box, click Rebuild to start the process. The Rebuild Master utility reinstalls the master database. To carry out this procedure, you may need to stop a server that is running on this computer.

Rebuilding the Master Database on a Virtual (Clustered) SQL Server 2000 Server

To rebuild the master SQL Server 2000 database, perform the following steps:

  1. Make sure that the node in which you execute Rebuildm.exe is controlling the SQL Server resources.

  2. Use the SQL Server service manager Bring the SQL Server virtual server offline by using.

  3. Make sure that the original shared installation files or the SQL Server installation compact disc is available. If you use the SQL Server installation compact disc, copy all the files from the compact disc to a local hard drive. Remove the read-only attribute from the files after you copy them to the hard drive. For more information, see the following article in the Microsoft Knowledge Base: 273572 BUG: Rebuildm.exe Utility Stops Responding When Source Directory is on a CD. Run Rebuildm.exe and point it to the original shared installation files or the files that you copied from the compact disc to the local hard drive.

  4. Select Windows Collation or SQL Collation.

  5. After the Rebuildm.exe program completes, verify that you can bring the resources online and that they successfully fail over.

  6. Execute the sp_helpsort stored procedure to verify the collation.

Note: The preceding procedure does not include the steps that are necessary to rebuild user databases. If you have a recent backup of the master database, you may restore it at this point. If not, you must restore or attach the user databases.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft