test

Solstice Backup 5.1 Administration Guide

Cloning

Cloning is a process of reproducing complete save sets from a storage volume to a clone volume. You can clone save set data from backups, archives, or migration. You can clone save sets automatically (as part of a backup, archive, or migration operation) or manually at another time.

Use cloning for higher reliability or convenience. For example, you can store clones offsite, send your data to another location, or verify backed-up data.

The cloning operation happens in two steps: first, Backup recovers data from the source volume. Then, Backup writes the data to a clone volume (a volume from a pool of type "clone"). Cloning requires at least two active devices, because one is required for reading the source volume and one is required for writing the new, cloned data. During cloning, the reproduction of data is from source volume to clone volume. Cloning does not involve data stored on the clients or server. Backup allows only one clone of a save set per volume. Therefore, if you specify three clones of a save set, each is written to a separate volume.

Automatic cloning (that is, cloning associated with a scheduled group backup operation) is performed after all backup operations are complete. The savegroup completion report that is issued after a scheduled backup also includes a report of the success or failure of the cloning operation for each save set.

The location of the devices where the clone data is written is determined by the list in the Storage Nodes attribute in the Clients resource for the Backup server. You can add or remove the names of storage nodes and the Backup server at any time, but you cannot have a different list of storage nodes to receive clone data than to receive backup data.

If you want to perform cloning long after a group has finished, you must do the cloning manually, volume by volume, or from the command line using a script in combination with a batch file. If you execute cloning manually, no report is generated.

When you clone data, different capacities of storage media may mean that more or fewer clone volumes are required. The cloning operation leaves traceable information entries in both the client file index and the media database. The capability to track cloned data distinguishes cloning from an operating system or hardware device copy operation.

To initiate cloning for a complete scheduled backup operation, enable cloning as part of the Group configuration. To clone individual save sets or clone single storage volumes, use the Save Set Clone or Volume Clone windows in the nwadmin GUI, or the nsrclone program from the command line.

When you specify that a particular volume be cloned, Backup uses the save sets on the specified volume as the source data.

When you specify a clone of a particular save set, Backup determines whether the save set already has a clone. If multiple clones of a save set exist, clones of save sets on volumes in an autochanger are generally selected as the source data, rather than a volume that requires human intervention to mount. Command line options enable you to specify the precise save set clone to use as the source, if you want.

If you execute a clone operation manually, no completion report is generated. Messages generated by the nsrclone program are displayed in a message window in the administration program's GUI and are also logged to the /nsr/logs/messages Backup message file.

Clone Storage Node Affinity

The link between a client's resource of a storage node and a list of available storage nodes to receive cloned save sets from the storage node client is called "clone storage node affinity." Data is cloned from media that contains the original save sets to media on the specified clone storage node. You define clone storage node affinity in the Clone Storage Nodes attribute, which is found in the Clients resource of a storage node. When you make a change to the Clone Storage Nodes attribute in the Client resource for a storage node client, the changed value is propagated to any additional Clients resources configured for that storage node client.

The Clone Storage Nodes attribute allows you to specify a different network interface for storage nodes that perform cloning operations than the network interface you specify for the storage node's remote device.

The server utilizes the exact hostname you specify in the Clone Storage Nodes attribute, instead of using the hostname prefix for the remote device name configured in the Devices resource.

When a volume is being cloned, the Backup server checks the value of the Clone Storage Nodes attribute for that storage node client. If the Clone Storage Nodes attribute has a null value, then the value listed in the server's Clone Storage Nodes attribute is used. If that list also contains a null value, then the server's Storage Nodes attribute is used.

Compatibility is maintained with the existing clone function which follows the server's Storage Node attribute.

To independently direct clones from each storage node, add the hostname of the storage node you want to receive the directed clones to the Clone Storage Nodes attribute in the Client resource configured for the storage node. The first entry made on the list that has a functional, enabled device is selected to receive the cloned data from the storage node.

To direct clones from all storage nodes to the same destination, leave the Clone Storage Nodes attribute blank for the Clients resources you configure for the storage nodes, and only configure the Backup server's Clone Storage Nodes attribute. This tactic provides a single source of control for clone destination.

The file index and media database entries for the save sets cloned to media on a remote device on a storage node still reside on the Backup server, which enforces the browse and retention policies in the same manner as for any cloned save sets that reside on the media in a device that is locally-attached to the server.

Cloning Versus Duplication of Volumes

When you clone a volume, the volume is not simply duplicated. Each save set on the volume is reproduced completely, which could mean that more or less space is used on the clone volume than on the source volume.

You might prefer to make exact copies (duplicates) of Backup volumes to provide additional disaster recovery protection. This approach, which in UNIX relies on the tcopy command, is not recommended but might serve a specific environment adequately. If you rely on an exact copy command, you must first ensure that the destination volume can hold the number of bytes that are contained in the source Backup volume. In addition, be aware that Backup would have no knowledge of the duplicated volume since the volume is not entered into the server's media database. If you enabled automated media management and you leave the volume in an autochanger managed by Backup, the volume may be considered eligible for relabeling and use during a scheduled backup, because it does not have a valid Backup label.

Similarly, it is possible to make an exact copy of an archive volume. However, the annotation that is associated with each archive save set is information that is stored in the Backup server's media database, not on the volume itself. Therefore, a duplicate volume of the archived save set does not include the annotation. If the entry of the original archive save set is removed from the media database, the annotation that describes it is also removed.

Cloning and Data Tracking Information

The clone operation does not insert entries into the client file index. Cloned save sets are only tracked through the media database. During a clone operation, the location of a cloned save set is added to the existing save set entry in the media database. That is, each save set clone shares the same ssid as the source save set. All characteristics that are true for the source save set are also true for the clone save set. If the source save sets are still browsable, the clone status is also browsable. If the source save sets have passed their browse policies, the clone status is recoverable.

Volumes that belong to a clone pool are also tracked through volume entries in the media database. The fact that all save sets share the same media database save set entry has implications for the following actions, which are executed on a "per save set basis" and not on a "per volume" basis:

Caution - Caution -

If you manually change the mode of a cloned volume to recyc with the intent of reusing a particular clone volume, be aware that the mode of a volume only changes to recyclable when all the save sets on that volume are recyclable. Therefore, when the mode of the volume changes to recyc, you effectively change the status of all save sets on the clone volume to recyc. Because the save sets share the same entry in the media database, there is no distinction between "original" and "clone" save sets. The end result is that all the save sets that reside on the now recyclable volume or on any other volume become candidates for immediate recycling.

To prevent inadvertent loss of data, if you want to reuse a particular clone volume and still protect the instances of a save set that exist on other volumes, first change the mode of the volumes to be protected to man_recyc. This means that Backup cannot automatically recycle the volume. Then, you can safely change the volume that you intend for reuse to mode recyc.

Similarly, if you purge a clone volume, you effectively remove from the client file index all file entries associated with all save sets that reside (in whole or in part) on the particular clone volume.

If you delete a clone volume, the nsrim index management program locates the entry in the media database for each save set that resides on the clone volume. From the entry, the nsrim program marks for deletion the information about the location of one of the save set clones from the entry. This action is performed for each save set entry. In addition, nsrim marks the entry for the particular clone volume (identified by its volume ID number) for deletion from the database.

Cloning Performance

In general, a volume write that occurs as part of a backup operation and a volume write that occurs as part of a cloning operation proceed at the same speed. However, if a clone operation is automatically requested as part of a scheduled backup, you may experience a performance degradation in other scheduled backups that follow. Backup generally attempts to complete one group's scheduled backup before a scheduled backup is initiated for another group. However, Backup considers that a group backup is finished when the backup operations are complete, not when any automatic cloning is complete. Therefore, if another group starts its backup while the previous group's clone operation is underway, you may experience contention for nsrmmd resources or specific volumes. To avoid this problem, you may decide to refrain from automatic cloning and instead initiate a single clone operation by passing a set of ssids to nsrclone as part of a job that runs at a nonpeak time after all backups are complete.

Cloning and Recovery

A clone volume is used for recovery any time Backup attempts to recover a particular save set and either the original save set volume has been deleted or the status of the original save set is marked "suspect."

You can always execute the scanner program on a clone volume to rebuild entries in the client file index, the media database, or both. After you re-create the entries, traditional recovery is available. Refer to the Solstice Backup 5.1 Disaster Recovery Guide for information on how to recover data with the scanner program.