On Thu, Apr 11, 2019 at 11:37:55AM +0200, Andrea Lo Pumo wrote: > - 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? Unfortunately, what gets overwritten is the inode table, which contains the inode structures. So all of the information which says, "logical block N of inode M is located on physical block P" is gone. So your only hope is going to be to use a program which looks at individual data blocks, and assumes that (for the most part) files tend to be allocated contiguously on the storage device. Fortunately, such a tool has already been written, and it is an open source tool called PhotoRec[1]. I see however, you've already tried PhotoRec. > 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. Yeah, unfortunately, no. You'll be able to find the directory data block, sure. And that will contain the inode number. But mke2fs overwrites the entire inode table, so there's nothing that you can find. > 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. You've listed the primary tools that are available already. It is possible to configure mke2fs to create an undo file, and then when something screws up they can use the e2undo file to unwind the modifications made by mke2fs (or e2fsck, if the undo file generation is enabled by e2fsck). This feature is not enabled by default, mainly because (a) it slows down the mke2fs and e2fsck operations, and that tends to make system administrators cranky, and (b) you have to put the e2undo file somewhere, and you need to have some kind of scheme to delete old e2undo files. So there is a lot of distribution integration changes that has never been done. Telling you this now isn't particularly helpful, since it's basically suggesting that you close the barn door after the horse has escaped. However, along with other changes you might want to make to your procedures (such as doing regular backups) to avoid future mistakes of this ilk, it might be something to consider. Good luck, and sorry there's not much else help we can offer you, - Ted
