Wow, Dan, thanks so much for all the ideas! This is a huge help. Here's
what's going on:
I already formatted the new drive with ext4 and copied 3 TB of data onto
it, so I don't want to undo all that right away, but there is another,
probably more appealing way to go:
/dev/sda and /dev/sdb are identical 2 TB drives that were previously in a
RAID1. It looks like sdb somehow disconnected from the RAID, but sda kept
working for a few months before it failed. I can mount /dev/sdb1 just
fine and I copied all the files off of it onto the new external drive. I
had no errors. So maybe /dev/sdb is in pretty good shape. Now that it's
backed up, maybe the best plan is to try to copy /dev/sda to /dev/sdb
using one of the dd tools.
So here's a question: /dev/sdb is formatted for ext4. If I want to use
it as the destination drive for the dd copy, do I have to use parted to
remove the partition table first? Or what?
Thanks again!
Mike
On Sat, 12 Sep 2015, Dan Armbrust wrote:
> On 09/11/2015 11:56 PM, Mike Miller wrote:
>>
>> [169448.936046] ata3.00: error: { UNC }
>> [169449.048405] ata3.00: configured for UDMA/133
>> [169449.048439] sd 2:0:0:0: [sda] FAILED Result: hostbyte=DID_OK
>> driverbyte=DRIVER_SENSE
>> [169449.048442] sd 2:0:0:0: [sda] Sense Key : Medium Error [current]
>> [descriptor]
>> [169449.048445] sd 2:0:0:0: [sda] Add. Sense: Unrecovered read error - auto
>> reallocate failed
>> [169449.048447] sd 2:0:0:0: [sda] CDB: [169449.048449] Read(10): 28 00 73
>> c5 1d 58 00 00 f8 00
>> [169449.048456] blk_update_request: I/O error, dev sda, sector 1942298138
>> [169449.048470] ata3: EH complete
>> [169449.048603] JBD2: Failed to read block at offset 8899
>> [169449.048900] JBD2: recovery failed
>> [169449.048903] EXT4-fs (sda1): error loading journal
>>
>
> I just wrote you a different response last night, where I noted that ext4 is
> the only one that cost me data... and here again, a single IO error on your
> drive, and ext4 has puked.
>
> It used to be that you could mount ext4 as ext3 - which would cause it to
> ignore the journal - but I think they have since changed the format of ext4,
> and that is no longer possible (unless you created this ext4 a really long
> time ago, when they were still compatible, by default)
>
> As far as trying anything else for recovery - the first step is to get
> whatever is on this drive onto good hardware - as any further operations may
> lead to more damaged blocks, making the problem even worse.
>
> Use a tool like one of these, to copy the entire disk, bit for bit onto that
> nice, new empty drive that you have:
>
> http://askubuntu.com/questions/211578/whats-the-difference-between-ddrescue-gddrescue-and-dd-rescue
>
>
> Its possible, that after copying the entire disk, bit for bit - that you
> might be able to mount it from the new drive - because the rescue tools do a
> much better job of isolating bad bits (as opposed to failing an entire sector
> read), and perhaps the remaining errors will be small enough to let ext4
> complete the mount.
>
> If not, start going down one of these recovery paths:
> https://linuxexpresso.wordpress.com/2010/03/31/repair-a-broken-ext4-superblock-in-ubuntu/
>
> But ONLY on the new drive - after you copied the data. The failing drive
> could completely disappear on you at any time.
>
> After you get done doing all of this, and hopefully get back the data you
> want - then you can go down the road of reformatting that new disk the way
> you want it in the end.
>
> From your other message:
>
>> I think parted is pretty easy to use, once you know what to do. I guess I
>> need to use parted -l to find the /dev/sd letter (I'll use /dev/sdx here),
>> then something like this will create the ext4 partition:
>>
>> sudo parted /dev/sdx mklabel gpt
>> sudo parted /dev/sdx mkpart primary ext4 0 5TiB
>>
>> I think it then needs to be formatted. Would this command do it?
>>
>> mkfs.ext4 /dev/sdx1
>
> This sounds about right - but all of this will be much easier if you just use
> gparted.
>
> Also, I'd still recommend doing an encryption step. So, after you make the
> primary partition, with truecrypt, anyway, you encrypt the entire primary
> partition. Then, after you "mount" the encrypted partition with truecrypt,
> you do the file system create steps inside of that encrypted container.
>
> I'm sure other encryption tools are similar, I'm just not familiar with them.
>
> You can find the last good version of truecrypt here:
> https://www.grc.com/misc/truecrypt/truecrypt.htm including the user guide:
> https://www.grc.com/misc/truecrypt/TrueCrypt%20User%20Guide.pdf
>
>
>
> _______________________________________________
> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota
> tclug-list at mn-linux.org
> http://mailman.mn-linux.org/mailman/listinfo/tclug-list
>