18.104.22.168.1 Record and report to its administration all incidents of data corruption or loss, and steps shall be taken to repair/replace
|22.214.171.124.1 Record and report to its administration all incidents of data corruption or loss, and steps shall be taken to repair/replace|
|Status||Ready for review|
|Compliance Rating||Fully compliant|
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.
This is necessary in order to ensure the repository administration is being kept informed of incidents and recovery actions, and to enable identification of sources of data corruption or loss.
Examples for Meeting the Requirement
Procedures related to reporting incidents to administrators; preservation metadata (e.g., PDI) records; comparison of error logs to reports to administration; escalation procedures related to data loss; tracking of sources of incidents; remediation actions taken to remove sources of incidents.
Having effective mechanisms to detect bit corruption and loss within a repository system is critical but it is only the initial step of a larger process. In addition to recording, reporting, and repairing as soon as possible all violations of data integrity, these incidents and the recovery actions and their results must be reported to administrators and made available to all relevant staff. Given identification of the sources of data loss, an assessment of revisions to software and hardware systems, or operational procedures, or management policies is needed to minimize future risk of data loss.
At the time of ingest a fixity check is taking place that calculates SHA-256 and MD5 checksums and compares those to the ones supplied as part of the bag in the metadata. If a checksum mismatches the depositor will be notified by email about the data corruption.
The system conducts the same fixity checks every 90-days after ingest and reports the same way.
Alerts are displayed on through the PharosPharos is APTrusts web interface to manage deposits and inspect deposit outcomesETag The entity tag is a hash of the object. The ETag reflects changes only to the contents of an object, not its metadata. web interface to institutional administrators. The repository also notifies depositors about failed fixity checks and successful restorations through Email Notifications. Restoration of alternative versions are handled manually by APTrust staff.
See the page on Risk Management, Threats, and Mitigations for information on the identifying, preventing, and mitigating risks.
Also see section 126.96.36.199 for additional information.