| Sun StorEdge SAM-FS Storage and Archive Management Guide |    
|
| Sun StorEdge SAM-FS Storage and Archive Management Guide |
|
| C H A P T E R 7 |
|
Using the Sun SAM-Remote Software |
The Sun SAM-Remote client and the Sun SAM-Remote server form a client/server implementation that enables libraries and other removable media devices to be shared between Sun StorEdge SAM-FS host systems. Sun SAM-Remote enables you to configure multiple storage clients that archive and stage files from a centralized tape library or magneto-optical library. For example, if you have host systems on a network that spans a large geographical area, files created in one city can be archived to cartridges in a library located miles away.
This chapter includes the following sections:
The following topics are covered in this overview:
FIGURE 7-1 shows an environment configured with two Sun SAM-Remote host system servers. Each has two clients.
Sun SAM-Remote software provides the following advantages:
You can configure the Sun SAM-Remote server and clients to provide multiple archive copies between two or more Sun Solaris host systems. For example, you can configure two Solaris systems running Sun StorEdge SAM-FS software as both a Sun SAM-Remote server and a Sun SAM-Remote client to each other. Benefits of this configuration include the ability to create local copies for each server with an additional archive copy of data on the other server. File systems can be shared between servers using standard NFS. In the event of a loss of access to the local library, Sun SAM-Remote software would automatically retrieve file data from the archive copy. Users of both servers would have uninterrupted access to their data, even if their primary storage library were unavailable.
Before attempting to configure a Sun SAM-Remote environment, make sure that your environment includes the following software and hardware:
The storage and archive manager treats cartridges in a remote library no differently from the way it treats cartridges in a local library. The following information, however, indicates the limits of Sun SAM-Remote software:
The Sun SAM-Remote clients interact with the Sun SAM-Remote server using a TCP/IP connection. The network between the Sun SAM-Remote clients can be any network type supported by the Sun Solaris operating environment, such as Ethernet, Fast Ethernet, or Fibre Channel.
FIGURE 7-2 shows Sun SAM-Remote client and Sun SAM-Remote server interactions.
The Sun SAM-Remote server consists of a full-capability Sun StorEdge SAM-FS storage management host and a Sun SAM-Remote server daemon that defines libraries to be shared among the clients. At least one SAM-QFS file system must be configured on the Sun SAM-Remote server.
You define a host system as a Sun SAM-Remote server by adding a line in the server system's /etc/opt/SUNWsamfs/mcf file with an equipment type of ss. You must provide a unique family set name for each server. Up to ten clients can be configured per daemon. To configure more than ten clients, add an additional remote server entry in the mcf file for each ten clients that you want to configure. For more information about the server daemon, see the sam-remote(7) man page.
The Sun SAM-Remote client is a Sun StorEdge SAM-FS host system that establishes a Sun SAM-Remote client daemon containing a number of pseudo-devices.
You define a host system as a Sun SAM-Remote client by adding a line in the client system's /etc/opt/SUNWsamfs/mcf file with an equipment type of sc. For more information about the client daemon, see the sam-remote(7) man page.
A pseudo-device defines a network connection to an actual removable media device on the Sun SAM-Remote server. Pseudo-devices have an equipment type of rd, which is a mnemonic for remote device. You define the pseudo-devices in the Sun SAM-Remote client's /etc/opt/SUNWsamfs/mcf file. The Sun SAM-Remote daemon and pseudo-devices are associated with one particular server.
The Sun SAM-Remote daemon supports an unlimited number of pseudo-devices for each client. The actual number of pseudo-devices to be used by the client is configurable. When determining how many pseudo-devices should be configured per client, think of these devices as the number of simultaneous data transfers that can occur between the client and the server. As more pseudo-devices are defined, the possibility of increasing the total network traffic load increases. It is up to you, the system administrator, to determine the actual number of pseudo-devices needed for the system.
The Sun SAM-Remote server daemon, sam-serverd, listens for the clients on port 1000. You can configure a different port in the Sun Solaris /etc/services directory with a service name of rmtsam. When a Sun SAM-Remote client connects to the Sun SAM-Remote server, the sam-serverd daemon establishes a connection on another port and communicates this port number to that client, using the defined port. The socket size is passed to the client. The socket size is configurable and is described in more detail in the Configuring the Sun SAM-Remote Software.
The Sun SAM-Remote library catalog is a subset of the catalog located on the Sun SAM-Remote server. The client catalog is updated in real time. The slots allotted to a Sun SAM-Remote client catalog are controlled only by the Sun SAM-Remote server.
Upon initialization, the system builds a client catalog and passes it to the Sun SAM-Remote client based on information from the Sun SAM-Remote server catalog file. After the connection between the host and client is established, media available to the client is flagged as available. If the connection between the client and server is lost, the media on the client side is flagged as unavailable. You can view the media availability through the samu(1M) v display. The information that appears in the samu(1M) v display on the client is a subset of that which appears in the v display on the server. It is therefore a good idea to access the media catalog through the samu(1M) v display on Sun SAM-Remote server. For more information about the Sun SAM-Remote server client file, see Configuring the Sun SAM-Remote Software. For information on using the samu(1M) operator utility, see the Sun StorEdge QFS Configuration and Administration Guide.
Changes to the catalog are passed between hosts as necessary. Any changes in the server catalog that involve a media type associated with a client are passed to the client, and the client catalog is updated.
Sun SAM-Remote archive processing is the same as Sun StorEdge SAM-FS archive processing. The Sun SAM-Remote client makes a mount request to be added to the server's mount request table. The client then waits for the server to respond with a message indicating that the media is mounted. Archiving begins when the media is available.
This section explains how to perform an initial configuration of the Sun SAM-Remote server and client software. It includes the following sections:
FIGURE 7-3 depicts the sample configuration used in this chapter's procedures. The examples in this chapter show how to configure a Sun SAM-Remote server called chicago.
The Sun StorEdge SAM-FS file systems on portland and sacramento use chicago as their Sun SAM-Remote server.
The following procedures explain how to configure the Sun SAM-Remote software on a Sun SAM-Remote server and on one or more Sun SAM-Remote clients. These procedures must be performed in the order described in the following sections:
1. To Log In to the Potential Server and Client Hosts
2. To Verify Client and Server Configurations
4. To Define a Sun SAM-Remote Client
5. To Define a Sun SAM-Remote Server in the Server's mcf File
6. To Create the Sun SAM-Remote Server Configuration File
Follow these steps for the potential server and all potential client hosts.
1. Log in to the Sun SAM-Remote server as the superuser.
You must have superuser access to the server system on which the Sun Sun SAM-Remote software is to be installed.
2. Log in to the Sun SAM-Remote clients as the superuser.
You must have superuser access to the client system or systems on which the Sun SAM-Remote software is to be installed.
To ensure that you have the required software levels installed, follow these steps on each system to be configured as part of a Sun SAM-Remote environment.
1. Issue the pkginfo(1M) command with its -l option, and examine the output.
CODE EXAMPLE 7-1 shows sample output from the pkginfo(1M) command.
You must have the same release and revision level of Sun StorEdge SAM-FS software level installed on all client and server hosts to be configured as part of a Sun SAM-Remote environment.
In the example output shown in CODE EXAMPLE 7-1, you can see that the server is running software version 4U0.5, and any systems included in an environment with this server would also have to be running 4U0.5.
2. Issue the showrev(1M) command with its -p option, and examine the output.
CODE EXAMPLE 7-2 shows sample output from the showrev(1M) command.
portland# showrev -p | grep SUNWsamfs Patch: 113546-07 Obsoletes: Requires: Incompatibles: Packages: SUNWsamfs portland# |
You must have the same patch collection installed on all client and server hosts to be configured as part of the Sun SAM-Remote environment.
In the example output shown in CODE EXAMPLE 7-2, you can see that the server is running patch 113546-07, and any systems included in an environment with this server would also have to be running patch 113546-07.
If the information from the pkginfo(1) command reveals that all systems to be included in the Sun SAM-Remote environment are running the same software release level and same patch level, you do not need to do anything.
In contrast, some systems are running earlier versions of the software or patches, you must upgrade all systems to the latest software levels. Using CODE EXAMPLE 7-1 as an example, if you are running a Sun StorEdge SAM-FS version earlier than version 4U0.5 on any system, you must upgrade to at least 4U0.5.
For information about performing software upgrades, see the Sun StorEdge SAM-FS Installation and Upgrade Guide.
1. From the Sun SAM-Remote server, stop the Sun StorEdge SAM-FS functions.
a. Issue the samcmd(1M) command with its idle eq option to idle each removable media drive under the control of the Sun StorEdge SAM-FS software.
For eq, specify the equipment ordinal of the removable media drive being addressed, as defined in the mcf file.
For more information about the samcmd(1M) command, see the samcmd(1M) man page.
Alternatively, you can also idle the drives by using the samu(1M) operator utility. For information on using the samu(1M) operator utility, see the Sun StorEdge QFS Configuration and Administration Guide.
b. Issue the samd(1M) command with its stop option to stop the sam-amld daemon and its child processes.
The samd(1M) command is installed in /opt/SUNWsamfs/sbin.
2. On each client, use vi(1) or another editor to edit the existing Sun StorEdge SAM-FS /etc/opt/SUNWsamfs/mcf file.
The goal of this step is to define the host as a Sun SAM-Remote client. CODE EXAMPLE 7-3 shows the edited mcf file on client portland. The mcf file defines a file system and shows the Sun SAM-Remote client portland being defined to the Sun SAM-Remote server chicago.
In this chapter's example, the same configuration process must be completed for client sacramento. For this system, edit the mcf file and copy the last set of lines from portland's mcf file to sacramento's mcf file. These are the lines that define the host to chicago as a Sun SAM-Remote client.
The mcf entry on the client consists of a single-line entry for the Sun SAM-Remote client and a pseudo-device entry for each device you want to configure. These entries follow the syntax as defined in the mcf(4) man page.
The first set of entries defines a Sun StorEdge QFS file system.
The second set of entries defines the Sun SAM-Remote client, portland, to the Sun SAM-Remote server, chicago. The first line defines the Sun SAM-Remote server itself, as described below.
The last two entries in this mcf file define the Sun SAM-Remote pseudo-devices, as indicated by the rd equipment type. A pseudo-device defines a network connection to an actual device on the Sun SAM-Remote server. Pseudo-device entries are created when the system is rebooted. You can define an unlimited number of pseudo-devices.
The Sun SAM-Remote client's configuration file contains a single-line entry consisting of the name of the Sun SAM-Remote server. As shown in To Edit the mcf Files in Step 2, the full path name of this client configuration file is specified in the client's mcf file.
1. On each client, use vi(1) or another editor to open a file to be known as the Sun SAM-Remote client configuration file.
2. Edit the file and include only the name of the Sun SAM-Remote server.
CODE EXAMPLE 7-4 shows the client configuration file on portland after you have edited it. It points to the Sun SAM-Remote server called chicago.
|
Note - You must have at least one Sun StorEdge SAM-FS file system configured in the mcf file for the Sun SAM-Remote server. |
On the Sun SAM-Remote server, use vi(1) or another editor to edit the existing Sun StorEdge SAM-FS /etc/opt/SUNWsamfs/mcf file.
Suppose you edit the mcf file on server chicago. The resulting file defines a Sun StorEdge QFS file system and also defines chicago as a Sun SAM-Remote server.
CODE EXAMPLE 7-5 shows the mcf file on chicago.
The syntax of entries is described in To Edit the mcf Files.
The Sun SAM-Remote server configuration file defines the disk buffer characteristics and media to be used for each client. Ten clients can be configured per server daemon. If you want to support more clients, you must configure another Sun SAM-Remote server daemon as described previously in To Edit the mcf Files (Step 2) and in To Define a Sun SAM-Remote Client.
1. On the server, use vi(1) or another editor to open a file to be known as the Sun SAM-Remote server configuration file.
2. Write the server configuration file.
CODE EXAMPLE 7-6 shows an example server configuration file, /etc/opt/SUNWsamfs/rmt200, which resides on Sun SAM-Remote server chicago. This file defines clients portland and sacramento.
As CODE EXAMPLE 7-7 shows, a server configuration file consists of multiline entries for each client. A pound character (#) indicates a comment line. Anything to the right of a comment line is ignored.
CODE EXAMPLE 7-7 shows the format for a Sun SAM-Remote server configuration file.
client_name [ parameter1 ] media eq media_type regex [ eq media_type regex ] [. . .] endmedia |
The following steps show how to write the server configuration file.
a. Write the client_name field.
The client_name defines the network name for each client to be served by this invocation of the Sun SAM-Remote daemon. The first character in the client_name must be the first character in the line. The client_name can be specified as either the network name, an IP address, or a fully qualified domain name.
The parameter (if specified) and media specifications following a client_name, and up to the next client definition, are specific to this client. The parameter and media definitions must be indented with white space or tab characters.
b. (Optional) Write the parameter field.
The parameter line is expressed in a keyword = value pair. You can use the parameter field to specify the network block size. The net_block_size parameter specifies the network block size to be used by this client's socket, in kilobytes. The format for this parameter is as follows:
For size, specify an integer from 4 
size 64. The default is 4, which specifies 4096 bytes.
The parameter line must be indented with white space or tab characters
c. Write the media and endmedia keyword fields.
The media and endmedia keywords are required in the server configuration file. They define the media archive volumes that a client can use. These media associations are specified as follows:
media eq media_type (regex) [ eq media_type (regex) ] [. . .] endmedia |
The media and endmedia keywords delimit the media definition area of the Sun SAM-Remote server configuration file. The eq media_type regex lines are the media definition lines. The media definitions must be indented with white space or tab characters. The regex data must be enclosed by parentheses.
The elements of the media type specification are as follows:
The following steps enable archiving and complete the configuration process.
1. Verify the archiver.cmd file on the client.
Depending on your configuration, you might need to perform the following tasks:
2. Issue the samd(1M) command with its start option to start the Sun StorEdge SAM-FS processes on the server and on the clients.
To ensure that the new configuration files on the server and clients are read, you must start or restart your Sun StorEdge SAM-FS software.
Enter the following command on the clients and the server:
For more complete instructions about starting and restarting Sun StorEdge SAM-FS, see the Sun StorEdge SAM-FS Installation and Upgrade Guide.
3. Invoke samu(1M) on the server and the clients.
The goal of this step is to verify the connection between hosts. Use the samu(1M) utility's s and R displays to show the status of Sun SAM-Remote connections. For more information on samu(1M), see the samu(1M) man page or see the Sun StorEdge QFS Configuration and Administration Guide.
CODE EXAMPLE 7-9 shows the samu(1M) status s display on the Sun SAM-Remote client portland. Note the device type sc, which represents the Sun SAM-Remote client. The message below that line indicates that a connection with the server chicago has been established.
CODE EXAMPLE 7-10 shows the samu(1M) status s display on the Sun SAM-Remote server chicago. Note the device type ss, which represents the Sun SAM-Remote server. This display indicates that this system is a Sun SAM-Remote server.
CODE EXAMPLE 7-11 shows the samu(1M) Sun SAM-Remote R display from the Sun SAM-Remote server chicago.
If you have multiple Sun SAM-Remote clients, you can scroll through the clients by pressing the CONTROL-f key sequence.
In CODE EXAMPLE 7-11, the connected client is named portland. The client index field indicates that this client is the zero of a possible 0 through 9 clients defined for this server daemon. The maximum file size, minimum file size, and network block size are listed in bytes. Flags indicate the state of the connection, as shown in TABLE 7-1:
4. From the server, use the samu(1M) utility's v display to ensure that the catalog is available on the clients.
For each client, you should be able to view the available Sun SAM-Remote catalog. From samu(1M), enter the following:
For eq, specify the equipment ordinal of the Sun SAM-Remote client daemon as defined in the mcf file.
CODE EXAMPLE 7-12 shows a samu(1M) display from chicago indicating the volumes that portland can access.
5. From each client, issue the archiver(1M) command and its -A option.
In this step, you verify that archiving is taking place from the client to the server. This command enables a listing to be written from the archiver, including the VSNs from the server. For information about this command, see the archiver(1M) man page.
If files are not archiving, see the Sun StorEdge SAM-FS Troubleshooting Guide.
This section contains information about recycling with Sun SAM-Remote. Sun Microsystems recommends recycling in a Sun SAM-Remote environment only under the very specific circumstances described here.
Because the recycling process involves freeing space on cartridges for more data, it is possible for the recycler to destroy important data on archive cartridges if the recycling process is not configured properly.
|
Note - These restrictions are not enforced by the Sun StorEdge SAM-FS software. |
To avoid data loss, it is essential that you adhere to the following restrictions:
You can prevent accidental recycling of VSNs used by Sun SAM-Remote clients by creating a no_recycle list in the Sun SAM-Remote server's /etc/opt/SUNWsamfs/recycler.cmd file. However, be careful of using the chmed(1M) command's +c option on volumes in a no_recycle list. When you use this command to set the recycling flag (+c) on a volume, that action overrides the no_recycle list in the /etc/opt/SUNWsamfs/recycler.cmd file.
Recycling in a Sun SAM-Remote environment should occur only if the following conditions are present:
The following subsections describe two methods for enabling recycling using a Sun SAM-Remote client and server. The methods are as follows:
The procedures in this section describe one method for enabling recycling in a Sun SAM-Remote environment in which the server is named sky and the client is named zeke.
The server must have Sun SAM-Remote configuration information in its mcf file and in its server configuration file. The following code examples show these files.
CODE EXAMPLE 7-13 shows the mcf file on server sky.
CODE EXAMPLE 7-14 shows the server configuration file on server sky.
The client must have Sun SAM-Remote configuration information in its mcf file and in its client configuration file. The following code examples show these files.
CODE EXAMPLE 7-15 shows the mcf file on client zeke.
CODE EXAMPLE 7-16 shows the client configuration file on client zeke.
# cat /etc/opt/SUNWsamfs/sky # File /etc/opt/SUNWsamfs/sky on Sun SAM-Remote client zeke: sky |
The procedure for configuring the recycling process includes a test for archiving and recycling. Because of the testing period, this procedure can take a day or two to complete, depending on how frequently files are archived and recycled.
1. Read about the recycler in Chapter 6.
Using the recycler in a Sun SAM-Remote environment requires a complete understanding of the steps in the recycling process. If you have not already familiarized yourself with the recycling process, take time now.
2. Make sure that the Sun SAM-Remote client and server are configured properly and that archiving is occurring.
For more information on configuring and verifying your Sun SAM-Remote environment, see Configuring the Sun SAM-Remote Software, which contains detailed information about configuring the Sun SAM-Remote client and server. That procedure includes steps for ensuring that archiving is taking place.
3. Edit the archiver.cmd file on the client system and add recycling directives.
In this example, the recycling is performed by archive set, not by library. The directives specifying that recycling be done by archive set must appear in the archiver.cmd file.
CODE EXAMPLE 7-17 shows the archiver.cmd file on client zeke. This file has been edited to communicate with the recycler.
The directives shown in CODE EXAMPLE 7-17 do the following:
4. Edit the recycler.cmd file on the client and specify a log file to receive recycling log output.
CODE EXAMPLE 7-18 shows the recycler.cmd file on client zeke, which has been edited to specify a recycler log file.
# # This is the /etc/opt/SUNWsamfs/recycler.cmd file # on client zeke. # logfile = /var/opt/SUNWsamfs/log/recycler |
5. Verify that the archiver.cmd file on the server is written to specify recycling by archive set.
When using Sun SAM-Remote, you must specify that recycling be performed on an archive set basis, not by library. The directives specifying that recycling be done by archive set must appear in the archiver.cmd file.
CODE EXAMPLE 7-19 shows the archiver.cmd file on server sky. This file specifies archiving by archive set.
6. Edit the recycler.cmd file on the server.
Modify the file to specify the following items:
CODE EXAMPLE 7-20 shows the recycler.cmd file on server sky, which has been edited to specify a recycler log file.
7. Use the sam-recycler(1M) command to test the recycler on the Sun SAM-Remote client.
Run the recycler on the Sun SAM-Remote client system. This is a test to see if the recycler properly acknowledges the devices and VSNs specified in the configuration files.
This testing is important, because if the recycler detects that the system on which it is running has no archive images on a particular VSN listed in any of that system's catalogs (including the historian catalog), the recycler.sh script can call for the cartridge to be labeled. Labeling a cartridge destroys all data on the cartridge. There is no communication between the Sun SAM-Remote client and the Sun StorEdge SAM-FS servers to inform each side of the presence of archive copies. All such information is provided locally from local Sun StorEdge SAM-FS file systems.
For example, you can use the following command to perform the initial test of the recycler:
The recycler runs and logs its activity to the recycler log file. The recycler log file is defined in the recycler.cmd file. For more information about the sam-recycler(1M) command, see the sam-recycler(1M) man page.
8. Examine the recycler log file.
You are looking for the following message:
CODE EXAMPLE 7-21 shows a sample log file.
9. Issue the sam-recycler(1M) command from the Sun SAM-Remote server to verify that the recycler is not recycling any VSNs reserved for the Sun SAM-Remote client.
The preceding command runs the recycler and writes its activity to the recycler log file. For more information about the sam-recycler(1M) command, see the sam-recycler(1M) man page.
CODE EXAMPLE 7-22 shows a sample recycler log file.
10. Analyze the server and client recycler.log files to choose VSNs that are candidates for recycling.
Toward the end of the recycler.log file is a Status column. VSNs with the following types of status entries in the client log file are candidates for recycling:
In the server log file, the best candidates for recycling are those with a 0 value in the Count, Bytes, and Use columns.
The no-data VSNs are the easiest VSNs to recycle. For these, the Count, Bytes, and Use field values are all 0 (zero).
1. Examine the recycler.log file from the client to see if there are any no-data VSNs.
VSNs 000029 and 000026 from the client zeke can be considered for recycling because they are no-data VSNs, as shown in CODE EXAMPLE 7-23.
2. Examine the recycler.log file from the server and determine if the VSNs you selected from the previous step are represented identically in the server's recycler log file.
You want to verify that there is no active data from the server archived on those VSNs.
CODE EXAMPLE 7-24 shows the data for the no_recycle VSNs in the server's recycler.log file. For VSNs 000029 and 000026, the data in the server's recycler.log file is identical to that in the client's recycler.log file.
3. If no active data from the server is archived on the selected VSNs, use the tplabel(1M) or odlabel(1M) command to relabel the VSNs.
|
Note - This destroys all data on the VSN and reclaims space. |
For example, for tape VSN 000029, use the following command:
When this VSN 000029 is relabeled, you regain 100 percent of the space on that VSN.
If the media had been a magneto-optical disk, you would have used the odlabel(1M) command. For more information on the odlabel(1M) command, see the odlabel(1M) man page.
The VSNs for which a partially full status is reported can also be recycled.
1. Examine the recycler.log file from the client to see if there are any partially full VSNs.
You can consider VSN 000025 from the client, zeke, for recycling because its status is partially full, as shown in CODE EXAMPLE 7-25.
VSN 000025 shows that 6 percent of its space is in use. These are active archive images that must be rearchived before this VSN can be recycled. The following steps in this process show how to ensure that these active archive images are rearchived to another VSN.
2. Examine the recycler.log file from the server side to ensure that no active data from the server is archived on that VSN.
The server's recycler.log file indicates that VSN 000025 is 6 percent free, which is the same percentage that was reported in the client's recycler.log file. The server is not aware of the client's archive images, so it reports that all of the remaining 94 percent is consumed by obsolete archive images.
3. On the server, use the chmed(1M) command with the +c option to rearchive the active files on the VSN.
For more information about the chmed(1M) command, see the chmed(1M) man page.
4. On the client, use the sam-recycler(1M) command to run the recycler again.
This marks each active file to be rearchived to another VSN.
You can do this either by letting the archiver run normally, or by typing :arrun from the samu(1M) utility on the client. For more information about the :arrun command, see the samu(1M) man page.
6. When archiving is complete, issue the sam-recycler(1M) command to rerun the recycler on the client.
This ensures that all active files have been rearchived.
7. If the Count, Bytes, and Use field values are all 0 (zero), use the tplabel(1M) or odlabel(1M) command to relabel the VSN from the server.
For example, for tape VSN 000025, use the following command:
This command relabels the VSN and destroys all data on it. After this VSN is relabeled, you regain 88 percent of the space on this VSN.
If the media had been a magneto-optical disk, you would have used the odlabel(1M) command. For more information about the odlabel(1M) command, see the odlabel(1M) man page.
This section presents another way you can recycle volumes using Sun SAM-remote software.
1. On the Sun SAM-Remote client, issue the sam-recycler(1M) command to determine which volumes are the best candidates for recycling.
2. Analyze the recycler log file.
3. On the Sun SAM-Remote server, issue the chmed(1M) command to set the recycle flag on the selected VSNs.
4. On the Sun SAM-Remote client, issue the sam-recycler(1M) command to recycle the selected VSNs on the Sun SAM-Remote client.
5. Wait until the VSNs being recycled are drained completely of archive images.
The archiver on the client side does this.
6. On the Sun SAM-Remote server, issue the tplabel(1M) or odlabel(1M) command, depending on the archive media, to relabel the volumes.
7. On the Sun SAM-Remote server, clear any flags, such as R or c that prevent the volumes from being used for archiving on the Sun SAM-Remote client.
| Sun StorEdge SAM-FS Storage and Archive Management Guide | 819-4329-10 |
|
Copyright © 2006, Sun Microsystems, Inc. All Rights Reserved.
To Log In to the Potential Server and Client Hosts
