Sorry for writing on this development mailing list, we are seeking an expert in ext4, we are also willing to offer a professional contract to solve this issue. On /dev/sda1(*) there was an ext4 file system with a lot of large files. Now, by mistake, mkfs.ext4 has been run on /dev/sda1. The result is that now /dev/sda1 is "empty": mounting it shows no files. Note *: actually, it is /dev/mapper/secure_storage, an encrypted volume opened with LUKS: cryptsetup luksOpen /dev/sda1 secure_storage Note 2: Ubuntu 18.04 This is my current understanding: - Originally, /dev/sda1 was created with "mkfs.ext4 /dev/sda1" - Now, the second "mkfs.ext4 /dev/sda1" has overwritten the superblock, and all backups of the superblock (because it has created the backups of the NEW superblock at the exact same locations of the previous superblock backups). - The inode map has been overwritten too. - However, the data is still there in the disk, and also the related inode structures. (Just the inode map is missing right?). So, if one is able to locate these inode structures, the relative files could be recovered. We know the name of important directories and files to be recovered. Could this help? We are willing to discuss a professional contract tailored to solve this issue. So if you have the right knowledge, or you know someone, please let us know. I could also invest some programming efforts to solve this issue, by hacking some available tools, if this could help and is not too complex. In this regard, I have this question: given that I know the name of some important directories and files to be recovered, theoretically I could write a program that "greps" the name of the file in /dev/sda1 and, around that point, I should locate the inode structure, and with the inode recover the whole file? Any hint toward this direction? I don't have experience with ext programming, but I am willing to hack. Final question: are there tools to handle this situation? testdisk and ext4magic do not seem to give good results. Photorec is useless to recover large .tar.gz and .ogg files, and more importantly the name of the file, which we also need. Thank you. Best regards.