Method is similar to restoring a corrupt btrfs filesystem.

Trying to restore a file or folder or subvolume that you accidentally deleted and you dont have a snapshot (perhaps because you accidentally delete the snapshot[s] with your operation). No fear here is a guide on how to use btrfs-find-root along with btrfs restore to try and find your files. First we generate a list of roots to look through with btrfs-find-root, then we look through those roots with a dry (no writing) run of btrfs restore, and finally once we find the root that has our data we will do an actual run of btrfs restore (not dry). SIDENOTE: I refer to roots as Well block numbers as thats how they appear in the output of btrfs-find-root.

This process is not guaranteed to restore your data. Its just one way to try. Here is another method: http://comments.gmane.org/gmane.comp.file-systems.btrfs/22560

Well lucky for you that snapshots are not the only thing that can help you go back in time with BTRFS. There is also all of those Copy on Write transactions.

Method I am covering is also covered here: http://superuser.com/questions/603708/btrfs-undelete-file

We will be using BTRFS RESTORE, read up on this: https://github.com/kdave/btrfs-wiki/wiki/btrfs-restore

(First Step) GENERATE LIST OF WELL BLOCK NUMBER / TREE ROOTS

find all of the “Well blocks”

You will see it be of the form:

Well block #, have: #, want: #.

More exactly its like this:

There should be many of these lines. Unless of course you dont take snapshots and dont have Copy on Write enabled.

We need the # next to the Well block.

Lets pretend for this example I lost a subvolume called “Pictures” & we are trying to recover it

 

(Second step) FIND ROOT WHERE DATA EXISTS

Start using this method to look thru the FS old points in time. This step is harmless as its a dry run. It just preforms a read operation but no writes.

From the bottom pick at random any Well block line. We will start with 1170288640

Well block #, have: #, want: #.

Here we are looking through the BTRFS filesystem /dev/sda3, and also we ask it to dump to /tmp. However it will not dump anywhere because of the -D. By the syntax rules we still need to specify a dump location even though nothing happens to it (we could also pick /dev/null). -v is verbose output to list files etc. -F is powerful helper (but might not be in your version of “btrfsprogs” although by now It might). Without -F you will get repeating messages “btrfs restore is looping through this file, we are at offset #, click Y to continue” so -F just clicks Y for us (or something along those lines – I might of got the message wrong, and it mmight say click N to continue. But the point is that -F automatically continues it for us so that we dont have to interfere). With -t we put that well block number, and btrfs restore will try to restore the data of that well block. Not sure if I said that correctly.

Now you saw there is a million well block, we can look through all of them, but it will take time and it will probably be pretty intense operation so we can simply nice it and loop it. HEre are two scripts that can help with that. One looks through every well block number. The 2nd script that one will look through X number of well blocks above a certain well block number (that perhaps you found sommething at) and Y number of well blocks below a certain well block number. The 2nd script is good if you found a well block number with some enteries and you want to look above and below.

NOTE: These scripts are copy pasteable, just change the variables to match your needs.

THe next script looks around a well block number that you found something on. Lets assume that we found the Pictures folder around 1170288640 but it didnt have all of the pics. So lets look above and below. Above will be older transactions (so maybe before some delete). Below will be after some transactions so perhaps the writes of the pictures are still to happen.

After finding out which well block produces the most numbers. You should rerun it like this to see what files it found

TIP: making a file every now and again in your filesystem can be helpful. you could look for that file like a marker. Then you will know the exact date and time of the “Well block” numbers. And if needed can interpolate for the Well block numbers in between.

 

(Third step) DUMPING THE DATA

Now that we identified the well block number that we want, we can go ahead and dump the data out. Lets assume we mounted a giant storage location to /mnt for backup purposes.

That will dump out all of /dev/sda3 at wellblock number 1170288640

So there is a way to ask btrfs restore to restore only what you want. From the output of “btrfs restore … -D …” above we should know how our restored files look like.

You have to use the –path-regex argument with a regular expressions of this form: –path-regex¬† '^/(|home(|/username(|/Desktop(|/.*))))$'

If my Pictures folder was on the root of the BTRFS filesystem so it was simply /Pictures (of course when its mounted, assuming sda3 mounted to /data, then it would be like this /data/Pictures). Then the regular expression will look like this: '^/(|Pictures(|/.*))$' Below will only restore the “/Pictures/” Subvolume/folder in the BTRFS volume.

So if my Pictures folder was in a folder called /Media. So it looked like this /Media/Pictures (of course when its mounted, assuming sda3 mounted to /data, then it would be like this /data/Media/Pictures). Then the regular expression will look like this: '^/(|Media(|/Pictures(|/.*)))$' Below will only restore the “/Media/Pictures” Subvolume/folder in the BTRFS volume.

 

One thought on “BTRFS UNDELETE – Recovering Deleted folder/file without snapshots

Leave a Reply

Your email address will not be published. Required fields are marked *