linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Courtier-Dutton <james.dutton@gmail.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
	linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: ext4 recovery
Date: Sun, 5 Apr 2020 17:10:52 +0100	[thread overview]
Message-ID: <CAAMvbhGrZRVxGfhe6e=zeTGwAP-CcTgDC6nPeMkjg9adv_hAwg@mail.gmail.com> (raw)
In-Reply-To: <1E3CE46B-2B81-42C0-A50A-02216CC6D8D1@dilger.ca>

HI,

Just an update. I managed to recover all the data I needed to. Many
thanks to everyone who responded.
Ext4 is the greatest file system!!!

Kind Regards

James



On Tue, 21 Jan 2020 at 02:20, Andreas Dilger <adilger@dilger.ca> wrote:
>
> You can use "filefrag -k" to get units of KB instead of blocks for the physical offsets of the files, and "lvdisplay -m /dev/XXX" to show the mapping of LVs to disks (not sure if you can get it to print different units, or just LE number and you gave to multiply by the LE size).  Hopefully the LV was layer out linearly and is just a matter of computing "> X and < Y" to determine the affected range.
>
> Note that it is likely that some files which were on the second disk will not show anything from filefrag since the inodes were zeroed out by dd_rescue. Some files on the second disk that _do_ show blocks that were allocated on that disk may just have zeroes for the data.
>
> Cheers, Andreas
>
> > On Jan 20, 2020, at 15:07, James Courtier-Dutton <james.dutton@gmail.com> wrote:
> >
> > On Tue, 14 Jan 2020 at 21:25, Theodore Y. Ts'o <tytso@mit.edu> wrote:
> >>
> >>> On Tue, Jan 14, 2020 at 04:03:53PM +0000, James Courtier-Dutton wrote:
> >>>
> >>> Say I started with 1 disk using LVM with an ext4 partition.
> >>> I then added another disk. Added it to the LVM group, expanded the
> >>> ext4 partition to then fill 2 disks.
> >>> I then added another disk. Added it to the LVM group, expanded the
> >>> ext4 partition to then fill 3 disks.
> >>
> >> Where you using RAID 0, or some more advanced RAID level?
> >>
> >>> One of the disk has now failed.
> >>
> >> How has it failed?  It is dead dead dead?  Or are there a large number
> >> of sector errors?
> >>
> >>> Are there any tools available for ext4 that could help recover this?
> >>> Note, I am a single user, not a company, so there is no money to give
> >>> to a data recovery company, so I wish to try myself.
> >>
> >> How valuable is your data?  The first thing I would recommend, if your
> >> data is worth it (and only you can make that decision) is to create a
> >> new RAID set (using larger disks if that helps reduce the price) so
> >> you can make an block-level image backup using the dd_rescue program.
> >>
> >> If you can, then run e2fsck on the backup copy, and then see what you
> >> can recover from that image set.  This will save time (how much is
> >> your time worth?) and perhaps increase the amount of data you can
> >> recover (how much is your data worth?).
> >>
> >>                                        - Ted
> >
> > Hi,
> >
> > Thank you all for the help.
> > I have made some progress.
> > Disk 1 is 100% OK.
> > Disk 2 did dd_rescue and recovered about 30% of the sectors.
> > Disk 3 is 100% OK.
> >
> > I have made images of all of that. LVM worked out what order they went
> > in, and ext4 even let me mount the LVM volume.
> > I have managed to recover a lot of the data, so thank you for the hints.
> > What I would like to do now is find out which files were on Disk 2.
> > I have found the fiemap  IOCTL that gives me the logical sectors for
> > the file itself.
> > How do I convert the value from the IOCTL into a physical sector, or
> > at least an offset into the LVM volume?
> > I can then work at that sector 0 to A is on Disk 1,  A to B is on Disk
> > 2, and B to C is on Disk 3.
> >
> > For example, this is how it is done on btrfs. What is the equivalent on ext4?
> >
> > $ sudo filefrag -v UEFI_Spec_2_8_final.pdf
> > Filesystem type is: 9123683e
> > File size of UEFI_Spec_2_8_final.pdf is 18586279 (4538 blocks of 4096 bytes)
> > ext:     logical_offset:        physical_offset: length:   expected: flags:
> >   0:        0..    4537:    9798022..   9802559:   4538:             last,eof
> > UEFI_Spec_2_8_final.pdf: 1 extent found
> > $ sudo btrfs-map-logical -l $[9798022*4096] /dev/nvme0n1p7
> > mirror 1 logical 40132698112 physical 31475654656 device /dev/nvme0n1p7
> > $ sudo dd if=/dev/nvme0n1p7 bs=1
> > skip=31475654656 count=64 2>/dev/null | hexdump -C
> > 00000000  25 50 44 46 2d 31 2e 36  0d 25 e2 e3 cf d3 0d 0a  |%PDF-1.6.%......|
> > 00000010  33 30 35 35 31 39 20 30  20 6f 62 6a 0d 3c 3c 2f  |305519 0 obj.<</|
> > 00000020  46 69 6c 74 65 72 2f 46  6c 61 74 65 44 65 63 6f  |Filter/FlateDeco|
> > 00000030  64 65 2f 46 69 72 73 74  20 31 31 37 39 2f 4c 65  |de/First 1179/Le|
> > 00000040
> >
> >
> > Kind Regards
> >
> > James

      reply	other threads:[~2020-04-05 16:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-14 16:03 ext4 recovery James Courtier-Dutton
2020-01-14 20:35 ` Andreas Dilger
2020-01-14 21:25 ` Theodore Y. Ts'o
2020-01-20 22:06   ` James Courtier-Dutton
2020-01-21  2:20     ` Andreas Dilger
2020-04-05 16:10       ` James Courtier-Dutton [this message]

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='CAAMvbhGrZRVxGfhe6e=zeTGwAP-CcTgDC6nPeMkjg9adv_hAwg@mail.gmail.com' \
    --to=james.dutton@gmail.com \
    --cc=adilger@dilger.ca \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).