All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Murphy <lists@colorremedies.com>
To: Sebastian Roller <sebastian.roller@gmail.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: All files are damaged after btrfs restore
Date: Wed, 24 Feb 2021 22:40:07 -0700	[thread overview]
Message-ID: <CAJCQCtT38_0Uk7_V-EnfJ-qj4dheJnqVcWEZEKvVRsw6tY5VDg@mail.gmail.com> (raw)
In-Reply-To: <CALS+qHMo-XVzXKEfd44E6BG7TPnWKT+r2m7p1wFtFs5XjQApEA@mail.gmail.com>

On Tue, Feb 23, 2021 at 8:49 AM Sebastian Roller
<sebastian.roller@gmail.com> wrote:
>
> Hello all.
> Sorry for asking here directly, but I'm in a desperate situation and
> out of options.
> I have a 72 TB btrfs filesystem which functions as a backup drive.
> After a recent controller hardware failure while the backup was
> running, both original and backup fs were severely damaged.
>
> Kernel version is 5.7.7. btrfs-progs is (now) 5.9.
>
> At the moment I am unable to mount the btrfs filesystem.
>
> root@hikitty:~$ mount -t btrfs -o ro,recovery /dev/sdf1 /mnt/
> mount: wrong fs type, bad option, bad superblock on /dev/sdf1,
>        missing codepage or helper program, or other error
>
>        In some cases useful info is found in syslog - try
>        dmesg | tail or so.
>
> [165097.777496] BTRFS warning (device sdf1): 'recovery' is deprecated,
> use 'usebackuproot' instead
> [165097.777500] BTRFS info (device sdf1): trying to use backup root at
> mount time
> [165097.777502] BTRFS info (device sdf1): disk space caching is enabled
> [165097.777505] BTRFS info (device sdf1): has skinny extents
> [165101.721250] BTRFS error (device sdf1): bad tree block start, want
> 126718415241216 have 0
> [165101.750951] BTRFS error (device sdf1): bad tree block start, want
> 126718415241216 have 0
> [165101.755753] BTRFS error (device sdf1): failed to verify dev
> extents against chunks: -5
> [165101.895065] BTRFS error (device sdf1): open_ctree failed
>
>
> Since I desperately need the data I ran btrfs restore.
> root@hikitty:~$ install/btrfs-progs-5.9/btrfs -v restore -i -s -m -S
> --path-regex '^/(|@(|/backup(|/home(|/.*))))$' /dev/sdf1
> /mnt/dumpo/home/
> checksum verify failed on 109911545430016 found 000000B6 wanted 00000000
> checksum verify failed on 109911545462784 found 000000B6 wanted 00000000
> checksum verify failed on 57767345897472 found 000000B6 wanted 00000000
> Restoring /mnt/dumpo/home/@
> Restoring /mnt/dumpo/home/@/backup
> Restoring /mnt/dumpo/home/@/backup/home
> …
> (2.1 GB of log file)
> …
> Done searching /@/backup/home
> Reached the end of the tree searching the directory
> Reached the end of the tree searching the directory
> Reached the end of the tree searching the directory
>
>
> Using that restore I was able to restore approx. 7 TB of the
> originally stored 22 TB under that directory.
> Unfortunately nearly all the files are damaged. Small text files are
> still OK. But every larger binary file is useless.
> Is there any possibility to fix the filesystem in a way, that I get
> the data less damaged?
>
> So far I ran no btrfs check --repair.
>
> Since the original and the backup have been damaged any help would be
> highly appreciated.
> Thanks for your assistance.
>
> Kind regards,
> Sebastian Roller
>
> ----------------  Attachment. All outputs. -------------------
> uname -a
> Linux hikitty 5.7.7-1.el7.elrepo.x86_64 #1 SMP Wed Jul 1 11:53:16 EDT
> 2020 x86_64 x86_64 x86_64 GNU/Linux
>
>
> root@hikitty:~$ install/btrfs-progs-5.9/btrfs --version
> btrfs-progs v5.9
> (Version v5.10 fails to compile)
>
>
> root@hikitty:~$ btrfs fi show
> Label: 'history'  uuid: 56051c5f-fca6-4d54-a04e-1c1d8129fe56
>         Total devices 1 FS bytes used 68.37TiB
>         devid    2 size 72.77TiB used 68.59TiB path /dev/sdf1
>
>
> root@hikitty:~$ mount -t btrfs -o ro,recovery /dev/sdf1 /mnt/hist/
> mount: wrong fs type, bad option, bad superblock on /dev/sdf1,
>        missing codepage or helper program, or other error
>
>        In some cases useful info is found in syslog - try
>        dmesg | tail or so.
>
> [165097.777496] BTRFS warning (device sdf1): 'recovery' is deprecated,
> use 'usebackuproot' instead
> [165097.777500] BTRFS info (device sdf1): trying to use backup root at
> mount time
> [165097.777502] BTRFS info (device sdf1): disk space caching is enabled
> [165097.777505] BTRFS info (device sdf1): has skinny extents
> [165101.721250] BTRFS error (device sdf1): bad tree block start, want
> 126718415241216 have 0
> [165101.750951] BTRFS error (device sdf1): bad tree block start, want
> 126718415241216 have 0
> [165101.755753] BTRFS error (device sdf1): failed to verify dev
> extents against chunks: -5
> [165101.895065] BTRFS error (device sdf1): open_ctree failed
>
>
> root@hikitty:~$ btrfs rescue super-recover -v /dev/sdf1
> All Devices:
>         Device: id = 2, name = /dev/sdh1
>
> Before Recovering:
>         [All good supers]:
>                 device name = /dev/sdh1
>                 superblock bytenr = 65536
>
>                 device name = /dev/sdh1
>                 superblock bytenr = 67108864
>
>                 device name = /dev/sdh1
>                 superblock bytenr = 274877906944
>
>         [All bad supers]:
>
> All supers are valid, no need to recover
>
>
> root@hikitty:/mnt$ btrfs rescue chunk-recover /dev/sdf1
> Scanning: DONE in dev0
> checksum verify failed on 99593231630336 found E4E3BDB6 wanted 00000000
> checksum verify failed on 99593231630336 found E4E3BDB6 wanted 00000000
> checksum verify failed on 124762809384960 found E4E3BDB6 wanted 00000000
> checksum verify failed on 124762809384960 found E4E3BDB6 wanted 00000000
> checksum verify failed on 124762809384960 found E4E3BDB6 wanted 00000000
> checksum verify failed on 124762809384960 found E4E3BDB6 wanted 00000000
> bytenr mismatch, want=124762809384960, have=0
> open with broken chunk error
> Chunk tree recovery failed
>
> ^^ This was btrfs v4.14
>
>
> root@hikitty:~$ install/btrfs-progs-5.9/btrfs check --readonly /dev/sdi1
> Opening filesystem to check...
> checksum verify failed on 99593231630336 found 000000B6 wanted 00000000
> checksum verify failed on 124762809384960 found 000000B6 wanted 00000000
> checksum verify failed on 124762809384960 found 000000B6 wanted 00000000
> checksum verify failed on 124762809384960 found 000000B6 wanted 00000000
> bad tree block 124762809384960, bytenr mismatch, want=124762809384960, have=0
> ERROR: failed to read block groups: Input/output error
> ERROR: cannot open file system
>
>
> FIRST MOUNT AT BOOT TIME AFTER DESASTER
> Feb 15 08:05:11 hikitty kernel: BTRFS info (device sdf1): disk space
> caching is enabled
> Feb 15 08:05:11 hikitty kernel: BTRFS info (device sdf1): has skinny extents
> Feb 15 08:05:12 hikitty kernel: BTRFS error (device sdf1): bad tree
> block start, want 141944039161856 have 0
> Feb 15 08:05:12 hikitty kernel: BTRFS info (device sdf1): read error
> corrected: ino 0 off 141944039161856 (dev /dev/sdf1 sector 3974114336)
> Feb 15 08:05:12 hikitty kernel: BTRFS info (device sdf1): read error
> corrected: ino 0 off 141944039165952 (dev /dev/sdf1 sector 3974114344)
> Feb 15 08:05:12 hikitty kernel: BTRFS info (device sdf1): read error
> corrected: ino 0 off 141944039170048 (dev /dev/sdf1 sector 3974114352)
> Feb 15 08:05:12 hikitty kernel: BTRFS info (device sdf1): read error
> corrected: ino 0 off 141944039174144 (dev /dev/sdf1 sector 3974114360)
> Feb 15 08:05:12 hikitty kernel: BTRFS error (device sdf1): bad tree
> block start, want 141944037851136 have 0
> Feb 15 08:05:12 hikitty kernel: BTRFS info (device sdf1): read error
> corrected: ino 0 off 141944037851136 (dev /dev/sdf1 sector 3974111776)
> Feb 15 08:05:12 hikitty kernel: BTRFS info (device sdf1): read error
> corrected: ino 0 off 141944037855232 (dev /dev/sdf1 sector 3974111784)
> Feb 15 08:05:12 hikitty kernel: BTRFS info (device sdf1): read error
> corrected: ino 0 off 141944037859328 (dev /dev/sdf1 sector 3974111792)
> Feb 15 08:05:12 hikitty kernel: BTRFS info (device sdf1): read error
> corrected: ino 0 off 141944037863424 (dev /dev/sdf1 sector 3974111800)
> Feb 15 08:05:12 hikitty kernel: BTRFS error (device sdf1): bad tree
> block start, want 141944040767488 have 0
> Feb 15 08:05:12 hikitty kernel: BTRFS info (device sdf1): read error
> corrected: ino 0 off 141944040767488 (dev /dev/sdf1 sector 3974117472)
> Feb 15 08:05:12 hikitty kernel: BTRFS info (device sdf1): read error
> corrected: ino 0 off 141944040771584 (dev /dev/sdf1 sector 3974117480)
> Feb 15 08:05:12 hikitty kernel: BTRFS error (device sdf1): bad tree
> block start, want 141944035147776 have 0
> Feb 15 08:05:12 hikitty kernel: BTRFS error (device sdf1): bad tree
> block start, want 141944035115008 have 0
> Feb 15 08:05:12 hikitty kernel: BTRFS error (device sdf1): bad tree
> block start, want 141944035131392 have 0
> Feb 15 08:05:12 hikitty kernel: BTRFS error (device sdf1): bad tree
> block start, want 141944036327424 have 0
> Feb 15 08:05:12 hikitty kernel: BTRFS error (device sdf1): bad tree
> block start, want 141944036278272 have 0
> Feb 15 08:05:12 hikitty kernel: BTRFS error (device sdf1): bad tree
> block start, want 141944035164160 have 0
> Feb 15 08:05:12 hikitty kernel: BTRFS error (device sdf1): bad tree
> block start, want 141944036294656 have 0
> Feb 15 08:05:16 hikitty kernel: BTRFS error (device sdf1): failed to
> verify dev extents against chunks: -5
> Feb 15 08:05:16 hikitty kernel: BTRFS error (device sdf1): open_ctree failed

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.

If there are no recent snapshots, and it's unknown what the controller
was doing while it was failing or how long it was failing for?
Recovery can be difficult.

Try using btrfs-find-root to find older roots, and use that value with
btrfs restore -t option. These are not as tidy as snapshots though,
the older they are, the more they dead end into more recent
overwrites. So you want to start out with the most recent roots you
can and work backwards in time.


-- 
Chris Murphy

  reply	other threads:[~2021-02-25  5:41 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 [this message]
2021-02-25  5:52   ` Chris Murphy
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=CAJCQCtT38_0Uk7_V-EnfJ-qj4dheJnqVcWEZEKvVRsw6tY5VDg@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.