Hi guys, first post here and quite rookie at vmware/veeam but ive found a problem i cant resolve and the closest reference ive found on forums ( http://forums.veeam.com/viewtopic.php?f=2&t=10867 ) doesnt apply to my case because the disks are shown as basic on the storage management console of de SO (2k8r2). Ive also contacted regional support and a third party provider that gives us support without success. This issue is a game breaker and would mean for me to try another backup tool, but i really would prefer to continue using veeam.
So the actual problem is that all logs give success for all vms of the hosts (2x IBM 3650 attached via fiber to IBM Storage V3700, ESXI 5.1), but when i try to recover guest files from two previously physical servers that were converted to virtual machine with vmware application, it shows only a C: partition that actually is the EFI partition of the vm, and i cant recover files from the "real" C: drive and E: drive.
Using Veeam 6.5 patch 3 with a proxy inside one of the vms of the storage via hotadd.
1) Are there any disk exclusions specified in the job settings (Virtual Machine -> Exclusions -> Disks)?
2) Do all the drives reside on the same .vmdk disk or on separate ones? Might be it possible that drives in questions reside on disk of unsupported type (
(physical RDM, independent disks) or connected to Windows machine thorough ISCSI initiator?
v.Eremin wrote:1) Are there any disk exclusions specified in the job settings (Virtual Machine -> Exclusions -> Disks)?
2) Do all the drives reside on the same .vmdk disk or on separate ones? Might be it possible that drives in questions reside on disk of unsupported type (
(physical RDM, independent disks) or connected to Windows machine thorough ISCSI initiator?
1) All vms shown as "All Disks" on exclusions
2) Each vm has only one vmdk where all logical disks reside
It is shown on "Other OS" type, but its way slower then guest file restore and incorrectly shows the tildes (spanish language) of files as a question mark inside a black romboid.
At least, we know now that the required files have been successfuly backed up. As another possible workaround, you can start "Windows Guest" restore, wait till the Backup Browser shows up, then, go to C:\VeeamFLR folder, using Windows Explorer, and see/copy whether corresponding files are present there.
Well guys im updating the satus of this problem just in case someon else runs into it.
After Tier1, 2 and 3 support they still dont know what causes the Veeam 6.5 patch3 Windows FLR to fail mounting the supported partitions (NTFS) while showing the unsupported one (EFI) as C:
Apart from that, Other OS FLR while mounting them, is also having issues with folder and archive names that contain spanish characters (á, é, í, ó, ú, ñ).
Veeam processing speed and straightoward approach as a backup tool is outstanding, but i have to wonder how at version 6.5 it still have problems with perfectly functioning NTFS partitions (they tried many things to find a possible corruption/problem in the virtual machine disks but nope, its not a VMWare/OS problem) and standard spanish characters (im the only spanish language guy using veeam? dont think so!).
I really hate bloated software like the other option my company is giving me and im doing everything possible to make veeam work, but as support level escalated the dispositiong to fix my problems have diminished.
It it were my product, i would use as many resources needed to fix problems of a potential customer thats trying the software and cooperates with each support request (following instructions and doing things myself / remote desktop sessions they have done)
I think it's likely the problem doesn't have anything to do with NTFS support, but rather EFI. EFI support did even exist in VMware until vSphere 5 and Veeam did not support it until version 6.5 and even at this point I rarely run across any VMs that are using it so that's likely why the problem isn't more widespread. Also, the Other OS wizard is a fallback approach and I suspect was suggested more as a troubleshooting step more than anything. It's known to have some issues with regards to NTFS recovery as that's not it's primary role. That being said, leveraging an FTP client you likely could retrieve your files, although I'm in no way suggesting that this is a final solution.
I'm sure your problem is undergoing additional investigation, not all resolutions happen immediately, and as there's just been a brand new major release, I'm sure support load is higher than normal, especially at the higher tiers. Support will always provide priority to existing customers over potential customers, not because they don't appreciate your cooperation to solve a problem that's impacting your evaluation, but because their primary role is to service paying customers that are experiencing problems impacting their production deployment of the product. If you were a customer that had already purchased the product and paid for support and sure you would expect no less than this. Unfortunately, there are only so many resources to go around.
That being said, I'm 100% sure that they appreciate your cooperation in investigating this issue and that they would like to resolve it, but patience will likely be required.
Hello, im reporting back on this issue. Problem was related to the P2V partitions. Support created a custom fix to my problem which i applied and so far is working well.
Thanks to all veeam suport staff /forum staff for helping us fixing this issue.
Thank YOU for updating the topic with the resolution, and recognizing our support.
This is naturally the best way to say "thanks" to everyone who helped you
Simon, private fix is available for this problem through support, should be provided to you by your support engineer right after it is confirmed that you're experiencing this very problem.
