cancel
Showing results for 
Search instead for 
Did you mean: 

Placeholder timestamps do not match originals in vault

RhoSysAdmin
Level 5

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?

 

1 ACCEPTED SOLUTION

Accepted Solutions

JesusWept3
Level 6
Partner Accredited Certified
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
https://www.linkedin.com/in/alex-allen-turl-07370146

View solution in original post

2 REPLIES 2

JesusWept3
Level 6
Partner Accredited Certified
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
https://www.linkedin.com/in/alex-allen-turl-07370146

RhoSysAdmin
Level 5

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.