DRS3 FAQ

What is the difference between "DRS Futures" and "DRS3" and "Libsafe"? Or between "DRS2" or "DRS Legacy"? How are any of those different from just "DRS"?

DRS is a service.

• At the core of the Digital Repository Service is the DRS system (the technical platform which facilitates digital preservation), but the Digital Repository Service is also the people, policies, and procedures that ensure that the system provides archival integrity, authenticity, and usability of digital content over time. Service ownership for the DRS is held by Digital Preservation Services (DPS), represented by Abby Wolf. Product ownership for the DRS system is held by Library Technology Services (LTS), represented by Vitaly Zakuta.

DRS Futures is a project.

• It is a multi-year, ITCRB-funded project to modernize the technical infrastructure of the DRS system.

DRS2 is a system.

• "DRS2" and "DRS Legacy" are synonymous and refer to the version of the DRS system in use prior to the implementation of Libsafe as a result of the DRS Futures project. DRS2 is expected to remain in use until fall 2026.

DRS3 is a system.

• "Libsafe" and "DRS3" are synonymous and refer to the new DRS system that will be implemented as a result of the DRS Futures project (anticipated rollout spring 2026). Libsafe is a vended system developed by Libnova.

How is data stored and protected in DRS3?

DRS3 uses a multi-copy, multi-vendor preservation strategy.

During initial rollout (April–November 2026):

• Hot storage: AWS (active workspace)

• Cold storage: Amazon Glacier backup

After full archival implementation:

Four preservation copies:

1. Cold archive copy (AWS)

2. Additional cloud copy (Wasabi, Harvard-managed)

3. Tape copy (vendor-managed)

4. Tape copy (Harvard-held)

Should we maintain local copies until ingest and replication are confirmed?

Yes. Repositories are advised to retain local copies until ingest and replication are confirmed.

Can we create deeper hierarchical collection / object structures?

No.

• Objects must be placed directly under containers (formerly billing codes)

• No additional object hierarchy layer is allowed

• However, inside object folders additional folder and subfolder structures are supported - they just can’t be other objects

What counts as an "object"?

An object is the top-level unit (folder) inside a container (insides which there may be additional folders with content or direct content such as image, video, grouped files, page-turned document).

How do we represent collections?

Through metadata, not hierarchy.

How do we improve discovery?

Through strong metadata and search. There is no hierarchical browsing.

Will there be standardized metadata practices?

Not automatically. Archivists must develop shared best practices.

Can we experiment with structures inside the objects?

Yes. Testing multiple approaches during training is encouraged.

How is Page-Turned Object structure handled during ingest?

Currently UI-based; planned support for JSON/CSV structure ingestion.

What new functionality does DRS3 provide?

• Built-in viewer (images, PDF, audio, video)

• Format conversion (e.g., OCR PDFs)

• Emulation for legacy formats

Can users generate searchable PDFs?

Yes, directly in LibSafe.

How can restricted content be shared directly from LIBSAFE?

Still under investigation. Possible approaches include manual download or time-limited links.

Will DRS3 integrate with Alma?

Not at launch. Integration is on the roadmap.

What training will be available?

• Overview and interactive training (starting March 31)

• Advanced training sessions

• Custom support and consultations

Will we have a testing environment?

Yes. QA environment available March 31 with nodes and container structured in the same way as in prod.

What documentation is available?

• LibSafe User Guide

• Harvard-specific documentation

• Data glossary and schema crosswalk (in progress)

What is the transition timeline?

• March 31: Training + QA

• April 14: DRS2 freeze

• April 28: DRS3 production launch

What delivery features are available at launch?

Available:

• Image delivery

• Page-turn objects

• Generic file download

Delayed:

• Full-text search

• AV streaming

How can we determine if an S3 (Cyberduck or similar) submission has failed?

• Although we are working on notifications that will provide failure information, you can also check the logs in the system for more immediate data. This page details that scenario: https://harvardwiki.atlassian.net/wiki/x/PYA-Ng

If a submission fails and needs to be retried:

• Can we reuse the same submission file name?

  • This will overwrite the previous version. 

• Should the previous submission be removed from S3 before retrying?

  • This is advisable

For successful submissions, should we clean up files in S3, or does Libsafe handle removal of processed files?

• For successful submissions, they are removed automatically, nothing more you need to do

‌