Proxmox Storage Recovery Challenge: Help Us Design a Realistic Data Loss Experiment

Hi! First, a quick disclosure. I'm one of the developers at Hetman Software, a Ukrainian company that has been developing commercial data recovery software for over 15 years.

I hope this doesn't come across as self-promotion. I'd like to propose a technical experiment, get feedback from experienced Proxmox administrators, and share what we find, including any failures or limitations.

The idea is to build a Proxmox VE test environment, deliberately break something, and investigate what can actually be recovered.
Here's the initial setup I'm considering:
  • ZFS: A ZFS pool configured as either RAIDZ1 or dRAID1, depending on the community's preference. We'll also use native ZFS encryption, compression, and snapshots.
  • LVM: A dedicated disk with thick-provisioned logical volumes.
  • LVM-Thin: Another disk with a thin pool and snapshots.
  • Directory storage: Ext4 and XFS for file-based virtual disks.
  • Virtual machines: Several Windows and Linux VMs using different storage configurations, including RAW, QCOW2, ZVOLs, and thick/thin LVM volumes. We could also include VMDK images.
We'll fill the virtual disks with known test data, record SHA-256 hashes, create snapshots at different stages, add more files, and delete some of the existing ones.

I'd like the community to suggest what we should break.

A few possible scenarios:
  1. Accidentally delete one or more VMs, including their virtual disks.
  2. Delete a ZFS dataset or destroy an entire pool.
  3. Simulate disk failures in RAIDZ1 or dRAID1, staying within their parity tolerance.
  4. Delete LVM volumes or damage LVM-Thin metadata.
  5. Delete snapshots, or combine several destructive operations into a more complicated failure scenario.
These are just starting points. If you have a more realistic or challenging scenario based on your own experience, I'd be interested in reproducing it.

Another question is how we should perform the recovery analysis.

I see two possible approaches:
  1. Run our recovery software inside a dedicated VM, giving it direct, strictly read-only access to the physical disks while keeping the Proxmox host running.
  2. Shut down the server, connect the disks to another computer, and perform the analysis offline.
I'm particularly interested in whether the first approach is technically feasible and safe, especially when the disks belong to a ZFS pool or LVM storage managed by the Proxmox host. Has anyone experimented with this kind of setup? What limitations should we consider?

My background is mainly in low-level storage analysis, filesystem internals, RAID reconstruction, and data recovery. I don't have the same experience administering large production Proxmox environments with many users and virtual machines. So if some of my proposed configurations seem unusual or unrealistic from an administrator's perspective, please point that out. That's exactly the kind of feedback I'm looking for.

What I can contribute is a detailed analysis of what actually gets written to disk during different operations, what metadata and file contents remain afterward, and whether software-based recovery is possible.

I'll document the test environment, recovery process, SHA-256 verification results, and the reasons why recovery succeeds or fails.

We can start with one experiment chosen by the community, or run a series of different scenarios if there's enough interest.

I'd appreciate your suggestions, especially from anyone who has dealt with unusual Proxmox storage failures in real production environments. What would you like us to test?
 
While I do not run large clusters but only a few smaller ones I see some additional failure sources - random thoughts:
  • is it a cluster or a single machine? For a cluster you may inject network errors/outages
  • I am not sure how to emulate Ram errors - but if you could inject them, it would damage data on storage earlier or later (without ECC at least)
  • bad power supplies (delivering too low voltage and/or ripple) could introduce "strange" errors on the whole motherboard
Run our recovery software inside a dedicated VM, giving it direct, strictly read-only access to the physical disks
Can you do this??? (I've never tried.)
In my understanding the most filesystems will alter meta data when data is read...

For a first test-setup you could virtualize the whole cluster. Then you can destroy the virtual hosts after creating a snapshot - for both quick repair and comparison after a crash.

Again: I am in no way a specialist in this area, I am just a "normal" PVE administrator - just brainstorming... ;-)
 
Thank you for the suggestions! Unfortunately, I don’t have enough hardware available to build and test a Proxmox cluster, so I’ll focus on a single-node setup for this experiment.


However, the idea of virtualizing the environment and using snapshots to reproduce failures and compare results is interesting. I’ll keep it in mind.
 
I think you're going about this the wrong way.

the payload of virtualization or standalong filesystem are not materially different. when I fire up testdisk on a block device, it doesnt care whether its a fileset of naked pictures or a root linux filesystem. If your intention is to built a zfs file recovery tool, just do that ;)
Can you do this??? (I've never tried.)
Yes. it works the same as it does on metal. once a disk is presented to a vm its indistinguishable from metal.