The repository shall provide evidence of the effectiveness of its preservation activities.

This is necessary in order to assure the Designated Community that the repository will be able to make the information available and usable over the mid-to-long-term.

Collection of appropriate preservation metadata; proof of usability of randomly selected digital objects held within the system; demonstrable track record for retaining usable digital objects over time; Designated Community polls.

The repository should be able to demonstrate the continued preservation, including understandability, of its holdings. This could be evaluated at a number of degrees and depends on the specificity of the Designated Community. If a Designated Community is fairly broad, an auditor could represent the test subject in the evaluation. More specific Designated Communities could require significant efforts.

APTrust uses a subset of fields from the PREMIS metadata schema to record and report preservation event metadata.

APTrust maintains a central registry (a SQL database that is replicated across multiple AWS availability zones in Virginia, and to Oregon) describing all intellectual objects, which files belong to each object, and where those files are stored. Based on the metadata attached to the files, APTrust would be able to reconstruct all ingested bags, and know which institutions those bags and files belong to. See the Preservation Services Policy and Preservation and Storage.

APTrust may decide to trigger an action on the content for various reasons, including:

• Depositor terminates a corresponding Sustaining Member Deposit Agreement or Sustaining Member Cooperative Agreement
• Depositor requests Restoration of content
• Depositor requests Updating of content
• Disaster (see Risk Management, Threats, and Mitigations)

One depositor, Georgetown University, has successfully restored a number of bags. Restored bags (DIPS) differ slightly from the original SIPS in the following ways:

1. Entries in the manifest-md5.txt file may not be in the same order as the original.
2. The DIP includes a manifest-sha256.txt file, even if the SIP did not.
3. If the SIP, or any of its component files, was re-uploaded to APTrust after the initial ingest, the DIP will contain the updated versions of any files that were updated in the second upload. The DIP will also contain additional files added in the second upload. (Ditto for all subsequent uploads. We always return the latest version of the file.)
4. The DIP will not include any files deleted by the depositor after ingest.
5. The DIP will be packaged in the latest BagIt format at the time of restoration, regardless of which BagIt format the SIP used.

Georgetown University also reported a number of failed restorations in Spring of 2017. These were due to a software bug that caused certain larger files in the SIP to be stored incorrectly in our East Coast S3 storage area. The failed restorations triggered a manual audit by APTrust staff to identify and fix all files affected by the bug. APTrust staff used a custom script to fix all of the affected files by overwriting the incorrect versions in S3/Virginia with valid versions from Glacier/Oregon. The script is not part of APTrust’s automated systems.