...
- The DuraCloud user browses the snapshot listings and clicks the "Restore" button on a snapshot
- The DuraCloud UI calls a DuraCloud Restore task
- The DuraCloud Restore task creates a space where the restored content will be placed and calls the bridge application with a restore request
- A bucket policy will be added to the space to delete content after a set time period (3 weeks? a month?)
- The bridge application adds an entry to the restore db table
- The bridge application creates a directory in bridge storage and sends a notification to Chronopolis to request a restore action
- Chronopolis copies the contents of the snapshot DPN bag to the bridge storage directory (Question - what ties are there between Chronopolis manifest and DuraCloud verification? - David)
- Chronopolis will validate the files on the bridge storage against the manifest in the bag (originally created during the snapshot phase)
- BagIt files are omitted during the copy, leaving only the files which were originally written by the bridge application
- The bridge application copies content from bridge storage to DuraCloud space
- The bridge application reads the content metadata file and updates each content item with its metadata values
- The bridge application verifies (based on manifest) that content transferred to DuraCloud is consistent with the content that was originally in DuraCloud (pre-snapshot)
- The bridge application deletes the directory in bridge storage used for the restore action
- The bridge application notifies the user who requested the restoration that the process is complete, informs them of the space ID where they can find their content, and tells them the date on which the content will be removed
...