Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.
Click here to check if anything new just came in.
August 18 2009
hail to ext3grep and its author
Today, I would like to thank Carlo Wood. Who's that you will probably think. He is the author of ext3grep. But first things first.
Everyone's (or at least my) homedir gets a little congestet from time to time and needs to be tidied up. As it goes, I once had a file 'bl.tex' for testing something and this file and all that get created during the run of 'pdflatex' were still lying around. So I typed 'rm bl.*' or at least I wanted to, instead I issued 'rm bl*'. One little dot, but a much larger effect. It happens that I had a file called blub.txt with some important content, and of course after that command, that file was gone.
Few seconds later, after I realized what I had done, I issued 'mount -o remount,ro /mnt/raid1' at my server. This is the volume where my homedir resides. This is important, as it stops writing to the filesystem. If writing would continue, the file might be overwritten or the journal would have lost the interesting parts. (Journal is involved in restore operation)
I probably could have used 'ext3grep /dev/mapper/storage-store --restore-file "home/nobody/blub.txt" however, as '/mnt/raid1' is a 750GB Volume, that would have taken some time. (I would have been willing to spend it, but as a nerd I of course wanted to have a faster way)
I did an "ls -li" in my homedir and discovered that the inode numbers of my files where more or less linear, probably because I recently moved my homedir by rsyncing it all to a new volume. I looked up the inode of the file lexically-before the first file deleted and the inode of the file lexivcally-after the last file deleted.
This way, I could be very sure that blub.txt had an inode somewhere between 10125947 and 10125958. Using
'for i in $(seq 10125947 10125958); do ext3grep /dev/mapper-storage-store --restore-inode $i; done'
I restored all those files deleted. Figuring out which of them was blub.txt was an easy task.
ps> 'ext3grep /dev/mapper-storage-store --ls --inode <inode of homedir>' would have probably shown the inode of 'blub.txt' too, but that would have taken some time on a 750GB volume.
Everyone's (or at least my) homedir gets a little congestet from time to time and needs to be tidied up. As it goes, I once had a file 'bl.tex' for testing something and this file and all that get created during the run of 'pdflatex' were still lying around. So I typed 'rm bl.*' or at least I wanted to, instead I issued 'rm bl*'. One little dot, but a much larger effect. It happens that I had a file called blub.txt with some important content, and of course after that command, that file was gone.
Few seconds later, after I realized what I had done, I issued 'mount -o remount,ro /mnt/raid1' at my server. This is the volume where my homedir resides. This is important, as it stops writing to the filesystem. If writing would continue, the file might be overwritten or the journal would have lost the interesting parts. (Journal is involved in restore operation)
I probably could have used 'ext3grep /dev/mapper/storage-store --restore-file "home/nobody/blub.txt" however, as '/mnt/raid1' is a 750GB Volume, that would have taken some time. (I would have been willing to spend it, but as a nerd I of course wanted to have a faster way)
I did an "ls -li" in my homedir and discovered that the inode numbers of my files where more or less linear, probably because I recently moved my homedir by rsyncing it all to a new volume. I looked up the inode of the file lexically-before the first file deleted and the inode of the file lexivcally-after the last file deleted.
This way, I could be very sure that blub.txt had an inode somewhere between 10125947 and 10125958. Using
'for i in $(seq 10125947 10125958); do ext3grep /dev/mapper-storage-store --restore-inode $i; done'
I restored all those files deleted. Figuring out which of them was blub.txt was an easy task.
ps> 'ext3grep /dev/mapper-storage-store --ls --inode <inode of homedir>' would have probably shown the inode of 'blub.txt' too, but that would have taken some time on a 750GB volume.
