Error when restoring a file / directory

[wsavenbe]

Hi,
I'm evaluating VEEAM B&R. I have this OpenSuse Machine and I want to do a FLR. The restore starts but immediately I receive the following error

"Cannot find a mapping rule matching directory path [/media/sda2/tmp/<myfile-or-folder-to restore]

Anyone a clue, hint, usefull tip, ....
Searching in the knowlegde base resulted in nothing.

Looking forward to your feedback

[PTide]

Hi and welcome to the community!

I have this OpenSuse Machine and I want to do a FLR

Do you use "Copy To' button or "Restore" one? AFAIR openSUSE is a Novell Linux distribution and you cannot restore files directly to the original location from backups of BSD, Mac, Novell and Solaris VMs. Use the Copy to option instead.

Looking forward to hear news from you.

Thank you.

[wsavenbe]

I right Click on the backup
Select Restore guest files - Linux and Other
Select Backup & Reason
Click Finish

Once the "new" appliance is open I browser for the file (or folder) to restore and select "Restore - Keep".

Is this a VEEAM issue or rather an OpenSuse problem ? Restores on CentOS & Ubutuntu are working.

[PTide]

Is this a VEEAM issue or rather an OpenSuse problem ? Restores on CentOS & Ubutuntu are working.

Veeam FLR works differently with openSuse. As it's stated in helpcenter please use Copy To button instead.

Thank you.

[jmmarton]

Hi and welcome to the community!

Do you use "Copy To' button or "Restore" one? AFAIR openSUSE is a Novell Linux distribution and you cannot restore files directly to the original location from backups of BSD, Mac, Novell and Solaris VMs. Use the Copy to option instead.

That's not entirely accurate. OpenSUSE is simply a completely free version of SUSE Linux, similar to Fedora in the Red Hat world. As far as the "Novell" filesystem limitation, that actually means NSS. Files backed up from NSS can't be restored to the original location. NSS is only available in Open Enterprise Server which is based off of SLES. I've personally restored files even backed from up OES that were sitting on ext3 to the original location. As far as OpenSUSE goes, it would only be using traditional Linux filesystems (e.g. ext3, ext4, btrfs) as NSS wouldn't be available so restoring to the original location shouldn't be an issue.

Joe

[wsavenbe]

Thanks to all for the feedback.

[PTide]

Thanks for the correction Joe!

Thanks to all for the feedback.

Considering everything Joe has said, it seems that there should be no issues with FLR from opensuse backup. Please double-check your VMware Tools and if that won't help kindly open a ticket with our support team and post your case ID in this thread.

Thank you.

[hyvokar]

Hi!

I get the same error with Ubuntu. Should FLR work with Ubuntu Linux?
VMwaretools are current and running.

[PTide]

Hi,

I get the same error with Ubuntu. Should FLR work with Ubuntu Linux?

Could you please provide an exact error that you get? Also please check if you you have a corresponding fstab entry for the drive that hosts the directory that you want to restore. If the entry is present please make sure that the directory is accessible (mounted).

Thanks

[hyvokar]

9.6.2016 17:46:06 Error Cannot find a mapping rule matching directory path [/media/mesotest-vg-root/tmp/vmware-root/vmware-apploader-1211.log]

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/mesotest--vg-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=20103653-f35b-4ee0-83e5-3ec829c3290e /boot ext2 defaults 0 2
/dev/mapper/mesotest--vg-swap_1 none swap sw 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto,exec,utf8 0 0


E: tried to restore stuff to my home folder which i absolutely have enough permissions, it failed also:
9.6.2016 17:59:39 Error Cannot find a mapping rule matching directory path [/media/mesotest-vg-root/home/meso_veeam/.bash_history]

[PTide]

That does not seem to be a normal behaviour - please consider opening a case with support team and post your case ID here.

Thanks

[hyvokar]

# 01821560

[drp0218]

Any resolution? I am having a similar issue with SLES 11 sp4.

[PTide]

Just checked the support case - they are still searching for a resolution. If nothing of what has been posted in this thread helped then you can either wait for the previous poster to report back or open your own case.

Thanks

[hyvokar]

Well I have to say once again, working with your support isnt pretty productive

However, for what I've found out, for some reason some of the backups has /media/mesotest-vg-root in front of their path, when it only should be like /tmp and that is why the restore fails.

[PTide]

The issue has been passed to our QA team for investigation, please wait for the thread to be updated

Thanks

[drp0218]

I am having the same issue. My case number 01830003. I haven't been pleased with the support either. They don't seem to understand linux LVM. I have given them a link to this post and case number. Hopefully, they will find resolution. I am using SLES 11 sp4.

[tyler]

I had the same issue, and after trying the support route I was able to resolve it on my own.

When setting up Guest OS file indexing on the backup job, I selected “Elevate specified user to root” as well as “add to list of sudoers” with a root PW and then it allowed me to do a file level restore directly to the Linux VM after running the backup job again.

I was also misled initially by the extraneous path being prepended to the restore path, but it seems this was in fact a permissions-related issue.

[drp0218]

tyler, I have tried these settings unsuccessfully. SLES 12 sp1 with btrfs. What versions are you using? Could it be a filesystem issue?

[dorr]

Veeam appears to try to use sudo in order to modify sudoers. In order to successfully complete a file-level restore, it was necessary to manually modify sudoers in advance of attempting privilege escalation. After that was done, Veeam successfully modified sudoers. Removing the root password and privilege escalation options still resulted in successful restores after sudoers was modified, suggesting Veeam properly uses sudo during subsequent tasks. [Tested successfully using Oracle Linux with current VMware tools, both with password and SSH keys .]