Undelete files

Undelete files

[Adrian Bastholm]

Hello all,
Is it possible to undelete files on BTRFS ? I just deleted a bunch of
folders and would like to restore them if possible.

I found this script
https://gist.github.com/Changaco/45f8d171027ea2655d74 but it's not
finding stuff ..

./btrfs-undelete /dev/sde1 ./foto /home/storage/BTRFS_RESTORE/
Searching roots...
Trying root 389562368... (1/70)
...
Trying root 37339136... (69/70)
Trying root 30408704... (70/70)
Didn't find './foto'

-- 
Vänliga hälsningar / Kind regards,
Adrian Bastholm

``I would change the world, but they won't give me the sourcecode``

Re: Undelete files

[Duncan]

Adrian Bastholm posted on Sat, 29 Dec 2018 23:22:46 +0100 as excerpted:

> Hello all,
> Is it possible to undelete files on BTRFS ? I just deleted a bunch of
> folders and would like to restore them if possible.
> 
> I found this script
> https://gist.github.com/Changaco/45f8d171027ea2655d74 but it's not
> finding stuff ..

That's an undelete-automation wrapper around btrfs restore...

> ./btrfs-undelete /dev/sde1 ./foto /home/storage/BTRFS_RESTORE/ Searching
> roots...
> Trying root 389562368... (1/70)
> ...
> Trying root 37339136... (69/70)
> Trying root 30408704... (70/70)
> Didn't find './foto'

That script is the closest thing to a direct undelete command that btrfs 
has.  However, there's still some chance...

** IMPORTANT **  If you still have the filesystem mounted read-write, 
remount it read-only **IMMEDIATELY**, because every write reduces your 
chance at recovering any of the deleted files.

(More in another reply, but I want to get this sent with the above ASAP.)



-- 
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

[Duncan]

Duncan posted on Sun, 30 Dec 2018 04:11:20 +0000 as excerpted:

> Adrian Bastholm posted on Sat, 29 Dec 2018 23:22:46 +0100 as excerpted:
> 
>> Hello all,
>> Is it possible to undelete files on BTRFS ? I just deleted a bunch of
>> folders and would like to restore them if possible.
>> 
>> I found this script
>> https://gist.github.com/Changaco/45f8d171027ea2655d74 but it's not
>> finding stuff ..
> 
> That's an undelete-automation wrapper around btrfs restore...
> 
>> ./btrfs-undelete /dev/sde1 ./foto /home/storage/BTRFS_RESTORE/
>> Searching roots...
>> Trying root 389562368... (1/70)
>> ...
>> Trying root 37339136... (69/70)
>> Trying root 30408704... (70/70)
>> Didn't find './foto'
> 
> That script is the closest thing to a direct undelete command that btrfs
> has.  However, there's still some chance...
> 
> ** IMPORTANT **  If you still have the filesystem mounted read-write,
> remount it read-only **IMMEDIATELY**, because every write reduces your
> chance at recovering any of the deleted files.
> 
> (More in another reply, but I want to get this sent with the above
> ASAP.)


First a question:  Any chance you have a btrfs snapshot of the deleted 
files you can mount and recover from?  What about backups?

Note that a number of distros using btrfs have automated snapshotting 
setup, so it's possible you have a snapshot with the files safely 
available, and don't even know it.  Thus the snapshotting question (more 
on backups below).  It could be worth checking...


Assuming no snapshot and no backup with those files...

Disclaimer:  I'm not a dev, just a btrfs user and list regular myself.  
Thus, the level of direct technical help I can give is limited, and much 
of what remains is more what to do different to prevent a next time, tho 
there's some additional hints about the current situation further down...


Well the first thing in this case to note is the sysadmin's (yes, that's 
you... and me, and likely everyone here: [1]) first rule of backups:  The 
true value of data isn't defined by any arbitrary claims, but by the 
number of backups of that data it is considered valuable enough to have.  
Thus, in the most literal way possible, not having a backup is simply 
defining the data as not worth the time/trouble/hassle to make one, and 
not having a second and third and... backup is likewise, simply defining 
the value of the data as not worth that one more level of backup.  
(Likewise, not having an /updated/ backup is simply defining the value of 
data in the delta between the current working copy and the last backup as 
of trivial value, because as soon as it's worth more than the time/
trouble/resources required to update the backup, by definition, the 
backup will be updated in accordance with the value of the data in that 
delta.)

Thus, the fact that we're assuming no backup now means that that we 
already defined the data as of trivial value, not worth the time/trouble/
resources necessary to make even a single backup.

Which means no matter what the loss or why, hardware, software or 
"wetware" failure (the latter aka fat-fingering, as here), or even 
disaster such as flood or fire, when it comes to our data we can *always* 
rest easy, because we *always* save what was of most value, either the 
data if we defined it as such by the backups we had of it, or the time/
trouble/resources that would have otherwise gone into the backup, if we 
judged the data to be of lower value than that one more level of backup.

Which means there's a strict limit to the value of the data possibly 
lost, and thus a strict limit to the effort we're likely willing to put 
into recovery after that data loss risk factor appears to have evaluated 
to 1, before the recovery effort too becomes not worth the trouble.  
After all, if it /was/ worth the trouble, it would have also been worth 
the trouble to do that backup in the first place, and the fact that we 
don't have it means it wasn't worth that trouble.

At least for me, looking at it from this viewpoint significantly lowers 
my stress during disaster recovery situations.  There's simply not that 
much at risk, nor can there be, even in the event of losing 
"everything" (well, data-wise anyway, hardware, or for that matter, my 
life and/or health, family and friends, etc, unfortunately that's not as 
easy to backup as data!) to a fire or the like, since if there was more 
at risk, there's be backups (offsite backups in the fire/flood sort of 
case) we could fall back on should it come to that.


That said, before-the-fact, it's an unknown risk-factor, while after-the-
fact, that previously unknown risk-factor has evaluated to 100% chance of 
(at least apparent) data loss!  It's actually rather likely that will 
change the calculation to some extent, making it worth at least /some/ 
effort at restoration, even if in practice that effort is limited by the 
value of the time taken for it against the value of the already declared 
of relatively limited value data.


OK, now we can assume it's worth at least some limited effort to try to 
recover... and that we've already exhausted our best chances, for 
deletion mistakes, setting immutable to prevent the deletion in the first 
place, at least the easy-restore backups, btrfs snapshots, the automated 
btrfs-undelete script...  Now things get significantly less likely to 
succeed and significantly more effort to try...

If it's still worth going further given the limited chance at success and 
higher effort on one hand against the already defined as strictly limited 
value of the data on the other...

You can try running btrfs restore manually, giving you a better chance at 
recovery due to better control of things that undelete script automates 
away.

There's the btrfs-restore manpage as a first information resource for 
that.

At a higher technical level, there's a page on the wiki that describes 
the process of trying to find older filesystem roots and checking them to 
see if they are any good, then if they look good, feeding them to btrfs 
restore.  However, the undelete script already automates this to some 
extent, and if you're beyond that into doing it manually, not only are 
you getting rather technical, but the chances of successful recovery go 
down dramatically.  But they're still not zero, so it's possible you'll 
find it worth trying, tho honestly, given the already declared to be of 
limited value data and the low chances of success, I'd seriously question 
whether it's worth going this far.

https://btrfs.wiki.kernel.org/index.php/Restore

If that too fails, then we're getting into extreme territory.  You're 
looking at the possibility of getting a dev directly involved, and/or 
doing direct data scraping, either yourself, or sending it to a data 
recovery company and paying big money for it.  This *really* isn't going 
to be worth it for most people, and it's almost certainly not worth it 
for anyone observing the above data valuation and backups rule, but when 
it comes to humans there's always a few for virtually anything you can 
think of, thus the existence of such companies in the the first place.

---
[1] Sysadmin:  I use this term in the wide/literal sense of anyone, home 
user with a single system or professional with a thousand systems, it 
doesn't matter, literally with the responsibility of administering their 
system, in this context, basically anyone who can't simply go ask their 
admin to restore from the admin's backups, who thus has the 
responsibility of administering the system themselves.  Which in practice 
means anyone likely to be posting such questions here, as well as many 
who unfortunately couldn't even get that far, as they've simply never 
taken the responsibility seriously enough to bother learning how, or to 
bother studying the filesystem they chose to entrust the safety of their 
data to.

-- 
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

[Jesse Emeth]

Hi Duncan

The backup is irrelevant in this case. I have a backup of this
particular problem.
I've had BTRFS on my OS system blow up several times.
There are several snapshots of this within the subvolume.
However, such snapshots are not helpful unless they are snapshots
copied elsewhere with restore/rsync etc.

I had spoken to someone expressing my concerns with BTRFS on IRC.
He wanted me to present this so that such problems could be rectified.
I also wanted to learn more about BTRFS to see if my determinations
about its inadequacies were incorrect.

Thus I want to follow this through to see if what is actually a very
very small problem related to just a non essential small Firefox cache
directory can actually be fixed.
At present this very very small problem brings down the entire volume
and all subvolumes with no way to mount any of it rw or easily fix the
issue.
That is not sane for such a small issue.

So far I've worked through this and still it is unresolved. I have
finally been told to use an old kernel to do a balance, but the old
kernel cannot even handle the partition ro, let alone rw.

Thus not a happy camper with BTRFS claims of the repair tools being adequate.

Regards

Jesse


On Sun, Dec 30, 2018 at 1:51 PM Duncan <1i5t5.duncan@cox.net> wrote:
>
> [This mail was also posted to gmane.comp.file-systems.btrfs.]
>
> Duncan posted on Sun, 30 Dec 2018 04:11:20 +0000 as excerpted:
>
> > Adrian Bastholm posted on Sat, 29 Dec 2018 23:22:46 +0100 as
> > excerpted:
> >
> >> Hello all,
> >> Is it possible to undelete files on BTRFS ? I just deleted a bunch of
> >> folders and would like to restore them if possible.
> >>
> >> I found this script
> >> https://gist.github.com/Changaco/45f8d171027ea2655d74 but it's not
> >> finding stuff ..
> >
> > That's an undelete-automation wrapper around btrfs restore...
> >
> >> ./btrfs-undelete /dev/sde1 ./foto /home/storage/BTRFS_RESTORE/
> >> Searching roots...
> >> Trying root 389562368... (1/70)
> >> ...
> >> Trying root 37339136... (69/70)
> >> Trying root 30408704... (70/70)
> >> Didn't find './foto'
> >
> > That script is the closest thing to a direct undelete command that
> > btrfs has.  However, there's still some chance...
> >
> > ** IMPORTANT **  If you still have the filesystem mounted read-write,
> > remount it read-only **IMMEDIATELY**, because every write reduces your
> > chance at recovering any of the deleted files.
> >
> > (More in another reply, but I want to get this sent with the above
> > ASAP.)
>
>
> First a question:  Any chance you have a btrfs snapshot of the deleted
> files you can mount and recover from?  What about backups?
>
> Note that a number of distros using btrfs have automated snapshotting
> setup, so it's possible you have a snapshot with the files safely
> available, and don't even know it.  Thus the snapshotting question
> (more on backups below).  It could be worth checking...
>
>
> Assuming no snapshot and no backup with those files...
>
> Disclaimer:  I'm not a dev, just a btrfs user and list regular myself.
> Thus, the level of direct technical help I can give is limited, and
> much of what remains is more what to do different to prevent a next
> time, tho there's some additional hints about the current situation
> further down...
>
>
> Well the first thing in this case to note is the sysadmin's (yes,
> that's you... and me, and likely everyone here: [1]) first rule of
> backups:  The true value of data isn't defined by any arbitrary claims,
> but by the number of backups of that data it is considered valuable
> enough to have. Thus, in the most literal way possible, not having a
> backup is simply defining the data as not worth the time/trouble/hassle
> to make one, and not having a second and third and... backup is
> likewise, simply defining the value of the data as not worth that one
> more level of backup. (Likewise, not having an /updated/ backup is
> simply defining the value of data in the delta between the current
> working copy and the last backup as of trivial value, because as soon
> as it's worth more than the time/ trouble/resources required to update
> the backup, by definition, the backup will be updated in accordance
> with the value of the data in that delta.)
>
> Thus, the fact that we're assuming no backup now means that that we
> already defined the data as of trivial value, not worth the
> time/trouble/ resources necessary to make even a single backup.
>
> Which means no matter what the loss or why, hardware, software or
> "wetware" failure (the latter aka fat-fingering, as here), or even
> disaster such as flood or fire, when it comes to our data we can
> *always* rest easy, because we *always* save what was of most value,
> either the data if we defined it as such by the backups we had of it,
> or the time/ trouble/resources that would have otherwise gone into the
> backup, if we judged the data to be of lower value than that one more
> level of backup.
>
> Which means there's a strict limit to the value of the data possibly
> lost, and thus a strict limit to the effort we're likely willing to put
> into recovery after that data loss risk factor appears to have
> evaluated to 1, before the recovery effort too becomes not worth the
> trouble. After all, if it /was/ worth the trouble, it would have also
> been worth the trouble to do that backup in the first place, and the
> fact that we don't have it means it wasn't worth that trouble.
>
> At least for me, looking at it from this viewpoint significantly lowers
> my stress during disaster recovery situations.  There's simply not that
> much at risk, nor can there be, even in the event of losing
> "everything" (well, data-wise anyway, hardware, or for that matter, my
> life and/or health, family and friends, etc, unfortunately that's not
> as easy to backup as data!) to a fire or the like, since if there was
> more at risk, there's be backups (offsite backups in the fire/flood
> sort of case) we could fall back on should it come to that.
>
>
> That said, before-the-fact, it's an unknown risk-factor, while
> after-the- fact, that previously unknown risk-factor has evaluated to
> 100% chance of (at least apparent) data loss!  It's actually rather
> likely that will change the calculation to some extent, making it worth
> at least /some/ effort at restoration, even if in practice that effort
> is limited by the value of the time taken for it against the value of
> the already declared of relatively limited value data.
>
>
> OK, now we can assume it's worth at least some limited effort to try to
> recover... and that we've already exhausted our best chances, for
> deletion mistakes, setting immutable to prevent the deletion in the
> first place, at least the easy-restore backups, btrfs snapshots, the
> automated btrfs-undelete script...  Now things get significantly less
> likely to succeed and significantly more effort to try...
>
> If it's still worth going further given the limited chance at success
> and higher effort on one hand against the already defined as strictly
> limited value of the data on the other...
>
> You can try running btrfs restore manually, giving you a better chance
> at recovery due to better control of things that undelete script
> automates away.
>
> There's the btrfs-restore manpage as a first information resource for
> that.
>
> At a higher technical level, there's a page on the wiki that describes
> the process of trying to find older filesystem roots and checking them
> to see if they are any good, then if they look good, feeding them to
> btrfs restore.  However, the undelete script already automates this to
> some extent, and if you're beyond that into doing it manually, not only
> are you getting rather technical, but the chances of successful
> recovery go down dramatically.  But they're still not zero, so it's
> possible you'll find it worth trying, tho honestly, given the already
> declared to be of limited value data and the low chances of success,
> I'd seriously question whether it's worth going this far.
>
> https://btrfs.wiki.kernel.org/index.php/Restore
>
> If that too fails, then we're getting into extreme territory.  You're
> looking at the possibility of getting a dev directly involved, and/or
> doing direct data scraping, either yourself, or sending it to a data
> recovery company and paying big money for it.  This *really* isn't
> going to be worth it for most people, and it's almost certainly not
> worth it for anyone observing the above data valuation and backups
> rule, but when it comes to humans there's always a few for virtually
> anything you can think of, thus the existence of such companies in the
> the first place.
>
> ---
> [1] Sysadmin:  I use this term in the wide/literal sense of anyone,
> home user with a single system or professional with a thousand systems,
> it doesn't matter, literally with the responsibility of administering
> their system, in this context, basically anyone who can't simply go ask
> their admin to restore from the admin's backups, who thus has the
> responsibility of administering the system themselves.  Which in
> practice means anyone likely to be posting such questions here, as well
> as many who unfortunately couldn't even get that far, as they've simply
> never taken the responsibility seriously enough to bother learning how,
> or to bother studying the filesystem they chose to entrust the safety
> of their data to.
>
> --
> 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

[Duncan]

Jesse Emeth posted on Sun, 30 Dec 2018 16:58:12 +0800 as excerpted:

> Hi Duncan
> 
> The backup is irrelevant in this case. I have a backup of this
> particular problem.
> I've had BTRFS on my OS system blow up several times.
> There are several snapshots of this within the subvolume.
> However, such snapshots are not helpful unless they are snapshots
> copied elsewhere with restore/rsync etc.

How can backups and snapshots not be helpful in terms of a problem where 
you'd be using undelete?  Undelete implies the filesystem is fine and 
that you're just trying to get a few files that you mistakenly deleted 
back, which in fact was the claim, and both backups and snapshots should 
allow you to do just that, get your deleted files back.

> I had spoken to someone expressing my concerns with BTRFS on IRC.
> He wanted me to present this so that such problems could be rectified.
> I also wanted to learn more about BTRFS to see if my determinations
> about its inadequacies were incorrect.
> 
> Thus I want to follow this through to see if what is actually a very
> very small problem related to just a non essential small Firefox cache
> directory can actually be fixed.
> At present this very very small problem brings down the entire volume
> and all subvolumes with no way to mount any of it rw or easily fix the
> issue.
> That is not sane for such a small issue.

That's not a file undelete issue.  That's an entire filesystem issue.  
Quite a different beast, and not one that I directly addressed in my 
reply (altho the data value vs. backups stuff applies to fat-fingering 
such as mistaken deletes, filesystem problems, hardware problems, and 
natural disasters, all four), because both the title and the content 
suggested a file undelete issue, which /was/ addressed.

-- 
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

undelete files

[Laurent Lauden]

I have a disk with a database directory that was cleared accidentally.

This disk stay mounted for 3 days but I don't see any writing on it 
after the deletion. The disk was almost full when the deletion occurred.

However, trying to use btrfs-undelete give me no results. :

# sudo btrfs-undelete /dev/sdb1 postgresql /data-restore/

# Didn't find 'postgresql'

And when I try with btrfs tools with -f option, I have errors on 
checksum, etc. especially on the base files

Error copying data for /tmp/postgresql/global/1136
Error mapping block -2

Error copying data for /tmp/postgresql/base/18068/111300
Couldn't map the block 155802124288
Invalid mapping for 155802124288-155802140672, got 249647071232-250183942144
Couldn't map the block 155802124288
bytenr mismatch, want=155802124288, have=0
Error mapping block -2

Error copying data for /tmp/postgresql/base/18068/111298
Couldn't map the block 155802124288
Invalid mapping for 155802124288-155802140672, got 249647071232-250183942144
Couldn't map the block 155802124288
bytenr mismatch, want=155802124288, have=0
Couldn't map the block 155802124288
Invalid mapping for 155802124288-155802140672, got 249647071232-250183942144
Couldn't map the block 155802124288
bytenr mismatch, want=155802124288, have=0
Error searching -5

Tried

for j in `cat b1.txt | awk '{print $3}'`;do export i=${j:0:-5} && btrfs 
restore /dev/sdb1 /data-restore/ --path-regex 
"^(.*(|/postgresql(|/.*)))$" -o -v  -i -t $i; done > restore_test.txt 2>&1

but with -t nothing appears and with -f almost only errors. (b1.txt is 
the result of btrfs-find-root /dev/sdb1)

The btrfs-find-root /dev/sdb1 give me that :

Superblock thinks the generation is 436544
Superblock thinks the level is 0
Found tree root at 131301376 gen 436544 level 0
Well block 129597440(gen: 436541 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 129482752(gen: 436534 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 129286144(gen: 436533 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 129089536(gen: 436532 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 128892928(gen: 436531 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 128696320(gen: 436530 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 128499712(gen: 436529 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 128303104(gen: 436528 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 128106496(gen: 436527 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 127909888(gen: 436526 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 127713280(gen: 436525 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 127516672(gen: 436524 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 127320064(gen: 436523 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 127123456(gen: 436522 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 126926848(gen: 436521 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 126730240(gen: 436520 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 126533632(gen: 436519 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 126337024(gen: 436518 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 126140416(gen: 436517 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 125943808(gen: 436516 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 125747200(gen: 436515 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 125550592(gen: 436514 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 125353984(gen: 436513 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 125157376(gen: 436512 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 124960768(gen: 436511 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 124764160(gen: 436510 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 124567552(gen: 436509 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 124370944(gen: 436508 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 124174336(gen: 436507 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 123977728(gen: 436506 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 123781120(gen: 436505 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 123584512(gen: 436504 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 123387904(gen: 436503 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 123191296(gen: 436502 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 122994688(gen: 436501 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 122798080(gen: 436500 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 122601472(gen: 436499 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 122257408(gen: 436498 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 121880576(gen: 436497 level: 1) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0
Well block 81821696(gen: 436495 level: 0) seems good, but 
generation/level doesn't match, want gen: 436544 level: 0

So, if anyone could help me I would be very grateful.

Thanks

Re: undelete files

[Massimo B.]

Hello,

I had a similar issue. On OpenSuse I deleted /.snapshots/ and was not aware that
/.snapshots/1/snapshot/ is the default subvolume representing my root file
system.
So I had no snapshot left, all ro subvolumes have been deleted before, and the
default subvolume had big parts deleted before I cancelled the rm -rfv. I kept a
copy of the STDOUT listing the deleted files and switched off the power of that
filesystem immediately, no sync or umount.
There have been no additional writes, so I was quite sure the data must still be
there.

I booted a live version of the OpenSuse TW. However btrfsprogs are missing the
important btrfs-find-root, so I compiled the progs from the very recent github
revision.

After I played with the btrfs restore and --path-regex I had no success, finding
some of the files that have been deleted.
I found a copy of the btrfs-undelete script and played with that:
https://gist.github.com/Changaco/45f8d171027ea2655d74

I learned how to traverse the root-ids to older generations, but the script
found absolutely none of the deleted files.
I modified the script to use btrfs-find-root -a which found some more root-ids
but still no success, for instance:

# btrfs-undelete /dev/mapper/_root "/@/.snapshots/1/snapshot/etc/cron.daily/1btrk.cron" /mnt/usb/rescue
Trying root 88866816... (329/332)
Trying root 66764800... (330/332)
Trying root 66600960... (331/332)
Trying root 60571648... (332/332)
Didn't find '@/.snapshots/1/snapshot/etc/cron.daily/1btrk.cron'

I did not trust the obscure --path-regex.

I also reproduced what the script does, using regular expressions like
'^/(|@(|/.snapshots(|/1(|/snapshot(|/etc(|/cron.daily(|/1btrbk.cron)))))))$'

However I did some btrfs restore --dry-run and grepped the known files myself,
until I found older root-ids containing almost all of the missing files with
meta-data. The snippets I like to share here:

# btrfs-find-root -a /dev/mapper/_root |grep Well |cut -d '(' -f 1 |awk '{print $3}' | while read -r rootid ; do echo "### rootid: $rootid"; btrfs restore -t $rootid -Dvi /dev/mapper/_root /mnt/usb/rescue/;done 2>/dev/null |grep -e "### rootid" -e "1btrbk.cron"

### rootid: 245530624
### rootid: 245022720
### rootid: 244760576
### rootid: 242139136
### rootid: 242892800
### rootid: 241942528
### rootid: 209518592
### rootid: 144097280
### rootid: 147816448
Restoring /mnt/usb/rescue/@/.snapshots/1/snapshot/etc/cron.daily/1btrbk.cron
### rootid: 123863040
Restoring /mnt/usb/rescue/@/.snapshots/1/snapshot/etc/cron.daily/1btrbk.cron

Best regards,
Massimo