1. It is a file belonging to a backup of a different VM environment, which cannot be directly backed up by our B+R (essentials). The procedure is:
- a) VM environment backs up to share on Server A with VMware data recovery
- b) some other physical servers back up to Veeam repository on Server A with endpoint backup
- c) Server A actually backs up itself (Veeam repository excluded) to the Veeam repository with endpoint backup
- d) Veeam B+R running on Server A backs up Veeam repository to tape
- Step c fails sometimes while reading files of the VMware data recovery (which is not active at that moment).
2. The file is located on a local drive in a not too long path: F:\external_backup\VMwareDataRecovery\BackupStore\000\slab-930
Although your configuration is quite tricky I can't find an explanation why the backup fails. Please open a case with our support team. Aslo may I ask you why your VM can't be backed up with B&R?
We cannot backup the VMs with B&R, because of our license. We have Backup essentials including B&R. We are only allowed to backup VMs running on 6 CPU sockets. We are backing that VMware environment up with B&R. But we have a second (older) VMware environment with another 3 hosts and cannot back that up with the essentials license.
That's why we still need to additionally use VMware Data Recovery appliance.
Is there anything else except B&R and shared folder on Server A? Have you thought about virtualizing it so B&R could backup itself? I think that would simplify the whole schema.
Anyway I still suggest you to open case with support and post your case ID here.
the physical Server A does not only contain B&R but also VCenter. The Server A has a lot of diskspace, because we are backing up our virtual environment to disk first and in a second step to tape. So I think it won't make sense to virtualize that Server.
We have made very bad experience with Veeam Support. We did open 2 Support cases so far. We gave a detailed description of our problem to the Support in both cases from the beginning, but the Support Team actually didn't even completely read our description and asked several times for information, which they already got before.
We stopped the first case and found a solution on our own. The second case was not solved by the Support Team, they just played along with us and told us that the (in our opinion severe bug) will sometime be fixed in a future version of B&R (The Backup browser actually has a severe bug: If files/folders from guest operating systems are not restored to the original location, but copied to a different location (via "CopyTo" in backup browser), the names of the files and folders are changed by B&R! Leading dots are removed, which occur e.g. in configuration files of eclipse IDE. A backup solution must never change contents or names of files!)
That's why I don't really want to open a Support case...
May I ask you to provide case IDs for purpose of improving customer experience?
That's why I don't really want to open a Support case...
Have you tried to escalate the case ("Talk to manager" button)?
The Backup browser actually has a severe bug: If files/folders from guest operating systems are not restored to the original location, but copied to a different location (via "CopyTo" in backup browser), the names of the files and folders are changed by B&R! Leading dots are removed, which occur e.g. in configuration files of eclipse IDE. A backup solution must never change contents or names of files!)
Will pass this to our QA team for deeper investigation.
One more question: does the VEB account has full access (read/write permissions) to access this folder? Check if this folder is accessible while logged in under the user account with running VEB
May I ask you to provide case IDs for purpose of improving customer experience?
I will post them as soon as I get them (from my colleague).
Have you tried to escalate the case ("Talk to manager" button)?
No we did not. We wrote twice in the mails that it is an important function for us, but that did not change anything.
Will pass this to our QA team for deeper investigation.
It is easily reproducable.
One more question: does the VEB account has full access (read/write permissions) to access this folder? Check if this folder is accessible while logged in under the user account with running VEB
I don't unterstand that question. I think VEB is running with the local SYSTEM account which is of course able to access all local files (edit: SYSTEM is contained in ACL of given file and has full Access). The credentials used in VEB are only used to store the backup in the Veeam repository?
The Backup browser actually has a severe bug: If files/folders from guest operating systems are not restored to the original location, but copied to a different location (via "CopyTo" in backup browser), the names of the files and folders are changed by B&R! Leading dots are removed, which occur e.g. in configuration files of eclipse IDE. A backup solution must never change contents or names of files!
Will pass this to our QA team for deeper investigation.
This is in our opinion a severe bug. It can be reproduced very easy:
- create a file named ".test" in a VM
- backup the VM
- restore guest file
- copy file to a different location than source location
- file will be copied but renamed to "test" (without leading dot)
File names with leading dots are allowed in Windows and they are e.g. used by Eclipse Java IDE.
I was told that there is a solid workaround. Run a File Level Recovery, then minimize the backup browser and navigate to C:\VeeamFLR (the folder used for mounting you backup). Then just drag and drop the needed files from the backup to the desired directory – the file name should remain untouched.
Can you elaborate why the described workaround is not an option for you?
Because it is a workaround.
I want to use the integrated "copy to" function in the software I paid for and I cannot understand why this essential function has not been fixed for months now.
To other users, which do not know that workaround, it can happen that they accidentally restore data wrongly, because Veeam does change it (the filenames)!
The Backup browser actually has a severe bug: If files/folders from guest operating systems are not restored to the original location, but copied to a different location (via "CopyTo" in backup browser), the names of the files and folders are changed by B&R! Leading dots are removed, which occur e.g. in configuration files of eclipse IDE. A backup solution must never change contents or names of files!)
Will pass this to our QA team for deeper investigation.
You passed this in 02/2016 (!) to your QA Team.
That bug is still existing in all backup browsers, used in Backup & Replication 9.5U2 and also in Veeam Agent for Windows 2.0.
This is a severe bug which probably can be fixed quite simple.
We gave you a straight description how to easily reproduce the bug:
- create a file named ".test" in a VM
- backup the VM
- restore guest file
- copy file to a different location than source location
- file will be copied but renamed to "test" (without leading dot)
It can also easily be reproduced by restoring individual files with a leading dot in filename in Veeam Agent for Windows.
It is very disappointing how this is handled by Veeam Team!
Unfortunately, this behavior remains the same in existing version.
This is a severe bug which probably can be fixed quite simple.
According to QA the fix is not easy – we must implement the special character checks based on operating system you are restoring to. That is the reason why the fix is delayed but we do have plans to implement it anyway.
I don't quite understand, why filenames have to be adjusted at all when restoring. The files are mounted into the local filesystem the correct way and are changed when restoring. I don't want my backup software to change any file names!
Nevertheless it's absolutely disappointing and inacceptable how the Veeam Team handles requests to fix bugs. We planned to use Agent for Windows to backup >100 Clients. We will not do that with Veeam anymore.
During recovery we create a new file and must obey the character limitations of the operating system otherwise the file creation fails. Frankly speaking we are in the situation where file level recovery either fails or modifies the file name (deletes the forbidden character) and succeeds in recovery. We went the second road.
Why should the filename not be allowed when restoring a file to the original location? It existed with that name before so it can be assumed that it is valid.
Why does Veeam not allow filenames with leading dots? They are actually allowed in Windows OS!
If Veeam for what reasons ever does change anything when restoring, it should at least inform the user about that.
As I said before: We have many Java developers using Eclipse IDE. They have lots of filenames with leading dots on their workstations. Because of that misbehavior of Veeam (IMHO) we cannot use Veeam for backing up the clients up.
I agree that this behavior is unexpected and should be fixed. I’ll check the status of this bug on Monday and update this thread with results. Meanwhile, I asked support team to create a KB.