[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hard drive testing?

Two days is fast!   I let it run for over a week one time - and got
everything back!


On Thu, Dec 23, 2010 at 5:37 PM, Robert G. (Doc) Savage
<dsavage@peaknet.net> wrote:
> On Tue, 2010-12-21 at 17:56 -0600, Wolfgang wrote:
>> I tried to copy the Windows partition over to my 500 GB (which has
>> enough space) and now it GParted is unable to due to bad sectors, any
>> ideas on that one? Also, I feel a shift to Windows 7/Fedora dual boot
>> and losing Ubuntu as Ubuntu is losing it's appeal now that they are
>> trying too hard to make it mainstream.
>> --
>> "You must control your future by taking command of your present, and
>> fixing and learning from your past."
>> "When history is forgotten people don't realize when it repeats."
>> " - .  - .     ."
> Wolfgang,
> In cases like this, a "rescue" version of dd is probably the best tool
> for the job. It tolerates and can step over bad sectors on the source
> (writing empty sectors to the destination).
> There are two common variants:
>    $ rpm -qa | grep rescue
>    dd_rescue-1.23-1.fc14.x86_64
>    ddrescue-1.13-1.fc14.x86_64
> There's a man page for ddrescue but not dd_rescue. For quickie help
> screens type 'ddrescue --help' or just 'dd_rescue' with no arguments.
> Each has strengths, weaknesses, and features not found in the other. I
> prefer dd_rescue:
>    # dd_rescue \
>    -l /pathto/local/logfile \
>    -o /pathto/local/badblockslogfile \
>    -A -v \
>    /pathto/source/partition \
>    /pathto/destination/partition_or_imagefile
> You can use dd_rescue to copy a partition from one device to another, or
> to an image file as an intermediary. Note: It will exhaustively retry
> reading every block with a read error. If all read tries fail, it writes
> zeros to the destination block, makes an entry to the badblockslogfile,
> and moves on. Those exhaustive retries can take a long time. I've had
> dd_rescue take two days to image a 40GB NTFS partition.
> --Doc
> -
> To unsubscribe, send email to majordomo@silug.org with
> "unsubscribe silug-discuss" in the body.

To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.