I have been noticing the below error in my "CBEngineCurr.errlog" log file. Would anyone know which key this error is referring to?
28E8 10B4 03/17 20:02:29.824 32 KeyManager.cpp(955) WARNING CKeyManager::IsKeyExpired::Key is expired according to expiry days [180]
@jham6509-5400 Are you using Azure Key Vault to store keys?
In the past, we noticed that this issue occurs if MARS agent cache folder is located under OS volume. changing the location usually fixes this issue. You may refer to a similar issue here - https://social.technet.microsoft.com/Forums/en-US/0e7e43cd-61ae-4761-9641-216138813b98/error-authentication-token-for-microsoftazurerecoveryservices?forum=windowsazureonlinebackup might be helpful.
Let us know how it goes!
If the response helped, do "Accept Answer" and up-vote it
I found the documentation below on how to change the Scratch location. Do the contents really need to be moved? What would I need to do if I wanted to completely get rid of its contents and start over with a new Scratch folder?
https://docs.microsoft.com/en-in/azure/backup/backup-azure-file-folder-backup-faq#backup
The scratch folder was moved to a non-OS disk but I am still having issues. Online recoveries appear to be working fine for SQL backups but disk/folder backups are all failing when attempting to do a Online Recovery Point.
This started happening around the same time as the thread below.
@SadiqhAhmed-MSFT Is there someone that I can send my CBEngineCurr.errlog to for review?
@jham6509-5400 You can safely ignore this warning for now. Additionally, moving around the scratch folder is not going to resolve this.
Thanks for bringing this to our attention. We can take a fix in one of the subsequent releases to address this message.
Regarding the question of moving of scratch folder, there are some files and settings which are to be copied (eg: OnlineBackup.kek) since there is no direct way for MARS agent to regenerate this without customer intervention. Hence, it is advised to copy the contents.
If the response helped, do "Accept Answer" and up-vote it
@jham6509-5400 - Sharing the solution with the community
Resolution:
Moving a large volume of data will take longer than moving a smaller volume of data. In some cases, backup time is related to not only the size of the data, but also the number of files or folders. This is especially true when millions of small files (a few bytes to a few kilobytes) are being backed up.
This behavior occurs because while you're backing up the data and moving it to Azure, Azure is simultaneously cataloging your files. In some rare scenarios, the catalog operation might take longer than expected.
If the response helped, do "Accept Answer" and up-vote it
4 people are following this question.
