1 Introduction

Caution:

Misconfiguration of SPM may lead to unexpected and disastrous results! Minor edits to slots can lead to catastrophic consequences including the deletion of hundreds of thousands of instances on tape (for example, an incorrect value in a slot's end time), or database corruption (for example, creating a Storage slot while the SPM is running, and changing it to Restore type slot while copy and delete instance actions have already begun processing). Without special training and familiarity with the product, you should always contact Oracle Support before making any changes to SPM. Failure to do so may result in severe damage to the Oracle DIVArchive system or even permanent data loss.

This chapter describes an overview of the SPM (Oracle DIVArchive Storage Plan Manager), and includes the following information:

• Oracle DIVArchive Storage Plan Manager Overview

• New and Enhanced SPM Features and Functionality

• Oracle DIVArchive Object Lifecycle

• Managing the Object Lifecycle

• SPM Slot Types

  • Actions, Action Steps, and Action States

• Managing DIVArchive Watermarks and Arrays

  • Recommended Best Practices for Watermarking

• Storage Plan Manager Workflows

  • Storage Plan Manager Tasks

  • Simple Object Lifecycle Example

  • Retrying SPM Failed Actions and Issue Resolution

  • Action Slot Workflow

  • Storage Slot Workflow

• Recommended Best Practices

  • SPM Configuration

  • Setting Up Tape Groups in DIVArchive

  • Valid Reasons for Creating Multiple Tape Groups

  • Invalid Reasons for Creating Multiple Tape Groups

  • Simple SPM Configuration Example

  • Additional SPM Configuration Examples

Oracle DIVArchive Storage Plan Manager Overview

The SPM (Oracle DIVArchive Storage Plan Manager) software component provides object lifecycle management (interacting with the Oracle DIVArchive Manager), and is typically installed on the same computer as the DIVArchive Manager. For example, an archived object can reside on a specific medium the first day, and migrate (over time) to a different medium according to your established policies and rules. Oracle DIVArchive executes the object lifecycle migration as a background activity by following the rules and policies defined in the corresponding Storage Plan.

See Appendix A for Oracle DIVArchive options and licensing information.

New and Enhanced SPM Features and Functionality

Starting with this DIVArchive release, you can change the status of SPM Failed Actions to COMPLETED by right clicking the action, and then selecting Mark Action COMPLETED from the context menu. See Marking Failed Actions Complete for detailed information.

The SPM service is ported to 64-bit in Windows. The OracleDivaDB_3-0-0_12_1_0_2_0_SE2_Windows_64-bit.zip and later releases no longer include the 32-bit Oracle database client. DIVArchive 7.6 and later in a Windows environment only supports DIVAOracle database package OracleDivaDB_3-0-0_12_1_0_2_0_SE2_Windows_64-bit.zip and later. No previous database package will work with DIVArchive 7.6 and later.

See the Oracle DIVArchive Installation and Configuration Guide in the Oracle DIVArchive Core documentation library for more information on running DIVArchive in a Linux environment, and DIVArchive new and enhanced features and functionality.

Oracle DIVArchive Object Lifecycle

This section describes the steps and processes encompassing the DIVArchive object lifecycle. Along with the standard DIVArchive terminology, Storage Plan Manager has additional terms that require identification. Understanding these additional terms will assist in comprehending the DIVArchive SPM module, the processes involved, and the DIVArchive Object Lifecycle.

See the Glossary for SPM specific terminology.

There are several steps included in the object lifecycle, depicted in the following example figure. You can use SPM to automate this generic object lifecycle.

Managing the Object Lifecycle

DIVArchive can define a storage policy for each object, or group of objects, which enables describing the complete lifecycle of an object, and managing the content migration throughout the lifecycle. Using the Storage Plan Manager, content lifecycle management becomes a background process that is performed automatically.

See Appendix A for Oracle DIVArchive options and licensing information.

You use a Storage Plan to specify the different migrations, and copies of the specified objects, from one media to another according to your defined storage rules and policies.

The SPM component in DIVArchive manages the Storage Plan. The Storage Plan is a way to select the best trade off between cost and performance of the different storage media technologies as a function of the age and access frequency of the object. The Storage Plan feature enables the customization of content lifecycle management.

You can specify rules and policies that include parameters such as:

• The amount of time an object is to be retained on a medium. This interval is called a Slot.

• Where to copy an object when its time has expired on the medium (for example, copy from array to tape after two weeks).

  For example, you can schedule tasks that consume relatively large amounts of system resources during low use periods (for example, between midnight and five am). These tasks are executed within the interval specified in the corresponding slot configuration.

• Time of day (local time) when the action is executed.

• When and where to restore an object.

• When to transcode an object, and where to store the transcoded content.

SPM Slot Types

DIVArchive SPM has a logical workflow as follows:

• A Medium is a combination of defined medium (disk arrays or tape groups) available to SPM.

• Each Storage Plan is associated with one, or more, mediums and contains one, or more, slots.

• Each defined Filter is associated with a Storage Plan.

• Each slot defines one, or more, Actions to be performed.

To create a slot, navigate to the Slots tab in the DIVArchive Configuration Utility and click the + button on the top right side of the screen.

To edit an existing slot, navigate to the Slots tab in the DIVArchive Configuration Utility, and then double-click the slot you want to edit in the Slots panel.

The following is a list of Slot Types and Actions.

Storage Slot

A Storage Slot enables copying of an object, and then deleting the object (if the slot is configured for deletion). Object deletion refers to either a DeleteInstance or DeleteObject process, depending on the SPM configuration, and whether other instances still exist. You can only create and configure Storage Slots on the DIVArchive Configuration Utility Storage Plans tab.

See Simple SPM Configuration Example for information on Storage Slot workflows, and Configuring Storage Slots for information on configuring Storage Slots.

Transcode Archive Slot

A Transcode Archived Slot enables transcoding of an archived object. You create and configure this type of slot using both the DIVArchive Configuration Utility Storage Plans tab, and the SPM Actions tab.

See Action Slot Workflow for information on Action Slot workflows, and Configuring Transcode Archived Slots for information on configuring Transcode Archived Slots.

Metadata Archive Slot

A Metadata Archive Slot enables archiving of the object metadata. You create and configure this type of slot using both the DIVArchive Configuration Utility Storage Plans tab, and the SPM Actions tab.

See Action Slot Workflow for information on Action Slot workflows, and Configuring Metadata Archive Slots for information on configuring Metadata Archive Slots.

Restore Slot

A Restore Slot enables restoring of an object. You create and configure this type of slot using both the DIVArchive Configuration Utility Storage Plans tab, and the SPM Actions tab.

See Action Slot Workflow for information on Action Slot workflows, and Configuring Restore Slots for information on configuring Restore Slots.

Actions, Action Steps, and Action States

A single Storage Plan can contain a single slot, or multiple slots. Each slot has one or two actions associated with it.

Every action has one Step, or two Steps associated with it as follows:

• Copy, Transcode Archived, Metadata Archive, and Restore

  These slots have a single Step associated with them.

• Delete (only valid for Storage Slots)

  The Delete Action has two Steps associated with it as follows:

  • POSTPONED

    Before SPM executes any Delete Actions, it checks whether the medium is watermarked. If the medium is marked Yes for Watermarking, and the level has not reached the High Watermark, SPM will not execute the Delete Action immediately. Instead, SPM marks the object for deletion, and set the object state to POSTPONED.

    If the medium is not watermarked, there will only be one step (Delete), and the object will be deleted immediately upon expiration.

  • Delete

    When the medium is marked Yes for Watermarking, and the watermarked medium level reaches the High Watermark, then the object will actually be deleted.

The Unified Slot View (on the Slots tab), all slot details are managed from a single window, and all Slot Types only require configuration from the Configuration Utility Slots tab.

When an object is added to DIVArchive, SPM checks for object compliance with the filters specified in the system. When an object conforms to one of the configured filters, the filter determines which configured Storage Plan to use for processing of the object. An object can be assigned to only one Storage Plan. If the object conforms to multiple filters, the first filter the object conforms to is the one that is considered.

The slots associated with the identified Storage Plan determine the actions performed on the object. If an object did not conform to any configured filters, the object is assigned to the SP_DEFAULT Storage Plan. The SP_DEFAULT is the default Storage Plan and must have no slots associated with it.

Action States indicate the status of the action. Each action performed on an object goes through different states as shown in the following example. Each state will finish processing before the status is updated to the next state.

Example:

1. An object matches the filter for a specific Storage Plan.

2. The Storage Plan's slot schedules the associated actions for execution on the object; the status is now SCHEDULED.

3. The action is then loaded into the Action Queue; the status is now LOADED.

4. The action is now executed; the status is now PROCESSING.

5. Upon successful execution of the action the status is updated to COMPLETED.

The additional possible action status states are POSTPONED, FAILED LONG, and REJECTED. The following table describes these additional statuses. See Storage Plan Manager Workflows for additional Slot Workflow information.

The following are the different SPM Action States:

SCHEDULED

This state is the initial state of an action. The action is scheduled, and will be loaded into the Action Queue for execution.

LOADED

The action is loaded into the Action Queue.

PROCESSING

The action is being executed. The action is loaded into the Action Queue, and SPM has started processing this action for execution.

POSTPONED

When a Delete Action is encountered on a watermarked array, SPM will mark the object for deletion, and set the state to POSTPONED. SPM will not actually delete the object until the High Watermark level is reached, and then the object will be removed from the array. If the medium is not watermarked, the object will be deleted immediately. This state only applies to Deleted Actions.

COMPLETED

The action has completed processing successfully.

FAILED LONG

The action failed, and will be retried according to the SPM Configuration. See the UPDATE_ACTIONS_RETRY_FAILED_DELAY parameter in SPM Configuration File Parameters.

Rejected

SPM sets an action to the Rejected state when it has reached the maximum number of retries and has failed. Rejected actions are never retried again.

SPM also sets Copy Actions of a storage slot to the Rejected state if the destination medium already has instances whose quantity is greater than the instances value configured in the Storage Slot.

Managing DIVArchive Watermarks and Arrays

You can manage deletions on disk mediums using watermarks. When watermarks are not used, deletions occur immediately after the slot expires. When watermarks are used, deletions are postponed until the disk array's occupied space hits a configured watermark.

The DSM (Disk Space Monitor) is a function of SPM, and monitors SPM identified arrays, not individual disks. The DSM process only starts if there is a SPM array that is configured for watermarking.

See SPM Configuration File Parameters and SPM Default Configuration File (spm.conf.ini) for configuration information.

When an object is set for deletion by a Storage Slot, it is not actually deleted until the watermarked array reaches the High Watermark. After the array reaches the High Watermark, objects marked for deletion will be deleted either by Last Access Time, or Largest Object Size. The method selected depends on how the watermark is configured. Objects are then deleted until the Low Watermark is reached.

Objects on watermarked arrays are deleted using one of the two following methods:

Last Access Time

This method deletes the oldest objects, among the objects marked for deletion (in non-Mixed Mode), first according to the last time the object was accessed.

Largest Object Size

This method deletes the largest objects, among the objects marked for deletion (in non-Mixed Mode), first according to the object size.

DSM has 2 methods for checking the Array watermark levels:

• Through the DIVArchive API

  This method is typically used. Requests are sent to the Manager and the watermark levels are sent back to DSM.

• Directly from the array

  This method uses the Operating System's commands to retrieve the information.

SPM arrays have three possible Watermark settings that are configurable in the DIVArchive Configuration Utility:

• Yes

  This setting watermarks the identified array, and only considers objects already marked for deletion.

• No

  This setting does not watermark the identified array.

• Mixed

  This setting incorporates a combination of watermarked and not watermarked. This setting is only valid for Storage Slots. The action taken depends on which of the following events occurs first:

  • The slot reaches its end time.

  • The High Watermark is reached. This considers both objects marked for deletion, and objects whose slots are still open.

Note:

You must restart SPM if you change the watermark state of an array.

Recommended Best Practices for Watermarking

If the total size of all permanently stored objects (that is, objects with no specified expiration time) on an array is greater than the configured Low Watermark, Oracle recommends reconfiguring the Low Watermark setting to a value higher than the amount of permanently stored objects.

The following figure represents this basic concept:

The following figures characterize a typical Watermarked Medium (watermarking set to Yes) and illustrate how watermarking ensures the medium does not reach full capacity.

The following figure represents a watermarked disk array with no objects, and shows the Low Watermark and High Watermark:

The following figure represents a watermarked disk array with permanently stored objects with a total size that is less than the Low Watermark:

The following figure represents a watermarked disk array with permanently stored objects with a total size that is less than the Low Watermark, and temporarily stored objects with a total size that is higher than the Low Watermark:

The following figure represents a watermarked disk array with permanently stored objects with a total size that is less than the Low Watermark, and temporarily stored objects with a total size that has reached the High Watermark level. In this figure the temporary objects have now reached the High Watermark, and will be removed using one of the two methods available (Last Access Time or Largest Object Size) until the level reaches the Low Watermark.

The following figure represents a watermarked disk array after the temporary objects have been deleted down to the Low Watermark. Objects have now been deleted (either by Last Access Time or Largest Object Size) and the Low Watermark has been reached. At this point, object deletion stops until the High Watermark is reached again; then the process repeats.

Storage Plan Manager Workflows

The following sections describe the Storage Plan Manager workflows.

Storage Plan Manager Tasks

The SPM module runs several processes, each in charge of a particular task, and uses the DIVArchive Database to process actions. There are always multiple tasks processing in parallel when SPM is operational. All actions currently being executed by SPM reside in the Action Queue until the execution is complete, and then they are deleted from the queue. You can view actions in the queue using the Control GUI SPM Actions panel, which is located under the Manager tab. You must at least be connected to the DIVArchive Database to access this view.

The following list describes internal tasks used by SPM:

Update

This task is responsible for generating, or updating, the actions based on the SPM configuration so the Load task can load the actions into the Action Queue.

Load

This task loads the actions into the Action Queue from the database for processing.

Execution

This task executes the actions loaded into the Action Queue, and submits requests to the Manager as necessary.

DSM (Disk Space Monitor)

DSM monitors a particular array (not individual disks) to make sure it does not exceed the High Watermark value.

Recovery

When SPM starts, the Recovery task checks for the actions that are in an inconsistent state (LOADED or PROCESSING) and sets them to the SCHEDULED state. The action will be in an inconsistent state when SPM was terminated, or stopped during execution of the actions. If the rescheduled action has a DIVArchive Request ID associated with it, it will be loaded into the Action Queue as part of the Recovery task so that SPM can update the Action Status based on the status of the request submitted to the DIVArchive Manager.

An action will be in an inconsistent state and have a Request ID associated with it if SPM was terminated, or stopped, when SPM:

• Has executed the action

• Submitted the request to the DIVArchive Manager

• Was waiting for the status of the request

The Recovery task only runs during SPM startup. If there are no actions in an inconsistent state, the task will just end.

Simple Object Lifecycle Example

The following is a very simple object lifecycle for an object being processed through SPM. The process for this example lifecycle is as follows:

1. An object exists on the Video server.

2. The object is archived to a disk array that is known to DIVArchive, and is one of the SPM monitored mediums.

3. SPM processing now begins as follows:

   1. SPM checks if the object matches any of the SPM Filters.

   2. If the object matches one of the filters, processing by SPM continues by identifying which Storage Plan is associated with the corresponding filter.

   3. When the Storage Plan is identified, SPM detects the slots that are included in the managed Storage Plan.

   4. The slots contain the actions that will be performed on the object.

   5. SPM processes the detected actions (included in the slots) on the object until processing is complete, or the slot ends (closes).

4. According to the Storage Slot that was created for the Storage Plan in the example, 10 minutes after the object is archived, it is copied to a target tape group.

5. SPM deletes the object from the DIVArchive system and SPM 10 minutes later (20 minutes after initially being archived to DIVArchive).

Retrying SPM Failed Actions and Issue Resolution

When a requested action fails to execute properly, or a connection issue occurs, SPM will retry the action according to the following scenarios. The initial retry is automatic, and the requested action state remains as PROCESSING.

Manager Connection Failures

SPM uses the DIVArchive API (C++) to connect to the Manager. If the Manager connection is down, SPM continues retrying to establish the connection to the Manager until a connection is established. See Appendix A for Oracle DIVArchive options and licensing information.

Database Connection Failures

SPM will continue retrying to connect to the DIVArchive database every 20 seconds until a connection is established.

Missing Instances

The following example indicates what occurs if SPM is looking for an instance that does not exist:

A Storage Slot is configured with Once Only set to N. The slot starts five minutes after archiving, and ends 30 minutes after archiving.

• SPM finishes the Copy Action after 5 minutes.

• A user manually deletes the copy made by SPM after 10 minutes.

  SPM senses the deletion and creates the copy again, because the slot period has not ended yet.

• The copy made by SPM is manually deleted again after 35 minutes.

  SPM does not perform another Copy because the slot period has already ended.

If the Once Only parameter was set to Y, SPM will only make the copy one time. If the copy made by SPM is manually deleted, SPM will not make the copy again.

Action Retries

The following list describes when SPM will retry failed actions. See Action Slot Workflow and Storage Slot Workflow for Action Slot and Storage Slot workflows.

• Manager is Busy

  If SPM could not execute the actions by submitting a request because the Manager is busy executing more requests than the value configured in DIVA_MANAGER_MONITOR_MAX_REQUESTS in the spm.conf configuration file, SPM will retry the same action after few seconds delay. The delay value is configured using the DIVA_MANAGER_MONITOR_ACTION_DELAY parameter in the spm.conf configuration file.

• Action Failed_Long State

  When SPM executes an action by submitting a request to the Manager and the Request fails, the action is marked as FAILED LONG. SPM will retry the failed action after the delay period configured in the UPDATE_ACTIONS_RETRY_FAILED_DELAY parameter in the spm.conf configuration file. SPM continues retrying this action 1,000 times using the configured delay. If the action continues to fail, it is marked as Rejected and is never retried again.

  After placed in a Failed_Long state, only Copy, Delete, and Restore Actions are retried. All other actions will not be retried.

• Action REJECT State

  SPM sets an action to the Rejected state when it has reached the maximum number of retries and has failed. Rejected actions are never retried again. SPM also sets Copy Actions of a storage slot to the rejected state if the destination medium already has instances whose quantity is greater than the instances value configured in the Storage Slot. This is a permanent failure.

• Once Only Slots

  If the Once Only parameter is set to false for a Storage Slot, all of its actions will be retried throughout the Slot Start Time and Slot End Time period.

Action Slot Workflow

Action Slots have a specific workflow that encompasses what DIVArchive will do in certain cases. The flowchart below displays the typical Action Slot workflow. There are three possible outcomes:

• Success

• Failed Long

• Not executed within the configured slot time

The following figure depicts the Action Slot workflow:

Storage Slot Workflow

Storage Slots also have a specific workflow that encompasses what DIVArchive will do in certain cases. The flowchart below displays the typical Storage Slot workflow. There are two possible outcomes:

• Success

• Failed Long

The following figure depicts the Storage Slot workflow:

Recommended Best Practices

The following sections describe Oracle recommended best practices for configuring and using the Storage Plan Manager.

SPM Configuration

This section identifies recommended best practices for SPM configuration.

Typical SPM Workflow

A typical SPM workflow consists of archiving objects to disk, and then copying them to tape. In this type of workflow, the SPM is configured to keep the disk copy for a fixed time (non-watermarked mode), or until no more space is available (watermarked mode). Keeping a disk copy for some period allows faster access to the data.

See Action Slot Workflow and Storage Slot Workflow for Action Slot and Storage Slot workflows.

Non-Watermarked (Fixed Retention) Mode

In Non-Watermarked Mode (Fixed Retention) Mode, the disk copy is kept until the Slot End Time (for example, two 2 days from the Archive), at which time the disk instance is deleted; the corresponding DeleteInstance SPM action is sent to the Manager, and then updates the action to the Complete state.

See Managing DIVArchive Watermarks and Arrays for more information on watermarking arrays.

Watermarked Mode

In Watermarked Mode, the disk instance is not deleted when the Slot End Time is reached. Instead, it is flagged as expired by setting the corresponding DeleteInstance SPM action to the POSTPONED state. When the disk's space use reaches a configurable High Watermark (for example, 90%), SPM will remove as many expired instances from the disk as required to lower the space use down to the configured Low Watermark (for example, 60%).

In Watermarked Mode, Oracle advises not to set the disk's Slot End Time for an extended period. The reason for this is so that SPM does not run short of expired instances when a disk purge is triggered. However, the Slot End Time should be far enough in the future to allow the tape copy to complete. If a tape copy is not available at the time of the DeleteInstance, the action will update to a FAILED status instead of POSTPONED. SPM will refuse to expire an instance on disk when no alternate instance is available.

A common disk Slot End Time for Watermarked Mode is three hours (180 minutes), or 24 hours (1440 minutes) if the slot's schedule only allows copies to be executed at a particular time. Confirm that the array is large enough to accommodate additional archived instances for the slot's configured time. If 100 Gigabyte of data per hour is archived at peak time, and the Slot End Time is configured to three hours, the array should be 500 Gigabyte (or larger).

See Managing DIVArchive Watermarks and Arrays for more information on watermarking arrays.

Choosing Appropriate Watermarks

You must choose your Watermarks carefully from the start. However, proper values are typically obtained after spending some time observing the system behavior. Oracle recommends starting with common values, and then fine-tuning them later. Typical common starting values are:

• HWM (High Watermark) = 90%

• LWM (Low Watermark) = 75%

The watermarks refer to the usage ratio of a particular array, not a disk. To compute an array's usage ratio, the Manager examines each disk in the array and divides the sum of each disk's used space by the sum of each disk's total capacity.

Example:

An array composed of two disks of the same size, one 100% full and one 50% full, is considered by the Manager to be 75% full. The same usage ratios with one disk of 2 Terabyte and one disk of 1 Terabyte will result in an 83% filling ratio for the array; 100% of 2 TB and 50% of 1 TB yields a total of 2.5 TB used, divided by a 3 TB total capacity.

See Managing DIVArchive Watermarks and Arrays for more information on watermarking arrays.

General Watermarking Rules

Oracle recommends that you adhere to the following general watermarking rules:

Do not set the High Watermark too high.

When the HWM is reached, SPM begins deleting expired instances. This process may take some time, especially if the instances are small, because the purge will require more DeleteInstance operations. Confirm that any archive activity will not store enough additional instances on the array during this process to fill it to 100%.

Example:

If the HWM is 90%, then the available space is 100 - 90 = 10%. If the array size is 2 Terabytes, this 10% represents 200 Gigabyte. If the SPM purge process encounters numerous small instances requiring deletion, the process will be slow and the archive activity may possibly store 200 Gigabytes (or more) during the purge's execution. This will fill the array to 100% during the process, and initiating Archive terminations.

If you experience this situation, try setting the HWM to a lower value.

Do not set the Low Watermark too low.

The lower you set the LWM, the shorter period disk instances will be kept on disk. The shorter period minimizes the chance to restore from disk, and the benefit of having disk instances.

If the array contains persistent data that cannot be purged (for example, objects belonging to a Storage Plan that keeps disk instances for an unlimited time, or user files not belonging to DIVArchive), you must set the LWM accordingly. If the persistent data accounts for 40% of the array's capacity, and the LWM is set to 30%, the purges will never complete. However, SPM will still purge what it can.

See Managing DIVArchive Watermarks and Arrays for more information on watermarking arrays.

Setting Up Tape Groups in DIVArchive

Configuring tape groups is a different topic in DIVArchive. However, you must complete creating and configuring tape groups before configuring the Storage Plans. The number of Storage Plans required is usually the same as the number of tape groups you configured. Tape groups enable DIVArchive to physically separate archived content into different tapes, and typically creating one Storage Plan per tape group is necessary. All Storage Plans are typically setup to be the same, except that the copy goes to different a tape group. However, the more tape groups DIVArchive uses, the less efficiently content will be stored across tapes.

If complex objects are going to be used in the system, you must setup tape groups containing tapes configured for AXF format. Complex objects are not compatible with the Legacy formatted tapes or disks. You can store non-complex objects using either Legacy or AXF format.

The following example illustrates how creating too many tape groups causes fragmentation of objects across the groups. Using fewer groups results in fewer Storage Plans to setup, less fragmentation across tapes, and is easier to maintain.

Having fewer tape groups will resolve the issue in the following example, and avoid fragmentation across the tape groups.

Example Configuration:

• 10 Tape Drives

• 30 Tape Groups with SetID=10

• 300 Total Tapes assigned to SetID=10

Results:

• Each Tape Group (in the worst case) will use at least ten tapes, and store files on each tape when an object is archived.

• After objects are archived to all 30 tape groups, all 60 tapes (total) are used.

• Over time, if any of the tape groups is heavily archived, and one of the tapes is 100% full, no more tapes are available.

• DIVArchive will run out of tapes, even though a lot of the tapes are still mostly empty (each containing only one object), but cannot be used because it was assigned to a different tape group.

Valid Reasons for Creating Multiple Tape Groups

Generally, you should only create multiple tape groups for a good reason. Multiple tape groups will cause tape group fragmentation, resulting in some tapes not being filled, and storage space being wasted.

The following are several valid reasons for creating multiple tape groups:

• Long and short form materials should be stored on different tape groups. If small objects are mixed with larger objects on the same tape, access to the smaller object will be delayed for an extended period until the larger object restore is complete.

• Content that is deleted regularly from the archive should be stored in a different tape group than content that will never (or rarely) be deleted. Deleting from tape will cause tape fragmentation and the fragmented space cannot be used until the tape is repacked. If the two types of content are mixed together, deleting will cause more tapes to become fragmented, and repacking will be required more frequently and take longer.

• Online and backup copies of the same content should be on two different tape groups. Backup copies are meant to be removed from the tape library and stored in an Iron Mountain type of facility as a backup. However, if both copies are mixed in the same tape group, it is impossible to determine which tape contains the backup copy. The result is being unable to remove it from the library for offline storage.

• When requirements necessitate using tapes purchased by different departments and enforcing that each department uses only the tapes they purchase themselves, you must create tape groups for each department with a different set of tapes.

• Different storage formats must be assigned to different groups. For example, one group would be Legacy Format while another group is AXF Format. Complex objects are not compatible with Legacy Format, and must be processed to and from AXF formatted medium. Non-complex objects are compatible with both Legacy and AXF formats.

Invalid Reasons for Creating Multiple Tape Groups

Having too many tape groups will cause DIVArchive to work less efficiently, result in tape group fragmentation, and are more difficult to configure and maintain. Unless you have one of the previously described valid reasons, the recommended best practice for creating Tape groups is to use as few tape groups as possible. See Setting Up Tape Groups in DIVArchive for recommended best practices.

The following are several invalid reasons for creating multiple tape groups:

• You want to store different content in different tape groups because you think it is easier to manage. DIVArchive manages the tapes. When restoring an object on a tape, DIVArchive automatically knows which tape the object is on, and mounts that tape, or notifies you to insert the necessary tape into the library. It will not require you to figure out which tape is needed.

• Creating many tape groups because it is easier to search. DIVArchive performs searches using object metadata stored in the database, not tape groups. The group only makes sure content is physically separated, and does not assist in searching functions.

• Creating multiple tape groups for cataloging. Users migrating from an analog tape environment tend to label what's recorded on each analog tape directly on the tape itself. A group of those tapes are then stored on different sections of a shelf. DIVArchive does not work efficiently this way, and this method should not be used.

Simple SPM Configuration Example

The following figure illustrates a simple SPM configuration example. The following occurs in this scenario:

1. The object is archived to a watermarked array (Medium-1 with Watermark set to Yes) and held there for one day.

2. The object is immediately copied to DIVArchive Medium-2, and stored there forever.

3. At the one day mark, the object is marked for deletion from the Medium-1 array.

See SPM Slot Types and Creating Slots for more information about Slot Types and Slot configuration.

Additional SPM Configuration Examples

The following figure is an example of a more complex SPM configuration. In the first example, one copy is kept on the SPM monitored array forever. At some point in time, the object will be restored with transcoding to a Proxy Source/Destination.

The following figure is an example of a more complex SPM configuration. In the second example, one copy is kept on the SPM watermarked array (with Watermark set to Yes) for two hours, and two copies are immediately made to a tape group named Programs. At the ten minute mark, one copy will be restored to a Proxy Source/Destination.

The following figure is an example of a SPM configuration with one copy left in the online tape group (Medium-2 named Programs), and a second backup copy made to a different tape group (Medium-3 named Backups) that is to be taken offline. In this example, one copy is kept on the SPM watermarked array (with Watermark set to Yes) for two hours, and two copies are made immediately. One copy is made to a tape group named Programs, the second copy is made to a different tape group named Backups. The Backups Tape Group would typically be externalized from the DIVArchive system and sent to an Iron Mountain type of facility for offline storage.