Concurrent Linux file restores in Veeam Backup and Replication v9.5 vCloud Director Self-Service Portal

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- 0 Flares ×

The new vCloud Director Self-Service Portal in Veeam Backup & Replication 9.5 allows tenant to perform backups and restores in a complete self-service mode. To execute file level restores for non-Microsoft file systems, a Multi-OS FLR Helper Appliance virtual appliance is used. This appliance is configured by a Veeam administrator before it can be used for any file restore. Otherwise, the first time a tenant tries to restore a file for one of his Linux VMs, he will receive this error in the Self-Service Backup Portal:


A Veeam administrator needs to configure the appliance from the Veeam Console. This can be achieved by initiating a file lever restore for any Linux VM:


The restore wizards asks to configure the Helper Appliance. the wizard suggests that the appliance should be connected to the same network where the guest VM is located, but it misses the other important information, that the FLR appliance needs to connect first of all to the Veeam mount server via port TCP/6170.


In our scenario, dvp-prodVM is a management network where the different Veeam components are running. Once the FLR appliance is configured from the Veeam Backup Server, its configuration can be used also from the Self-Service Backup Portal by a tenant to mount the backup in the web interface:


The tenant has the three different options to restore one or more files from the backup set. While the Download option is immediately consumable by a tenant, the two Restore options require even more networking configurations, as the Veeam Backup Server would try to connect to the Guest VM to start the restore process from within the guest, but as there’s no network connectivity between the two, it will fail:


For this reason, when Veeam Backup & Replication 9.5 is used in completely fenced environments, we suggest to leverage the download options of the vCloud Self-service portal, and let tenant consume this portal to retrieve the files they need. To avoid a double operation of downloading the file to their workstations and then uploading them again to the linux machine, we suggest as a best practice to access the portal from a virtual machine already running in the vCloud virtual datacenter. If the machine used to retrieve the files is not the final destination of the restored files, a tenant will only need tools like WinSCP to transfer the file to the linux machine, but both the download and the scp copy will happen in a local network, with the files not even leaving the service provider datacenter.

Multiple concurrent restores

If the service provider is offering the self-service capabilities of the Veeam vCloud Portal, it could not be so uncommon that multiple tenants will start a restore operation at the same time. What happens in this scenario?. Let’s test it in our lab again.

Customer1 owns a single linux virtual machine called linux, inside the linux_vapp vcloud app. He wants to restore a file from the latest backup, so he starts the procedure from the self-service portal as described before; the customer selects the restore point and asks the software to initiate the mount operation:



The customer can browse the content of the backup, do searches, and download any file he may need.

In the backend, Veeam Backup & Replication v9.5 is using the FLR Appliance to mount the backup and read the linux filesystem used by the linux virtual machine, and this can be checked in both Veeam console:


And in vSphere Client:


The machine is automatically disposed (powered off and deleted from the vSphere environment):

–          After 15 minutes of inactivity from the vCloud Portal
–          If the operator logs out from the vCloud Portal

For the entire duration of the restore process, the FLR will be powered on and used by the tenant. So, what happens if another tenant wants to restore a file from a Linux machine? There are two cases.

FLR Appliance configured with a static IP address

The configuration of the FLR appliance can be done in two ways, by assigning a fixed IP address or by leveraging a DHCP server. As the appliance is often managed as a regular server, and to be sure it always have an IP address to start and execute the restores, many administrators configure it with a static IP address. The IP you see in my example is a static IP address:



During a file restore from the portal, Veeam Backup & Replication uses the existing configuration of the FLR appliance, since there is no possibility to change the configuration from the portal itself. This works perfectly for one single restore operation, but if for example Customer2 tries to do a file restore for one of his linux machines after Customer1 is already performing a restore, this is what happens to Customer2:


Customer2 has to wait until Customer1 has no restore operation running anymore, before he can start his own restore. This is done on purpose to avoid multiple FLR appliances to be spin up using multiple times the same IP address, thus leading to unexpected results.

FLR Appliance configured with dynamic IP address

The solution is to configure the FLR appliance with a dynamic IP address, once we have verified that a DHCP server is available in the port group where the appliance will be connected:


If we then repeat the same tests, we can notice immediately some differences.


Two different FLR appliances are running this time with two different IP addresses, both leased by the DHCP server. And even more important, Customer1 and Customer2 can now browse the content of their VMs at the same time:



Final notes

I know that is common (and good) practice for service providers to avoid machines using dhcp, and they prefer to use static IP addresses. But in order to allow FLR appliances to scale, I highly suggest for once to forget their habits, and go for a dhcp-based Veeam FLR appliance.