How to Recover Data from QCOW2 Virtual Disks and KVM (QEMU) Snapshots in RHEL 7.9
-
Author:
Vladimir Artiukh
-
Editor:
Oleg Afonin
In this article, we will explain how to recover KVM virtual disks and snapshots in Red Hat Enterprise Linux 7.9, identify the cause of data loss, and restore access to information using the appropriate tools.
- KVM and LVM Architecture in RHEL 7.9
- Connecting the Disks to the Computer
- How to Recover KVM (QEMU) Virtual Machines and Snapshots from RHEL 7.9
- Conclusion
- Frequently Asked Questions
- Comments
Virtualization based on KVM (Kernel-based Virtual Machine) and QEMU is widely used in Red Hat Enterprise Linux 7.9 to create and manage virtual machines. Their operating systems, applications, and user files are stored on virtual disks, for example in QCOW2 or RAW formats. Snapshots can be used to preserve a previous state of virtual machines, allowing you to roll back to a specific point in time. However, accidental file deletion, disk image corruption, failure of a physical drive, or a broken snapshot chain can lead to loss of access to critical data.
How to Recover KVM (QEMU) Virtual Machines & Snapshots from RHEL 7.9
KVM and LVM Architecture in RHEL 7.9
Let us take a closer look at the architecture of our server system.
The Red Hat Enterprise Linux 7.9 operating system itself is installed on a separate system disk with the XFS file system. The storage for the KVM virtualization environment, however, uses a complex, multi-layer disk subsystem.
The system is built on RAID 5 and RAID 0 disk arrays. LVM logical volumes are deployed on top of them. To ensure data security, these volumes are additionally encrypted using the LUKS standard, and only inside this cryptographic container is the ext4 file system created, where the virtual machine files are stored directly.
All of this environment is managed through the Libvirt daemon, which conveniently abstracts the physical disk hierarchy into storage pools and associates them with the configurations of each virtual machine. However, at the moment of a failure, this convenience works against us, because when the lower storage layer fails, Libvirt immediately loses connection to the pools. As a result, all virtual machines simply disappear from the management console or immediately become unavailable.
The main problem is that such a complex architecture significantly complicates the data recovery process. This entire structure (RAID, LVM, LUKS, and ext4) is tightly interconnected. A failure at any of these levels immediately breaks the entire chain and completely blocks access to the virtual machines.
Let us move directly to the virtual machines. They use virtual disks in the popular qcow2 format. This format supports snapshots, that is, captures of the system state at a specific point in time. Storing all snapshots and current changes in a single virtual disk file is extremely convenient for administration and resource management.
However, from a reliability perspective, this makes the system highly vulnerable. If this single qcow2 file becomes logically corrupted due to a host system failure, you risk losing not only the current working version of the virtual machine, but also all of its saved states at once.
Fortunately, this does not mean permanent loss of information, because with Hetman RAID Recovery you can analyze the damaged structure and successfully recover both the virtual disks themselves and the data stored inside them.
| Component | Purpose and Features |
|---|---|
| KVM (Kernel-based Virtual Machine) | A Linux kernel module that provides hardware virtualization and allows virtual machines to run in RHEL 7.9. |
| QEMU | Emulates virtual hardware and provides virtual machine operation, including access to their virtual disks. |
| libvirt | Virtualization management tools used to create, start, stop, and configure virtual machines through virsh and other tools. |
| Virtual machine (VM) | An isolated environment in which a guest operating system runs with its applications, settings, and files. |
| QCOW2 virtual disk | A QEMU disk image format that supports dynamic allocation, metadata, and internal snapshots. It can also be used as part of an external snapshot chain. |
| RAW virtual disk | A disk image without the additional QCOW2 container structure. It can be stored in a file or on an LVM block device. |
| Snapshot | A saved state of a disk or virtual machine. Snapshots can be internal, stored in a single QCOW2 file, or external, where changes are written to a separate file. |
| External snapshot chain | A sequence of a base image and child disks that store changes. To access the current data state, the correct links between the files must be preserved. |
| LVM (Logical Volume Manager) | A Linux logical volume management system that allows physical devices to be combined into volume groups and logical volumes to be created for virtual disks. |
| PV (Physical Volume) | A physical device or partition prepared for use in LVM. It is the base level of the LVM structure. |
| VG (Volume Group) | A volume group that combines one or more PVs and provides space for creating logical volumes. |
| LV (Logical Volume) | A logical volume that can be used as a block device to store a RAW virtual disk or a file system with QCOW2 images. |
| Host file system | The RHEL file system, such as XFS or ext4, on which virtual disk files and virtual machine configurations can be stored. |
| libvirt XML configuration | Contains virtual machine parameters, including the disk path, controller type, and other settings. Helps determine which image was used by the virtual machine. |
| LVM metadata | Contains information about physical volumes, volume groups, and logical volumes. Corruption of this metadata can make logical volumes and the data stored on them inaccessible. |
Connecting the Disks to the Computer
To begin the recovery process, you need to physically remove the disks from the problematic server and connect them to a computer. The best and fastest option is a direct connection to the computer motherboard via SATA or SAS ports.
You can also use external USB docking stations or adapters, but keep in mind that this may reduce scan speed.
An important rule when assembling arrays: to successfully recover data from a RAID 5 array, it is sufficient to connect all disks except one failed disk. For a RAID 0 array, however, it is mandatory to connect absolutely all drives that were part of the array; otherwise, recovery will be impossible.
If there are not enough free ports to connect all drives, or if the disks show signs of hardware failure, the best solution is to create sector-by-sector images. This built-in Hetman RAID Recovery function allows you to save an exact byte-for-byte copy of each disk as a regular file. Working with images is a standard safety practice, because scanning takes place without any physical load on the original server drives.
To create an image, select the connected disk in the main window and click the Save disk button on the top panel, specifying the save path.
After creating all images, mount them in the program: open the main menu and select Mount disk.
Select the Raw disk images type and open the saved files.
They will immediately appear in the list of available devices, ready for automatic array assembly and further scanning.
How to Recover KVM (QEMU) Virtual Machines and Snapshots from RHEL 7.9
METHOD 1. Recovering Virtual Machine Files
Let us move on to practice and consider recovering access to a qcow2 virtual disk file.
In our case, the file was not deleted, but access to it was completely blocked due to a sudden hardware failure of the server and the subsequent destruction of the array’s logical structure.
However, Hetman RAID Recovery algorithms make it easy to bypass this problem. In the main program window, we can see an already automatically assembled RAID 5 array, but to access the data, its logical volume must first be unlocked by entering the LUKS password.
Only after the cryptographic protection has been successfully removed do we select this volume and start the Fast scan algorithm, which will immediately analyze the structure of our file system, which in this case is ext4.
Navigate to the folder where the virtual machine was stored. The program successfully reconstructed the directory tree and found our intact qcow2 file.
Select the found image and click the Recovery button on the top panel, then be sure to choose a safe location on the computer’s local disk or another storage device to avoid overwriting the data.
METHOD 2. Recovering Files from Guest OSs
Now let us consider another common scenario: data loss occurred directly inside the virtual machine itself. In our example, the guest operating system is Windows 10.
Typically, access to such files requires starting the hypervisor and fully booting the virtual machine, which is not always possible or safe after system failures. However, Hetman RAID Recovery allows direct work with the qcow2 format. You can open the virtual disk directly in the program interface without using a hypervisor.
To do this, open the Mount disk menu, select the appropriate option for virtual machines, specify the path to the folder containing your saved qcow2 file,
and click Mount folder.
After that, the virtual disk will immediately appear in the general list of devices. Since our guest system is Windows 10, we immediately see its partition with the NTFS file system.
Select this partition and start the Fast scan analysis. The program will deeply analyze the internal structure of the virtual disk and find deleted or lost data. In our case, this is a set of test files. Thanks to the preview function, you can visually assess the integrity of documents and photos directly before recovery.
After verifying the correctness of the found information, select the required files, click the Recovery button, and save them to the local disk of your computer.
METHOD 3. Recovering Data Using Snapshots
Another powerful feature of Hetman RAID Recovery is working with snapshots, that is, system state captures.
As we mentioned at the beginning of the video, the qcow2 format stores all snapshots within a single file. When such a virtual disk is mounted, the program automatically finds all snapshots contained within it and displays them as separate connected drives in the general list.
This makes it easy to recover data from previous system states. For example, if an important file was modified or completely deleted and it no longer exists in the current working version of the virtual machine, you can simply return to an older snapshot. Select the required snapshot in the list and start the Fast scan algorithm.
The program will analyze its structure and find previous versions of files. After that, all you need to do is visually verify the found data, select the necessary files, and save them to a safe local disk using the Recovery button.
Conclusion
Recovering KVM virtual disks and snapshots in Red Hat Enterprise Linux 7.9 requires an understanding of the virtualization architecture, storage structure, and the way data is stored. Depending on the virtual machine configuration, its disk may be represented by a QCOW2 or RAW file located on a file system, or by an LVM logical volume. This determines the choice of tools and the sequence of actions during recovery.
If the virtual machine no longer starts, the disk was accidentally deleted, or a snapshot is corrupted, the first step is to determine the cause of the problem and verify the availability of the original data. Special attention should be paid to external QCOW2 snapshots, because broken links between the base and child images can result in loss of access to the current state of the virtual disk. When using LVM, you must check the status of physical volumes, volume groups, and logical volumes without changing their structure unnecessarily.
To increase the chances of successful recovery, it is recommended to stop writing to the damaged storage device, avoid deleting residual snapshot files, and, if possible, create a sector-by-sector copy of the drive or a backup copy of the images. Specialized data recovery software can be used to search for lost files, including Hetman Software solutions. At the same time, the result depends on the type of damage, the condition of the drive, and whether the lost data has been overwritten.
To minimize the risk of repeated data loss, you should regularly create backups of virtual disks and virtual machine configurations, verify the integrity of backups, and monitor storage health. Snapshots should be used as a way to return to a previous state, not as a full replacement for backups.
