From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Sebastian Roller <sebastian.roller@gmail.com>,
linux-btrfs@vger.kernel.org
Subject: Re: All files are damaged after btrfs restore
Date: Wed, 17 Mar 2021 09:38:01 +0800 [thread overview]
Message-ID: <2411012e-0b50-ff76-2710-5fa55b8487eb@gmx.com> (raw)
In-Reply-To: <CALS+qHMo-XVzXKEfd44E6BG7TPnWKT+r2m7p1wFtFs5XjQApEA@mail.gmail.com>
On 2021/2/23 下午11:45, Sebastian Roller 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
This means the tree block is completely wiped out.
And I don't believe it's just one tree block wiped out, but a much
larger range of on-disk data get wiped out.
> [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
This looks like the same problem.
> 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?
From the result, it looks like the on-disk data get (partially) wiped out.
I doubt if it's just simple controller failure, but more likely
something not really reaching disk or something more weird.
In short, this is really the worst case.
Thanks,
Qu
>
> 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
>
next prev parent reply other threads:[~2021-03-17 1:39 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
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 [this message]
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=2411012e-0b50-ff76-2710-5fa55b8487eb@gmx.com \
--to=quwenruo.btrfs@gmx.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.