Documentation

Backup Plan

Backup Plan

1. Policy Statement

As part of York University Libraries (YUL) implementation of the Bit-stream Copying Preservation Strategy (as detailed in the Preservation Implementation Plan), YUL is committed to regular backup procedures of both data storage areas and its operational areas (e.g. databases, application files). These backups are intended to serve as the basis for restoration of York University Digital Library (YUDL) materials in the case of disaster recovery or corruption of data.

Data backup at YUL is coordinated through Library Computing Systems and University Information Technology. Since the data is stored on physical hardware located in the YUL data centre, it uses the same backup hardware and software as the general university systems.

2. Implementation

2.1 Database Backup

This backup strategy applies to content that is stored in a database. Primarily, this refers to objects located in YUDL's databases (MySQL).

2.1.1 MySQL Database Backup Strategy

  • Database dumps are backed up daily and taken off site. Each backup is kept for 60 days.

2.2 Application Backup

2.2.1 Fedora Commons Backup Strategy

  • Fedora Commons is backed up daily and taken off site. Each backup is kept for 60 days.

2.2.2 Drupal (Islandora)

  • Drupal is backed up daily and taken off site. Each backup is kept for 60 days.

2.2.3 Solr

  • Solr is backed up daily and taken off site. Each backup is kept for 60 days.

2.3 Objects

  • Fedora objects are backed up daily and taken off site. Each backup is kept for 60 days.

2.4 Verification

  • Quarterly disaster recovery drills coordinated between the Digital Assets Librarian and YUL Library Computing Systems to test system verification.

Acknowledgements

Adapted from and inspired by:

License

CC0

CC0 1.0 Universal (CC0 1.0) Public Domain Dedication

Fixity procedures

Policy Statement

York University Library are committed to maintaining the integrity of objects in its care. This includes creating checksums for all archival format objects -- plus associated datastreams -- ingested into the repository, and regular fixity checking of those objects.

Implementation

At the time of ingest an SHA1 checksum value is calculated for the archival format object, and is stored along the object in the repository.

Daily, a set number of files in the repository will have their current checksum calculated (using a single checksum) and compared to this stored value, which is expected to match. In cases where the calculated and stored values do not match, this is reported to the repository manager.

Acknowledgements

Adapted from and inspired by:

License

CC0

CC0 1.0 Universal (CC0 1.0) Public Domain Dedication