From: Chris Murphy <lists@colorremedies.com>
To: Chris Murphy <lists@colorremedies.com>
Cc: Sebastian Roller <sebastian.roller@gmail.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: All files are damaged after btrfs restore
Date: Wed, 24 Feb 2021 22:52:15 -0700 [thread overview]
Message-ID: <CAJCQCtRkPa7GSjqOBs95ZsJL04o-FBXhgB6xH5KwP+TgupjCnw@mail.gmail.com> (raw)
In-Reply-To: <CAJCQCtT38_0Uk7_V-EnfJ-qj4dheJnqVcWEZEKvVRsw6tY5VDg@mail.gmail.com>
On Wed, Feb 24, 2021 at 10:40 PM Chris Murphy <lists@colorremedies.com> wrote:
>
> I think you best chance is to start out trying to restore from a
> recent snapshot. As long as the failed controller wasn't writing
> totally spurious data in random locations, that snapshot should be
> intact.
i.e. the strategy for this is btrfs restore -r option
That only takes subvolid. You can get a subvolid listing with -l
option but this doesn't show the subvolume names yet (patch is
pending)
https://github.com/kdave/btrfs-progs/issues/289
As an alternative to applying that and building yourself, you can
approximate it with:
sudo btrfs insp dump-t -t 1 /dev/sda6 | grep -A 1 ROOT_REF
e.g.
item 9 key (FS_TREE ROOT_REF 631) itemoff 14799 itemsize 26
root ref key dirid 256 sequence 54 name varlog34
The subvolume varlog34 is subvolid 631. It's the same for snapshots.
So the restore command will use -r 631 to restore only from that
subvolume.
--
Chris Murphy
next prev parent reply other threads:[~2021-02-25 5:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-23 15:45 All files are damaged after btrfs restore Sebastian Roller
2021-02-25 5:40 ` Chris Murphy
2021-02-25 5:52 ` Chris Murphy [this message]
2021-02-26 16:01 ` Sebastian Roller
2021-02-27 1:04 ` Chris Murphy
2021-03-04 15:34 ` Sebastian Roller
2021-03-05 3:01 ` Chris Murphy
2021-03-07 13:58 ` Sebastian Roller
2021-03-08 0:56 ` Chris Murphy
2021-03-09 17:02 ` Sebastian Roller
2021-03-09 20:34 ` Chris Murphy
2021-03-16 9:35 ` Sebastian Roller
2021-03-16 19:34 ` Chris Murphy
2021-03-17 1:38 ` Qu Wenruo
2021-03-17 2:59 ` Chris Murphy
2021-03-17 9:01 ` Sebastian Roller
2021-03-17 1:54 ` Dāvis Mosāns
2021-03-17 10:50 ` Sebastian Roller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJCQCtRkPa7GSjqOBs95ZsJL04o-FBXhgB6xH5KwP+TgupjCnw@mail.gmail.com \
--to=lists@colorremedies.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=sebastian.roller@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.