It’s been awhile since we last wrote about the preservation architecture underlying the repository in Preservation Architecture: Phase 2 – Moving Forward with Duke Digital Repository. 
We’ve made some terrific progress in the interim, but most of that is invisible to our users not unlike our chilly friends, icebergs.
Let’s take a brief tour to surface some these changes!
Policy and Procedure Development
The recently formed Digital Preservation Advisory Group has been working on policy and procedure to bring DDR into compliance with the ISO 16363 Audit and Certification of Trustworthy Digital Repositories Minimum Criteria. We’ve been working on diverse policy areas like defining how embargoes may be set; how often fixity must be checked and reported to stakeholders; in what situations may content be removed and who must be involved in that decision; and what conditions necessitate a ‘tombstone’ to explain the removal of an object. Some of these policies are internal and some have already been made publicly available. For example, see our Deaccession Policy and our Preservation Policy. We’ve made great progress due to the fantastic example set by our friends at Purdue University Research Repository and others.
Preservation Infrastructure
Durham, North Carolina, is a lovely city– close to mountains, the beach, and full of fantastic restaurants! Sometimes, though, your digital assets just need to get away from it all. Digital preservation demands some geographic diversity. No repository wants all of its data to be subject to a hurricane, of course! That’s why we’ve partnered with DuraCloud, a preservation-focused cloud provider, to store copies of our digital assets in geographically diverse locations. Our data now enjoys homes at Duke, at DuraCloud, and in Amazon Glacier!
To bring transparency to the process of remotely replicating our assets and validating the local and remote assets, we’ve recently implemented a process that externalizes these tasks from Fedora and delivers scheduled reports to stakeholders enumerating and detailing the health of their assets.
Research and Development
The DDR has grown tremendously in the last year and with it has grown the need to standardize and scale to demand. Writing Python to arrange files to conform to our Standard Ingest Format was a perfectly reasonable solution in early 2016. Likewise, programmatic reformatting of endangered file formats wasn’t feasible with the resources available at the time. We also did need to worry about traffic scaling back then. Times have changed!
DDR staff are exploring tools to allow non-developers to easily ingest large amounts of material, methods to identify and migrate files to better supported formats, and are planning for more sustainable and durable architecture like increased inter-application messaging to allow us to externalize processes that have been handled within the repository to external servers.