Skip to main content
commvault.com commvault.com
Solved

Guest Files and Folders Restore does not restore everything

F
Byte
Forum|alt.badge.img+6

Hi,

 

Today I tried to to restore a Folder directly to a VM but only 5 of 6 Items were restored (if I restored the same folder directly to the MA all was fine). For this I used the Command Center.

I think this one file which was not restored has a problem if Commvault copies it over the network.

Here is a snippet of the log:

 

8164  d1c   08/18 09:16:09 29346 CVSAgentlessRestoreToVM::CopyToGuest() - Creating guest dir [D:\tmp\Scripte\]
8164  d1c   08/18 09:16:09 29346 CVWinGuestAPI::CopyFileToGuest() - MoveFileExW failed[2]! \\?\C:\Program Files\Commvault\ContentStore\iDataAgent\JobResults\CV_JobResults\2\0\29346\ForGuestVM\Scripte\geöffnete Dateien anzeigen.cmd -> \\?\UNC\192.168.50.238\D$\tmp\Scripte\geöffnete Dateien anzeigen.cmd
8164  d1c   08/18 09:16:09 29346 CVSAgentlessRestoreToVM::CopyToGuest() - Failed to copy [C:\Program Files\Commvault\ContentStore\iDataAgent\JobResults\CV_JobResults\2\0\29346\ForGuestVM\Scripte\geöffnete Dateien anzeigen.cmd] to [D:\tmp\Scripte\geöffnete Dateien anzeigen.cmd]
8164  d1c   08/18 09:16:09 29346 CVSAgentlessRestoreToVM::CopyToGuest() - Successfully copied file to guest VM srcPath[C:\Program Files\Commvault\ContentStore\iDataAgent\JobResults\CV_JobResults\2\0\29346\ForGuestVM\Scripte\SoftwareDestribution.cmd] VMdestPath [D:\tmp\Scripte\SoftwareDestribution.cmd]
8164  d1c   08/18 09:16:09 29346 CVSAgentlessRestoreToVM::UpdateFileTimes() - Successfully changed file attributes [D:\tmp\Scripte\SoftwareDestribution.cmd]
8164  d1c   08/18 09:16:09 29346 CVSAgentlessRestoreToVM::CopyToGuest() - Successfully copied file to guest VM srcPath[C:\Program Files\Commvault\ContentStore\iDataAgent\JobResults\CV_JobResults\2\0\29346\ForGuestVM\Scripte\TeamViewer_START.bat] VMdestPath [D:\tmp\Scripte\TeamViewer_START.bat]
8164  d1c   08/18 09:16:09 29346 CVSAgentlessRestoreToVM::UpdateFileTimes() - Successfully changed file attributes [D:\tmp\Scripte\TeamViewer_START.bat]
8164  d1c   08/18 09:16:10 29346 CVSAgentlessRestoreToVM::CopyToGuest() - Successfully copied file to guest VM srcPath[C:\Program Files\Commvault\ContentStore\iDataAgent\JobResults\CV_JobResults\2\0\29346\ForGuestVM\Scripte\TeamViewer_STOP.bat] VMdestPath [D:\tmp\Scripte\TeamViewer_STOP.bat]
8164  d1c   08/18 09:16:10 29346 CVSAgentlessRestoreToVM::UpdateFileTimes() - Successfully changed file attributes [D:\tmp\Scripte\TeamViewer_STOP.bat]
8164  d1c   08/18 09:16:10 29346 CVSAgentlessRestoreToVM::CopyToGuest() - Successfully copied file to guest VM srcPath[C:\Program Files\Commvault\ContentStore\iDataAgent\JobResults\CV_JobResults\2\0\29346\ForGuestVM\Scripte\WSUS.cmd] VMdestPath [D:\tmp\Scripte\WSUS.cmd]
8164  d1c   08/18 09:16:10 29346 CVSAgentlessRestoreToVM::UpdateFileTimes() - Successfully changed file attributes [D:\tmp\Scripte\WSUS.cmd]

 

 

Does anyone has the same Issue if special characters or spaces are in the filename?

 

Kind Regards

Florian

Best answer by Dan White

Hello @flokaiser 

 

For Agentless Restores we use the “Copy-VMGuestFile” CMDlet through VMware. However, I don’t see any character limitations on the VMware documentation for the CMDlet but judging by the log cuts it seems clear there might be.

 

Have you attempted other files with the “ö” character? Are you able to create another file with this character and try again?

 

When you restore to a Media Agent or any server with the Restore Only agent installed, you take the “Copy-VMGuestFile” CMDlet out of the equation which is why it is working.

 

 

View original
Did this answer your question?

6 replies

Mike Struening
Vaulter
Forum|alt.badge.img+23

Hey @flokaiser , thanks for the question!

I’m not aware of any direct issues, though we all know special characters have been known to cause issues.  I’ll ask internally for some feedback.

In the meantime, do you see any failure reason in the job details or job summary report (with details)?  curious if we can find out WHY it failed.

8164  d1c   08/18 09:16:09 29346 CVSAgentlessRestoreToVM::CopyToGuest() - Failed to copy [C:\Program Files\Commvault\ContentStore\iDataAgent\JobResults\CV_JobResults\2\0\29346\ForGuestVM\Scripte\geöffnete Dateien anzeigen.cmd] to [D:\tmp\Scripte\geöffnete Dateien anzeigen.cmd]

https://www.linkedin.com/in/michael-struening
MichaelCapon
1 person likes this
  • MichaelCapon
    MichaelCapon
F
Byte
Forum|alt.badge.img+6
  • flokaiser
  • Author
  • Byte
  • 48 replies
  • August 18, 2021

No, there are no special errors in the job.

D
Vaulter
Forum|alt.badge.img+8
  • Dan WhiteVaulter
  • Vaulter
  • 54 replies
  • Answer
  • August 18, 2021

Hello @flokaiser 

 

For Agentless Restores we use the “Copy-VMGuestFile” CMDlet through VMware. However, I don’t see any character limitations on the VMware documentation for the CMDlet but judging by the log cuts it seems clear there might be.

 

Have you attempted other files with the “ö” character? Are you able to create another file with this character and try again?

 

When you restore to a Media Agent or any server with the Restore Only agent installed, you take the “Copy-VMGuestFile” CMDlet out of the equation which is why it is working.

 

 

"If you give a man a fish, you feed him for a day. If you teach a man to fish, they will probably burn your spot"
Mike Struening
MichaelCapon
2 people like this
  • Mike Struening
    Mike Struening
  • MichaelCapon
    MichaelCapon
F
Byte
Forum|alt.badge.img+6
  • flokaiser
  • Author
  • Byte
  • 48 replies
  • August 19, 2021

Tried a few different Files with ‘ö’, ‘ä’ and ‘ü’ in the Filename or as Foldernames and everytime the job failed. I will use the filesystem agent for this cases now because this works without any problems.

Damian Andre
Vaulter
Forum|alt.badge.img+23
flokaiser wrote:

Tried a few different Files with ‘ö’, ‘ä’ and ‘ü’ in the Filename or as Foldernames and everytime the job failed. I will use the filesystem agent for this cases now because this works without any problems.

FS agent will give you much faster and efficient restores in either case (with the trade off of convenience of not deploying a FS agent), but I will escalate this on our side, we should not see this type of failure with either method!

Damian Andre
Vaulter
Forum|alt.badge.img+23

hey @flokaiser,

Engineering tested the special characters (its part of our automation testing, but they did it anyway) - they were unable to reproduce the issue, so it could be related to a specific feature release of maintenance release, system OS, file system or some other environmental anomaly. If you want to pursue this further for a fix or to identify the root cause, we’d need a support case and some logs to dig into it deeper.

 

I know that is a pain since you have a valid workaround, but more than happy to get this escalated to determine the root cause and fix if you would like to pursue it.

Reply


Most helpful members this week

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings