Re: Btrfs data recovery

[Duncan]

Christian Rene Thelen posted on Sun, 13 Aug 2017 19:12:48 +0200 as
excerpted:

> I have formated an encrypted disk, containing a LVM with a btrfs system.
> 
> All superblocks appear to be destroyed; the btrfs-progs tools can't find
> the root tree anymore and scalpel, binwalk, foremost & co return only
> scrap. The filesystem was on an ssd and mounted with -o compression=lzo.
> 
> How screwed am I? Any chances to recover some files? Is there a
> plausible way to rebuild the superblock manually? Checking the raw image
> with xxd gives me not a single readable word.
> 
> I managed to decrypt the LV and dd it to an image. What can I do?

Sysadmin's rule #1 of backups:  The value of your data is not defined by
arbitrary claims, but by the number of backups you consider it worth the
trouble to make.  No backups, you defined the data as worth less to you
than the trouble and resources it would take to make them, and unlike
words, actions, or lack thereof, are facts that don't lie.

So regardless, you're not screwed, because if you had backups you can
always recover from them, and if you didn't, then you considered the time
and trouble to make backups worth more than the data itself, so in either
case, you saved what your actions defined as of most importance to you,
and actions don't lie.

It sounds like you can be happy that you saved the real important time and
resources you would have otherwise put into making those backups, which
means you can be happy, because the data was self-evidently worth less to
you than the time and resources you saved.

=:^)

Meanwhile/alternatively, because I've learned the value of my data as
defined by backups too... Consider the lesson of Hurricane Katrina.

During the hurricane and the immediate aftermath, Intercosmos/drectNIC (a
hosting company located in New Orleans) had a small team that stayed on-
site, keeping the servers up and the data available, and blogging about
their experience.

Many sysadmins and other technically inclined users were glued to that
blog, living for each update.  I was certainly among them. (2005)

https://www.feld.com/archives/2005/09/blogging-from-a-new-orleans-data-center.html

But at the same time I was seeing the wider news out of New Orleans.  The
looting.  The people who /thought/ they were safe on that bridge, only to
be slain by the police that were /supposed/ to be protecting them.  The
aftermath with the raw sewage, and bloated and decaying animal and
occasional human bodies floating by.

Of course that got me thinking about /real/ tragedy.  I am (If you are)
still relatively healthy, have a home to go to at night, food on the
table, in the fridge, or money to buy it at the burger/taco/sandwich shop
down the street, and a family and/or friends likewise fortunate, you have
the /truly/ important stuff, and with a bit of perspective, the triviality
of loss of some data in the bigger picture can be seen.  Even if that data
was irreplaceable family photos, consider how much more fortunate you are
than the folks who just lost all that and more to a fire or flood... or as
refugees just robbed of the last /truly/ valuable thing they had other
than life itself, their family, or part of it, washed overboard.

https://en.wikipedia.org/wiki/Death_of_Alan_Kurdi (2015)

And if your lack of backups defined the data as trivial and you now regret
it, well... be glad you'll live another day and get the chance to create
more... this time, defining the data as more valuable than what you lost,
by having more and/or more frequently updated backups thereof.

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

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Btrfs data recovery

[Chris Murphy]

On Sun, Aug 13, 2017 at 11:12 AM, Christian Rene Thelen  wrote:
> I have formated an encrypted disk, containing a LVM with a btrfs system.
>
> All superblocks appear to be destroyed;

This is an unclear description. I don't understand the exact layout of
the storage stack, and what part of it you formatted. For example I
can't tell if the whole block device is encrypted, a partition is
encrypted, or if it's the LV that's encrypted. And I can't tell if the
formatting was a mistake, and what you accidentally formatted. I can't
tell if the encrypted device opens without error, if the LV is
discovered.

You need to be really clear because any changes you make dramatically
increase the chance of total data loss.

What do you get for:

$ sudo btrfs rescue super -v /dev/mapper/...


This should be the logical block device that contains the Btrfs file
system, the device you would mount (if it weren't damaged).

It's possible but somewhat unlikely that all of the supers are
damaged; but it depends on the size of the file system and what you
formatted.


-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Btrfs data recovery

[Hugo Mills]

On Sun, Aug 13, 2017 at 07:12:48PM +0200, Christian Rene Thelen wrote:
> I have formated an encrypted disk, containing a LVM with a btrfs system.

   What did you format it as? (i.e. what are the locations of the
damaged blocks?)

> All superblocks appear to be destroyed; the btrfs-progs tools can't
> find the root tree anymore and scalpel, binwalk, foremost & co
> return only scrap. The filesystem was on an ssd and mounted with -o
> compression=lzo.

   The compression would explain the junk you're getting from the
carving tools. They tend to rely on being able to identify sequences
of bytes as something recognisable -- compression defeats that by
reducing everything to (statistically) random bits.

> How screwed am I?

   Quite badly.

> Any chances to recover some files?

   The compression isn't helping, as noted above.

   The metadata will be uncompressed, though, so that should be
readable, depending on how much was formatted/damaged in the original
incident.

> Is there a plausible way to rebuild the superblock manually?
> Checking the raw image with xxd gives me not a single readable word.

   That's unsurprising. Metadata isn't human-readable, and nor is
compressed data.

   Did you ever balance this filesystem? More particularly, did you
ever balance the metadata? If you did, then there's a good chance it
wasn't at the front of the device, and so has a much smaller chance of
being damaged.

> I managed to decrypt the LV and dd it to an image. What can I do?

   btrfs-find-root may be able to find some of the tree heads. That at
minimum is the information you need in order to reconstruct the
superblock (well, that plus the UUID, but the UUID is going to be all
over the place -- it shouldn't be hard to find that if the rest is
discoverable).

   That said, recovering this is going to be somewhere between very
hard and miraculous.

   Hugo.

-- 
Hugo Mills | But somewhere along the line, it seems
hugo@... carfax.org.uk | That pimp became cool, and punk mainstream.
http://carfax.org.uk/  |
PGP: E2AB1DE4  |  Machinae Supremacy, Rise


signature.asc
Description: Digital signature

Btrfs data recovery

[Christian Rene Thelen]

I have formated an encrypted disk, containing a LVM with a btrfs system.

All superblocks appear to be destroyed; the btrfs-progs tools can't find the 
root tree anymore and scalpel, binwalk, foremost & co return only scrap. The 
filesystem was on an ssd and mounted with -o compression=lzo.

How screwed am I? Any chances to recover some files? Is there a plausible way 
to rebuild the superblock manually? Checking the raw image with xxd gives me 
not a single readable word.

I managed to decrypt the LV and dd it to an image. What can I do?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html