Accidental deletion of data on a VDO volume, any chance of recovering it?

[tigerblue77]

Hello,
Almost everything is in the title, I don't have backups or snapshots... Any idea ?

I'm using Debian 12, 6.1 kernel and KVDO 8.2.1.3

I already tried :

• testdisk
  => which gives me testdisk write isn't available because the partition table type none even if it detects EXT4 FS
• ext4magic /dev/Ultron-vg/COMPRESSED-DEDUPLICATED-VDO-LV-1 -r /var/lib/docker/
  => which gives me ERROR: can not use "RECOVERDIR" for recover directory. It's the same filesystem : "/dev/Ultron-vg/COMPRESSED-DEDUPLICATED-VDO-LV-1"
• scalpel /dev/Ultron-vg/COMPRESSED-DEDUPLICATED-VDO-LV-1 -o /mnt/recovery/
  => which seems to recover a lot of things but no file tree...
• extundelete /dev/Ultron-vg/COMPRESSED-DEDUPLICATED-VDO-LV-1 --restore-all
  => which gives me

extundelete /dev/Ultron-vg/COMPRESSED-DEDUPLICATED-VDO-LV-1 --restore-all
NOTICE: Extended attributes are not restored.
Loading filesystem metadata ... 9831 groups loaded.
Loading journal descriptors ... malloc(): invalid next size (unsorted)
Abandon`

Of course if you think I'm miss using one of these tools, tell me !
For now, I unmounted the volume and unloaded KVDO module to ensure nothing is cleaned... Although I already restarted.

Thanks in advance for your help !

[raeburn]

Unfortunately, I think you’re probably looking at the best tools already. There’s no provision in VDO for accessing older versions of the content.

If your file system isn’t mounted with the discard option, and you haven’t run fstrim, the unreferenced data blocks should be visible to file system recovery tools a while; VDO doesn’t know anything about the file system structure and will preserve the data until it’s overwritten or trimmed.

We don’t immediately scribble over every block that’s been trimmed (and isn’t a duplicate), either, so the raw bits might survive a while on the underlying storage until they get reallocated to use for more data, especially if the data was highly compressible (because all compressed fragments stored together in one block have to have all references dropped before the block can be reused). But there’s no good way to locate the previous address mappings to put the file system structure back together.

[tigerblue77]

Hello @raeburn,
Thanks for your reply. I've been very busy since but server was shutted down and I can't get used to the idea of losing this data.

If your file system isn’t mounted with the discard option, and you haven’t run fstrim

Yes, it's my case.

there’s no good way to locate the previous address mappings to put the file system structure back together.

So, if I understand correctly, there is no chance I get back these files... ?

Today I started the server, didn't mount the VDOLV, I ran a testdisk /dev/mapper/Ultron--vg-COMPRESSED--DEDUPLICATED--VDO--LV--1 then selected "None" as I had no partition, I was writing directly on VDO LV, and here is the result :

then when I hit "Enter" :

Write isn't available because the partition table type "None" has been selected.

And when I browse found files, I unhide deleted files but I don't find the folder I'm looking for...

I'll re-try other tools in next days but any advice is welcome :)

[pabloab]

You could try also sleuthkit (autopsy is its GUI) or foremost.