Child pages
  • Preservation Policies

Versions Compared


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


  • 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.

Other preservation-related items