The repository shall have procedures for all actions taken on AIPs.

This is necessary in order to ensure that any actions performed against an AIP do not alter the AIP information in a manner unacceptable to its Designated Communities.

Written documentation describing all actions that can be performed against an AIP.

This documentation is normally created during design of the repository. It should detail the normal handling of AIPs, all actions that can be performed against the AIPs, including success and failure conditions and details of how these processes can be monitored.

Preservation and Storage covers the regular preservation lifestyle and storage considerations for digital files being preserved by APTrust.

APTrust performs fixity checking on individual files every 90 days. Fixity checks do not alter the AIP or any of its component files. Failed fixity checks generate alerts to both APTrust staff and the depositing institution.

When a fixity check fails, indicating a missing or corrupt file, we retrieve another copy of the same file from a different storage location (Glacier in Oregon), validate the fixity on that copy, then overwrite the bad copy with the valid copy. This process currently requires intervention from APTrust staff. We have scripts to repair missing and corrupt files, but an APTrust staff member must manually run the scripts. We ran them in 2017 to fix a number of files that were incorrectly copied to long-term storage upon ingest, so we know the scripts work.

APTrust also provides a “restore” feature. When a depositor requests that we restore an object, our system does the following:

1. Gather a list of all files that constitute the object (the AIP).
2. Copy all of the AIP files to a local staging area and validate their sha256 checksums.
3. Assemble all of the files into a single tarred BagIt bag (the DIP).
4. Validate the bag (the DIP).
5. Copy the bag to an S3 bucket from which the depositor can download it.
6. Make a note in our registry/web UI/REST API that the restoration is complete. The note tells the depositor the URL from which they can download the DIP.

The restoration process does not alter or delete the AIP files in the preservation storage area.

APTrust also provides a deletion feature. To delete an object or file, a user must log in to our WebUI (Registry) with a valid email address and password. If the user has delete permissions, they can request that an object or file belonging to their institution be deleted. Our system then emails the administrative user at the depositing institution with a message saying which user at his/her institution requested deletion of which file or object. The administrative user can approve or deny the deletion request by clicking the appropriate link in the email. (The email links contain randomly generated tokens to ensure authenticity.) The system will delete the object or file from preservation storage only after the depositor’s administrative user approves the action. Upon deletion, the system creates a PREMIS event describing when the object was deleted, and at whose request. The system also keeps tombstone records of all deleted objects and files. The tombstone records are identical to the records of existing items, except that the item’s State attribute is changed from “A” (active) to “D” (deleted).

APTrust depositors who are also DPN members may push items from APTrust into DPN by clicking a button in the APTrust WebUI The initial request to move an item to DPN creates a Work Item record in APTrust. The depositor can monitor the state of the Work Item as it moves through several phases. When the item is ingested into DPN, APTrust creates a PREMIS event record describing when the item was copied into DPN. The PREMIS record also includes the item’s DPN identifier. Pushing an item to DPN does not alter the state of the item in APTrust’s preservation storage.

Also see the Academic Preservation Trust Core Preservation Service Policy, Version 1.0: https://doi.org/10.18130/V3N58CK61