reiserfs文件系统反删除（Undelete）操作的实践

Hi all,

I just want to thank for the tips on recovering deleted files. I've just wrongly deleted some files and been able to recover them by following your steps / steps from pages mentioned herein. Instead of finding deleted files in lost+found directory, I've ended up finding them in the original directories (from where they were deleted). I've compiled the sequence of steps for my specific case (slight changes will suit particular issues regarding unwanted file deletion), which follows:

Recover deleted files (from /home = /dev/hda7)
0. Unmount partition from where to recover deleted files

umount /home

1. Create partition copy

dd if=/dev/hda7 conv=noerror > /hda7.img

2. Set up device containing copy of partition (created in 1.)

losetup /dev/loop/0 /hda7.img

3. Rebuild FS tree, performing a thorough partition scan and logging to /recovery.log file

reiserfsck --rebuild-tree -S -l /recovery.log /dev/loop/0

(4. Check written log file)

(less /recovery.log)

5. Create directory for mounting recovered partition

mkdir /recovery

6. Mount recovered partition in directory created in 5.

mount /dev/loop/0 /recovery

7. Access recovered partition's lost+found directory and look for files

cd /recovery/lost+found

8. If not there (7.), then look for in original directory

cd /recovery/

9. Remount /home partition

mount /home

10. Copy recovered files from 7./8. to /home/

cp /recovery// /home//

11. Unmount recovered partition

umount /recovery

12. Detach recovered partition device

losetup -d /dev/loop/0

@nT$

Reiserfs filesystem recovery

Cleaning up after disk crashing season hasn't been fun, but I am pleased with what I've managed to recover from the worst crash.

I wanted to get the latest data from the dead webserver. It was in MySQL, and stored in /var/lib/mysql. Unfortunately, the /var/lib directory no longer existed.

I didn't want to try to recover it in place -- with so many bad blocks, things can only get worse -- so I copied the entire partition to a file on my laptop (the one with the shiny new disk): ssh deadserver dd if=/dev/hda1 conv=noerror > hda1.img (You need the conv=noerror or else dd will stop when it hits the first bad block.)

So, then I had most of a corrupt filesystem image. To make it useful I used the loop driver: losetup /dev/loop/0 hda1.img

Now I could try reiserfsck to see what I could recover. I started with reiserfsck --rebuild-sb /dev/loop/0 to rebuild the superblock: even it if hadn't been affected by the physical disk corruption, it would certainly be confused by it new home in a looped image that probably wasn't the same size as the original partition. Next step was reiserfsck --rebuild-tree /dev/loop/0 to try to find the contents of the missing directories. I finished it off with reiserfsck --check /dev/loop/0 to make sure it was happy.

Now I can just mount /dev/loop/0 /mnt and have a look in /mnt/lost+found. The data is there!

List: reiserfs
Subject: Re: "Unformat" a ReiserFS partition : a testimony :-)
From: Vitaly Fertman
Date: 2003-03-25 17:25:38
[Download message RAW]

Hi,

On Tuesday 25 March 2003 03:16, Yury Umanets wrote:
> Nicolas Vanderavero wrote:
> > Hello,
>
> Hello Nicolas,
>
> > while reinstalling a Debian on a new hard drive, I made the mistake to
> > format in reiserfs my good old /home which was on /dev/sda7 instead of
> > formatting the new /dev/hda7. Gasp ! Eight gigabytes lost ...
> >
> > Or ... maybe it was not totally lost :-) I immediately made a dump of
> > the partition with 'dd' and started grepping some known text on it. It
> > seemed that no data was really lost. I didn't know what to do. So I
> > read the man pages and found the reiserfsck command quite interesting :-)
>
> You have lost the super block and probably old root node. I said
> "probably" because it might be not used in teh time you did format.

superblock, bitmaps, journal content and almost always one block which usualy
is not old root node, but the very first leaf on the fs with a part/the whole
root directory.

> > Ok, I am a total newbie to filesystems and to ReiserFS. So maybe it
> > will sound trivial to you, but just in case it happens to anyone else,
> > I just wanted to say that running a reiserfsck --rebuild-tree -S on my
> > partition was enough to unformat it. I ended up with some file in
> > lost+found, but a 'file *' is enough to discover what they are.

Right.

> The first thing you should do in cases like this is to make backup. I
> hope you'll find eight gigabytes for that. Now you may feel free to do
> anything with you old partition. Then you should to do --rebuild-sb and
> try to fsck the partition with --check key. Then follow to fsck sugestions.

:)) no, Yura, reiserfs is in a good state after mkreiserfs and --rebuild-sb /
--check will say 'all is fine, enjoy'. Plus, -S is used in cases when fs is
ok, but some data are lost, so you may want to backup not the whole partition,
but only cp important data somewhere from the mounted fs (to avoid their
corruption while rebuilding with -S option what may occure).

> These should be enought for getting you partition back.
>
> > So, maybe it would be usefull to add an entry in the "Example of
> > using" section of the man page of reiserfsck, saying something like :
> > "If you reformatted by mistake a reiserFS partition, you can try to
> > unformat it by running reiserfsck --rebuild-tree -S on it".

--scan-whole-partition does what is written in man page - scan the whole
partition, not only used space - and brings back all what was found. That
means that have just created reiserfs partition with all copeid data on
it will be recovered, all not overwritten data from the previous reiserfs
will be recovered. There were also some data which were deleted once and
the space they occupied has not been reused - get recoved also. All data
with the same key go to the same file/dir and old versions of files will
be merged with new versions, or deleted file will be merged with the new
one - this may lead to data corruption. And while building the tree for
all these found data you can run out of disk space.

So it is not an undelete feature and not unformat feature, although can be
used pretty efficiently for these 2 purpose _just_after_ a wrong remove /
format. Or just after fsck --rebuild-tree, if fsck has not recovered some
important data due to bitmap corruption.
As a result, -S is more like a hack - it is not undelete, unformat, undo,
but you can try to recover smth from unused space, valid data can become
corrupted while being merged with old data, so it should be used with high
caution and it is not for wide-usage anyway.

> P.S. Please read http://www.namesys.com/support.html. Can you as for
> support?

It seems that Nicolas does not need our support as he wrote about his
result how he had successfully unformatted the fs.

--

Thanks,
Vitaly Fertman

UPDATE (15 June, 2004): I just found this thread which warns of possible corruption of existing files on the partition. Essentially, the recovery process may take older (deleted) versions of a current file and try and merge it with the new file resulting in data corruption. As a safety measure, make a backup of important undamaged files on another partition before you carry out the steps below.

UPDATE (31 March, 2005): Make sure you read through all the comments to this howto before starting the recovery process. Lots of tips and warnings are present in those comments!

UPDATE (11 August, 2005): For even more hopeless data loss cases, try Foremost.

NOTE: These steps are only for really bad hard disk muck-ups and accidentally deleted files. For normal filesystem inconsistencies, don't use these steps!

1. Once you realize that you've lost data, don't do anything else on that partition - you may cause that data to be overwritten by new data.
2. Unmount that partition. e.g., umount /home
3. Find out what actual device this partition refers to. You can usually get this information from the file /etc/fstab. We'll assume here that the device is /dev/hda3.
4.

Run the command: reiserfsck --rebuild-tree -S -l /root/recovery.log /dev/hda3

You need to be root to do this. Read the reiserfsck man page for what these options do and for more options. Some interesting options are '--rebuild-sb, --check'

After the command finishes, which might be a long time for a big partition, you can take a look at the logfile /root/recovery.log if you wish.
5. Mount your partition: mount /home
6. Look for the lost+found directory in the root of the partition. Here, that would be: /home/lost+found
7. This directory contains all the files that could be recovered. Unfortunately, the filenames are not preserved for a lot of files. You'll find some sub-directories - filenames within those are preserved!
8. Look through the files and copy back what you need.

Here's a useful link for more advanced tricks.

Hope that helps! Please leave a comment here if you found this page useful and/or if there should be something more on this page that I missed.

PS: For normal filesystem inconsistencies, use the --fix-fixable option with reiserfsck. See the man page for more on that.