From owner-freebsd-questions@freebsd.org Thu Aug 25 12:26:39 2016 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C92F3BC4EBE for ; Thu, 25 Aug 2016 12:26:39 +0000 (UTC) (envelope-from g8kbvdave@googlemail.com) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C0161942 for ; Thu, 25 Aug 2016 12:26:39 +0000 (UTC) (envelope-from g8kbvdave@googlemail.com) Received: by mail-wm0-x22f.google.com with SMTP id q128so236941917wma.1 for ; Thu, 25 Aug 2016 05:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=Yglu8zXgfbPiWAToiP4TKdGhwJEBfhlK8m2Sd0AGVvk=; b=V47KfjX9QrninjnXPrhglUf6Gsiw06NULZI987wsSBT61vNXcJh0dKvqZqwE8FgCvX +eNla5eMJxQIC8oGrmt/d6I9sbzdItr12zLJYvhWs6mHxlDOJj2pZR98toXEamcuo6x4 2f0Smk0lDcPHTcxN7LCdOOR8qv7Q1EwlnlB0F5/EooogWjSWk0sX9dWLn8n6gqanMzxw +fqM74Ou/1CKbv4GUtJ7u+LHeJn+PE/kqe0moyM0r37IiNBy0gcCZIVTIIzRH0Utv+3X blvcgAGrD7oAi73ZmXTc8YWlinLxzcNCOP47pnCuFGDYSzttM58H5MR+2UE4GxLOJnPR DPQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=Yglu8zXgfbPiWAToiP4TKdGhwJEBfhlK8m2Sd0AGVvk=; b=ZlZix7jL8SpgkAvxWtClmzwwDHRYuFQUkXIctto4X3mN5tjxAUAJ93w4eu7epOGrI9 gt8ZmBT3x49+k+DlUZ2TxK0QQL1OQQG3UA91hbrUH92DisuQiLPQqQ7Ux2OFe3tLeXWz 4bHnSOwcmXyREGbbTm9PGoIvdw68sT5ZYkUCoBZ9Rm0sVHzFnGsRZYxcWtnW1MBcHbOg n9SEQEz4YTVbbj10Jr/S1npDOCrn7A0prNTc2tpYeQSp/PXoc9Yr9lEd8hbIXRrMtTBz m6xGiooFoYvGhkJJdFkWB6qysv2VgxNSeYyIxV7giFdwggmIjVQtQsAq0rl5Tn7AsFYU 2Fgw== X-Gm-Message-State: AE9vXwOVqaIr9ekWTdnivgTwYz/fcilnTSrDexk1mMtUsB9cGNrqbHb1MTMegEi7ZKBXcA== X-Received: by 10.28.142.2 with SMTP id q2mr6773128wmd.119.1472127997469; Thu, 25 Aug 2016 05:26:37 -0700 (PDT) Received: from [192.168.2.52] ([217.41.35.220]) by smtp.gmail.com with ESMTPSA id a9sm14960314wjf.16.2016.08.25.05.26.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Aug 2016 05:26:36 -0700 (PDT) Subject: Re: freebsd-questions Digest, Vol 638, Issue 4 To: freebsd-questions@freebsd.org References: From: Dave B Message-ID: <773a1834-ceb9-0da5-7407-cba8a6cdac29@googlemail.com> Date: Thu, 25 Aug 2016 13:26:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 12:26:39 -0000 I think you're going to need something that can read/write to the drive, at a sector by sector level, well away from any operating system. Even then, chances are it's a hardware failure, not a surface corruption, in which case sadly it's a door stop, or a job for a professional hard disk recovery facility, who can repair/replace (for example) the head read amplifiers in the drive. The only software I know of that has any chance of rescuing drives like that without taking the covers off (so long as the surface can be read in some way) is Spinrite by Steve Gibson (Google it.) Not free, but *Very* good. It recently pulled an old XP laptop back from the brink, when that was stuck in a boot loop, showing unrecoverable hard disk errors. (It was dropped while working!) In reality, in that case it was one sector damaged, the rest of the drive was fine. It "Recovered" as much of the faulty sector (save for 21 bits that were the problem, and that took an hour+) after that, the system booted as normal, the drive's SMART data was not effected, even chkdsk was OK.. Be careful with some of the FLOS disk testing and imaging tools, many will not accept any read errors from the source drive, dying, halting or otherwise not completing the task. Some will hammer the faulty drive to it's final end. There is nothing wrong in what they do, just that they don't actually "do" what many people expect. Regards. Dave B. NO affiliation whatsoever to grc.com, other than a long time owner of a copy of Spinrite. On 25/08/16 13:00, freebsd-questions-request@freebsd.org wrote: > Subject: > recoverdisk strategy > From: > "Christoph P.U. Kukulies" > Date: > 24/08/16 16:46 > > To: > "freebsd-questions@freebsd.org" > > > Presently I'm again in the situation to have to recover a hard disk > that has a Windows NTFS on it, refused to > boot Windows 7 and has a lot of I/O-Errors. > > I connected the disk to my FreeBSD system and now I'm trying to create > a dump of it using "recoverdisk". > > But it gives I/O-errors lots and lots and this quite slowly: > > > (ada2:ahcich0:0:0:0): CAM status: ATA Status Error > (ada2:ahcich0:0:0:0): ATA status: 00 () > (ada2:ahcich0:0:0:0): RES: 00 00 00 00 00 00 00 00 00 00 00 > (ada2:ahcich0:0:0:0): Error 5, Retries exhausted > (ada2:ahcich0:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 > 00 00 > (ada2:ahcich0:0:0:0): CAM status: ATA Status Error > (ada2:ahcich0:0:0:0): ATA status: 71 (DRDY DF SERV ERR), error: 04 > (ABRT ) > (ada2:ahcich0:0:0:0): RES: 71 04 9d 00 32 40 00 00 00 04 00 > (ada2:ahcich0:0:0:0): Retrying command > (ada2:ahcich0:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 > 00 00 > (ada2:ahcich0:0:0:0): CAM status: ATA Status Error > (ada2:ahcich0:0:0:0): ATA status: 71 (DRDY DF SERV ERR), error: 04 > (ABRT ) > (ada2:ahcich0:0:0:0): RES: 71 04 9d 00 32 40 00 00 00 04 00 > (ada2:ahcich0:0:0:0): Error 5, Retries exhausted > (ada2:ahcich0:0:0:0): Synchronize cache failed > > Setting > sysctl kern.cam.ada.retry_count=0 > > seems to run faster but still it's not gathering any percentage. Still > staying at 0.00000 after running some 10 minutes or so. > > What else could I do? Skipping disk blocks/cylinders? > > The aim is to produces an image of the disk that contains as much as > possible sane sectors with the rest filled wth 0, > so that the dump still keeps a mirror of the disk (with holes in it, > of course). Once being done, I'd apply a > > program like "testdisk" that can do a deep search and can try to > recover the partition information and the file system (hopefully). > > > -- > > Christoph