Data Aging - Failed to run Data Aging job due to change in system time.

  • 12 September 2022
  • 9 replies

Badge +2

Hello All,

My apologies in advance if this ends up being something super simple.

Commvault seems to be throwing this error when attempting Data Aging:

Time difference between current time and last stored time in seconds : [3184347]
checkTimeShift() - Forward System time shift is greater than 1 day.
IsTimeShiftDetected() - Setting Cvd/isTimeShiftDetected registry key to [1]
Failed to run Data Aging job due to change in system time.

The time and date (as well as the time-zone) are correct on Commserve.

Has anyone encountered this before?
I’ve searched FAQs and I’m hoping there’s something I missed.


Best answer by Scott Moseman 12 September 2022, 22:34

View original

9 replies

Userlevel 6
Badge +18

Confirming CommServe Server Time Change

I cannot answer why your time may have changed, but you should be able to clear this by restarting the CV services and accepting the prompt warning about the time change.

This is a security setting which helps prevent someone or something from changing the CS time in an attempt to prematurely age backup data.


Userlevel 7
Badge +17

Do you use a time server to sync with?

Userlevel 7
Badge +23

If your CommServe is a VM, it could have moved to a different host where the time is dramatically different - the guest tools (i.e VMware Tools) automatically tries to sync the time with the host. That could be the reason why this happened without any changes to the machine.

I would check the application or system logs on the server to see if there are any clues.


Badge +2

Thank you Scott, Data Aging has completed successfully.

Thanks as well to Jos and Damian for the additional input,  yes it syncs with a time server and you assumed correctly CommServe is a VM and that could totally be what could definitely be the underlying cause.


I have failed.

system has been off for a long time

Please give specific guidance.



Commserve - Linux Server





Userlevel 2
Badge +5

Well I encountered this also in my lab.

Restart Commserve services in the Process Manager and accept your worst nightmare.

Luckily it's just my lab. 



Badge +1

I have Live Sync between a physical server and a VM running on a different server.  Not sure if the time on the VM was different at one point or not and perhaps that is what caused this issue.  The active CommServe has been on the physical server for probably the past year at this point.  I still get the message if I stop the services in Process Manager (yes I can always start the services one by one via Windows Services but that’s a tad painful).  I filtered the log and found the following. The time on my physical server is correct but I guess it conflicts with the database. 


The better question is how to fix it?


Badge +1

I know about the string.  It fails even when I copied it out of another ticket.


This is on 11.30.40

Badge +1

Updated the Last Stored System Time with the current time as given to me by:

and reset the time shifted back to 0

Error addressed.