Undelete files / directory

Undelete files / directory

[Jean-Denis Girard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi list,

Two days ago I mistakenly deleted a directory on a btrfs file system. As
soon as I realized, I cleanly unmounted the partition, and have not
touched it since then. I have no snapshot and no backup; I was on
vacations with my laptop, and the directory deleted contained ~3 weeks
of photos.

I found this script:
http://comments.gmane.org/gmane.comp.file-systems.btrfs/22560
but the commands have probably changed, and it no longer runs.

So is there a way to recover a deleted directory on btrfs? Just to make
things clear, this is not a broken file system, just a normally deleted
directory.

I'm on Fedora 20, with kernel 3.15.10-200.fc20.x86_64, and
btrfs-progs-3.14.2-3.fc20.x86_64.


Thanks,
- -- 
Jean-Denis Girard

SysNux                  Systèmes    Linux    en  Polynésie  française
http://www.sysnux.pf/   Tél: +689 40.50.10.40 / GSM: +689 87.79.75.27
-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAlP+HbIACgkQuu7Rv+oOo/hH7wCdFJhYm4eFwU5TbUyrdWM4iIuP
aqQAn2H3D0dvEznBhgyij8Pn8Ww6XQF5
=ybUk
-----END PGP SIGNATURE-----

Re: Undelete files / directory

[Duncan]

Jean-Denis Girard posted on Wed, 27 Aug 2014 08:04:34 -1000 as excerpted:

> Two days ago I mistakenly deleted a directory on a btrfs file system. As
> soon as I realized, I cleanly unmounted the partition, and have not
> touched it since then. I have no snapshot and no backup; I was on
> vacations with my laptop, and the directory deleted contained ~3 weeks
> of photos.
> 
> I found this script:
> http://comments.gmane.org/gmane.comp.file-systems.btrfs/22560 but the
> commands have probably changed, and it no longer runs.
> 
> So is there a way to recover a deleted directory on btrfs? Just to make
> things clear, this is not a broken file system, just a normally deleted
> directory.
> 
> I'm on Fedora 20, with kernel 3.15.10-200.fc20.x86_64, and
> btrfs-progs-3.14.2-3.fc20.x86_64.

Were you trying to use that script as-posted without understanding what 
it did?  You realize how easy it'd be for someone to post some script 
claiming to do something great, that instead did a rm -rf /* or some 
such, right?

Anyway, looks like line 67 needs changed.

The command is now btrfs-find-root not just find-root, and the script 
assumes it's being run from the same directory as the find-root command, 
which isn't likely to be the case, so you can remove the "$dir"/ bit and 
just let the normal path do the searching.  You can read the btrfs-find-
root manpage and experiment with running the command on its own a bit to 
see what it does.

Then, it looks like he hard-coded the device-path for the filesystem as 
/dev/mapper/queen-home.  You'll need to fix that.  Looks like you can 
replace it with "$dev".

So line 67 should look like this:

btrfs-find-root "$dev" 2>&1 \

Line 84, the command should be btrfs restore.  Again, kill the $dir/ bit 
along with the quote around the command, and you can read about it in the 
btrfs-restore manpage.

Finally, at least as I'm seeing it here, line 103 is a bunch of 
corruption at the end of the file and can simply be deleted.

At a quick glance that's all that immediately jumps out at me as needing 
changed, but I neither examined the output of btrfs-find-root too closely 
to see if lines 68 and 69 need changed at all, nor the command-line 
options to see if they changed.  Presumably you can do that yourself -- 
thus the mentions of the manpages and experimenting with the btrfs-find-
root command.

Also, while nothing immediately jumps out at me as bad about the script, 
keep in mind that something simply posted to a list isn't a trusted 
source already checked for at least the worst system-eating mistakes like 
your distro's packages should be, and you'll need to run it as root for 
device access.  I've not gone thru it looking for stuff that might go 
wrong if fed the wrong parameters, etc.  Understand what it actually does 
before attempting to run it as root, as if he screwed up something and/or 
you mistype the parameters you're feeding it, I don't expect you want it 
deleting all your files as a result!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: Undelete files / directory

[Chris Murphy]

Line 84
		"$dir/restore" -i -t $id -m "$regex" "$dev" $out

I don't see a -m option for btrfs restore, maybe use --path-regex instead.

I just did this without the script and it worked:

1. mkfs.btrfs /dev/sdc
2. mount /dev/sdc /mnt
3. mkdir /mnt/pics
4. scp IMG_3327.tif <blahhost>:/mnt/pics/    #copied TIFF from another computer
5. btrfs fi sync /mnt     #make sure it's committed
6. rm -f /mnt/pics/IMG_3327.tif
7. btrfs fi sync /mnt     #make sure it's gone, superfluous probably
8. umount /mnt
9. btrfs-find-root /dev/sdc
Super think's the tree root is at 29917184, chunk root 20987904
Well block 4194304 seems great, but generation doesn't match, have=2, want=9 level 0
Well block 4243456 seems great, but generation doesn't match, have=3, want=9 level 0
Well block 29376512 seems great, but generation doesn't match, have=4, want=9 level 0
Well block 29474816 seems great, but generation doesn't match, have=5, want=9 level 0
Well block 29556736 seems great, but generation doesn't match, have=6, want=9 level 0
Well block 29736960 seems great, but generation doesn't match, have=7, want=9 level 0
Well block 29900800 seems great, but generation doesn't match, have=8, want=9 level 0
Found tree root at 29917184 gen 9 level 0

At this point I can pretty much guess that the file I want is in generation 7. It might be in 8. But I went ahead and looked for it using btrfs-debug-tree and sure enough I see a bunch of items with very big lengths and it's gen 7. So in the above list, block 29736960 is for generation 7.

10. btrfs restore -t 29736960 -v /dev/sdc /home/chris
parent transid verify failed on 29736960 wanted 9 found 7
parent transid verify failed on 29736960 wanted 9 found 7
parent transid verify failed on 29736960 wanted 9 found 7
parent transid verify failed on 29736960 wanted 9 found 7
Ignoring transid failure
Restoring /home/chris/pics
Restoring /home/chris/pics/IMG_3327.tif
Done searching /pics
Done searching 


11. I did an shasum on the restored and original TIFFs and they match.


So the script probably makes it easier to find the right root, and also has a regex pattern to probably filter out the junk. In retrospect I probably should have deleted the directory rather than the file for this test, so I went back and mounted sdc, rmdir'd the directory, unmounted, and the same command still restores the file that was in that directory.


Chris Murphy

Re: Undelete files / directory

[Jean-Denis Girard]

Hi Chris,

Thanks for your detailed answer.

Le 28/08/2014 06:25, Chris Murphy a écrit :
> 9. btrfs-find-root /dev/sdc
> Super think's the tree root is at 29917184, chunk root 20987904
> Well block 4194304 seems great, but generation doesn't match, have=2, want=9 level 0
> Well block 4243456 seems great, but generation doesn't match, have=3, want=9 level 0
> Well block 29376512 seems great, but generation doesn't match, have=4, want=9 level 0
> Well block 29474816 seems great, but generation doesn't match, have=5, want=9 level 0
> Well block 29556736 seems great, but generation doesn't match, have=6, want=9 level 0
> Well block 29736960 seems great, but generation doesn't match, have=7, want=9 level 0
> Well block 29900800 seems great, but generation doesn't match, have=8, want=9 level 0

Here is what the command returns :

[root@x220 ~]# btrfs-find-root /dev/mapper/home
Super think's the tree root is at 115230801920, chunk root 131072
Went past the fs size, exiting[root@x220 ~]#

I just tried with latest btrfs-progs (from git), it returns exactly the
same.

The btrfs partition is on top of dm-crypt, could it be a problem?


Thanks,
Jean-Denis Girard

Re: Undelete files / directory

[Chris Murphy]

On Aug 28, 2014, at 11:04 AM, Jean-Denis Girard <jd.girard@sysnux.pf> wrote:

> Hi Chris,
> 
> Thanks for your detailed answer.
> 
> Le 28/08/2014 06:25, Chris Murphy a écrit :
>> 9. btrfs-find-root /dev/sdc
>> Super think's the tree root is at 29917184, chunk root 20987904
>> Well block 4194304 seems great, but generation doesn't match, have=2, want=9 level 0
>> Well block 4243456 seems great, but generation doesn't match, have=3, want=9 level 0
>> Well block 29376512 seems great, but generation doesn't match, have=4, want=9 level 0
>> Well block 29474816 seems great, but generation doesn't match, have=5, want=9 level 0
>> Well block 29556736 seems great, but generation doesn't match, have=6, want=9 level 0
>> Well block 29736960 seems great, but generation doesn't match, have=7, want=9 level 0
>> Well block 29900800 seems great, but generation doesn't match, have=8, want=9 level 0
> 
> Here is what the command returns :
> 
> [root@x220 ~]# btrfs-find-root /dev/mapper/home
> Super think's the tree root is at 115230801920, chunk root 131072
> Went past the fs size, exiting[root@x220 ~]#
> 
> I just tried with latest btrfs-progs (from git), it returns exactly the
> same.
> 
> The btrfs partition is on top of dm-crypt, could it be a problem?

Doubtful.

What do you get for 

btrfs-debug-tree -R /dev/sdc

Under each listed "btrfs root backup slot" is a line for tree root block with a generation and a block number listed. Good chance the generation with the highest value will not contain your file; or any generation more than 30 seconds from the time of the deletion. But since it's a read only command you can't really mess it up, just try each of those tree root block values in reverse (descending) order for the btrfs restore -t value.

Obviously you should not mount the volume rw.


Chris Murphy

Re: Undelete files / directory

[Jean-Denis Girard]

Le 28/08/2014 10:21, Chris Murphy a écrit :
> What do you get for 

[root@x220 ~]# btrfs-debug-tree -R /dev/mapper/home

root tree: 115230801920 level 1
chunk tree: 131072 level 1
extent tree key (EXTENT_TREE ROOT_ITEM 0) 115230806016 level 2
device tree key (DEV_TREE ROOT_ITEM 0) 115191881728 level 0
fs tree key (FS_TREE ROOT_ITEM 0) 115215908864 level 3
checksum tree key (CSUM_TREE ROOT_ITEM 0) 115230842880 level 3
uuid tree key (UUID_TREE ROOT_ITEM 0) 115196645376 level 0
data reloc tree key (DATA_RELOC_TREE ROOT_ITEM 0) 115623051264 level 0
btrfs root backup slot 0
        tree root gen 138441 block 115220434944
                extent root gen 138441 block 115217117184
                chunk root gen 73727 block 131072
                device root gen 130645 block 115191881728
                csum root gen 138441 block 115216838656
                fs root gen 138441 block 115215908864
                26813235200 used 42947575808 total 1 devices
btrfs root backup slot 1
        tree root gen 138442 block 115230801920
                extent root gen 138442 block 115230806016
                chunk root gen 73727 block 131072
                device root gen 130645 block 115191881728
                csum root gen 138442 block 115230842880
                fs root gen 138441 block 115215908864
                26813235200 used 42947575808 total 1 devices
btrfs root backup slot 2
        tree root gen 138439 block 115231158272
                extent root gen 138439 block 115230871552
                chunk root gen 73727 block 131072
                device root gen 130645 block 115191881728
                csum root gen 138440 block 115231473664
                fs root gen 138440 block 115231453184
                26818527232 used 42947575808 total 1 devices
btrfs root backup slot 3
        tree root gen 138440 block 115210838016
                extent root gen 138440 block 115233878016
                chunk root gen 73727 block 131072
                device root gen 130645 block 115191881728
                csum root gen 138441 block 115216838656
                fs root gen 138441 block 115215908864
                26813243392 used 42947575808 total 1 devices
total bytes 42947575808
bytes used 26813235200
uuid ca93d247-9076-4aa7-862b-a6add3a5c16c
Btrfs v3.14.2

So this seems fine; why is btrfs-find-root not working for me?

Then I tried to use the root with oldest generation:
[root@x220 ~]# btrfs restore -t 115231158272 -v /dev/mapper/home
--path-regex '^/(|jdg(|/tmp(|/.*)))$' .

It did recover many files / directories, but unfortunately not my
photos. Does it mean I discovered my mistake and unmounted the partition
too late, and the info is lost?

I made a dump of the device to another computer (using dd), I think the
data are still here (hexedit).

What else could I try?


Thanks,
Jean-Denis Girard

Re: Undelete files / directory

[Chris Murphy]

On Aug 28, 2014, at 11:04 AM, Jean-Denis Girard <jd.girard@sysnux.pf> wrote:

> Hi Chris,
> 
> Thanks for your detailed answer.
> 
> Le 28/08/2014 06:25, Chris Murphy a écrit :
>> 9. btrfs-find-root /dev/sdc
>> Super think's the tree root is at 29917184, chunk root 20987904
>> Well block 4194304 seems great, but generation doesn't match, have=2, want=9 level 0
>> Well block 4243456 seems great, but generation doesn't match, have=3, want=9 level 0
>> Well block 29376512 seems great, but generation doesn't match, have=4, want=9 level 0
>> Well block 29474816 seems great, but generation doesn't match, have=5, want=9 level 0
>> Well block 29556736 seems great, but generation doesn't match, have=6, want=9 level 0
>> Well block 29736960 seems great, but generation doesn't match, have=7, want=9 level 0
>> Well block 29900800 seems great, but generation doesn't match, have=8, want=9 level 0
> 
> Here is what the command returns :
> 
> [root@x220 ~]# btrfs-find-root /dev/mapper/home
> Super think's the tree root is at 115230801920, chunk root 131072
> Went past the fs size, exiting[root@x220 ~]#
> 
> I just tried with latest btrfs-progs (from git), it returns exactly the
> same.
> 
> The btrfs partition is on top of dm-crypt, could it be a problem?

So I'm working with a really rudimentary case here. However, this might also be possible:

# btrfs-show-super /dev/sdc
[snip]
generation		11
[snip]

That's the current generation at unmount time. If nothing at all was being written to the volume between delete time and unmount time, the generation you want will be one less than this.

Then you can use, for example:

# btrfs-debug-tree -g 10 /dev/sdc

And that'll hopefully return a tree block for that generation. In my case it wouldn't be good news because I had already had several remounts, so the generation had rolled over a few times since I'd deleted the file so it's not in generation 10, or even generation 8. So I tried generation 7 again where I found it before:

# btrfs-find-root -g 7 /dev/sdc
Super think's the tree root is at 29491200, chunk root 20987904
Well block 4194304 seems great, but generation doesn't match, have=2, want=7 level 0
Well block 4243456 seems great, but generation doesn't match, have=3, want=7 level 0
Well block 29409280 seems great, but generation doesn't match, have=10, want=7 level 0
Well block 29491200 seems great, but generation doesn't match, have=11, want=7 level 0
Well block 29556736 seems great, but generation doesn't match, have=6, want=7 level 0

Unfortunately there's no gen 7. So I'm not sure how to discover the tree block number.

I still have it written down from before of course, and it still works:

btrfs restore -v -t 29736960 /dev/sdc /home/chris/
parent transid verify failed on 29736960 wanted 12 found 7
parent transid verify failed on 29736960 wanted 12 found 7
parent transid verify failed on 29736960 wanted 12 found 7
parent transid verify failed on 29736960 wanted 12 found 7
Ignoring transid failure
Restoring /home/chris/pics
Restoring /home/chris/pics/IMG_3327.tif
Done searching /pics
Done searching 


The shasum for this file though doesn't match the original. Size is correct though. But it doesn't open, application says it's corrupted. So it might take some work to recover that, if even possible. So I'd definitely say (again) don't mount the volume rw. And hopefully nothing was written between directory delete time and unmount time.


Chris Murphy

Re: Undelete files / directory

[Chris Murphy]

On Aug 28, 2014, at 3:23 PM, Jean-Denis Girard <jd.girard@sysnux.pf> wrote:

> So this seems fine; why is btrfs-find-root not working for me?


Don't know. btrfs-progs 3.16 is current in git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git master branch. It's already built since yesterday in koji for Fedora if you can use RPMs.



> It did recover many files / directories, but unfortunately not my
> photos. Does it mean I discovered my mistake and unmounted the partition
> too late, and the info is lost?

I don't know. How much time between deletion and unmount? And was anything written after deletion and before unmount? I think there is a -d option to only go into a specified directory for recovery. And -D will do a dry run and should show what files will be recovered without recovering them. It may take a long time to actually do a restore only to find out the files you want aren't in it so maybe -D is useful.


Chris Murphy

Re: Undelete files / directory

[Chris Murphy]

On Aug 27, 2014, at 12:04 PM, Jean-Denis Girard <jd.girard@sysnux.pf> wrote:

> I'm on Fedora 20, with kernel 3.15.10-200.fc20.x86_64, and
> btrfs-progs-3.14.2-3.fc20.x86_64.

Ahh yes. So you'll see here that there's a new build for you not yet in updates repo.

http://koji.fedoraproject.org/koji/buildinfo?buildID=571861

Go here and click on the download link
x86_64	(build logs)
btrfs-progs-3.16-1.fc20.x86_64.rpm (info) (download)

You can apply it one of two ways:
yum install <downloadURL>

Or you can download the RPM to a local folder (curl -Os or whatever) and do:
yum install *rpm



Chris Murphy

Re: Undelete files / directory

[Jean-Denis Girard]

Le 28/08/2014 11:51, Chris Murphy a écrit :
> Ahh yes. So you'll see here that there's a new build for you not yet in updates repo.

btrfs-progs-3.16-1.fc20.x86_64 installed, but it doesn't change anything:

[jdg@tiare tmp]$ btrfs-find-root x220_home.img
Super think's the tree root is at 115230801920, chunk root 131072
Went past the fs size, exiting[jdg@tiare tmp]$


Thanks,
Jean-Denis Girard

Re: Undelete files / directory

[Konstantinos Skarlatos]

On 28/8/2014 8:04 μμ, Jean-Denis Girard wrote:
> Hi Chris,
>
> Thanks for your detailed answer.
>
> Le 28/08/2014 06:25, Chris Murphy a écrit :
>> 9. btrfs-find-root /dev/sdc
>> Super think's the tree root is at 29917184, chunk root 20987904
>> Well block 4194304 seems great, but generation doesn't match, have=2, want=9 level 0
>> Well block 4243456 seems great, but generation doesn't match, have=3, want=9 level 0
>> Well block 29376512 seems great, but generation doesn't match, have=4, want=9 level 0
>> Well block 29474816 seems great, but generation doesn't match, have=5, want=9 level 0
>> Well block 29556736 seems great, but generation doesn't match, have=6, want=9 level 0
>> Well block 29736960 seems great, but generation doesn't match, have=7, want=9 level 0
>> Well block 29900800 seems great, but generation doesn't match, have=8, want=9 level 0
Hi all,

I did a successful btrfs restore a few months ago, saving all of my 
deleted files except 2 (So i lost about 1GB on a 4TB filesystem)
Here is what i did (this is from memory and from my .zsh_history file, 
so i may be missing something)

btrfs-find-root  /dev/sdd -o 5 > b1.txt
I think the -o 5 option is quite important here.
After that, i ran this

for i in `awk '{print $3}' b1.txt`; do echo "------------------------  
$i --------------------" && btrfs restore /dev/sdd /storage/A3/ -Dv -f 
$i  ; done

I think i did that in order to brute force a correct offset

I also have done this, in order to find the offset that gave the largest 
number of files
for i in `awk '{print $3}' b1.txt`; do echo "------------------------  
$i --------------------" && btrfs restore /dev/sdd /storage/A3/ -Dv -f 
$i |wc -l ; done


Then i did some test restores using various addresses
btrfs restore /dev/sdd /storage/A3/B1/  -vD -f 2149617336320
btrfs restore /dev/sdd /storage/A3/B1/  -vD -f 1607682736128
btrfs restore /dev/sdd /storage/A3/B1/  -vD -f 2688721551360

and then i finally did the restore using the offset that looked best

btrfs restore /dev/sdd /storage/A3/B1/  -v -f 2688721551360

I hope this helps, good luck!


> Here is what the command returns :
>
> [root@x220 ~]# btrfs-find-root /dev/mapper/home
> Super think's the tree root is at 115230801920, chunk root 131072
> Went past the fs size, exiting[root@x220 ~]#
>
> I just tried with latest btrfs-progs (from git), it returns exactly the
> same.
>
> The btrfs partition is on top of dm-crypt, could it be a problem?
>
>
> Thanks,
> Jean-Denis Girard
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Konstantinos Skarlatos

Re: Undelete files / directory

[Jean-Denis Girard]

Le 28/08/2014 21:40, Konstantinos Skarlatos a écrit :
> On 28/8/2014 8:04 μμ, Jean-Denis Girard wrote:
>> Hi Chris,
>>
>> Thanks for your detailed answer.
>>
>> Le 28/08/2014 06:25, Chris Murphy a écrit :
>>> 9. btrfs-find-root /dev/sdc
>>> Super think's the tree root is at 29917184, chunk root 20987904
>>> Well block 4194304 seems great, but generation doesn't match, have=2,
>>> want=9 level 0
>>> Well block 4243456 seems great, but generation doesn't match, have=3,
>>> want=9 level 0
>>> Well block 29376512 seems great, but generation doesn't match,
>>> have=4, want=9 level 0
>>> Well block 29474816 seems great, but generation doesn't match,
>>> have=5, want=9 level 0
>>> Well block 29556736 seems great, but generation doesn't match,
>>> have=6, want=9 level 0
>>> Well block 29736960 seems great, but generation doesn't match,
>>> have=7, want=9 level 0
>>> Well block 29900800 seems great, but generation doesn't match,
>>> have=8, want=9 level 0
> Hi all,
> 
> I did a successful btrfs restore a few months ago, saving all of my
> deleted files except 2 (So i lost about 1GB on a 4TB filesystem)
> Here is what i did (this is from memory and from my .zsh_history file,
> so i may be missing something)
> 
> btrfs-find-root  /dev/sdd -o 5 > b1.txt
> I think the -o 5 option is quite important here.

Thanks for the reply, but for some reason btrfs-fins-root does not work
on this file system. Here is what I get:

[jdg@tiare tmp]$ btrfs-find-root x220_home.img -o 5
Super think's the tree root is at 115230801920, chunk root 131072
Went past the fs size, exiting[jdg@tiare tmp]$

I can mount the file system, access the files, though obviously not the
deleted directory.



Regards,
Jean-Denis Girard

Re: Undelete files / directory

[Jean-Denis Girard]

So I commented out the break on line 238 of btrfs-find-root so that it
continues even if it thinks it went past the fs size, rerun the command,
and I finally got a list of blocks to try!

Then as you suggested I did:
for i in `awk '{print $3}' root.txt`
 do echo "------------------------  $i --------------------"
 btrfs restore -v -f $i --path-regex '^/(|jdg(|/tmp(|/.*)))$' \
	../x220_home.img .
done

And I now have back my ~2800 photos (~13 Gb).

Many thanks to those who helped!


Best regards,
Jean-Denis Girard


Le 30/08/2014 10:12, Jean-Denis Girard a écrit :
> Le 28/08/2014 21:40, Konstantinos Skarlatos a écrit :
>> On 28/8/2014 8:04 μμ, Jean-Denis Girard wrote:
>>> Hi Chris,
>>>
>>> Thanks for your detailed answer.
>>>
>>> Le 28/08/2014 06:25, Chris Murphy a écrit :
>>>> 9. btrfs-find-root /dev/sdc
>>>> Super think's the tree root is at 29917184, chunk root 20987904
>>>> Well block 4194304 seems great, but generation doesn't match, have=2,
>>>> want=9 level 0
>>>> Well block 4243456 seems great, but generation doesn't match, have=3,
>>>> want=9 level 0
>>>> Well block 29376512 seems great, but generation doesn't match,
>>>> have=4, want=9 level 0
>>>> Well block 29474816 seems great, but generation doesn't match,
>>>> have=5, want=9 level 0
>>>> Well block 29556736 seems great, but generation doesn't match,
>>>> have=6, want=9 level 0
>>>> Well block 29736960 seems great, but generation doesn't match,
>>>> have=7, want=9 level 0
>>>> Well block 29900800 seems great, but generation doesn't match,
>>>> have=8, want=9 level 0
>> Hi all,
>>
>> I did a successful btrfs restore a few months ago, saving all of my
>> deleted files except 2 (So i lost about 1GB on a 4TB filesystem)
>> Here is what i did (this is from memory and from my .zsh_history file,
>> so i may be missing something)
>>
>> btrfs-find-root  /dev/sdd -o 5 > b1.txt
>> I think the -o 5 option is quite important here.
> 
> Thanks for the reply, but for some reason btrfs-fins-root does not work
> on this file system. Here is what I get:
> 
> [jdg@tiare tmp]$ btrfs-find-root x220_home.img -o 5
> Super think's the tree root is at 115230801920, chunk root 131072
> Went past the fs size, exiting[jdg@tiare tmp]$
> 
> I can mount the file system, access the files, though obviously not the
> deleted directory.
> 
> 
> 
> Regards,
> Jean-Denis Girard
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Undelete files / directory

[Marc MERLIN]

On Sat, Aug 30, 2014 at 11:26:52AM -1000, Jean-Denis Girard wrote:
> So I commented out the break on line 238 of btrfs-find-root so that it

Thanks for that report.
Can a developer review this and see if it should be made an option or
removed entirely?

Marc

> continues even if it thinks it went past the fs size, rerun the command,
> and I finally got a list of blocks to try!
> 
> Then as you suggested I did:
> for i in `awk '{print $3}' root.txt`
>  do echo "------------------------  $i --------------------"
>  btrfs restore -v -f $i --path-regex '^/(|jdg(|/tmp(|/.*)))$' \
> 	../x220_home.img .
> done
> 
> And I now have back my ~2800 photos (~13 Gb).
> 
> Many thanks to those who helped!
> 
> 
> Best regards,
> Jean-Denis Girard
> 
> 
> Le 30/08/2014 10:12, Jean-Denis Girard a écrit :
> > Le 28/08/2014 21:40, Konstantinos Skarlatos a écrit :
> >> On 28/8/2014 8:04 μμ, Jean-Denis Girard wrote:
> >>> Hi Chris,
> >>>
> >>> Thanks for your detailed answer.
> >>>
> >>> Le 28/08/2014 06:25, Chris Murphy a écrit :
> >>>> 9. btrfs-find-root /dev/sdc
> >>>> Super think's the tree root is at 29917184, chunk root 20987904
> >>>> Well block 4194304 seems great, but generation doesn't match, have=2,
> >>>> want=9 level 0
> >>>> Well block 4243456 seems great, but generation doesn't match, have=3,
> >>>> want=9 level 0
> >>>> Well block 29376512 seems great, but generation doesn't match,
> >>>> have=4, want=9 level 0
> >>>> Well block 29474816 seems great, but generation doesn't match,
> >>>> have=5, want=9 level 0
> >>>> Well block 29556736 seems great, but generation doesn't match,
> >>>> have=6, want=9 level 0
> >>>> Well block 29736960 seems great, but generation doesn't match,
> >>>> have=7, want=9 level 0
> >>>> Well block 29900800 seems great, but generation doesn't match,
> >>>> have=8, want=9 level 0
> >> Hi all,
> >>
> >> I did a successful btrfs restore a few months ago, saving all of my
> >> deleted files except 2 (So i lost about 1GB on a 4TB filesystem)
> >> Here is what i did (this is from memory and from my .zsh_history file,
> >> so i may be missing something)
> >>
> >> btrfs-find-root  /dev/sdd -o 5 > b1.txt
> >> I think the -o 5 option is quite important here.
> > 
> > Thanks for the reply, but for some reason btrfs-fins-root does not work
> > on this file system. Here is what I get:
> > 
> > [jdg@tiare tmp]$ btrfs-find-root x220_home.img -o 5
> > Super think's the tree root is at 115230801920, chunk root 131072
> > Went past the fs size, exiting[jdg@tiare tmp]$
> > 
> > I can mount the file system, access the files, though obviously not the
> > deleted directory.
> > 
> > 
> > 
> > Regards,
> > Jean-Denis Girard
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/                         | PGP 1024R/763BE901

Re: Undelete files / directory

[Konstantinos Skarlatos]

On 1/9/2014 7:27 μμ, Marc MERLIN wrote:
> On Sat, Aug 30, 2014 at 11:26:52AM -1000, Jean-Denis Girard wrote:
>> So I commented out the break on line 238 of btrfs-find-root so that it
> Thanks for that report.
> Can a developer review this and see if it should be made an option or
> removed entirely?
I think that is the best way to proceed, or maybe even better make a 
"brute force" option for btrfs restore that does something like my for 
loop, recovering what it can through the filesystem.

Until then, can we make this into a concise set of instructions so we 
can post it on the wiki?

>
> Marc
>
>> continues even if it thinks it went past the fs size, rerun the command,
>> and I finally got a list of blocks to try!
>>
>> Then as you suggested I did:
>> for i in `awk '{print $3}' root.txt`
>>   do echo "------------------------  $i --------------------"
>>   btrfs restore -v -f $i --path-regex '^/(|jdg(|/tmp(|/.*)))$' \
>> 	../x220_home.img .
>> done
>>
>> And I now have back my ~2800 photos (~13 Gb).
>>
>> Many thanks to those who helped!

I am glad i could help!


>>
>>
>> Best regards,
>> Jean-Denis Girard
>>
>>
>> Le 30/08/2014 10:12, Jean-Denis Girard a écrit :
>>> Le 28/08/2014 21:40, Konstantinos Skarlatos a écrit :
>>>> On 28/8/2014 8:04 μμ, Jean-Denis Girard wrote:
>>>>> Hi Chris,
>>>>>
>>>>> Thanks for your detailed answer.
>>>>>
>>>>> Le 28/08/2014 06:25, Chris Murphy a écrit :
>>>>>> 9. btrfs-find-root /dev/sdc
>>>>>> Super think's the tree root is at 29917184, chunk root 20987904
>>>>>> Well block 4194304 seems great, but generation doesn't match, have=2,
>>>>>> want=9 level 0
>>>>>> Well block 4243456 seems great, but generation doesn't match, have=3,
>>>>>> want=9 level 0
>>>>>> Well block 29376512 seems great, but generation doesn't match,
>>>>>> have=4, want=9 level 0
>>>>>> Well block 29474816 seems great, but generation doesn't match,
>>>>>> have=5, want=9 level 0
>>>>>> Well block 29556736 seems great, but generation doesn't match,
>>>>>> have=6, want=9 level 0
>>>>>> Well block 29736960 seems great, but generation doesn't match,
>>>>>> have=7, want=9 level 0
>>>>>> Well block 29900800 seems great, but generation doesn't match,
>>>>>> have=8, want=9 level 0
>>>> Hi all,
>>>>
>>>> I did a successful btrfs restore a few months ago, saving all of my
>>>> deleted files except 2 (So i lost about 1GB on a 4TB filesystem)
>>>> Here is what i did (this is from memory and from my .zsh_history file,
>>>> so i may be missing something)
>>>>
>>>> btrfs-find-root  /dev/sdd -o 5 > b1.txt
>>>> I think the -o 5 option is quite important here.
>>> Thanks for the reply, but for some reason btrfs-fins-root does not work
>>> on this file system. Here is what I get:
>>>
>>> [jdg@tiare tmp]$ btrfs-find-root x220_home.img -o 5
>>> Super think's the tree root is at 115230801920, chunk root 131072
>>> Went past the fs size, exiting[jdg@tiare tmp]$
>>>
>>> I can mount the file system, access the files, though obviously not the
>>> deleted directory.
>>>
>>>
>>>
>>> Regards,
>>> Jean-Denis Girard
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>


-- 
Konstantinos Skarlatos

Re: Undelete files / directory

[Jean-Denis Girard]

Le 01/09/2014 07:00, Konstantinos Skarlatos a écrit :
> Until then, can we make this into a concise set of instructions so we
> can post it on the wiki?

I would be happy to contribute to the wiki, but I'm not sure where to
add this: a new paragraph in the "Problem FAQ" or a new page?


Thanks,
Jean-Denis Girard

Re: Undelete files / directory

[Marc MERLIN]

On Mon, Sep 01, 2014 at 06:08:28PM -1000, Jean-Denis Girard wrote:
> Le 01/09/2014 07:00, Konstantinos Skarlatos a écrit :
> > Until then, can we make this into a concise set of instructions so we
> > can post it on the wiki?
> 
> I would be happy to contribute to the wiki, but I'm not sure where to
> add this: a new paragraph in the "Problem FAQ" or a new page?

If it fits in a couple of paragraphs, the FAQ page sounds fine.
If it's longer than that and is becoming more of a HOWTO, a separate
page with links to it, like a link from the FAQ page, would work great.

It sounds like the latter might be best here, but up to you.

Marc
 
 
> Thanks,
> Jean-Denis Girard
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/                         | PGP 1024R/763BE901

Re: Undelete files / directory

[David Sterba]

On Mon, Sep 01, 2014 at 08:00:03PM +0300, Konstantinos Skarlatos wrote:
> On 1/9/2014 7:27 μμ, Marc MERLIN wrote:
> >On Sat, Aug 30, 2014 at 11:26:52AM -1000, Jean-Denis Girard wrote:
> >>So I commented out the break on line 238 of btrfs-find-root so that it
> >Thanks for that report.
> >Can a developer review this and see if it should be made an option or
> >removed entirely?
> I think that is the best way to proceed, or maybe even better make a "brute
> force" option for btrfs restore that does something like my for loop,
> recovering what it can through the filesystem.

Agreed, let's make 'find-root' a subcommand of 'rescue' instead of a
standalone utility. Then we can add options to allow inspecting a more
broken filesystem, eg. like the 'block out of fs'.