From owner-freebsd-questions@freebsd.org Thu Oct 19 15:02:09 2017 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 7E807E3DE6E for ; Thu, 19 Oct 2017 15:02:09 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: from cosmo.uchicago.edu (cosmo.uchicago.edu [128.135.20.71]) by mx1.freebsd.org (Postfix) with ESMTP id 520F26D1E8 for ; Thu, 19 Oct 2017 15:02:08 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: by cosmo.uchicago.edu (Postfix, from userid 48) id 00D85CB8D08; Thu, 19 Oct 2017 10:02:01 -0500 (CDT) Received: from 128.135.52.6 (SquirrelMail authenticated user valeri) by cosmo.uchicago.edu with HTTP; Thu, 19 Oct 2017 10:02:01 -0500 (CDT) Message-ID: <43621.128.135.52.6.1508425321.squirrel@cosmo.uchicago.edu> In-Reply-To: References: <59DBA387.4050108@gmail.com> <20171009191435.145c9dd2.freebsd@edvax.de> <72772933-C642-43DB-AFD6-6B5D40EEF39E@fjl.co.uk> Date: Thu, 19 Oct 2017 10:02:01 -0500 (CDT) Subject: Re: How to recover data from dead hard drive. From: "Valeri Galtsev" To: "Frank Leonhardt (m)" Cc: "FreeBSD" , "Carmel NY" Reply-To: galtsev@kicp.uchicago.edu User-Agent: SquirrelMail/1.4.8-5.el5.centos.7 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 15:02:09 -0000 On Thu, October 19, 2017 3:47 am, Frank Leonhardt (m) wrote: > > > On 14 October 2017 11:14:26 BST, Carmel NY wrote: >>On Fri, 13 Oct 2017 12:03:11 +0100, Frank Leonhardt (m) stated: >> >>>Good list that. ddrescue is, IME, the place to start. > >>>I also have some expensive licensed software for recovering incomplete >>file >>>systems, and charge Windows users like a wounded rhinoceros when they >>need >>>their data back. >> >>Years ago, I used "Spinrite" to recover a damaged drive. It worked >>better than >>anything else on the market, at least for me, at the time. I don't >>think it >>has been maintained in over a decade though. >> >>Personally, I fail to understand why anyone with any "mission critical" >>system would not be using some form of RAID. It doesn't make any sense >>to me. >>Even my Laptop is configured to automatically back up data to a cloud >>service. >>Even if the drive went south, I could restore all of my data. > > I can explain why people aren't using RAID... IME It's because they think > they are. But they do it wrong, and only find out when things go wrong. > > Most if the disasters I deal with involve "hardware" RAID cards. I won't > single out PERC or MegaRAID because that wouldn't be fair. Hm... My mileage is different. I use hardware RAIDs a lot. With great success, and not a single disaster happened to me. Statistics for my case is: between a dozen and two dozens of hardware RAIDs during at least decade and a half. Some that are still are in production are over 10 years old. My favorite 3ware, alas, was eradicated by competitors, second favorite is Areca, next will be LSI, and it is not a most favorite as it has horrible (confusing!) command client interface. Sometimes people come from different places and tell "hardware RAID horror" stories. After detailed review, all of them boil down to either or all of: 1. RAID was not set up correctly. Namely: there were no surface scan (scrub, or similar) scheduled to happen. Monthly would be enough, I usually schedule it weekly. I will not go into detail how it leads to problem, it's been described many times; 2. notification to sysadmin about failed drive, lost redundancy of RAID is not arranged (which is as well incorrectly configured RAID) 3. inappropriate drives are used. The worst for RAID are "green" drives that spin down to conserve power. While they spin up when request from RAID card comes, they just time out... 4. Enabling cache, while not having battery backup that keeps cache RAM with all its data in case of power outage ... I've heard many time people bashing hardware RAID in favor of software RAID. And everybody who is in favor of software RAID ignored the following. Software RAID runs as process(es) under the main system. Hardware RAID runs under very slim system on its own dedicated hardware (CPU, RAM inside RAID card). The difference is: the second is way more robust; being really small code it is much less likely to have bugs. If the [main] system locks up, software RAID never finishes its function, and whereas there are mechanisms for filesystem to be recovered from similar situation, (software) RAID does not have good mechanisms to get out of it with minimal losses (someone correct me if I'm wrong here). Hardware RAID will continue and finish its tasks even if the [main] system got locked up with kernel panic: it is independent of system that runs on the machine. Similarly with sudden power loss, if power is restored within reasonable time hardware RAID will loose much less (if any) as opposed to software RAID. All in all hardware RAID is one of well known general ways of increasing reliability of sophisticated system: instead of designing one big sophisticated system one splits it into independent smaller and simpler functioning units each of them keeps doing its task even if some other unit failed (next step will be redundancy, which I'm leaving out as it does not relate to software/hardware RAID comparison). Just my $0.02 Valeri > > People are using stupid operating systems (i.e. not FreeBSD or Solaris) > and the HBA acts as a volume manager. The OS is clueless when a drive goes > flaky as all it sees is one big drive, and the first the know if a problem > is when the final one croaks. (Who is there to see the identity lamp > flashing red). > > Companies pay lots of money for this kit (to run Windows) and believe what > they were told when they bought it. The more kit costs, the more lusers > trust it. > > > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > freebsd-questions@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org" > ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++