5.1 Technical Infrastructure Risk Management #
5.1.1 - The repository shall identify and manage the risks to its preservation operations and goals associated with system infrastructure. #
Response #
SP performs technical risk management in order to ensure the integrity, security, and reliability of the repository’s content. SP has assessed threats to its hardware, software, and technical operations and implemented a broad range of risk-minimization strategies in collaboration with the University of Toronto Libraries' Information Technology Services (ITS) department. Technical risk management is a part of the repository’s comprehensive risk management strategy, described in the Risk Analysis and Management Strategies document. In addition, the repository has a Backup Plan that describes policies and procedures implemented by SP and ITS to provide reliable backup of the repository’s data, databases, and applications. To support the repository’s risk-minimization activities, SP maintains an inventory of hardware and software components.
The Risk Analysis and Management Strategies document covers, among other things, the following technical risks:
- hardware failure and obsolescence
- storage media failure and obsolescence
- software failure and obsolescence
- loss of critical hardware or software support
- operator error
- cyber attack
In order to change hardware or software components without disrupting normal operations, SP implements and tests changes in isolated environments. For policies and procedures related to hardware and software change management, please see 5.1.1.1.4, 5.1.1.1.8, 5.1.1.4, 5.1.1.5 , 5.1.1.6.1, and 5.1.1.6.2. For policies and procedures related to operator authorization and access, please see 5.2.3.
Responsibility #
- Digital Preservation Librarian
- Systems Administrator
Potential Risks #
See this item in 5.2.1 and 5.2.2.
Monitoring Commitments #
See this item in 5.2.1 and 5.2.2.
Future Plans #
See this item in 5.2.1 and 5.2.2.
Documents #
- Risk Analysis and Management Strategies
- Backup Plan
- Scholars Portal Access Policy
- Hardware and Software Inventory (available on request)
5.1.1.1 - The repository shall employ technology watches or other technology monitoring notification systems. #
Response #
SP staff collaborate with personnel from the University of Toronto Libraries' Information Technology Services (ITS) department to assess the long-term viability of the repository’s hardware and software. This is an ongoing and comprehensive process that incorporates information obtained from automated monitoring systems, manual quality controls, the repository’s Designated Community, the repository’s hardware and software vendors, and the enterprise IT community at large. The chief objective is to predict deterioration and obsolescence before they can impair the repository’s ingest, data management, archival storage, or dissemination processes. Furthermore, systems administrators monitor hardware and software in order to detect potential points of failure and identify opportunities to reduce costs.
SP employs experienced systems administrators and programmers to oversee its technical operations. In addition to their operational duties, systems personnel monitor innovations in data management and storage, attend relevant conferences, and upgrade their skills through the repository’s professional development program (see 3.2.1.3). At the same time, SP can draw on the expertise of systems administrators at ITS and vendors for help with technology evaluation.
SP benefits from an active and technologically savvy Designated Community, composed of librarians, researchers, and students, who report problems in system behaviour. SP receives feedback from its Designated Community on a regular basis. Librarians at OCUL member institutions can contact SP staff directly to report problems and discuss issues. Representatives from the Designated Community sit on the repository’s advisory committees, giving them an opportunity to report technology issues to SP staff.
For more information about hardware monitoring and change management, please see 5.1.1.1.1 and 5.1.1.1.2. For software, please see 5.1.1.1.5 and 5.1.1.1.6.
Responsibility #
- Digital Preservation Librarian
- Systems Administrator
Potential Risks #
The primary risks associated with technology monitoring are (1) failure to gather information from a wide variety of reliable sources and (2) failure to monitor sources in a timely manner. SP and ITS staff minimize these risks by regularly gathering information from a large number of trusted sources within and without the repository (see Explanation above).
There is a risk that systems personnel, who know the Designated Community, system requirements, and system behaviour intimately, will leave the organization at some point. To minimize this risk, SP uses well known hardware and software and delegates critical responsibilities to several people. Please see the Risk Analysis and Management Strategies document for more information about SP’s strategies for reducing the impact of personnel departures.
Future Plans #
Systems administrators will revise and update their monitoring practices as new tools and resources become available.
Documents #
- Risk Analysis and Management Strategies
- Hardware and Software Inventory (available on request)
5.1.1.1.1 - The repository shall have hardware technologies appropriate to the services it provides to its designated communities. #
Response #
In order to provide a level of service that meets the repository’s contracted obligations, SP selects and implements hardware technologies based on a clear and comprehensive understanding of the needs and expectations of its Designated Community Definition, who support decision-making by providing an overview of the repository’s user communities.
SP staff work closely with members of the Designated Community to identify system requirements and test components. Representatives from the Designated Community sit on SP’s advisory committees, giving them a direct channel to the repository’s directors and systems administrators. In addition, SP receives ongoing feedback about system behaviour from its Designated Community. Feedback from the Designated Community provides valuable information about response times, page loading, and overall system performance. Generally, the close relationship between SP and its Designated Community means that SP staff are aware of new needs and expectations at an early stage.
Systems administrators at SP and the University of Toronto Libraries' Information Technology Services department receive information about system behaviour and usage from automated monitoring programs. These programs warn administrators about events and loads that exceed predetermined levels. Please see 5.1.1.1.2 for more information.
The repository has an inventory of hardware and software to help staff carry out long-term technology planning.
Responsibility #
- Digital Preservation Librarian
- Systems Administrator
Potential Risks #
In order to comply with this point, SP must maintain a thorough understanding of the needs of its Designated Community. If SP has imperfect or inadequate information about the repository’s Designated Community, then there is a risk of using inappropriate hardware. The practices described above (see Explanation) are designed to minimize this risk, but sudden, unexpected changes in user behaviour are possible.
Future Plans #
SP has procedures, commitments, and financial resources for regular hardware replacement and media refreshment. See 5.1.1.1.4 for details.
Documents #
- Designated Community
- Hardware and Software Inventory (available on request)
5.1.1.1.2 - The repository shall have procedures in place to monitor and receive notifications when hardware technology changes are needed. #
Response #
SP uses a variety of widely accepted, industry-standard techniques and tools to monitor the repository’s hardware platform. Systems administrators at SP and the University of Toronto Libraries' Information Technology Services receive information about system behaviour and usage from a number of custom-built scripts, a Nagios monitoring program, and monitoring functionality built into the hardware. These tools warn administrators about abnormal activity such as excessive processor loads and slow response times. In addition, staff monitor critical processes, such as ingest and data management, for malfunctions and suboptimal performance.
Feedback from the Designated Community is an important source of information about system behaviour and hardware performance. As described in 5.1.1.1.1, SP receives ongoing and extensive feedback from its Designated Community.
As a rule, SP replaces hardware within a 5-year period (i.e. every 5 years or less) even if the hardware is functioning normally. Typically, SP buys a 5-year warranty for hardware when available.
Systems administrators receive notices and alerts about stability and security issues from vendors on a regular basis.
Responsibility #
- Digital Preservation Librarian
- Systems Administrator
Potential Risks #
See 5.1.1.1
Future Plans #
SP has procedures, commitments, and financial resources for regular hardware replacement and media refreshment. See 5.1.1.1.4 for details.
Documents #
- Hardware and Software Inventory (available on request)
5.1.1.1.3 - The repository shall have procedures in place to evaluate when changes are needed to current hardware. #
Response #
SP employs a number of experienced systems administrators and programmers to oversee its technical operations and evaluate when hardware changes are needed. In addition to their operational duties, systems personnel monitor developments in data management and storage, attend relevant conferences, and upgrade their skills through SP’s professional development program (see 3.2.1.3).
SP staff collaborate with personnel from the University of Toronto Libraries' Information Technology Services (ITS) department to evaluate hardware alternatives and the timing of hardware replacements or upgrades. Evaluations vary in formality according to the circumstances. The most extensive assessments take place whenever large components, such as the repository’s servers or storage array network, require replacement. When necessary, systems administrators at SP and ITS consult vendors for additional information and advice. Staff evaluate potential changes for their effect on the integrity and understandability of information, the speed and interoperability of the system, and the accessibility and usability of content. Staff also take the cost of hardware and future maintenance into account.
Responsibility #
- Digital Preservation Librarian
- Systems Administrator
Potential Risks #
There is a risk that systems personnel, who know the Designated Community, system requirements, and system behaviour intimately, will leave the organization at some point. To minimize this risk, SP uses well known hardware components and delegates critical responsibilities to several people. At the same time, SP can draw on the expertise of systems administrators at ITS and vendors for help with hardware evaluation. Please see the Risk Analysis and Management Strategies document for more information about SP’s strategies for reducing the impact of personnel departures.
Future Plans #
SP has procedures, commitments, and financial resources for regular hardware replacement and media refreshment. See 5.1.1.1.4 for details.
Documents #
5.1.1.1.4 - The repository shall have procedures, commitment and funding to replace hardware when evaluation indicates the need to do so. #
Response #
SP has a commitment of funding for regular hardware replacement and storage media refreshment. Administrators assess and, if necessary, revise funding commitments during the repository’s annual budget review. SP replaces hardware within a 5-year period (i.e. every 5 years or less) even if the hardware is functioning normally. Typically, SP buys a 5-year warranty for hardware components. When hardware replacement is necessary, SP staff analyze information provided by vendors, consult experts at OCUL member libraries and the University of Toronto Libraries' Information Technology Services, and conduct a cost-benefit analysis of hardware alternatives. To support decision-making, SP has an inventory of hardware and software components. Please see 5.1.1.5 for additional information about hardware change processes.
Responsibility #
- Digital Preservation Librarian
- SP Director
- Systems Administrator
Potential Risks #
Loss of funding, whether through cuts or freezes, can make it difficult for the repository to replace or upgrade hardware. SP has assessed the risk of loss of funding and implemented a number of risk-minimization strategies. Please see the Risk Analysis and Management Strategies document for more information.
Documents #
- Risk Analysis and Management Strategies
- Hardware and Software Inventory (available on request)
5.1.1.1.5 - The repository shall have software technologies appropriate to the services it provides to its designated communities. #
Response #
In order to provide a level of service that meets the repository’s contracted obligations, SP designs and implements software technologies based on a clear and comprehensive understanding of the needs and expectations of its Designated Community. The repository’s Designated Community supports decision-making by providing an overview of the repository’s user communities.
SP staff work closely with members of the Designated Community to design applications and test usability. Representatives from the Designated Community sit on SP’s advisory committees, giving them a direct channel to the repository’s directors and programmers. In addition, SP receives ongoing feedback about application behaviour and interface design from its Designated Community. Feedback from the Designated Community provides valuable information about accessibility, usability, understandability, and holdings. Generally, the close relationship between SP and its Designated Community means that SP staff are aware of new needs and expectations at an early stage.
Software developers at SP and the University of Toronto Libraries' Information Technology Services department receive information about system behaviour and usage from automated monitoring programs. These programs warn administrators about events and loads that exceed predetermined levels. Please see 5.1.1.1.6 for more information.
SP uses a combination of custom-built, open-source, and commercial software to run its critical processes. The repository has an inventory of software to help staff carry out long-term technology planning.
Responsibility #
- Digital Preservation Librarian
- Software Developer
Potential Risks #
In order to comply with this point, SP must maintain a thorough understanding of the needs of its Designated Community. If SP has imperfect or inadequate information about the repository’s Designated Community, then there is a risk of using inappropriate software. The practices described above (see Explanation) are designed to minimize this risk, but sudden, unexpected changes in user behaviour are possible.
Future Plans #
SP has a procedures, commitments, and financial resources for regular software replacement or upgrade. See 5.1.1.1.8 for details.
Documents #
- Designated Community
- Hardware and Software Inventory (available on request)
5.1.1.1.6 - The repository shall have procedures in place to monitor and receive notifications when software changes are needed. #
Response #
Software development, testing, and improvement is an ongoing process at SP. In general, there is no time when software is not subject to monitoring and evaluation.
SP uses a variety of widely accepted, industry-standard techniques and tools to monitor the repository’s applications. Systems administrators and programmers at SP receive information about system behaviour and usage from a number of custom-built scripts. In addition, staff receive information from monitoring functionality built into commercial software. These tools warn administrators about abnormal activity such as conflicts or slow processing times. The repository records and reports software failures through a JIRA tracking system.
Feedback from the Designated Community is an important source of information about accessibility, usability, understandability, holdings, and overall system performance. As described in 5.1.1.1.5, the repository receives ongoing and extensive feedback from its Designated Community.
Systems administrators receive notices and alerts about stability and security issues from vendors on a regular basis.
Responsibility #
- Digital Preservation Librarian
- Software Developer
Potential Risks #
Future Plans #
SP has a procedures, commitments, and financial resources for regular software replacement or upgrade. See 5.1.1.1.8 for details.
Documents #
- Hardware and Software Inventory (available on request)
5.1.1.1.7 - The repository shall have procedures in place to evaluate when changes are needed to current software. #
Response #
SP employs a number of experienced systems administrators and programmers to oversee its technical operations and evaluate when software changes are needed. In addition to their operational duties, systems personnel monitor development in programming and software, attend relevant conferences, and upgrade their skills through SP’s professional development program (see 3.2.1.3).
SP has the expertise to evaluate software alternatives and the timing of software replacements or upgrades. Evaluations vary in formality according to the circumstances. When necessary, staff consult vendors for additional information and advice. Staff evaluate potential changes for their effect on the integrity and understandability of information, the speed and interoperability of the system, and the accessibility and usability of content. Staff also take the cost of software and future maintenance into account.
Responsibility #
- Digital Preservation Librarian
- Software Developer
- System Administrator
Potential Risks #
There is a risk that software development personnel, who know the Designated Community, hardware platform, and application behaviour intimately, will leave the organization at some point. To minimize this risk, SP uses well known software development practices and delegates critical responsibilities to several people. Please see the Risk Analysis and Management Strategies document for more information about SP’s strategies for reducing the impact of personnel departures.
Future Plans #
SP has procedures, commitments, and financial resources for regular software replacement or upgrade. See 5.1.1.1.8 for details.
Documents #
5.1.1.1.8 - The repository shall have procedures, commitment and funding to replace software when evaluation indicates the need to do so. #
Response #
SP has a commitment of funding for regular software replacement and upgrade. Administrators assess and, if necessary, revise funding commitments during the repository’s annual budget review. SP has no fixed schedule for software replacement, but relies on information received from its Designated Community and from internal performance reports to indicate when software change is needed (see section 5.1.1.1.6 for more information). When software replacement is necessary, SP staff analyze information provided by vendors, consult experts at OCUL member institutions and the University of Toronto Libraries' Information Technology Services, and conduct a cost-benefit analysis of software alternatives. To support decision-making, SP has an inventory of hardware and software components. Please see 5.1.1.6.1 and 5.1.1.6.2 for information about software change processes.
Responsibility #
- Digital Preservation Librarian
- SP Director
- Software Developer
Potential Risks #
Loss of funding, whether through cuts or freezes, can make it difficult for the repository to replace or upgrade software. SP has assessed the risk of loss of funding and implemented risk-minimization strategies. Please see the Risk Analysis and Management Strategies Strategies document for more information.
Documents #
- Risk Analysis and Management Strategies
- Hardware and Software Inventory (available on request)
5.1.1.2 - The repository shall have adequate hardware and software support for backup functionality sufficient for preserving the repository content and tracking repository functions. #
Response #
SP is committed to using current, reliable, and adequate hardware and software to backup its data, databases, applications, logs, and administrative documents. In the event of a disaster that results in data corruption or loss, SP can restore information from one of two TSM backup copies, one of which is stored at an off-site facility. Beyond the repository’s own copies, it may be possible to re-ingest copies held by content Providers. The repository uses industry-standard practices for backup management and media refreshment in order to ensure the long-term integrity of information. Since the repository’s information resides on a storage platform managed by the University of Toronto Libraries' Information Technology Services (ITS) department, SP staff are not directly involved in the day-to-day management of the backup system.
Please see the Backup Plan for complete information.
SP is developing a Disaster Recovery Plan that describes emergency contacts, staff roles and responsibilities, communication policies, and data recovery procedures.
Responsibility #
- Digital Preservation Librarian
- Systems Administrators
Potential Risks #
SP does not have an online mirror site that can disseminate the information in the event of data corruption or loss. For that reason, efforts to restore data from a tape backup may result in temporary service outages.
Monitoring Commitments #
SP has polices and procedures for regular assessment and refreshment of backup media. Please see the Backup Plan for more information. Both the Backup Plan and the Disaster Recovery Plan are subject to regular review based on the Review Cycle for Documentation Policy.
Future Plans #
SP and ITS recognize that the implementation of an online mirror site would provide an additional layer of security and ensure continuous service in the event of a disaster. In the long run, the repository would like to establish a mirror site to provide online redundancy of archival storage, data management, and dissemination systems.
Documents #
5.1.1.3 - The repository shall have effective mechanisms to detect bit corruption or loss. #
Response #
In order to ensure the long-term integrity and reliability of information, SP uses a number of tools and procedures to detect bit corruption or loss. The repository uses widely accepted hashing techniques to generate digest values for new content and carries out regular, automated fixity checks on archived content.
In addition, the Pillar Axiom storage array has health-monitoring, diagnostic, and error-correction tools. The storage controllers will automatically report errors to the University of Toronto Libraries' Information Technology Services staff. The MarkLogic database performs consistency checks on bibliographic and preservation metadata.
Please see the complete text of the Fixity Check Procedures document for additional information. The Risk Analysis and Management Strategies document contains information about the Pillar array’s health-monitoring and error-correction functionality.
Content Note - Journals #
For each journal article, the repository generates and records MD5, SHA-1, and CRC32 values for each file associated with the article, including the bibliographic metadata. Digest values are stored in the preservation metadata, which is separate from the article’s files. SP also records file sizes at byte scale.
Responsibility #
- Digital Preservation Librarian
Potential Risks #
SP is in the process of generating digest values for content that was ingested before the repository adopted its fixity procedures. Until this process is complete, some files do not have digest values and are not candidates for regular fixity testing.
SP does not generate digest values for its preservation metadata files. In other words, there is no fixity check for the fixity values. It should be noted, however, that these files are subject to MarkLogic’s internal consistency checking.
Monitoring Commitments #
SP operates a rolling test of digest values. Fixity tests that produce a mismatch are automatically reported to staff through the repository’s issue tracking system.
Documents #
5.1.1.3.1 - The repository shall record and report to its administration all incidents of data corruption or loss, and steps shall be taken to repair/replace corrupt or lost data. #
Response #
SP uses JIRA to record and report episodes of data corruption or loss to the repository’s administration. JIRA is a widely used, industry-standard issue tracking system. JIRA also provides a platform for tracking responses and recording information about the nature of errors. JIRA automatically assigns issues to appropriate staff and notifies them by email. In most cases of data corruption or loss, SP staff will replace each damaged file with a copy from backup and record the event in each file’s preservation metadata. Staff will assess the cause of data corruption or loss on a case-by-case basis.
Errors detected by the health-monitoring and diagnostic tools built into the Pillar Axiom storage array are reported automatically to the University of Toronto Libraries' Information Technology Services staff.
Responsibility #
- Digital Preservation Librarian
Documents #
- Workflow Charts
- SP JIRA (access on request)
5.1.1.4 - The repository shall have a process to record and react to the availability of new security updates based on a risk-benefit assessment. #
Response #
SP staff evaluate all mandatory and optional updates on a risk-benefit basis. Staff evaluate updates for their effect on the integrity and understandability of information, the speed and interoperability of the system, and the accessibility and usability of content.
Staff apply all mandatory updates to software and firmware. Staff may or may not apply optional updates. As in all cases of software change, SP tests and evaluates updates in an isolated development environment to ensure that changes will not disrupt normal operations. Please see 5.1.1.1.6 and 5.1.1.6.2 for more information about software monitoring and testing. Moving software from development to production is done through a version control system, which serves as a record of all updates.
Please see the Risk Analysis and Management Strategies document for additional information about the repository’s efforts to reduce the risk of software failure.
Responsibility #
- Systems Administrator
- Digital Preservation Librarian
Potential Risks #
There is always a risk of software failure in complex information systems. SP uses widely accepted, industry-standard procedures for testing and evaluating software changes, but small errors or conflicts sometimes escape testing. Software failure could force SP to suspend certain operations until the affected systems can be thoroughly analyzed, repaired, and tested.
Monitoring Commitments #
SP systems administrators and programmers receive notices and alerts about stability and security issues from hardware and software vendors on a regular basis. They also monitor the enterprise IT community for news about emerging risks.
Documents #
5.1.1.5 - The repository shall have defined processes for storage media and/or hardware change (e.g., refreshing, migration). #
Response #
SP replaces storage media according to a predetermined schedule or whenever media exhibit performance problems. As a rule, SP refreshes its storage array media within a 5-year period (i.e. every 5 years or less) even if the drives are functioning normally and appear healthy. Typically, SP buys a 5-year warranty for hardware. SP tests, re-tensions, and, if necessary, replaces backup tapes annually to reduce the risk of degradation.
Large-scale media and hardware change is carried out by technicians from the hardware vendor in collaboration with systems administrators from SP and the University of Toronto Libraries' Information Technology Services. Staff test and evaluate new hardware in isolation before moving the repository to the new component(s). In addition to tests and checks carried out by automated hardware monitoring programs (see 5.1.1.1.2), staff manually assess changes by examining samples of relevant content. Staff evaluate changes for their effect on the integrity and understandability of information, the speed and interoperability of the system, and the accessibility and usability of disseminated content. Whenever hardware changes involve migrating data, the repository performs checksum and file size tests to validate the integrity of information.
Responsibility #
- Systems Administrator
- Digital Preservation Librarian
Potential Risks #
There is always a risk of data corruption during large-scale migration. For this reason, the repository retains known good copies of all information until testing and evaluation of new components has been completed.
Documents #
5.1.1.6 - The repository shall have identified and documented critical processes that affect its ability to comply with its mandatory responsibilities. #
Response #
As a repository that is committed to the long-term preservation of digital information and the dissemination of content to a diverse Designated Community, SP strives to comply with standards and models used by the international digital curation field. The Mandatory Responsibilities described in the OAIS Reference Model are important standards. Accordingly, SP designs its critical processes and operating procedures to ensure that the repository complies with all of the OAIS Mandatory Responsibilities. By meeting these high-level requirements, SP supports the authenticity, integrity, longevity, and understandability of information.
In order to identify and document the repository’s compliance, SP created a traceability matrix that links Critical Processes and OAIS Mandatory Responsibilities described in OAIS 3.0. Please see the Critical Processes and OAIS Mandatory Responsibilities.
Responsibility #
- Digital Preservation Librarian
Monitoring Commitments #
SP will monitor changes to critical processes and procedures for compliance with the OAIS Mandatory Responsibilities. In addition, the repository will examine new editions of the OAIS Reference Model for changes to the Mandatory Responsibilities.
Documents #
5.1.1.6.1 - The repository shall have a documented change management process that identifies changes to critical processes that potentially affect the repository’s ability to comply with its mandatory responsibilities. #
Response #
SP retains historical versions of software so that changes to critical processes can always be reversed. This software controls ingest, certain aspects of data management, archival storage, access, and dissemination. SP stores software in its code versioning system. The repository’s backup plan includes procedures that make regular copies of the code versioning system.
Responsibility #
- Systems Administrator
- Digital Preservation Librarian
Potential Risks #
Please see 5.1.1.6.2 for risks associated with changes to critical processes.
Monitoring Commitments #
SP carries out extensive testing and evaluation of changes and adjustments to critical processes. Please see 5.1.1.6.2 for more information.
Documents #
5.1.1.6.2 - The repository shall have a process for testing and evaluating the effect of changes to the repository’s critical processes. #
Response #
SP tests and evaluates changes to its critical processes in an isolated development environment to ensure that changes will not disrupt normal operations or cause data corruption or loss. In addition to automated tests and checks performed by software, SP staff manually evaluate changes by examining samples of the relevant content. Staff evaluate changes for their effect on the integrity of information, the speed and efficiency of the system, and the accessibility and usability of disseminated information. The repository uses a code versioning system to record changes to software. Testing and evaluation continues in the production environment, and the repository uses JIRA for logging and reporting problems (see 5.1.1.3.1 for more information about JIRA).
Feedback from the Designated Community is an important source of information about accessibility, usability, understandability, holdings, and overall system performance. As described in 5.1.1.1.5, the repository receives ongoing and extensive feedback from its Designated Community.
Please see the Risk Analysis and Management Strategies document for additional information about software failure. SP has a Backup Plan that describes policies and procedures used by SP and the University of Toronto Libraries' Information Technology Services department to provide reliable backup copies of the repository’s data, databases, and applications.
Responsibility #
- Digital Preservation Librarian
- Software Developer
Potential Risks #
There is always a risk of software failure in complex information systems. SP uses widely accepted, industry-standard procedures for testing and evaluating software changes, but small errors or conflicts sometimes escape testing. Software failure could force SP to suspend certain operations until the affected systems can be thoroughly analyzed, repaired, and tested.
Monitoring Commitments #
SP will monitor changes to critical processes and procedures for compliance with the OAIS Mandatory Responsibilities. In addition, the repository will examine new editions of the OAIS Reference Model for changes to the Mandatory Responsibilities.
Documents #
- Critical Processes and OAIS Mandatory Responsibilities
- Risk Analysis and Management Strategies
- Backup Plan
5.1.2 - The repository shall manage the number and location of copies of all digital objects. #
Response #
SP uses an automated URI generation procedure, file naming procedure, and file system to manage the number and location of objects in a consistent manner. Each object has a unique, unambiguous URI and location in archival storage. This information is located in the preservation metadata. The TSM backup system has a database that associates tape backup copies with their originals in the Pillar storage array.
Please see the URI & File Naming Plan and Workflow Charts for more information. For reference, the Backup Plan is also available.
Responsibility #
- Digital Preservation Librarian
Documents #
5.1.2.1 - The repository shall have mechanisms in place to ensure any/multiple copies of digital objects are synchronized. #
Response #
SP does not have an online mirror site for its content, so it does not use online synchronization. TSM backup copies are synchronized with copies in archival storage by regular replication from a known good copy. The TSM backup system has a database that associates tape backup copies with their originals in the Pillar storage array. The Backup Plan describes how SP creates and manages backup copies.