Does btrfs-restore report missing/corrupt files?

Does btrfs-restore report missing/corrupt files?

[Christian Tschabuschnig]

Hello,

currently I am trying to recover a btrfs filesystem which had a few subvolumes. When running
# btrfs restore -sx /dev/xxx .
one subvolume gets restored.

Would the restore utility report any corruption within this subvolume? May I assume that all data was recovered if there are no messages on STDERR?

In this particular case there were a few messages on STDERR but I believe they refer to the other subvolumes:
Check tree block failed, want=43702427648, have=4902726477564852953
Check tree block failed, want=43702427648, have=4902726477564852953
Check tree block failed, want=43702427648, have=9670034583150859267
Check tree block failed, want=43702427648, have=4902726477564852953
Check tree block failed, want=43702427648, have=4902726477564852953
read block failed check_tree_block
Error reading subvolume ./cur-root: 18446744073709551611

Re: Does btrfs-restore report missing/corrupt files?

[Robert White]

On 10/26/2014 12:59 AM, Christian Tschabuschnig wrote:
>
> Hello,
>
> currently I am trying to recover a btrfs filesystem which had a few subvolumes. When running
> # btrfs restore -sx /dev/xxx .
> one subvolume gets restored.

Important Aside: The one time I had to resort to btrfs restore I didn't 
get the contents of _many_ of the really small files. My _guess_ is that 
those where the files small enough to reside entirely within the 
original filesystem's metadata.

You should mount the filesystem read-only and recursively copy the 
hirearchy to another file system as well as doing a restore. The two 
results can then be folded together, or at least the former might help 
you find some of what the latter might miss.

I could be totally wrong, or restore could have been improved since 
then, but it was what seemed to be happening.

Re: Does btrfs-restore report missing/corrupt files?

[Duncan]

Robert White posted on Mon, 27 Oct 2014 17:39:13 -0700 as excerpted:

> On 10/26/2014 12:59 AM, Christian Tschabuschnig wrote:
>>
>> Hello,
>>
>> currently I am trying to recover a btrfs filesystem which had a few
>> subvolumes. When running # btrfs restore -sx /dev/xxx .
>> one subvolume gets restored.
> 
> Important Aside: The one time I had to resort to btrfs restore I didn't
> get the contents of _many_ of the really small files. My _guess_ is that
> those where the files small enough to reside entirely within the
> original filesystem's metadata.
> 
> You should mount the filesystem read-only and recursively copy the
> hirearchy to another file system as well as doing a restore. The two
> results can then be folded together, or at least the former might help
> you find some of what the latter might miss.
> 
> I could be totally wrong, or restore could have been improved since
> then, but it was what seemed to be happening.

You don't mention how long ago that was, but FWIW, when I had to use 
btrfs restore during the 3.15 kernel cycle (with progs 3.14 or 3.14.1, 
I'd guess), the only thing I noticed missing was the symlinks.  I never 
thought about why, but metadata-only might indeed explain it.

It was only /var/log and /home (both independent filesystems, I prefer 
not to keep all my data eggs in a single filesystem basket) that I needed 
to restore, however.  / is mounted read-only by default, as it was that 
time, so it wasn't damaged, and /boot and /mnt/pkgs weren't mounted, so 
they weren't damaged either.  And of course the backup copies of all the 
above weren't mounted so weren't damaged, and my media partition is on 
spinning rust and still reiserfs (all my btrfs are on ssd).

The point being, the biggest set of small files that were on the 
filesystems I restored were the various user config files in /home.  I 
run kde and customize rather heavily, so I'd have tended to notice if 
they were missing, but they were restored just fine.  Like I said, it was 
just the symlinks that I noticed missing.  They were a bother to restore, 
but at least with missing symlinks, I knew what the "contents" was.

So presumably your restore experience was before the kernel 3.15 cycle, 
and presumably they fixed restore to deal with no-extent metadata-only 
files between your usage and mine.  But I've enough symlinks scattered 
around that having them go missing was a hassle.

As for mounting the filesystem read-only, that's definitely the best 
policy if it works.  But most of the time when people are resorting to 
restore, it's because the filesystem won't mount, even read-only, so 
that's unfortunately not an available option.

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