All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neil@brown.name>
To: tyranastrasz@gmx.de, antlists <antlists@youngman.org.uk>,
	linux-raid@vger.kernel.org
Subject: Re: Restoring a raid0 for data rescue
Date: Mon, 03 Aug 2020 14:37:29 +1000	[thread overview]
Message-ID: <873654tkdy.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <057b0c58-3876-0f03-af33-86f3b266a18a@gmx.de>

[-- Attachment #1: Type: text/plain, Size: 1930 bytes --]

On Sun, Aug 02 2020, tyranastrasz@gmx.de wrote:
>
> I tried something what was told here
> https://askubuntu.com/questions/69086/mdadm-superblock-recovery
>
> root@Nibler:~# mdadm --create /dev/md0 -v -f -l 0 -c 128 -n 2 /dev/sdd
> /dev/sdb

That was a mistake.  I probably could have saved you before you did
that.  Maybe I still can...

You have an Intel IMSM RAID0 array over sdb and sdd.
This was 3711741952 sectors in size using the first 1855871240 sectors
of each device - data arranged in 7249496 256KiB stripes (128KiB on each
device).

This 1900GB array was partitioned into 3 partitions: 3MB, 1800MB,
and 18MB.

Presumably the data you want is on the 2nd partition: the 1800MB one?

When you ran the "mdadm --create" command it wrote some meta data at the
start of the device - probably only a 4K block at 8K from the start.
This is before the first partition, so it might not have affected any
data at all.  It may have corrupted the partition table.

You need to put the array together again without writing anything to
it.  Fortunately that is fairly easy with RAID0.

1/ If /dev/md0 still exists, stop it "mdadm --stop /dev/md0"
2/ put the two devices into a RAID0 with no metadata.
    mdadm --build /dev/md0 -n 2 -z 927935620 -c 128 -l 0 /dev/sdb /dev/sdd

3/ create a read-only loop device over the second partition
    losetup -r -o 4096K --sizelimit 7176980M /dev/loop0 /dev/md0

4/ Examine the filesystem at /dev/loop0 READ-ONLY.
  You didn't say what sort of filesystem you used.  If ext4, then
     fsck -n /dev/loop0

5/ If it looks good, try mounting /dev/loop0 READ-ONLY.

I recommend that you FIRST read the relevant parts of the mdadm and
losetup man pages, and check my arithmetic to make sure the numbers that
I have given are correct.  If unsure, ask.

If it doesn't work, I recommend reporting results, asking, and waiting
before doing anything that might change anything on the drives.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  parent reply	other threads:[~2020-08-03  4:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <S1726630AbgHBR6v/20200802175851Z+2001@vger.kernel.org>
2020-08-02 18:09 ` tyranastrasz
2020-08-02 19:01   ` antlists
2020-08-02 19:24     ` tyranastrasz
2020-08-02 20:38       ` tyranastrasz
2020-08-02 20:50         ` antlists
2020-08-03  0:46           ` tyranastrasz
2020-08-03  2:55             ` Phil Turmel
2020-08-03  4:37         ` NeilBrown [this message]
2020-08-04  0:51           ` tyranastrasz

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=873654tkdy.fsf@notabene.neil.brown.name \
    --to=neil@brown.name \
    --cc=antlists@youngman.org.uk \
    --cc=linux-raid@vger.kernel.org \
    --cc=tyranastrasz@gmx.de \
    --subject='Re: Restoring a raid0 for data rescue' \
    /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

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.