Video Screencast Help
Symantec Appoints Michael A. Brown CEO. Learn more.

Placeholder timestamps do not match originals in vault

Created: 09 Jan 2013 | 2 comments

I'm doing some testing with fsautility and the -b function.  It is consistently restoring files with modify dates precisely 4 (or 5) hours older than the timestamps that were on the placeholders.  After some spot checking of files in the vault versus the equivalent placeholders on my CIFS share, everything in the vault is consistently 4 or 5 hours older than the equivalent placeholder timestamp.

It's worth noting that these placeholders have all been migrated from a Windows file server to a CIFS share on a NetApp.  I don't know if this is relevant point or not.

I've checked the clock settings on my EV server and they're correct, as is the timezone.

I don't know whether this is an EV issue or not.  Could it be the placeholder migration (fsautility -pm) I did back in November?

 

Comments 2 CommentsJump to latest comment

JesusWept3's picture

what timezone is the server?
Its possible its not converting the times properly, all the times held in the database are UTC (typically 5 hours ahead of EST) and if thats the case and its an issue, you may have to call support

One thing you could try if you have a lab environment you don't mind messing around with is to change the date of an item in the database for the idDatetime and then restoring via FSAUtility and then seeing if that item restores with the correct date/time etc and if it does change it to the time you set, then you know whats happening

However would not recommend that in a production environment etc

RhoSysAdmin's picture

my server is in EST.

upon further review, it's the modify date on the placeholder that's wrong.  The modify date of the original file in the vault is correct.  The modify date on the placeholder is the date that's wrong.  So the problem could be when the placeholder was created.

The CreatedDate is correct on the placeholder so I don't see how migrating the placeholders could have changed just the Modify date. 

I've opened a case with Symantec and they're researching it.