![]() |
![]() |
Use this section to help you audit storage pool volumes for data
integrity.
Task | Required Privilege Class |
---|---|
Audit volumes in storage pools over which they have authority | Restricted storage privilege |
Audit a volume in any storage pool | System privilege, unrestricted storage privilege |
The server database contains information about files on storage pool volumes. If there are inconsistencies between the information in the database about files and the files actually stored in a storage pool volume, users may be unable to access their files.
To ensure that all files are accessible on volumes in a storage pool, audit any volumes you suspect may have problems by using the AUDIT VOLUME command. You have the option of auditing multiple volumes using a time range criteria, or auditing all volumes in a storage pool.
You should audit a volume when the following conditions are true:
If a storage pool has data validation enabled, run an audit for the volumes in the storage pool to have the server validate the data.
When you audit a volume, a background process is started. During the auditing process, the server:
You can specify whether you want the server to correct the database if inconsistencies are detected. Tivoli Storage Manager corrects the database by deleting database records that refer to files on the volume that cannot be accessed. The default is to report inconsistencies that are found (files that cannot be accessed), but to not correct the errors.
If files with read errors are detected, their handling depends on the following:
To display the results of a volume audit after it has completed, use the QUERY ACTLOG command. See Requesting Information from the Activity Log.
For a volume in a primary storage pool, the values for the FIX parameter on an AUDIT VOLUME command have the following effects:
If the AUDIT VOLUME command does not detect a read error in a damaged file, the file state is reset, and the file can be used. For example, if a dirty tape head caused some files to be marked damaged, you can clean the head and then audit the volume to make the files accessible again.
If the AUDIT VOLUME command detects a read error in a file:
If the AUDIT VOLUME command does not detect a read error in a damaged file, the file state is reset, and the file can be used. For example, if a dirty tape head caused some files to be marked damaged, you can clean the head and then audit the volume to make the files accessible again.
For volumes in a copy storage pool, the values for the FIX parameter on an AUDIT VOLUME command have the following effects:
Data validation for storage pools allows the server to validate that data sent to a device during a write operation matches what the server later reads. This is helpful if you have introduced new hardware devices. The validation assures that the data is not corrupt as it moves through the hardware, and then is written to the volume in the storage pool. You can use the DEFINE STGPOOL or UPDATE STGPOOL commands to enable data validation for storage pools.
When you enable data validation for an existing storage pool, the server validates data that is written from that time forward. The server does not validate existing data which was written to the storage pool before data validation was enabled.
When data validation is enabled for storage pools, the server generates a cyclic redundancy check (CRC) value and stores it with the data when it is written to the storage pool. The server validates the data when it audits the volume, by generating a cyclic redundancy check and comparing this value with the CRC value stored with the data. If the CRC values do not match, then the server processes the volume in the same manner as a standard audit volume operation. This process can depend on the following:
See Volumes in a Primary Storage Pool and Volumes in a Copy Storage Pool for details on how the server handles inconsistencies detected during an audit volume process. Check the activity log for details about the audit operation.
The server removes the CRC values before it returns the data to the client node.
Data validation is available for nodes and storage pools. The forms of validation are independent of each other. Figure 70 shows data validation:
You can enable data validation for one or more nodes, storage agents, or storage pools. Figure 70 illustrates data transfer that is eligible for data validation within a Tivoli Storage Manager environment. Your environment may contain some or all of these objects.
Figure 70. Data Transfer Eligible for Data Validation
Table 28 provides information that relates to Figure 70. This information explains the type
of data being transferred and the appropriate command to issue.
Table 28. Setting Data Validation
Numbers in Figure 70 | Where to Set Data Validation | Type of Data Transferred | Command | Command Parameter |
---|---|---|---|---|
(1) | Node Definition | File Data and Metadata | See Note | See Note |
(2) | Node Definition | File Data and Metadata | REGISTER NODE UPDATE NODE | VALIDATEPROTOCOL= ALL or DATAONLY |
(3) | Server Definition (Storage Agent only) | Metadata | DEFINE SERVER UPDATE SERVER | VALIDATEPROTOCOL=ALL |
(4) | Storage Pool Definition Issued on the TSM Server | File Data | DEFINE STGPOOL UPDATE STGPOOL | CRCDATA=YES |
(5) | Storage Pool Definition Issued on the TSM Server | File Data | DEFINE STGPOOL UPDATE STGPOOL | CRCDATA=YES |
Figure 71 is similar to the previous figure, however note that the top section encompassing (1), (2), and (3) is shaded. All three of these data validations are related to the VALIDATEPROTOCOL parameter. What is significant about this validation is that it is active only during the client session. After validation, the client and server discard the CRC values generated in the current session. In contrast to storage pool validation, (4) and (5), which is always active as long as the storage pool CRCDATA setting is equal to YES.
An additional aspect of storage pool validation, that you should understand, is that the validation of data transfer between the storage pool and the storage agent (4) is managed by the storage pool CRCDATA setting defined by the TSM server. So even though the flow of data is between the storage agent and the storage pool, data validation is determined by the TSM server storage pool definition. Therefore, if you always want your storage pool data validated, set your primary storage pool CRCDATA setting to YES.
Figure 71. Protocol Data Validation versus Storage Pool Data Validation
If the network is unstable, you may decide to only enable data validation for nodes. Tivoli Storage Manager generates a cyclic redundancy check when the data is sent over the network to the server. Certain nodes may have more critical data than others and may require the assurance of data validation. When you identify the nodes that require data validation, you can choose to have only the user's data validated or all the data validated. Tivoli Storage Manager validates both the file data and the file metadata when you choose to validate all data. See Validating a Node's Data During a Client Session.
When you enable data validation for a server-to-server exchange or between a storage agent and server, the server must validate all data. You can enable data validation by using the DEFINE SERVER or UPDATE SERVER command. For a server-to-server exchange, see Using Virtual Volumes to Store Data on Another Server for more information. For data that is exchanged between a storage agent and the server, refer to the Tivoli Storage Manager Managed System for SAN Storage Agent User's Guide for the storage agent's operating system.
If the network is fairly stable but your site is perhaps using new hardware devices, you may decide to only enable data validation for storage pools. When the server sends data to the storage pool, the server generates cyclic redundancy checking, and stores the CRC value with the data. The server validates the CRC value when the server audits the volume. Later, you may decide that data validation for storage pools is no longer required after the devices prove to be stable. Refer to Auditing a Storage Pool Volume for more information on data validation for storage pools.
Consider the impact on performance when you decide whether data validation is necessary for storage pools. Data validation impacts performance because the server requires additional CPU overhead to calculate and compare CRC values. This method of validation is independent of validating data during a client session with the server. When you choose to validate storage pool data, there is no performance impact on the client.
If you enable CRC for storage pools on devices that later prove to be stable, you can increase performance by updating the storage pool definition to disable data validation.
The AUDIT VOLUME command has additional parameters that allow you to specify an audit for data written to volumes within a range of days, or to run an audit for a given storage pool.
You can manage when the validation of data in storage pools occurs by scheduling the audit volume operation. You can choose a method suitable to your environment, for example:
To audit a disk volume named SERVER.STORAGE.POOL001, for example, and have only summary messages sent to the activity log and system log, enter:
audit volume server.storage.pool001 quiet=yes
The audit volume process is run in the background, and the server returns an informational message as follows:
+--------------------------------------------------------------------------------+ |ANR2313I Audit Volume NOFIX process started for volume | |SERVER.STORAGE.POOL001 (process id 4). | +--------------------------------------------------------------------------------+
To view the status of the audit volume process, enter:
query process
The following figure displays an example of the report you receive about the audit volume process.
+--------------------------------------------------------------------------------+ | Process Process Description Status | | Number | |-------- ------------------------ --------------------------------------------- | | 4 Audit Volume (Inspect Storage Pool BACKUPPOOL, Volume | | Only) ADSM.STORAGE.POOL001, Files | | Processed: 680, Irretrievable Files | | Found: 0, Partial Files Skipped: 0 | +--------------------------------------------------------------------------------+
To display the results of a volume audit after it has completed, you can issue the QUERY ACTLOG command.
When you audit a sequential storage volume containing files that span multiple volumes, the server selects all associated volumes. The server begins the audit process with the first volume on which the first file resides. For example, Figure 72 shows five volumes defined to ENGBACK2. In this example, File A spans VOL1 and VOL2, and File D spans VOL2, VOL3, VOL4, and VOL5.
Figure 72. Tape Volumes with Files A, B, C, D, and E
If you request that the server audit volume VOL3, the server first accesses volume VOL2, because File D begins at VOL2. When volume VOL2 is accessed, the server only audits File D. It does not audit the other files on this volume.
Because File D spans multiple volumes, the server accesses volumes VOL2, VOL3, VOL4, and VOL5 to ensure that there are no inconsistencies between the database and the storage pool volumes.
For volumes that require manual mount and dismount operations, the audit process can require significant manual intervention.
To audit a single volume in a sequential storage pool, request that the server skip any files that span multiple volumes. This option is useful when the volume you want to audit contains part of a file, the rest of which resides on a different, damaged volume.
For example, to audit only volume VOL5 in the example in Figure 72 and have the server fix any inconsistencies found between the database and the storage volume, enter:
audit volume vol5 fix=yes skippartial=yes
You can limit the audit to volumes that were written in a certain time range. For example, to audit the volumes in storage pool BKPOOL1 for volumes written from March 20, 2002 to March 22, 2002.
audit volume stgpool=bkppool1 fromdate=032002 todate=032202
The server audits all volumes that were written to starting at 12:00:01 a.m. on March 20 and ending at 11:59:59 p.m. on March 22, 2002.
When you use the parameters FROMDATE, TODATE, or both, the server limits the audit to only the sequential media volumes that meet the date criteria, and automatically includes all online disk volumes. When you include the STGPOOL parameter you limit the number of volumes that may include disk volumes.
You can limit the audit to volumes in a specified storage pool. For example, you can audit the volumes in storage pool BKPOOL1 by issuing the following command:
audit volume stgpool=bkppool1
You can define administrative schedules to have the server audit volumes on a regular basis. The following example can be used if your critical users store data in storage pool STPOOL3 and you want all volumes in the storage pool audited every 2 days.
define schedule crcstg1 type=administrative cmd='audit volume stgpool=STPOOL3' active=yes starttime=21:00 period=2
This command will audit all volumes in the STPOOL3 storage pool every two days. The audit operation will begin at 9:00 p.m.