With the release of x360Recover 15.0.0, virtualization and virtual disk exports are now available for supported Linux distributions.

Note: As of 15.0.0, supported distributions for Virtualization and Virtual Disk Export includes only Debian and Ubuntu Linux varieties. Support for RedHat Enterprise Linux (RHEL) Linux varieties will be released later in 2025

For supported Linux distributions, the Snapshots table on the Protected System Details page will now contain all recovery options:

Note: Unsupported Linux distributions will still only show the option to mount a recovery point and perform file and folder recovery.

 Linux virtualization

When starting a VM on an appliance or private vault, Linux virtual machines are configured exactly like Windows virtual machines

1. Choose your RAM and CPU resources       2. Select Mode - either Test or Live (Optional) Specify Boot Key, Boot Device and CD-ROM image if desired     3. (Recommended) Select Use Virt IO 4. Enter the password if prompted 5. Click Start

Linux virtual disk exports

With the release of x360Recover 15.0.0, exporting to Virtual Disk images is also now supported for Linux protected systems.

1. Select which disks are to be exported  2. Select the exported virtual disk image Format  Note: v15.0.0 now supports QCOW2 Dynamic disk images             3. Enter the protected system Password if prompted ** Note: New to v15.0.0 is the option to Apply P2V Changes to the exported virtual disk image. See the details of this option below. 4. Enable Apply P2V Changes for Linux protected systems  5. Click Start

** (Recommended)  Apply P2V Changes for Virtual Disk Export

When starting a protected system recovery point as a virtual machine, x360Recover has always performed a number of changes to the virtual machine disks before starting the system. 

These changes are applied to resolve known bootability issues, including:

• Ignore previous shutdown warnings
• Fix MBR records
• Delete old BCD log files
• Fix BDR file attributes
• Install Virtio Drivers
• Disable hibernation and hiberfil.sys

For Linux in particular, performing P2V is essential for reliable virtual machine recovery. 

Linux P2V operations include:

• Grooming of fstab
  1. Remove missing volume references to ensure system doesn’t hang on boot
  2. Translate hard device paths to uuid device names to ensure hardware changes are agnostic
• Remove references to any volumes from cryptfs
• Fix uefi and grub configurations
• Clear mesa cache (fixes video bugs in Debian)
• Enable virtio drivers (some distros do not include drivers by default)
• Patch and rebuild initramfs

By performing p2v on your Linux virtual disk exports, you ensure that the disk images are presented in a format that is highly hardware independent. 

This avoids most of the common pain points when restoring the system to different hypervisor platforms or different physical hardware than the original protected system.

Linux full disk encryption

x360Recover fully supports backup of protected systems using native Linux full disk encryption.

 However, the backup is performed against the UNLOCKED, unencrypted filesystem volumes, not the underlying encrypted physical disks.

Just like with Windows systems, the agent doesn’t have the ability to read and process the raw encrypted volume data. When recovering an encrypted system, it will be returned from the backup as an unencrypted system.

Under Windows, this isn’t much of a problem, since Windows itself is largely unaware of and unaffected by the presence of encryption. (i.e. Drive C: is Drive C: whether it’s encrypted or not, and you can simply re-enable Bitlocker on the device after performing recovery to re-enable encryption.)

Under Linux, this is a bit more complicated. 

Linux encrypts the disks outside of the underlying operating system, and physically stores the unencrypted volumes inside the encrypted physical volume container. 

This means that Linux must first unlock the disks during bootup and then boot from the unencrypted volumes. (Windows does this as well, but it’s more seamless under the hood.)

Linux stores encrypted disk dependencies in the file /etc/cryptfs. 

If any entries are present in this file, the OS expects to find an encrypted volume that must be unlocked before booting can continue. Some Linux distributions (notably Debian and Ubuntu) will silently time out looking for missing cryptfs volumes and boot fine, but others (notably RHEL) will hard fail into the grub loader if the files are missing.

Important: Since we don’t capture the underlying cryptfs encrypted volume data, x360Recover doesn’t have these disks during recovery. 

This makes it essential to select ‘Apply P2V Changes’ when exporting virtual disks for encrypted Linux systems, so that cryptfs can be groomed and initramfs can be rebuilt to ensure a seamless boot experience.

 SUPPORT | 720-204-4500 | 800-352-0248

• Contact Axcient Support at https://partner.axcient.com/login or call 800-352-0248 
• Have you tried our Support chat for quick questions?
• Free certification courses are available in the Axcient x360Portal under Training 
• Subscribe to Axcient Status page for updates and scheduled maintenance

1992