Skip to end of metadata
Go to start of metadata

Overview of "Manage Replicated Long-Term Archive (Deprecated)" Use Case

Index, Browse, Validate, Retrieve, Mirror, Migrate, and Regulate long-term archival holdings Not available in Release 2

Metadata

Refer to the Product Description and Product Description Release 2 pages for metadata definitions.

Actors Integrated Observatory Operator
References See Persistent Archive Services II components "IRODS persistent archive", "Persistent archive replication service", "Long-term data archive service", "Long-term data archive access", and "Persistent archive index service"
Uses UC.R1.05 Synchronize State Data
UC.R1.08 Persist Streamed Data
Is Used By  
Extends  
Is Extended By  
Technical Notes This Use Case will be deleted, is is moved to R3.
Note this use case is heavily derived from UC.R2.27, which is not about long-term archives.
Long Term Archive Strategy manages historical data, potentially replicated, subject to longer access times.
The algorithms needed here could also apply to the management of persistent stores.
Lead Team DM
Primary Service Persistent Archive Services Part 2
Version 2.2.1
UC Priority 4
UC Status Deprecated
UX Exposure ONC

Summary

This information summarizes the Use Case functionality.

Perform the basic management activities needed to ensure that long-term archives are performing their function reliably. Provide each of the described services for the ION long-term archives. Monitor long-term archives as needed to perform those services. Manage information in dark or offline archives. Maintain information integrity. Provide estimates for data retrieval time. Move data to and from archive to online repository. Notify data requester of completed retrieval.
Capabilities to access remote data archives identified by OOI.

Assumptions

  • Replication is not 'en mass'; strategies about what gets replicated where are determined by applying policy to information resources of particular characteristics.
  • Replication provides effective long-term backup of data which do not need to be instantly on-line.
  • Contextual information in the OOI system that relates to archived information resources (required metadata, related annotations, vocabulary terms, linked information) is either archived with the data, or assumed to be independently maintained and recoverable, whether by OOI or an independent entity. (For example, there is an independent system of maintaining vocabulary terms, such that any version of any term can be recovered by the OOI indefinitely. Links pointing to other OOI information artifacts can always be recovered, because the linked information knows what it is linked to.)
  • While replication into long-term archives may provide other benefits (e.g., hosting a copy of all data of a given type for export into an external repository), the primary use case for this design in Release 2 is simply migrating data into storage that is less closely connected to the system.
  • Content (to which policy is to apply) is characterized by resource type, dataset provider class (OOI or external), intended use, requested quality of service, nature of data set, geographical affinity (archive at east coast), access privileges, owner, known copies and their location, or any other concepts which may be used in policy statements.
  • ION operator may appreciate many operational factors that affect setting and execution of policy, including nature and capacity of data storage locations. These may be taken into account in performing and adjusting the management steps below.

Initial State

A cataloged source archive exists from which content can be replicated. A destination archive exists into which content can be replicated; content has already been categorized.

Scenario for "Manage Replicated Long-Term Archive (Deprecated)" Use Case

  1. Operator defines a replication policy for specified content
    1. Operator defines content selection, archive location (potentially), number of replicas, backup interval and metadata
    2. Policy management capabilities can inform this step.
    3. Technology implementation(s) not visible to the operator and interface are oriented to resources and policy creation based on resource attributes
    4. Policies may cascade or be refined at lower levels (marine facility, platform, instrument, etc)
  2. Operator replicates content for archiving
    1. Use archive tools to extract a consistent snapshot of a set of persistent resources.
    2. This requires a service to write out the state of the interesting resources for backup. This could be refined by the user to limit to associations of interest.
    3. Use persistent archive services to replicate the snapshot to specific distributed storage facilities
  3. Operator restores information resources from backup after failure
    1. System prompts operator with recommended plan for restoration, including estimated retrieval times.
    2. Not all data from long-term archives must be restored in every case; restoration service must be able to intelligently select which data to restore from which archives to bring the restored system to the desired state.
    3. Operator is able to customize plan to meet restoration needs.
  4. Operator is notified of completion of restoration process

Final State

Archive policies are created, archive content is constructed and updated by the system and archived data are accessible as required.

Comments

These comments provide additional context (usually quite technical) for editors of the use case.

Labels

usecase usecase Delete
productdescription productdescription Delete
r2-usecase-deprecated r2-usecase-deprecated Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.