danthem / undelete-btrfs Goto Github PK

Only to say an huge thanks for doing that script saving files from users.
You deserve much bless in your path.
Have an nice week.

I noticed while trying to restore some huge files with lots of extents that btrfs restore would sometimes wait for user input if it looped too many times while searching the filesystem tree (or whatever it does). By sending all of btrfs restores output to /dev/null, this feedback is lost and the script apparently hangs—I had to terminate a run because the CPU usage of btrfs restore had sat at 0 for about half an hour.

Hey @danthem , regardless of what i enter for path or directory it just returns: Regex generated: '^/(|$'

This doesn't seem right?

I have tried another script and it did recover the file, but my issue is that I overwrote the file in question, so would it be possible with your script working to recover an older revision of the same file?

Would be lovely to have the script verify whether the <recovery destination> exists.

This could happen either:

• before the file search commences, or
• before the recovery attempt commences

If <recovery destination> does not exist:

• offer an error message prior to attempting data recovery, or
• offer to create <recovery destination>

Currently, if <recovery destination> doesn't exist, the user only discovers the problem and requirement once the recovery process has been engaged, and throws find errors:

Just recently, I had an incident where I deleted import files. I use BTRFS, so first thing I did was boot a live USB. The files appeared in BTRFS undelete (and I gave it the OK to restore), but when I mounted the drive to look for the files, they were nowhere to be found. Now BTRFS undelete can not even find them anymore to restore. My files are probably gone for good now, but I am curious why it did not save the files, I checked the live usb’s file system and the drive that the files were being restored from.

By default this script stores some temporary data in /tmp , this is not always ideal and should be changed or at least customizable. I'm thinking about storing the files in $dst instead but need to make sure to ignore them when script checks if any data found.

A bonus feature would be to keep the temporary files and if they're detected, query user if they want to use the same roots or re-generate, but this also requires some kind of tracking of depth level.

(this issue was inspired by @d0m1n1qu3 who made a fork due to /tmp running out of space)

I'm using a flat btrfs layout, that is the top volume is at /dev/nvme0n1p1 and several subvolumes inside mounted to different directories, e.g:

I booted into a live CD and run the script by sudo ./undelete-btrfs /dev/nvme0n1p1 /tmp, attempted to specify the file path as /etc/fstab and /@/etc/fstab respectively, but neither of them found the missing file.

I don't see a way to contact you on here, but just wanted to say thanks for saving my bacon 🥓.

The script got me out of a major hole at 1am last night!

You should consider adding a donate button...

No matter what I enter as the input, the program is not able to find anything. The unlocked partition (whole disk) is at /dev/mapper/luks_drive . Is this a normal limitation?

Please allow pass btrfs restore options or set -xm as default

-x|--xattr

get extended attributes

-m|--metadata

restore owner, mode and times for files and directories

Due to a recent change to btrfs progs we need to increase verbosity to get the output which the undelete script is looking for.

See PR #16 for details and fix.

I wrote this back when 4.15 was the latest version of btrfs-progs, btrfs-progs 5.2 is the latest version at the time of writing this.

Need to test and ensure script still works well and explore if there are any new features that can improve chances of recovery.

I'm trying to recover the directories I deleted by mistake with the rm command in the /home/user/.config directory.
When I launch the script from a bootable drive of Fedora, it can't find any data from any directory, not even the fstab file.
I've already check for right parsing of the device (which is /dev/sdb4).
Thanks.

It seems to go level 1 and then directly to level 2.

I have been using Fedora since Core 1 and still have the old HDs and I have kept using ext[234] FSs just for simplicity / consistency up to the current time (F39) - but now I want to experiment with btrfs and I was thinking I could go through the exercise of converting an old SATA boot drive where I am still using /dev/sdd5 (the old /home partition) as one of a few backup partitions / drives for current live data from my workstation and some small servers.

At first I was thinking I could delete ext4 parts 1-4, replace them with a new btrfs partition and then maybe somehow use btrfs-convert to integrate the remaining ext4 part 5 into the new part 1? . . but what I really want to do is create a new btrfs using the whole of the disk (GPT) - but somehow avoid having to spend a LONG time copying back about 4TB (to the 8TB drive) - the only way I could see that possibility working is to somehow do a recovery on the rest of the disk after the newly-created btrfs only takes up part of the beginning of the disk but leaves the old ext4 dirs and files recoverable somehow from near the beginning of the disk to just past halfway on the disk . .

This is just an interesting idea for experimenting with - it is not the end of the world if it is not possible or if it might be possible but difficult and I crash the drive in the experiment . . but I thought this script might offer a solution?

Implement quick check to see if is mounted or not. Script can only run on umounted devices so pointless to try on one that's mounted.