Agentless Ubuntu 20 backups - reports integration services is not running

Just setup a new 2019 HyperV server and installed the 6.5 Agent on it. The HyperV server is running 2x Ubuntu 20.04 LTS servers and we've run the commands on both servers for the integration services https://www.serverwatch.com/guides/installing-and-activating-hyper-v-linux-integration-services/ and restarted both machines, all of the Integration services and guest services are enabled on HyperV for both machines as well.

When we're looking at the virtual Ubuntu machines on the Rapid Recovery 6.5 Console, they're coming up with the warning "snapshots may only be crash-consistent because Integration Services is not running on the virtual machine or it is out of date".  We've also done a base image of both Ubuntu servers and the recovery points have a yellow circle next to the recovery point saying "Not consistent, machine may have boot problems".  

This is the first time we're backing up Ubuntu agentless, am i missing anything obvious or is this correct?

  • I can't say I have run Ubuntu 20 on HV to try it, however all that means really is that a full MS VSS snapshot can't be taken of the VM. The backup isn't quiesced, it is backed up, but not quiesced: 

    support.quest.com/.../rapid-recovery-defaults-to-guest-quiescing-when-taking-a-vmware-snapshot

    I know the KB is for ESXi, but same concept applies. For Hyper-V if a full MS VSS snapshot can't be taken it will failover to just using a 'checkpoint' snapshot, which is what gets you that yellow 'inconsistent' error in the GUI. It is alarming as all get out, however I'd encourage you to do an FLR or export and validate the restore capabilities and it is probably fine. 

    I haven't looked at the compatibility matrix myself, which I will now, or tried this specifically, however now I want to in order to see how mine behaves. It wouldn't surprise me one bit however given the nature of HV running upon a MS OS and trying to report on a linux based OS. My guess is that the backup/restore is fine, and this  will be an 'expected behavior' from Quest as again it is a linux OS running inside MS. Now I am curious though as I want to see it too. Time to fire up some VMs I guess. 

  • Hello Simon,

    In order to enable the integration services for a Linux box, additional components are required. You can install the following and perform a reboot right after.

    sudo apt-get install linux-tools-<Kernel version>
    sudo apt-get install linux-cloud-tools-<Kernel version>

    You can check the kernel version with the cmdlet: uname -r

    After rebooting the Linux machine and refreshing the metadata from the Rapid Recovery Core server, the crash-consistent backup banner should disappear.

  • Apologies for the delay, that's now worked Luciano, thankyou

    Just as a quick side note.  The Ubuntu server that this error relates to runs a webserver and a MySQL database with a big data load happening early in the morning and also drips through during the day.  We have noticed that if the big data load happens when a backup is happening, the incremental backup can explode in size and it also blocks any new data loads until the backup has finished....as an example, a normal 6am backup is 20GB, if the dataload is still happening when this backup starts, it can block all data loads until the backup finishes and it can cause the backup size to go from 20GB to 50-100GB.

  • Hello Simon,

    I'm glad to know that the cmdlets I previously shared were helpful.
    Regarding Rapid Recovery blocking the data loads during a backup, further analysis is required, I recommend opening a Service Request by clicking this link.

    You will get a support engineer that will further assist you on this matter.

    Sincerely,

    Luciano Guerra