2 Checksum Support Configuration

You configure checksum support through the DIVArchive Configuration Utility using the Engineer login. The following sections describe each option and how to adjust the settings.

Global Checksum Parameters

You access the global checksum parameters under the Manager Settings tab in the Configuration Utility using the Engineer login. Each of the global parameters affects all checksum support settings throughout the system. The following are the global parameter descriptions.

Manager: Default Checksum type

There are several checksum algorithms available on the system including MD2, MD5, SHA, SHA-1, MDC2, and RIPEMD160. The MD5 algorithm is the default checksum for the DIVArchive system. To change the Default Checksum Type in use, select the desired default checksum type from the Default Checksum Type list.

Manager: Number of retries following failed checksum

This parameter sets the number of times the system will retry the operation after a failed checksum. The default (and recommended) setting is one retry after a checksum failure. Enter the number of retries allowable for your data and system in the Number of retries following failed checksum field.

Note:

A checksum error should be an extremely rare event, and typically indicate an issue with the hardware or the network.
Manager: Select different drive per retry on failed checksum

This parameter distinguishes whether the retry (after a failed checksum) will be attempted on the same drive (option deselected) or if the system should try the operation using a different drive (option selected). The default setting for this parameter uses the same drive (deselected).

General Checksum Configuration

There are two aspects to the general checksum configuration. The configuration procedures described below are samples provided for your convenience. Actual procedures may vary depending on your software release. Refer to the applicable product documentation for more details.

DIVArchive Configuration

Use the following procedure to configure DIVArchive:

  1. Add the Source/Destination declared in the DFM configuration file.

  2. Add the Storage Media Name declared in the DFM configuration file.

  3. The source must be pointing to the FTP server.

  4. The source must be configured with the following options:

    • Checksum Type must be set to SHA1

    • GC_Mode must be set to MDF_XML

DFM Configuration

You must install and preconfigure DFM according to the Oracle DIVArchive DFM User's Guide. Use the following procedure to configure DFM to monitor the specific folder.

When DFM is used in a Linux environment to monitor an FTP folder, it must be configured as in the following example: User: diva

User Home Directory: /ifs

Folder to be Monitored: /ifs/folder1

Correct DFM Configuration: ftp://diva:password@host_ip/folder1

Incorrect DFM Configuration: ftp://diva:password@host_ip/ifs/folder1

In the DFM configuration file, configure a Single type folder to point to the folder.

<folderConfig>
  <!-- Folder URL. -->
  <url>ftp://diva:diva@172.16.3.47/</url>
  <type>single</type>
  <priority>30</priority>
  <mdfConfigPriority>Primary</mdfConfigPriority>
  <categoryName>dfm_sd</categoryName>
  <incompleteThreshold>86400</incompleteThreshold>
  <sourceDestinationDIVAName>dfm_sd</sourceDestinationDIVAName>
  <archiveFilePathTemplate platform="DETECT"
   options="">URL_TO_FILE</archiveFilePathTemplate>
  <archiveFileNameTemplate platform="DETECT" 
   options="">filename.ext</archiveFileNameTemplate>
  <divaMediaName>array_01</divaMediaName>
  <fileFilter type="exclude">
  <mask>*.XML</mask>
  </fileFilter>
  <deleteBeforeArchive>TRUE</deleteBeforeArchive>
</folderConfig>

The following significant parameters in the above example are described as:

<url>

The FTP connection details.

<type>

The type of folder DFM is monitoring (Single or File Set).

<SourceDestinationDIVAName>

The name of the source used when DFM submits the archive request to the Manager.

<divaMediaName>

The name of the media that DFM will submit the archive request to.

<fileFilter>

Prevents DFM from archiving the metadata XML file.

Source/Destination Checksum Configuration

You change the checksum support configuration for Source/Destinations on the System tab in the Configuration Utility using the following procedure:

  1. Navigate to the System tab in the Configuration Utility.

  2. Double-click the Source or Destination for which checksum configuration is required (on the right side of the screen).

  3. The Edit Sources and Destinations Entry dialog box appears with several checksum support options. These options are mainly associated with the Genuine Checksum type.

    The Genuine Checksum Source must be used (Yes) for the system to read the checksum from the external source providing the file. This initiates a real-time checksum calculation to compare the checksums and verify the initial transfer.

  4. Select the desired Checksum Type using the provided list - all supported checksum types are listed.

    The Genuine Checksum is only used for the first verification. The selected Checksum Type is only used once and then discarded. Beyond the initial use of the selected Checksum Type (after the transfer), the default type is used. The Checksum Type and GC Mode must match the settings implemented at the source.

  5. Select the desired Genuine Checksum Mode from the list. This selection tells the Actor the format of the files containing the checksum data. Available options are MDF_XML, TEXT and AXF.

    • When Verify Following Archive (VFA) is turned on (selected), performing the initial transfer from the source results in a read-back operation and therefore the data is being read twice for verification. After the data is read twice, the two checksums are compared. If they are the same then verification is successful, if not identical then verification fails.

      Verify Following Archive is not compatible with Genuine Checksum or complex objects. There is no need to use VFA when GC is being used because the checksum is already verified. The Genuine Checksum must be turned off to gain access to the VFA check box. If GC is turned on, the VFA check box will be grayed out and not selectable.

    • When Verify Following Restore (VFR) is turned on (selected), performing the final transfer to the destination results in a read-back operation where the data is being read twice for verification. A checksum is calculated during the read-back and compared to the checksum attached to the stored data. Verification is successful if they match, if they are not identical then verification fails. The setting of GC has no bearing on the VFR setting.

      Note:

      Verify Following Restore is not compatible with complex objects or the -axf option.

      Verify Following Restore was designed to read back the restored content from a video server to confirm it is not corrupt. Using the -axf option does not create a checksum-verifiable restore. It creates an object export that is encompassed in an AXF Wrapper (container). VFR and -axf are mutually exclusive and should not be part of the same workflow.

  6. Click OK to complete the process.

Array and Disk Checksum Configuration

The Verify Write (VW) functionality can be turned on or off either on an array basis, or disk by disk. VW applies when you write to the final storage location in DIVArchive. When turned on, the system will perform a read-back of what was just written and compare the checksum calculated during the read-back to the checksum attached to the incoming data.

The Verify Write (VW) column indicates whether the Verify Write function is on or off for the particular array and disk. The default setting is off. If there is nothing defined in the Disk VW column, the system will use the setting defined in the Array VW column.

Use the following procedure to change the Checksum Support configuration in the Configuration Utility to override the setting defined in the Array VW column for a specific disk:

  1. Navigate to the Disks tab in the Configuration Utility.

  2. Select the disk to configure, and then click Edit located just above the Disk VW column. The Edit Disks Entry dialog box appears.

  3. When the dialog box appears, use the Verify Write list to select ON, OFF, or NONE (the blank selection). If NONE is selected, the Verify Write will use the setting identified in the array for this particular disk.

  4. Click OK to complete the process.

The selection made in the Edit Disks Entry dialog box is reflected in the Disks VW column.

Group Checksum Configuration

You configure Verify Write (configurable by Groups) in the VW column in the Configuration Utility using the following procedure:

  1. Navigate to the Groups area of the Sets, Groups & Media Mapping tab in the Configuration Utility.

  2. Select the Group to configure.

  3. Click Edit and select ON or OFF using the Verify Write list.

  4. Click OK to complete the process.

The selection made will be reflected in the VW column on the Groups display area. When writing a file to a particular group, the setting for that group will be applied to the file. The default setting for Groups is off.

Actor Checksum Configuration

This setting defines if the Actor is automatically selected for the Verify Tape workflow. All Actors are included by default, however you can exclude specific Actors as necessary (see Appendix A for Oracle DIVArchive options and licensing information.). You configure Verify Tape for Actors in the Configuration Utility using the following procedure:

  1. Navigate to the Actors area under the System tab.

  2. Select the Actor to configure.

  3. Click Edit and select Yes (Y) or No (N) using the Verify Tape list.

  4. Click OK to complete the process.

Genuine Checksum Configuration

Genuine Checksums are passed to DIVArchive using an XML Metadata file. When the Actor is instructed to read a file using an Source/Destination configured for GC, the Actor generates checksums according to the configuration. These values, and the values obtained from the metadata file, will be transferred to the Manager for comparison.

For example, for a file named sample.abc, the metadata file name and structure are in an XML-formatted file with the following parameters (as a minimum):

<DIVAObjectDefinition>
  <objectName>sample</objectName>
  <fileList>
    <file checksumType="SHA1"
       checksumValue="9F097AAEEF48C4A170D95AAF6161790662626802">
       sample.abc
    </file>
    </fileList>
</DIVAObjectDefinition>

The resulting metadata file name will be sample.abc.xml.