How to Restore Virtual Machine Data and Snapshots from LVM-Thin in Proxmox VE
-
Author:
Vladimir Artiukh
-
Editor:
Oleg Afonin
In this article, we will examine the process of recovering data from virtual machines and snapshots located on LVM-Thin block storage in a Proxmox Virtual Environment 9.1.1 environment. We will analyze the most common data loss scenarios faced by administrators and users. We will also cover how to diagnose the state of disks, connect drives directly to a computer, and recover data using specialized software.
- LVM-Thin Architecture in Proxmox
- Working with Proxmox VE Disks
- Data Recovery in Proxmox VE
- Conclusion
- Frequently Asked Questions
- Comments
Loss of access to a virtual machine in Proxmox VE does not always mean the loss of the data itself. If virtual disks and Snapshots were stored on LVM-Thin block storage, data recovery may require working directly with the storage structure and its metadata.
In this article, we will examine how to recover data from virtual machines and Snapshots located on LVM-Thin in a Proxmox VE environment. We will show how to access virtual disks, correctly identify the storage structure, and search for and recover lost files.
Special attention will be given to situations where a virtual machine becomes unavailable due to deletion, configuration corruption, drive failure, or a critical error on the Proxmox server itself. We will also cover working with mounted virtual disk images and recovering data from Snapshots.
The methods described will help you gain access to information even when standard Proxmox VE tools no longer allow you to start or attach the virtual machine.
Proxmox ZFS Data Recovery: Recover ZVOLs, VMs and LXC Containers
LVM-Thin Architecture in Proxmox
To understand the recovery process, it is necessary to identify the architectural differences in data storage in Proxmox.
- When using the standard Directory storage type based on the Ext4 file system, virtual machine disks exist as regular files in qcow2 format. This approach provides convenient administration: files can be copied, moved, or added to backups. However, the additional file-system layer creates overhead and objectively reduces server performance.
- The LVM-Thin architecture works differently. It is block-level storage with no conventional files or directories. The hypervisor creates a single pool on the physical drive and allocates logical volumes for each virtual machine as needed. For the guest operating system, such an allocated volume appears as a standard physical hard drive. In essence, these are RAW devices interacting with the server hardware at the lowest level.
The main advantage of LVM-Thin is maximum performance due to direct block access and support for thin provisioning, where disk space is reserved only when data is actually written.
The downside of this technology is a more complex recovery process. In the event of a critical failure, extracting the virtual machine file in the traditional way is impossible because it does not physically exist as a file. That is why recovering data from such arrays requires tools capable of detecting and analyzing raw block structure without the operating system involved.
| Characteristic | LVM-Thin | Directory |
|---|---|---|
| Storage type | Block storage with thin provisioning | File-based storage |
| Core operating principle | Data is stored in the thin pool as blocks | Data is stored as regular files in a file system |
| Virtual disk placement | Logical Volume (LV) | Disk image files |
| Typical virtual disk formats | Raw | RAW, QCOW2, VMDK, and others |
| File system inside the storage | Not used for storing individual VM files | EXT4, XFS, ZFS, or another supported file system |
| Thin provisioning | Supported | Depends on the underlying storage |
| Snapshot | Implemented at the thin pool level | Depends on the image format and file system |
| Data access | Through a block device | Directly through the file system |
| Visibility of VM files | No separate files exist inside LVM-Thin | Virtual disk files are directly accessible |
| Recovery after damage | Requires analysis of LVM metadata, thin pool, and blocks | Direct scanning of files and the file system is possible |
| Working with deleted data | May be more complex due to thin provisioning specifics | Depends on the file system and file state |
| Snapshot recovery | Requires analysis of the thin pool structure and related volumes | Depends on the snapshot creation mechanism |
| Typical use case | Proxmox VE virtual machines and containers | Files, ISO images, backups, and VM images |
Working with Proxmox VE Disks
METHOD 1. Connecting the Disks
Before starting the recovery process, you need to connect the physical server drive to the workstation.
The most reliable method is a direct connection via the SATA interface to the computer motherboard. This ensures the highest data read speed and operational stability during in-depth analysis. If your server was equipped with SAS drives, you will need to install a compatible HBA controller in a PCIe slot for them to be recognized on a standard PC.
Using external USB enclosures or docking stations is allowed as an alternative if direct connection is not possible.
Keep in mind that USB bandwidth is usually a bottleneck, so the block-space scanning speed will be noticeably lower, which directly affects the total recovery time.
METHOD 2. Working with Disk Images
Since in our scenario the LVM-Thin pool is deployed on a single drive, the hardware part of the task is as simple as possible: you only need to remove and connect this specific disk.
However, in situations where it is technically impossible to connect all required drives to the computer at the same time (for example, due to a lack of free ports on the motherboard), you can use the sector-by-sector image creation function.
An image is an exact byte-for-byte copy of a physical disk stored as a regular file on another medium. You can connect disks to the system one by one, create images from them, and then load all the resulting files directly into the program.
Our utility will work with mounted images exactly as it does with real hardware, allowing you to fully recover the Proxmox storage structure and extract data from it.
To create an image, launch the program, select the required disk from the list, and click Save disk.
In the window that appears, specify the save location for the file.
Note: the size of the finished image will equal the full capacity of the source drive, regardless of how many gigabytes are actually used on it. Therefore, make sure in advance that the target drive has enough free space.
When the save process is complete, go to the main menu and select Mount disk.
In the type list, select Raw disk images and load the created file.
It will immediately appear in the general device list alongside physically connected disks. If you have several problematic drives, simply repeat this procedure for each of them.
After all required elements are present in the system, either physically or as images, the program will analyze them automatically, determine the LVM pool structure, find the virtual machine disks, and prepare them for deep analysis and data recovery.
Data Recovery in Proxmox VE
METHOD 1. Recovering Data from LVM-Thin
In many cases, loss of access to virtual machines is not caused by accidental file deletion, but by a failure of the server hardware itself or critical errors in the Proxmox hypervisor. In such situations, the server stops booting and access to the storage becomes completely blocked. However, the data on the drives is usually still intact. That is why we perform recovery on a standard Linux computer, to which it is sufficient to connect the disk from the failed server.
After launch, the utility automatically analyzes the file structure of the connected drive. Since we are dealing with LVM-Thin storage, you will not find the usual directories containing image files here; instead, the program reads the pool metadata on its own and recognizes the virtual machine disks as separate logical volumes.
For the utility, just like for Proxmox itself, each such volume appears as an isolated block device that is fully ready for further deep scanning.
To recover lost objects, we will use Hetman RAID Recovery.
In our case, after connecting the disk with the LVM structure, the utility analyzes it automatically and recognizes the pool logical volumes. In the program window, these virtual machine volumes will be displayed not as image files, but as fully connected physical disks.
First, let us find the system disk of our virtual machine. It will have the identifier vm-101-disk-0 and a capacity of 20 gigabytes. Since the guest operating system was Windows 10 Pro, the program will immediately detect the corresponding file system on it.
Click this disk and start Fast scan. This quick scan is ideal for finding recently deleted files or working with intact file systems.
After the analysis is complete, open the found file system and go to the usual Windows folder hierarchy. Find the directory from which your data disappeared. The program will display all found objects.
Select the required files by ticking the checkboxes and click Recovery on the toolbar.
On the next step, the program will ask you to specify the path for saving the files. Be sure to choose a separate drive with enough free space to avoid overwriting the original data, and confirm the operation.
Now let us move on to the additional drive that we created and connected to this same virtual machine for file storage. Return to the main menu and select the next logical volume named vm-101-disk-1 with a capacity of 3 gigabytes.
Run the same Fast scan mode for it. After scanning, open the disk contents, find the deleted test files, select them, and repeat the save procedure.
As you can see, the program allows you to work with each logical volume of the virtual machine separately in an isolated and convenient way, displaying them as ordinary physical drives, which ensures successful and fast recovery of all lost information.
METHOD 2. Recovery via Snapshots
Let us move on to one of the most interesting data protection mechanisms — working with snapshots, or system state images.
The key feature of snapshot creation in an LVM-Thin environment is that the hypervisor does not physically copy files or fully clone disks. Instead, the system generates a new logical volume that instantly records the current state of the metadata and blocks of the original disk at the moment the snapshot is created.
In our program’s device list, such volumes are easy to identify because they have a specific name prefix, for example snap_vm-101-disk-1.
This architecture opens unique possibilities for data recovery. Imagine that after the snapshot was created, important documents were irreversibly deleted from the main virtual machine disk. From the perspective of the current guest operating system, this data is gone, but its original blocks are safely preserved inside the system snapshot.
Hetman RAID Recovery can read such LVM snapshots directly, eliminating the need to boot the hypervisor or perform a full rollback of the virtual machine through the console.
To begin recovery, we search in the utility’s main window for the snapshot of the virtual machine system disk vm-101. This snapshot volume contains the full structure of the operating system and user files as of the moment the snapshot was created.
We select it and start Fast scan.
The program will instantly analyze the frozen file system, allowing us to access the data even if the virtual machine itself later experienced critical changes or an erroneous rollback.
We then locate the snapshot of the additional drive in the same way. In the list of logical volumes, it is labeled snap_vm-101-disk-1. During our work, we added new test files, created a second system snapshot, and then deliberately deleted part of the information from all environments.
Applying Fast scan to this second snapshot allows us to read its file table instantly and successfully find all the documents that we deleted at the final stage. Since the data blocks are safely preserved inside the snapshot, they remain fully readable by our software, even though they have already been deleted from the guest Windows system itself.
Next, everything is standard: we select the required objects, click Recovery on the toolbar, and specify a safe path for saving the data to the hard drive of our computer.
As we can see, using Fast scan to directly read LVM-Thin snapshots saves a significant amount of time, since it eliminates the need for complex recovery operations through the Proxmox console.
Conclusion
Recovering data from virtual machines and Snapshots on LVM-Thin in Proxmox VE has its own specifics, since the information is stored not as regular files but within the block structure of the Thin Pool. Therefore, standard file-system access may be insufficient for finding lost information.
In the event of storage corruption, deletion of a virtual machine, loss of configuration, or issues with the Proxmox server, it is important not to perform operations that may overwrite the source data. First, you need to identify the LVM-Thin structure, gain access to the relevant logical volumes, and only then proceed to data analysis and recovery.
Specialized data recovery software makes it possible to work with the LVM-Thin structure and mounted virtual disk images, search file systems, and recover files from virtual machines and Snapshots.
Thus, even if Proxmox VE no longer starts the virtual machine or standard tools cannot access its disk, the data may still be physically present on the storage. Proper analysis of the LVM-Thin structure and the use of appropriate recovery tools make it possible to access this information and preserve important files.
