preservation copy of vq518cf9512 (service disk 8) has a number of issues #1395
Comments
jmartin-sul
added
the
moab_remediation
jmartin-sul
changed the title
|
questions for all of these remediations: have the moabs in question been replicated? if so, do the archives need to be re-pushed? related useful query: https://github.com/sul-dlss/preservation_catalog/tree/master/db#view-the-zip-parts-for-a-given-druid input> druid = 'ab123cd4567'
input> ZipPart.joins(zipped_moab_version: [{ complete_moab: [:preserved_object] }, :zip_endpoint]).where(preserved_objects: { druid: druid }).pluck(:druid, 'current_version AS highest_version', 'zipped_moab_versions.version AS zip_version', :endpoint_name, :status) |
|
With the help of @jmartin-sul did some exploration for the missing files in druid vq518cf9512 and found JIRA ticket LEGACY-2715 from 2016 that mentioned two files to be removed are:
The DRUID is accessible at this PURL link with these five remaining files available for download through stacks but are missing from both versions on the preservation storage root of
@andrewjbtw any suggestions on the best process for remediation of druid vq518cf9512? |
|
I've looked at the expunge documentation and the procedures there aren't detailed on how to make something a valid Moab. The last step is literally:
It also says that part of expunging is to set the version back to 1. Looking at preservation and the workflows, it appears that the versioning information is inconsistent across systems. It's not clear to me that all the steps were followed. I think for remediation, I should try to bring things in line with what expunging is supposed to do. Since expunge is on the list of repo manager tasks, you can go ahead and assign this issue to me. |
|
There are many things wrong with this object beyond the Moab state. It looks like what should have happened was:
Looking at the JIRA ticket, it appears that the files went through multiple rounds of review, which prevented this from being a one-time process where all steps were followed in sequence. I believe this is why:
I think that if we accept that there is currently a v002 (avoiding the need to update prescat to show only one version) I can:
|
|
I've now made this into a valid Moab. To do so I needed to:
Remediation won't be complete until the workflows are also fixed and I've confirmed that a new object version can be created. I think what's left to do now is to delete the duplicate version 1 and version 2 workflows, which were likely created because the object was reaccessioned after the version numbering had been reset to 1. |
|
Ok, I've cleaned up the workflows on this item, created a new version successfully, and re-run the audit successfully. So I think it's closeable. |
spawned from #1324.
when looking for moabs with non-
okstatus, one that turned up was:when looking at that object on disk, it appears that there are only two version directories, neither with
data/contentsubdirectories, though thesignatureCatalog.xmlfiles expect a number of content files.other oddities:
signatureCatalog.xmlfiles also refer to a number of missing datastream files.checksums for /services-disk08/sdr2objects/vq/518/cf/9512/vq518cf9512/v0002/data/metadata/events.xml version 2 do not match.)signatureCatalog.xmlfor a given version should have signatures for content from all prior versions, but no knowledge of subsequent versions, as moabs are structured using a forward-delta versioning approach)./services-disk08/sdr2objects/vq/518/cf/9512/vq518cf9512/v0002/manifests/signatureCatalog.xml refers to file (/services-disk08/sdr2objects/vq/518/cf/9512/vq518cf9512/v0003/data/metadata/events.xml) not found in MoabThe text was updated successfully, but these errors were encountered: