Recovering a deleted C-Clip

Thanks Graham - that looks like it could do it.  All of the blobs were gathered at the end of the CDF & there didn't seem to be a relationship, but I finally realized that the index numbers in the tags correspond to the blob numbers.  There is one weird thing, though - the blobs span tags.  The tags are set to mimic file folders, with parent folders as the outer tags and child folders as inner, nested tags.  The vendor adapted their archiving process that wrote to optical platters to now write to the Centera.  It's a streaming process that doesn't pay any attention to the folder (now tag) structure.  The blob will have files from multiple, unrelated folder trees, all of which refer back to the single blob.

The more I look at it and think about it, I may have to extract out all of the images and documents to their original folder structure & re-archive them.  It may end up being the easiest way to get them their data back.

Thanks for your response.  I appreciate your time in looking at this.

Best wishes,

Daniel

Hi Daniel

I suggest implementing DelayedDeletes with an optional AdvancedRecovery on top of it. This would replicate the delete request with a configurable delay. This could be 3 months for your test and dev pool and one year for your production pool.

Recovery could then either be on a clip level on Centera or into a file based on the blobs being read from the replica system.

At least keep it in mind for your production environment.

CU, Holger

Thanks, Holger - I like that suggestion.  It wil be a part of my recommendations to the team for improving our current configuration.

Cheers,

Daniel

You can use the tools from the Centera SDK, specifically the JCASS tool. You can open C-Clips and see their contents.

what error are you getting back from the SDK when you try and open the clipid?

If you have deleted it you'll get an error that sounds like it just doesnt exist on the cluster.  If its corrupt I think you'll get a different type of error

As Daniel suggests using jcasscript rather than your application will help you

Hello, while researching answers for a similar problem I came across this post.

I have an application that writes to Centera, plain and simple, we write the file and store the ClipID in our database, later randomly we request the file and la la its usually pulled back down. Currently two ClipIDs that had been written right next to each other in a series are showing not valid.

The environment is a live customer environment and they are wondering why our software deleted these files. Everything we can tell thus far shows us that we did not delete the files, there are no log data showing the deletion but the customers storage team insists that the ClipID is not found on the Centera Device.

Does anyone have any clue how something like this could happen?

How often does file corruption happen on these devices? (I hate to use that word on your own website but I am running out of ideas here)

Also any clues on how I could go about recovering this, or at least explaining it.

I have the clip ID and thats about it.. I also have general file information (name, size, type, date inserted, ect..)

Thanks!

We are still trying to ensure our software hasn't deleted it...

I'd like to know if there is anyway a clipID could be returned without a the data being written.

Also any ways to verify that the ClipID index hasn't become corrupt.

Thanks for the very very fast response by the way!

It is very rare for a objects to become corrupt or unreadable on a Centera but of course if multiple node failures have occured it can happen (thats why we have replication!)

As this is a customer production site please get the customer to submit a fault call to EMC support.  As this is a Data Loss issue they should get a priority response.

If your customer does have replication set up then its likely the clips can be read back from the replica.  EMC support have tools to try and recover missing files and the very least they can try and figure out what went wrong

Not really sure what error they see or what tool the customer is using to verify these ClipIDs. Our next step will most likely be to contact EMC support for assistance but at the moment still looking at a few things to try and very our system didn’t delete the files (There is retention built into our software so we need to confirm every avenue before trying to blame it on the storage device). ☺

Thanks for your help!