4.1.1.3 Archival Storage

From wiki.dpconline.org
Jump to: navigation, search
OAIS Community Logo small.png

Community Forum | OAIS Community | OAIS Structure | OAIS Blog Posts | Active Topics and News

The functions of the Archival Storage Functional Entity are illustrated in figure 4-3. The term ‘media’ is used to designate one or more mechanisms, local or remote, for storing digitally encoded information.

Figure 4-3 Functions of the Archival Storage Functional Entity 650x0m2.jpg

Figure 4-3: Functions of the Archival Storage Functional Entity

The Receive Data function receives a storage request and an AIP from Ingest and moves the AIP to permanent storage within the Archive. The transfer request may need to indicate the anticipated frequency of utilization of the Data Objects making up the AIP in order to allow the appropriate storage devices or media to be selected for storing the AIP. This function will select the media type, prepare the devices or volumes, and perform the physical transfer to the Archival Storage volumes. Upon completion of the transfer, this function sends a storage confirmation message to Ingest, including the storage identification of the AIPs.

The Manage Storage Hierarchy function positions, via commands, the contents of the AIPs on the appropriate media based on storage management policies, operational statistics, or directions from Ingest via the storage request. It will also conform to any special levels of service required for the AIP, or any special security measures that are required, and ensures the appropriate level of protection for the AIP. These include on-line, off-line or near-line storage, required throughput rate, maximum allowed bit error rate, or special handling or backup procedures. It monitors error logs to ensure AIPs are not corrupted during transfers. This function also provides operational statistics to Administration summarizing the inventory of media on-hand, available storage capacity in the various tiers of the storage hierarchy, and usage statistics.

The Replace Media function provides the capability to reproduce the AIPs over time. Within the Replace Media function the Content Information and Preservation Description Information (PDI) must not be altered. However, the data constituting the Packaging Information may be changed as long as it continues to perform the same function and there is a straightforward implementation that does not cause information loss. The migration strategy must select a storage medium, taking into consideration the expected and actual rates of errors encountered in various media types, their performance, and their costs of ownership. If media-dependent attributes (e.g., tape block sizes, CD-ROM volume information) have been included as part of the Content Information, a way must be found to preserve this information when migrating to higher capacity media with different storage architectures. Anticipating the terminology of 5.1.3, this function may perform ‘Refreshment’, ‘Replication’, and ‘Repackaging’ that is straightforward. An example of such ‘Repackaging’ is migration to new media under a new operating system and file system, where the Content Information and PDI are independent of the file systems. However, complex ‘Repackaging’ and all ‘Transformation’ are performed under Administration supervision by the Archival Information Update function to ensure information preservation. (Refer to 5.1.3 for a detailed description of migration issues.)

The Error Checking function provides statistically acceptable assurance that no components of the AIP are corrupted in Archival Storage or during any internal Archival Storage data transfer. This function requires that all hardware and software within the Archive provide notification of potential errors and that these errors are routed to standard error logs that are checked by the Archival Storage staff. The PDI Fixity Information provides some assurance that the Content Information has not been altered as the AIP is moved and accessed. Similar information is needed to protect the PDI itself. A standard mechanism for tracking and verifying the validity of all Data Objects within the Archive may also be used. For example, CRCs could be maintained for every individual data file. A higher level of service, such as Reed-Solomon coding to support combined error detection and correction, could also be provided. The storage facility procedures should provide for random verification of the integrity of Data Objects using CRCs or some other error checking mechanism.

The Disaster Recovery function provides a mechanism for duplicating the digital contents of the Archive collection and, for example, storing the duplicate in a physically separate facility. This function is normally accomplished by copying the Archive contents to some form of removable storage media (e.g., digital linear tape, CD-ROM), but may also be performed via hardware transport or network data transfers. The details of disaster recovery policies are specified by Administration.

The Provide Data function provides copies of stored AIPs to Access. This function receives an AIP request that identifies the requested AIP(s) and provides them on the requested media type or transfers them to a temporary storage area. This function also sends a notice of data transfer to Access upon completion of an order.

--Please retain original text above for reference. Propose amendments or additions below this line or respond using the Discussion tab above--


OAIS Community Logo small.png

Community Forum | OAIS Community | OAIS Structure | OAIS Blog Posts | Active Topics and News

These wiki pages are licensed under a Creative Commons Attribution-NonCommercial 3.0 Unported License. Attribute as "Community forum for digital preservation and curation standards http://wiki.dpconline.org/". The content on this wiki represents the opinions of the author and not the Digital Preservation Coalition. This wiki is not associated with ISO, the OAIS Standard or the CCSDS.