restore Linux VM with elevating to root (sudo)

[sandsturm]

Hi all

Besides our Windows virtual machines, we run some linux VM's (RHEL,SuSE) as well. Our company security guidelines doesn't allow us to login directly with root to a linux system via ssh, we have to login with a non-root-permission account and make a sudo to root after login.
The problem is, if I want to make a single file restore for a linux virtual machine, I'm confronted with the same problem. As soon as I want to restore the file to the linux system, I have to type in the credentials. But root credentials dont work for direct ssh login, so I have to use my non-root-permissions user, but this user hasn't the permission to restore some of the files because he has no root user permissions. What do I have to do, to address this issue? Allow direct root login is not a selectable variant.

thx,
sandsturm

[sandsturm]

Is really nobody confronted with the above problem? Have you guys no linux machines with disabled direct root login to backup or how do you this? This is a very serious problem for me, if I don't have a solution for this I need another backup solution and thats not a nice idea....

thx,
sandsturm

[foggy]

As a workaround, you can use other protocols for restore (SFTP, for example), though the process would require more manual steps (some of them can be automated through PowerShell).

[sandsturm]

Thank you for your answer, but this isn't really a satisfying solution for me. I want to use Veeam to simplify the backup/restore process. If I want to switch our data protection solution to Veeam, the way to restore something must be simpler then now. (IBM TSM agent within the virtual machines). But our Linux admins will have a more complex restore process with veeam and as as a second point, the restore of such a file takes much longer then before (longer then a restore from tape!), because until the FRL appliance is started etc. it takes some minutes. Not really satisfying to bring a new solution which is worse then before...
Your workaround may work for companies with a handful of linux VM's, but thats not a possible way for 400-500 Linux VM's on different ESXi clusters....

Is there really no other solution for that? I can't believe that?

thx,
sandsturm

[cby]

We run many Linux VMs and after experimenting with FLR found it to be unreliable and take a long time to render directories in the explorer window. With a directory containing thousands of files the FLR process would often crash. We found that restoring either the entire VM or VMFS volume(s) (server LVM layout permitting) was quicker than FLR. You do of course need to manage the network/VLAN side once restored and powered up to avoid potential conflicts, but that's no big deal.

Have to say I haven't tried FLR with Linux with 9.5 so things may have improved.

[jmmarton]

I worked with a customer who was experiencing issues displaying the contents of folders on Linux VMs during FLR when the folders had thousands of files. He saw performance issues with 9.5, but after applying update 1 it was significantly better. I haven't looked into update 2 to see if there have been any additional improvements.

Joe

[sandsturm]

Hi

We found that restoring either the entire VM or VMFS volume(s) (server LVM layout permitting) was quicker than FLR. You do of course need to manage the network/VLAN side once restored and powered up to avoid potential conflicts, but that's no big deal.

But how do you restore files from this restored vm to the original one. As you said, it's not possible to connecte the vm to the network because the "original" VM is up and running.... and without network connection it's difficult to restore files from the restored vm to the original one?

[cby]

That's where the VM console comes in ...

o In a console on the vSphere client fire up the restored VM (without n/work enabled) in default mode, usually init 3 (init 2 if you want to be cautious or for the really cautious init 1). VLAN should be same as production VM in VM settings. You may get a bunch of boot-up errors/warnings and whatever network dependency problems encountered by your startup applications on the VM. Ignore these so long as server boots and you can get to the shell

o Disable all services and scripts that kick in on n/work start and might impact/conflict with the production system/VM (mail server, cron jobs, background tasks, database and/or application initialisation etc.)

o Assign an IP in the same subnet as the production system

o Connect network in vSphere, start restored VM's n/work service

o Confirm restored & production VMs can see each other and copy restored file to production VM

Don't bother with external media like USB uploads. USB passthrough in ESX is unreliable and a pain to make it work successfully even when it appears to be working.

[cby]

Needless to say running with init 2 or 1 means a bit more work on the network side, so best stick with init 3 if you can or are unfamiliar with what's required with init 1 in particular

[sandsturm]

Hi cby

thank you for your explantation. You're right, that's a way to restore a file... but a very complicate way in my opinion... Veeam is known for easy backup and restore, but in this case it's a pain. Our Linux Admins have the easier way now with our legacy backup solution and if we change to Veeam they have a more complex way to restore single files. I hope you understand they will kill me, if I bring them such a solution

Is there really no easy way to do it?
thx,
sandsturm

[cby]

Things are improving for Linux but when the vast majority of your users employ Windows it's natural that that Veeam give this o/s more attention.

FLR does work but is not entirely satiafactory for reasons given previously. Interestingly, Veeam 6 FLR was simple to deploy and worked but, and I may be wrong here, subsequent versions of Veeam use a different technique for FLR which in my experience has made things more complex and less reliable.

I think the Veeam approach of backing up the entire VM does have its drawbacks, the implementation of FLR being an obvious case, but as a whole it is much more flexible and reliable than other non-VM based backup products we've used.

Like I said I haven't tried FLR in 9.5, especially update 2, so I will test that out when I get a chance.

[einhirn]

I never use the FLR appliance but instead use instant restore on the machine I want to recover files from. But I don't power up the restored VM, I just "hot-add" it's disk to the running original machine, mount, restore, unmount, delete device, remove hot-added device, done.

Perhaps this could even be scripted via Powershell to be more elegant...