Child pages
  • Preservation Policies

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

RLG "Trusted Digital Repository" Checklist

The most important document related to preservation is RLG's Audit Checklist for the Certification of Trusted Digital Repositories.

Items on RLG's checklist of immediate interest


. For the most part, these items relate to our use of HPSS:

  • 3.6 Repository commits to define, collect, track, and provide, on demand, its information
    integrity measurements.
  • B1.1 Repository identifies properties it will preserve for each class of digital object.
  • B1.5 Repository obtains sufficient physical control over the digital objects to preserve
    them. (The description of this is confusing, encompassing many different aspects of repository functionality.)
  • B2.1 Repository has an identifiable, written definition for each AIP or class of information
    preserved by the repository.
  • B2.4. Repository has and uses a naming convention that can be shown to generate visible,
    unique identifiers for all AIPs.
  • B3.7 Repository actively monitors AIP integrity. (This includes maintaining checksums in a location separate from media files, and maintaining logs of the integrity checks.)
  • B4.2 Repository can demonstrate that referential integrity is created between all AIPs and
    associated descriptive information.
  • B5.2 Repository logs all access management failures, and staff review inappropriate
    "access denial" incidents. (This should probably apply both to Fedora and to HPSS.)
  • D1.1 Repository functions on well-supported operating systems and other core
    infrastructural software. (Not sure if HPSS will ever meet this...)
  • D1.2 Repository ensures that all platforms have a backup function sufficient for the
    repository's services and for the data held, e.g., metadata associated with access controls,
    repository main content, etc.
  • D1.4 Repository has mechanisms in place to insure any/multiple copies of digital objects
    are synchronized.
  • D1.5 Repository has effective mechanisms to detect data corruption or loss. For example, if the policy were the repository could not lose more than 0.001% of the collection per year, then the repository would need to confirm media integrity at least every 72 days to achieve an average time-to-recover of 36 days or about one tenth of a year.
  • D1.6 Repository reports to its administration all incidents of data corruption or loss, and
    steps taken to repair/replace corrupt or lost data.
  • D1.7 Repository has defined processes for storage media migration.
  • D1.8 Repository has a documented change management process that identifies changes to
    critical processes.
  • D1.9 Repository has a process for testing the effect of critical changes to the system.
  • D1.10 Repository has a process to stay current with the latest operating system security
  • D3.4 Repository has written disaster preparedness and recovery plan(s), including at least
    one off-site copy of all deposited data. Multiple off-sites copies are expected of most repositories, but others may be able to justify not providing these.
  • D3.5 Repository tests disaster plans regularly.
  • D3.6 Repository has defined processes for service continuity and disaster recovery.

Possible threats to the preservation repository

  • Failure to access HPSS
  • Failure of HPSS tapes
  • Fire, tornado, or other catastrophic failure in WCC machine room
  • Disgruntled employee attempts to delete everything from HPSS
  • Disgruntled employee attempts to delelte random sets of items from HPSS

Other preservation-related items