This chapter describes the tape exporting and importing procedures, and includes the following information:
See Appendix B for Oracle DIVArchive options and licensing information.
Starting with the DIVArchive 7.6 release, tape drive encryption supports secure bulk tape migration between DIVArchive systems.
After enabling encryption on a tape group, all additional tapes added to the group will also be encrypted. However, any existing tapes in the group remain unencrypted if encryption was previously disabled.
Enabling encryption on a tape group generates an encryption key, which is also encrypted. You can change the encryption key at any time from the Configuration Utility. Updating the encryption generates a new key.
New tapes added to the group after the change will use the new encryption key. The existing tapes that were already encrypted will continue to use the original key. Therefore, tapes in the same tape group can have different encryption keys. You must notify the Manager of the change when updating the encryption key.
Disabling encryption (after it is already enabled) only affects additional tapes added to the group, and the existing tapes remain encrypted.
You can view the encryption status of the tape on the Home, Tapes screen in the Control GUI.
See the Oracle DIVArchive Installation and Configuration Guide in the Oracle DIVArchive 7.6 Core documentation library for detailed configuration information.
Tape compression is supported at the tape group level, and configured in the Configuration Utility.
When tape compression is enabled, any empty tape assigned to the group will have compression enabled, and instances written to the tape will be compressed. Tapes assigned to the group before compression was enabled remain uncompressed, and instances written to the uncompressed tape will be uncompressed.
When exporting a tape, compression is tracked using the new isCompressionEnabled attribute. This attribute value can be either true or false.
To view all tapes with compression enabled, you must select the Home, Tapes icon in the Control GUI, and set the Compression filter to Y.
You can now export and import tapes through the Java API, and also in the Java Initiator. The following is sample output from the export and import of a single encrypted tape using the Java Initiator.
DIVArchive JInitiator - Using JavaAPI Version : 8.0 SNAPSHOT 0 = Exit 1 = Connect 2 = Archive object 3 = Copy to New object 4 = Copy to Group (new instance) 5 = Associative Copy 6 = Delete Object 7 = Delete Instance 8 = Delete File 9 = Delete File For Category Mask 10 = Restore Object 11 = Restore Instance 12 = N - Restore 13 = Partial Restore 14 = TranscodeArchive 15 = Transfer 16 = Insert tape 17 = Eject tape 18 = Cancel Request 19 = Change Priority 20 = Get Request Information 21 = Get Partial Restore Request Information 22 = Get Finished Request List 23 = Get Object Info 24 = Get Tape Info 25 = Get Object Details List 26 = Get Files and Folder Names for Object 27 = Get Array List 28 = Get Source/Destination List 29 = Get Tape Group List 30 = Add Tape Group 31 = Delete Tape Group 32 = Require Instance 33 = Release Instance 34 = Get Storage Plan Names List 35 = Get Object List By File Name 36 = Get Archive System Information 37 = Lock Object 38 = Unlock Object 39 = Link Objects 40 = Enable Automatic Repack 41 = Export Tapes 42 = Import Tapes 100= close connection Enter a command number : 41 *** exportTapes *** Specify the Tape barcodes. Barcode 1 <1S0009>: 3L2247 Add another? <N>: Comment <>: Set delete from database (Y/N) <Y>: Priority <-1>: --- Export Tapes --- Tapes 3L2247 Comment: Delete from database: true Priority: -1 Submit[S] or Submit and Wait[W] <S>: Status: Running Request ID: 20272 Success Press Enter to continue. Request 20272 has completed successfully DIVArchive JInitiator - Using JavaAPI Version : 8.0 SNAPSHOT 0 = Exit 1 = Connect 2 = Archive object 3 = Copy to New object 4 = Copy to Group (new instance) 5 = Associative Copy 6 = Delete Object 7 = Delete Instance 8 = Delete File 9 = Delete File For Category Mask 10 = Restore Object 11 = Restore Instance 12 = N - Restore 13 = Partial Restore 14 = TranscodeArchive 15 = Transfer 16 = Insert tape 17 = Eject tape 18 = Cancel Request 19 = Change Priority 20 = Get Request Information 21 = Get Partial Restore Request Information 22 = Get Finished Request List 23 = Get Object Info 24 = Get Tape Info 25 = Get Object Details List 26 = Get Files and Folder Names for Object 27 = Get Array List 28 = Get Source/Destination List 29 = Get Tape Group List 30 = Add Tape Group 31 = Delete Tape Group 32 = Require Instance 33 = Release Instance 34 = Get Storage Plan Names List 35 = Get Object List By File Name 36 = Get Archive System Information 37 = Lock Object 38 = Unlock Object 39 = Link Objects 40 = Enable Automatic Repack 41 = Export Tapes 42 = Import Tapes 100= close connection Enter a command number : 42 *** importTapes *** Specify the file or directories to import File 1 <>: D:\workspace\Manager\bin\exported\2017-04-04--17.28.57 Add another file? <N>: Group name <>: default Skip Object import if already exists in database (Y/N) <N>: Add as instance if the object already exists in database (Y/N) <N>: --- Import Tapes --- Files and Directories D:\workspace\Manager\bin\exported\2017-04-04--17.28.57 Group name: default Continue? <Y>: ---------- Response ---------- Success Press Enter to continue.
The Export Tapes function enables one or more tapes containing DIVArchive objects to be exported for use in another independent DIVArchive system (for example at a remote disaster recovery or partner site).
The metadata of each tape for non-complex objects are maintained in the DIVArchive database. The metadata of each tape is saved to an XML file when the tape(s) are exported and used to transfer the metadata to the other DIVArchive system's database during the import operation.
The metadata for complex objects is maintained in both the DIVArchive database and the metadata database. When an export request is initiated, the Export Utility creates an additional plain text file and assigns a .ffm extension to the file.
The export feature checks to see if any of the selected tapes contain objects that span onto other tapes. If so, these tapes are included in a menu so that they can also be exported. These spanned tapes must be selected to export the original list of tapes.
The Export Tapes command is not used for transferring tapes between two or more libraries controlled by the same Oracle DIVArchive Manager (see Appendix B for Oracle DIVArchive options and licensing information). To transfer tapes between libraries under the same DIVArchive Manager's control, you use the Eject command, move the tape to the desired library, and then execute an Insert Tape command.
The default action in the export feature removes the tape metadata from the DIVArchive database after the export. In this case, if an object being exported is the last (or only) instance of the object, it will be removed entirely from the database. However, the object metadata can be left in the original DIVArchive database if desired.
Ejected tapes can also be exported. Ejecting tapes before exporting them is the recommended method when the number of tapes to be exported exceeds the robotic tape library selected CAP (Cartridge Access Port) size.
The media type (Write-Once or not) and whether the media is a cartridge or not is identified in the exported XML file and also imported during an Export/Import operation. The new attributes of the tape element are isWriteOnce and isCatridge each with a value of either true or false.
Tape export limits are configured in the manager.conf configuration file. There are several configurable parameters as described in the following table.
Table 2-1 Tape Export Limitation Parameters
| Parameter | Definition | Limits |
|---|---|---|
|
|
The maximum number of tapes allowed in an export request. Reloadable in SERVICE mode. |
The range of possible values is
|
|
|
The maximum number of elements allowed in an export request. Reloadable in SERVICE mode. |
The range of possible values is
|
Oracle highly recommends:
Only performing one export operation at a time. You risk data loss if more than one export operation is running simultaneously.
Not performing large exports during peak periods. System performance will be decreased during large exports.
Delete and repack actions do not clear WORM drives as these are Write-Once Media. The instances are deleted but the space is not recoverable.
An encryption key hash and salt are generated during the export of encrypted tapes. This key hash and key salt are stored in the metadata file. The export process optionally generates a new password protected Keystore file in the same folder as the metadata file. You configure this setting on the Manager Settings tab in the Configuration Utility. You must be in Engineering mode to access the setting.
The Keystore file contains information used to import encrypted tapes.
Note:
A valid Keystore password is required to export encrypted tapes. See the following section for information.You can verify the integrity of the Keystore file using the Java keytool. See https://docs.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html for details on Java's keytool.
The Keystore password is set in the Configuration Utility in the Manager Configuration view. You enter the Keystore password in the Export: Tape Encryption Keystore Password field. The password must be at least eight characters and contain at least one digit, at least one lowercase alphabetic character, at least one upper case alphabetic character, and at least one special character within a set of special chars (!@#%$^).
You enable exporting encryption keys by selecting the Export: Enable Export of Encryption Keys check box. Exporting encryption keys is disabled by default. You must be in Engineering mode to view or edit both settings.
The following table describes the export metadata parameters.
Table 2-2 Export Metadata Parameters
| Parameter | XML Element and Attribute | Notes |
|---|---|---|
|
|
Attribute of the object element |
Not imported - A new Object ID is generated during import. |
|
|
Attribute of the object element |
Imported if present, otherwise a new UUID will be generated. |
|
|
Attribute of the object element and attribute of the tape element |
|
|
|
Attribute of the object element |
|
|
|
Attribute of the object element |
|
|
|
Attribute of the object element |
|
|
|
Attribute of the element's element |
If exists in the database |
|
|
Attribute of the element's element |
If exists in the database |
|
|
Attribute of the element's element |
If exists in the database |
|
|
Attribute of the element's element |
If exists in the database |
|
|
Element |
Valid for complex objects |
|
|
Element |
Valid for complex objects |
|
|
Element |
Not valid for complex objects |
|
|
Attribute of the component element |
The fully qualified path of Element ID values for a file or an empty folder's fully qualified path. |
|
|
Attribute of the component element |
Represents the type of object component:
Components of non-complex objects created before the 7.4 release default to |
When tapes are exported from the DIVArchive system, DIVArchive writes each tape's metadata to a .xml file. DIVArchive generates an additional .ffm file for each exported complex object. If an object is spanned across two (or more) tapes, the XML file will encompass every tape included in the spanned set. The naming format of each tape metadata XML file is Tapeset-<Barcode>.xml (for example Tapeset-000131.xml).
The Root Path where the XML files are saved is defined by the DIVAMANAGER_EXPORT_ROOT_DIR parameter in the DIVArchive Manager configuration file. By default the export absolute folder Root Path is DIVA_HOME\Program\Manager\bin\exported\.
From this Root Path the .xml and .ffm files (if complex objects exist) from each Export Tapes command are saved in sub-directories based on the date and time the command was run.
The .ffm file contains file and folder information for complex objects. The .ffm files are referenced from within the specified .xml file and are named using the Object Name and Object Category of the exported object. This file must exist in the same directory as the .xml file when importing. The Import Utility will look for them both in the same location. If the file is missing, the import process will terminate and an error message will be written to the log file.
Caution:
When using complex objects, the FFM files must be in the same folder as the XML files for importing. If the FFM files are not found the import process will terminate and an error will be written to the log file.The Export Tape request is initiated using the Export Tape button on the GUI ribbon bar, or the Tapes view in the Home tab by right-clicking the tape to export and selecting Export Tape from the resulting menu. When selecting the tapes for export, it is possible to see more tapes available in the tape window than initially selected. If a tape has objects that are spanned onto another tape, these tapes are also included. In this case, select all of the spanned tapes from this list for the export to succeed. See Appendix B for Oracle DIVArchive options and licensing information.
Use the following procedure to export tapes:
Highlight and then right-click the tapes desired for export.
Select Export Tape from the context menu to begin the export process.
The Export Tape dialog box will appear showing information about the selected tapes and options for the export process. The available options include:
Enter any comments desired in the text box. They will be stored in the request's properties.
If checked, the barcodes, tapes, and object instances stored on those tapes will be deleted from the DIVArchive database upon completion of the export. This parameter is set to true by default.
If tapes or object instances are needed in the system again after they have been exported, you must import them because this option removes them from the system's database.
This area identifies which tapes were selected from the Control GUI for export, if the tape has the original barcode, and if it can be removed from the export operation. For example, if a tape is part of a tape set (rather than a single tape), the Can Be Removed column would indicate No for that tape because it is required to complete the export successfully.
Removes the highlighted tapes in the Exported Tapes area from the export process.
After all options have been set and verified, click OK to begin the tape export.
This is a multi-step process. If a set of tapes was selected that includes another spanned tape, the GUI will display re-selection dialogs enabling selection of additional tapes in the set.
When the OK button is clicked, the export process begins. This results in a .xml (and possibly .ffm files) being created in the export folder. The XML and FFM files contain all of the information concerning the objects on the tape(s) being exported.
When the export is complete, a good practice is to compress all of the resulting files into a .zip file. You must include all of the files because they are required for the import process to complete successfully.
DIVArchive 7.6 internally splits an export request into smaller exports consisting of no more than 100 tapes and 1 million tape elements. This process enables DIVArchive to accept a larger number of tapes and tape elements than can be handled by earlier DIVArchive releases.
The number of tapes an export request is split into will always be 100, and the number of tape elements will always be 1 million. These values are adjustable.
For example, if you set the maximum number of tapes value to 3, the resulting export is split into smaller exports each including no more than three tapes. Each internal export generates a single XML file. All files are output to the same directory.
Importing tapes to be used in restore operations is a two-step process. First, the metadata that describes the tape objects is imported using the importtapes command line utility. Once the metadata has been successfully loaded, the physical tapes can be inserted into the tape library using the Insert function in the DIVArchive Control GUI.
Note:
Multiple simultaneous import operations are enabled, but not recommended.To use the importtapes command you must first ensure that the exported XML metadata file and the .ffm files exist on the destination DIVArchive System. The files must exist in uncompressed form in the DIVArchive Manager's bin directory (by default). Also, the Object Tape Group must already exist on the target system before the import begins. This tape group does not necessarily have to be the same group assigned to the tape in the source system. See Appendix B for Oracle DIVArchive options and licensing information.
The three main ways that a tape object can be treated during the import process are as follows:
Imported as a new object
Skipped
Added as an instance of an object already existing in the DIVArchive database
Normally, when a tape object is imported by the utility it is imported as a new DIVArchive object. This can only occur when the Object Name and Object Category for the tape object does not exist in the target DIVArchive system. In the event of a naming conflict, the default behavior is to terminate the import operation without importing any tapes or objects.
When new objects are imported into the target DIVArchive system, the import function only looks at the XML and FFM files and does not read directly from the tape structure. SPM is also automatically notified and if the object matches any of the SPM filters, then SPM will initiate the required actions for the object. See Appendix B for Oracle DIVArchive options and licensing information.
Caution:
You must be careful when skipping objects because the tape object that is skipped may or may not actually be the same as the object in the database. The tape object that had the naming conflict may in fact contain different content than the existing one in the DIVArchive database (content that should be preserved). If a tape is imported and then repacked, objects that were skipped will not be copied to the new tape and the old tape will be reclaimed. If all objects on a tape are skipped (and the tape is made writable), the tape will be marked for deletion and new objects will overwrite existing objects on the tape. If you write new objects to the tape after the last object on tape is skipped, that tape instance will immediately be overwritten.A tape object can be skipped if the -skipIfNameExists flag is passed to the Import Utility. If there is another object already in the DIVArchive database that has the same Object Name and Object Category as a tape object being imported, and the -skipIfNameExists flag is set, the object is skipped. The object instance on the tape is not recorded in the DIVArchive database (it is considered deleted by DIVArchive), and processing continues with the next tape object in the import metadata.
The DIVArchive TapeImport command line utility provides an additional command line switch named -useImportDateAsArchiveDate.
Using this switch during object import causes the date of the imported object to be used as the date of object archival in the system where it is being imported. The original archive date is not replaced in the XML export or on the original DIVArchive system, it is only replaced for the object on the imported system.
This feature supports tapes with spanned objects in the same way as regular tapes.
An object can be imported as an instance of another object if the -addAsInstanceIfNameExists flag is passed to the Import Utility. If there is another object already in the DIVArchive database that has the same Object Name and Object Category as a tape object being imported, and the -addAsInstanceIfNameExists flag is passed, an Import as an Instance is attempted.
First, the checksums for the tape object are compared to the checksums in the database object that matches it. If a match is produced (for each object component), the object is imported as an instance of the matching object. The Comments, Archived Path Root, Archive Date, UUID, Storage Plan, Group, and so on, of the imported object are lost and become that of the object already in the DIVArchive database.
A new Object instance ID is assigned every time the utility imports as an instance.
If the Checksum Type of the object components in the database does not match the Checksum Type in the imported object, or if one of the two objects has checksums that are missing, the tape object is not imported as an instance. This is considered a checksum mismatch and the import processing halts. However, if both the -skipIfNameExists flag and the -addAsInstanceIfNameExists flag are passed to the Import Utility (and a tape object matches one that already exists in the DIVArchive database), the utility first tries to import the object as an instance by comparing checksums. If this attempt fails the object is skipped and processing will continue.
Note:
SPM is not notified when importing as an instance. If the object matches any of the SPM Filters then SPM will not initiate the required actions for the object.If the tape media is not recognized by the Manager an error will be generated specifying what occurred.
If the import process fails and Manager detects a database error, the import process will be terminated and any operations performed during the failed import will be rolled back and not saved in the system.
In the case where the checksum comparison failed (or the checksum is not present) for one or several objects, the entire import process will be stopped and the database transaction will be rolled back.
If the -skipIfNameExists flag is used, the checksum verification will still execute. However in this case an unverified (mismatched) object will be skipped instead of stopping the entire import process.
All errors are displayed on the screen and written to the log file. When using the -skipIfNameExists flag, you must check the screen messages and log file to determine whether all content intended to be imported was processed successfully. This option is not compatible with automated workflows since it may require operator intervention and decision.
Complex objects that are compared this way must have been archived in the same exact order to pass the checksum verification.
The Import Utility does not compare UUID, Object ID, Archive Dates, or Site ID. The Comments, Archived Path Root, Archive Date, UUID, Storage Plan, Group, and so on, of the imported object are not preserved when being added as an instance.
The utility does not enable the import of a set of tapes that contain an object with more than one instance on the tapes. An import metadata file having an object with more than one instance appearing within an exported tape set is not allowed. The export utility prevents this from happening.
You only specify the destination group, and the folder containing the xml metadata file and the optional Keystore file to import encrypted tapes.
If a Keystore file is not present in the export folder, and you are attempting to import encrypted tapes, the tape encryption key for every tape must match the encryption key of the destination group.
If the Keystore file is present in the export folder, it will be opened using the password in the Manager Configuration panel of the new system, and therefore the password must match. If it does not match, you will be asked one time for the Keystore password before failing the import. During the import the encryption keys will be compared to the encryption key hash and salt to validate the keys. If any key is not valid, the import will terminate.
Example:
Importer default D:\workspace\Manager\bin\exported\2017-03-25--10.37.14 =========================================================================== DIVArchive Version cannot be obtained because the DIVArchive version file is missing from the DIVA home directory. DIVArchive Tape Importer Copyright (c) 1999, 2017 Oracle and/or its affiliates. All rights reserved. All rights reserved. =========================================================================== The import completed successfully. (Code 0)
After inserting all tapes into the new system in the default group, you can disable the Tape Protection Setting for all tapes. You change the setting on the Inserted Protected Tapes panel in the Configuration Utility, Select all tapes, click Edit, change the setting, and then click OK.
Example:
Importer default "D:\workspace\Manager\bin\exported\2017-03-28--11.04.31" =========================================================================== DIVArchive Version cannot be obtained because the DIVArchive version file is missing from the DIVA home directory. DIVArchive Tape Importer Copyright (c) 1999, 2017 Oracle and/or its affiliates. All rights reserved. All rights reserved. =========================================================================== The import completed successfully. (Code 0)
Importing of tapes is accomplished using a combination of the Windows command-line interface and the DIVArchive Control GUI. Inserting the tape is an optional part of the workflow but is necessary to access the objects on the tape. It is possible to run the importtape command line utility to enter the tape's metadata into the DIVArchive database and still keep the tape externalized. However, to access the objects on the tape, the tape must be inserted using the DIVArchive insert tape function.
The following procedure is used for importing tapes into DIVArchive:
Open a Windows command-line interface.
Copy the exported XML and FFM Files into the DIVA_HOME\Manager\bin folder.
Change to the DIVA_HOME\Manager\bin folder.
Run the importtape command using any of the following necessary command line options:
help (-h)Displays help information.
groupnameThe tape group to which imported tapes will belong. The group must already exist in the system.
mfiledirThe XML file containing exported tape metadata, or a folder that contains the files.
-skipIfNameExistsSkip import of objects with naming conflicts. The default behavior is that if the Object Name and Object Category already exist, the utility will terminate without importing the tape(s). Using this option in the command line will override the default.
-addAsInstanceIfNameExistsAttempt to add the tape object as an instance of an existing object in the DIVArchive database. The tape object must have the same Object Name and Object Category, components, and checksums as the object in the database.
-useImportDateAsArchiveDateChanges the imported object's original archive date to the date of import on the destination system. This does not change the original archive date in the exported XML file or in the original system where the object was exported from, only on the system where the object was imported.
In the DIVArchive Control GUI, navigate to the Home tab, and then click the Tapes button to show the list of tapes identified in the system through the Tapes panel. Imported tapes can be left externalized, but to restore the objects on a tape it must be inserted into the library.
Highlight the desired tape (or tapes) and then navigate to the Action tab on the ribbon bar and click Insert Tape to open the Insert Tape dialog box.
If the object's instance must preexist in the database before the tape is inserted, select the check box Require instances on tape(s). Otherwise leave it deselected.
Select the appropriate Robot Manager Name using the menu list.
An error is displayed if no Robot Manager is selected.
Select the appropriate CAP ID using the menu list.
An error is displayed if no CAP ID is selected.
Use the slide control to select the priority value for the insert operation.
Restoration of the objects on the imported tapes is possible after the tapes are inserted.
The tape with barcode number 000131 also contains objects that are spanned across the tape with a barcode of 000120. When tape 000131 is exported, its exported XML File is named Tapeset-000131.xml. This XML file also includes the objects from tape 000120, and both tapes 000131 and 000120 will be ejected from the library. After all objects from both tapes are exported to the XML file, all instances on each tape and references to the tapes themselves are removed from the DIVArchive database.
The XML file is then copied to the DIVA_HOME\Program\Manager\bin folder of the target DIVArchive system. The command importtapes MOVIES Tapeset-000131.xml results in the metadata for this tape being imported into the group MOVIES.
When the tape's metadata has been successfully imported to the database (check the Control GUI Current Requests queue), both of the tapes and their objects are considered externalized and can then both be entered into the library with the Insert Tape command.
Importing of WORM Media is supported by DIVArchive 7.4 and later. However, when you import DIVArchive 7.4 (or later) WORM media into a DIVArchive release earlier than DIVArchive 7.4, DIVArchive ignores the WORM flag (set to false) and logs it in the Manager log. The device will be seen in the Control GUI as a tape but not usable if finalized or no WORM drive is connected to the system.