<?xml version='1.0' encoding='UTF-8'?><?xml-stylesheet href="http://www.blogger.com/styles/atom.css" type="text/css"?><feed xmlns='http://www.w3.org/2005/Atom' xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/' xmlns:georss='http://www.georss.org/georss' xmlns:gd='http://schemas.google.com/g/2005' xmlns:thr='http://purl.org/syndication/thread/1.0'><id>tag:blogger.com,1999:blog-8012568243058880053</id><updated>2012-01-26T04:55:37.761-08:00</updated><category term='raid 10'/><category term='data recovery'/><category term='zfs'/><category term='zero fill'/><category term='bad sectors'/><category term='raid5'/><category term='delayed parity'/><category term='2011'/><category term='sd card'/><category term='free'/><category term='sdelete'/><category term='overwritten data'/><category term='tailpacking'/><category term='ldm'/><category term='write hole'/><category term='alignment'/><category term='seagate'/><category term='waterproof sd card'/><category term='hfs'/><category term='hfs+'/><category term='raid5ee'/><category term='urban legend'/><category term='partitioning'/><category term='wipe'/><category term='raid 5'/><category term='sd'/><category term='tom&apos;s'/><category term='mbr'/><category term='overclocking'/><category term='disk image'/><category term='jbod'/><category term='mdadm'/><category term='fake flash drive'/><category term='raid1'/><category term='boot sector'/><category term='chkdsk'/><category term='promise'/><category term='raid'/><category term='hot spare'/><category term='cluster size'/><category term='raid5e'/><category term='flash drive'/><category term='story'/><category term='raid recovery'/><category term='xfs'/><category term='speed'/><category term='ext'/><category term='ntfs'/><category term='hotswap'/><category term='remote recovery'/><category term='s.m.a.r.t.'/><category term='TLER'/><category term='image file'/><category term='raid1e'/><category term='format'/><category term='trim'/><category term='raid reconstructor'/><category term='raw filesystem'/><category term='nas'/><category term='jmb393'/><category term='raid6'/><category term='QNAP suckage'/><category term='reallocation'/><category term='BigLBA'/><category term='fat32'/><category term='raid tips'/><category term='raid10'/><category term='mtbf'/><category term='secure erase'/><category term='SSD'/><category term='ure'/><category term='photo recovery'/><category term='raid triangle'/><category term='raid01'/><category term='raid0'/><category term='exfat'/><category term='fail'/><category term='ubuntu'/><category term='HPA'/><category term='fat'/><category term='raid 6'/><category term='software RAID'/><category term='cropel'/><category term='erase'/><title type='text'>Data Recovery Weekly</title><subtitle type='html'></subtitle><link rel='http://schemas.google.com/g/2005#feed' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/posts/default'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default?max-results=100'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/'/><link rel='hub' href='http://pubsubhubbub.appspot.com/'/><link rel='next' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default?start-index=101&amp;max-results=100'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><generator version='7.00' uri='http://www.blogger.com'>Blogger</generator><openSearch:totalResults>133</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>100</openSearch:itemsPerPage><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-797152966806882109</id><published>2012-01-25T12:44:00.000-08:00</published><updated>2012-01-25T12:49:12.085-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='cropel'/><category scheme='http://www.blogger.com/atom/ns#' term='s.m.a.r.t.'/><title type='text'>S.M.A.R.T.</title><content type='html'>Looks like our S.M.A.R.T. tool at &lt;a href="http://www.cropel.com"&gt;www.cropel.com&lt;/a&gt; might be ready for slow-ish initial release.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-797152966806882109?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/797152966806882109/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2012/01/smart.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/797152966806882109'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/797152966806882109'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2012/01/smart.html' title='S.M.A.R.T.'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-8700093662019070110</id><published>2012-01-13T02:08:00.000-08:00</published><updated>2012-01-13T02:23:15.174-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><title type='text'>Simultaneous disk failure</title><content type='html'>Modern hard drives have annual failure rate of about 5%. With this sort of the failure probability you cannot realistically talk about the simultaneous hard drive failures, even if the window of &lt;span style="font-style:italic;"&gt;simultaneousness&lt;/span&gt; spans several hours.  The simultaneous failure of two drives is just not probable enough. The catch is, the statistics only applies to independent drives. The common-mode failure, when several drives fail because of a single cause, is not accounted for.&lt;br /&gt;&lt;br /&gt;As a consequence of this, in fault-tolerant RAID applications more effort should be put to eliminate possible single points of failure. &lt;strike&gt;Realistically, this means the most effective thing you can do is to eliminate the operator, eh.&lt;/strike&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-8700093662019070110?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/8700093662019070110/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2012/01/simultaneous-disk-failure.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/8700093662019070110'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/8700093662019070110'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2012/01/simultaneous-disk-failure.html' title='Simultaneous disk failure'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-4927223878558031239</id><published>2012-01-02T02:03:00.000-08:00</published><updated>2012-01-02T02:03:00.678-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid triangle'/><title type='text'>Why don't we use RAID 8?</title><content type='html'>All RAID types are built using three elements:&lt;br /&gt;&lt;ol&gt;&lt;li&gt;Striping Data blocks on several disks.&lt;/li&gt;&lt;li&gt;Writing redundant data (it is usually the result of calculating particular functions).&lt;/li&gt;&lt;li&gt;Writing multiple copies of data (usually two copies are written).&lt;/li&gt;&lt;/ol&gt;Different combinations of these elements allow to get data placement patters (RAID levels) which provide desired balance between speed, reliability and price.&lt;br /&gt;&lt;br /&gt;If we only use striping, we get a RAID 0. Using only one function to calculate redundant data we will get us a RAID 5. If we add one more set of redundant data to a RAID 5, it becomes a RAID 6. We get a RAID 1 from identical copies, but if you combine the striping technique with exact copies then you get a RAID 10. These data placement patterns are the most widespread and well-known, forming a so-called &lt;a href="http://www.raid-calculator.com/raid-types-reference.aspx"&gt;raid triangle&lt;/a&gt;. &lt;br /&gt;&lt;br /&gt;Except these RAID types, we can also see exotic combinations.&lt;br /&gt;&lt;br /&gt;For example, if in RAID 10 we use the number of disks which is not an integral multiple of the number of data copies we will get significantly less symmetrical array called RAID 1E. Also in RAID 1 we can use three copies of data instead of two. Fault tolerance increases and the price of the device increases as well. The same way, if you add the third set of redundant data to a RAID 6, fault tolerance increases even more along with the price and performance decreases.&lt;br /&gt;&lt;br /&gt;Exotic RAID types are rarely used because they have too much imbalance between price, speed and fault tolerance. RAID 6 is an still acceptable tradeoff, but RAID 8 is not.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-4927223878558031239?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/4927223878558031239/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2012/01/why-dont-we-use-raid-8.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4927223878558031239'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4927223878558031239'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2012/01/why-dont-we-use-raid-8.html' title='Why don&apos;t we use RAID 8?'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-576360906761269337</id><published>2011-12-29T01:56:00.000-08:00</published><updated>2011-12-29T01:56:00.659-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid1'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='story'/><title type='text'>Stories</title><content type='html'>&lt;i&gt;&lt;br /&gt;The computer with Asus motherboard based on ICH8R has worked flawlessly for about 1.5 years. Two 250 GB hard disks were in RAID1 divided into two partitions.&lt;br /&gt;Two weeks ago I heard about a problem (the request to press a key when loading) which don't lead to subsequent problems in the operation. &lt;br /&gt;&lt;br /&gt;When the system is starting up, the message "Primary HDD not found. Press F1 to resume" is displayed. Pressing F1 leads to usual system start with the message "New device was found ...". When I started to sort out what happened I found out that RAID controller switched over to IDE mode. Disk Management displayed copies of logical disks (originally there were C:, D:, -- but now E: and F: are added with the same sizes and labels). The freshest file dates on the copies coincided with the date when start up problems arose.&lt;br /&gt;&lt;br /&gt;When I switched the controller to RAID, RAID1 appeared immediately with the name specified by me in RAID settings. The state of RAID 1 was shown as "Normal" that meant the controller didn't understand that the disks were not synchronized.&lt;br /&gt;&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;That's why it is important to monitor an array's state and to synchronize disks in a mirror or recalculate parity in a RAID 5 periodically. There are situations when a controller loses an array and an user doesn't note or just ignore it as in "RAID seems to work and the rest doesn't matter". However RAID loses its fault tolerance and instead of RAID 1 we get a single backup copy which will not update anymore.&lt;br /&gt;&lt;br /&gt;Actually a good example for one of our RAID Tips &lt;a href="http://www.raidtips.com/monitor-raid.aspx"&gt;here&lt;/a&gt;.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-576360906761269337?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/576360906761269337/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/12/stories.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/576360906761269337'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/576360906761269337'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/12/stories.html' title='Stories'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-6027743826729262710</id><published>2011-12-26T01:50:00.000-08:00</published><updated>2011-12-26T01:55:46.010-08:00</updated><title type='text'>File system reliability doesn't depend on the load</title><content type='html'>The idea that filesystem fragmentation degrades reliability, put forward by some of the defragmenter vendors, is not true.&lt;br /&gt;&lt;br /&gt;A filesystem handles all the fragments in the same way. &lt;br /&gt;&lt;br /&gt;At first significant differences arise between contiguous files which have only one fragment and files consisting of two fragments. The next significant difference appears when the list of fragments becomes large and the list itself is divided into several parts. On NTFS the mark is usually at about 100 fragments. Once it is tested that a filesystem properly handles one fragment, the list of fragments, and the list of lists, you can be sure that a filesystem handles any number of fragments.&lt;br /&gt;&lt;br /&gt;The same way a heavy load on the data storage system hardware doesn't by itself decrease reliability. High disk queue length doesn't lead to a disk failure. Definitely it indicates an overload, but if you wait long enough, all the requests will be processed. Strictly speaking, if the load is very heavy, some of the requests will be eventually cancelled due to timeout. This doesn't affect the ability of the storage to keep working properly when the load decreases.&lt;br /&gt;&lt;br /&gt;However, there are some factors which arise along with the overload that can lead to failures and losing data. In the hardware these are usually temperature and vibration. A disk system under load warms up and vibrates. If the cooling system is not good enough it can lead to overheating and excessive wear.&lt;br /&gt;&lt;br /&gt;In the software, due to an overload, race conditions and other bugs are ore likely come up. In addition, there can be errors in programs which work with the filesystem driver although they are not part of it.&lt;br /&gt;&lt;br /&gt;For example when multi-core processors were not yet invented, and dual CPUs were expensive and rare, not many antivirus programs were being tested on a multiprocessor. Once you get the antivirus filter driver on a dualhead, blue screens were quite an ordinary thing.&lt;br /&gt;&lt;br /&gt;However, filesystem errors are eventually found and fixed, and drivers of any mature filesystem are reliable and are already tested with most any load you can imagine.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-6027743826729262710?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/6027743826729262710/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/12/file-system-reliability-doesnt-depend.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/6027743826729262710'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/6027743826729262710'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/12/file-system-reliability-doesnt-depend.html' title='File system reliability doesn&apos;t depend on the load'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-7999468942628068792</id><published>2011-12-24T15:35:00.000-08:00</published><updated>2011-12-24T15:37:44.073-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>On average, machine wins</title><content type='html'>If in RAID recovery the software says the block size is X, while customer says it is Y, X and Y being diffferent, the software is correct at least nine times out of ten. Sometimes, that annoys the customer, but there is little we can do about it.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-7999468942628068792?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/7999468942628068792/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/12/on-average-machine-wins.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/7999468942628068792'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/7999468942628068792'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/12/on-average-machine-wins.html' title='On average, machine wins'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-1099218618211758646</id><published>2011-12-12T23:11:00.000-08:00</published><updated>2011-12-12T23:15:49.733-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='data recovery'/><title type='text'>Recovering confidential data</title><content type='html'>When one deals with data recovery, sometimes he worries about the confidentially of the recovered data. Look at the example below:&lt;br /&gt;&lt;br /&gt;&lt;a href="http://forum.hddguru.com/data-recovery-company-with-high-confidentiality-t21208.html#p142087"&gt;&lt;i&gt;...a Western Digital HD that makes clicking noises. .... The HD has many customer credit card numbers and legal documents on it, so confidentiality is very important to us.&lt;/i&gt;&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;If the automatic &lt;a href="http://www.ReclaiMe.com"&gt;data recovery software&lt;/a&gt; works well enough, there is no problem. In this case one recovers data himself and data always stays on his own computer.&lt;br /&gt;&lt;br /&gt;In all the other cases, for example, when a mechanical repair of disk is required, a technician has full access to a disk and that data which he is able to recover. &lt;br /&gt;Any respectable data recovery company usually doesn't reject to sign either a non-disclosure agreement (NDA) or an agreement that data cannot be viewed at all during a disk repair. &lt;br /&gt;&lt;br /&gt;The prohibition of reading data makes data recovering harder because of two reasons:&lt;br /&gt;&lt;ol&gt;&lt;br /&gt;&lt;li&gt;Quality control becomes more difficult, and often impossible at all. Some data recovery programs provide automatic integrity control of some recovered files (e.g. in ZAR). In addition, many data recovery companies use custom-made programs for this purpose. However, not all file types can be checked without reading them.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;In case the data recovery fails at the first try, resetting the program for the second time becomes more complex. &lt;br /&gt;&lt;/li&gt;&lt;br /&gt;&lt;/ol&gt;&lt;br /&gt;On top of that data recovery companies might &lt;a href="http://forum.hddguru.com/data-recovery-company-with-high-confidentiality-t21208.html#p142400"&gt;worry that the recovered data might be potentialy illegal&lt;/a&gt;.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-1099218618211758646?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/1099218618211758646/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/12/recovering-confidential-data.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1099218618211758646'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1099218618211758646'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/12/recovering-confidential-data.html' title='Recovering confidential data'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-5911354777499363136</id><published>2011-12-08T01:51:00.000-08:00</published><updated>2011-12-08T02:13:38.526-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='tom&apos;s'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><title type='text'>Ah sh!t!... erm... press on.</title><content type='html'>If you are reconfiguring a RAID, or whatever other storage system, and something unexpected happens, or something happens that you do not fully understand, stop. &lt;br /&gt;&lt;br /&gt;Pressing on in this situation would likely make things worse. Pressing on for long enough will eventually make things irreversibly bad.&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.tomshardware.co.uk/forum/277148-14-pooched-raid-options"&gt;This thread on Tom's&lt;/a&gt; presents a good example. When reading it, keep in mind two things, &lt;br /&gt;&lt;ul&gt;&lt;br /&gt;&lt;li&gt;Even if one do not initialize the RAID, each time RAID 10 is reassembled and resynched with different order of disks, there is a 50:50 chance of total data loss&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Repairing a filesystem or troubleshooting boot process without having fixed an underlying RAID first is certainly useless and often damages the data.&lt;br /&gt;&lt;/li&gt;&lt;br /&gt;&lt;/ul&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-5911354777499363136?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/5911354777499363136/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/12/ah-sht-erm-press-on.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/5911354777499363136'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/5911354777499363136'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/12/ah-sht-erm-press-on.html' title='Ah sh!t!... erm... press on.'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-6175468043157615769</id><published>2011-12-06T01:43:00.001-08:00</published><updated>2011-12-06T01:51:48.460-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='xfs'/><category scheme='http://www.blogger.com/atom/ns#' term='data recovery'/><title type='text'>XFS coming soon</title><content type='html'>Probably as soon as tomorrow. The only thing still missing is a comparison test against typical failure modes: file deletion, format, and bad blocks.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-6175468043157615769?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/6175468043157615769/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/12/xfs-coming-soon.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/6175468043157615769'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/6175468043157615769'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/12/xfs-coming-soon.html' title='XFS coming soon'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-6583532693383351226</id><published>2011-11-25T02:40:00.000-08:00</published><updated>2011-11-25T02:58:05.974-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='xfs'/><category scheme='http://www.blogger.com/atom/ns#' term='data recovery'/><title type='text'>XFS recovery</title><content type='html'>We've been working for a couple of weeks now to implement an XFS recovery capability for our ReclaiMe &lt;a href="http://www.ReclaiMe.com"&gt;data recovery software&lt;/a&gt;. The single most significant impression is that XFS is unnecessarily and exceedingly complex. Having... how many that would be, five? types of directories is actually OK, as long as these types utilize the same basic structures and design. Taking design commonalities into account, the number of distinct directory types is reduced to just two. Data storage comes in three forms (NTFS and ext4 are both OK having just two). The most interesting discovery of all to date was that each allocation group has two different sizes.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-6583532693383351226?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/6583532693383351226/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/11/xfs-recovery.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/6583532693383351226'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/6583532693383351226'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/11/xfs-recovery.html' title='XFS recovery'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-1013601575570989236</id><published>2011-11-14T04:56:00.000-08:00</published><updated>2011-11-14T04:56:00.387-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='jbod'/><title type='text'>Data loss on JBODs</title><content type='html'>&lt;a href="http://forum.qnap.com/viewtopic.php?f=25&amp;t=50629"&gt;&lt;i&gt;After a disasterous data loss coused by the raid system I have changed all to JBOD assuming that 1/8 data loss is more acceptable than a full disaster&lt;/i&gt;&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;Wrong. If you have eight drives in JBOD, and one of them dies, there are several options:&lt;br /&gt;&lt;ul&gt;&lt;li&gt;On NTFS filesystem, if first drive dies, the entire array is lost. If any other drive dies, 7/8th of the data is lost.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;On ext-whatever, you can salvage an unspecified amount of data because the superblocks are distributed more-or-less evenly across the volume. However, everything in disk groups which span across two disks is likely lost. So you can theoretically approach "1/8th of the data lost", but that involves using some &lt;a href="http://www.reclaime.com/"&gt;data recovery software&lt;/a&gt; and is far from easy.&lt;br /&gt;&lt;/li&gt;&lt;/ul&gt;&lt;br /&gt;If you want to be sure that the loss is limited to 1/8th of data in eight-disk configuration, forget JBOD and create eight separate volumes instead.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-1013601575570989236?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/1013601575570989236/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/11/data-loss-on-jbods.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1013601575570989236'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1013601575570989236'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/11/data-loss-on-jbods.html' title='Data loss on JBODs'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-9027512488777919877</id><published>2011-11-07T03:37:00.000-08:00</published><updated>2011-11-15T06:01:02.681-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>Human vs. computer in RAID recovery.</title><content type='html'>Human vs. computer battle.&lt;br /&gt;&lt;br /&gt;&lt;a href="http://forum.hddguru.com/mac-element-raid-drive-order-help-needed-t21006.html"&gt;&lt;i&gt;As far as I am aware there is no way to rebuild HFS+ RAID from file-system analysis. NTFS is simple because has good system counters to use, same as EXT. But HFS+ requires good knowledge of RAID distributions.&lt;/i&gt;&lt;/a&gt; &lt;br /&gt;&lt;br /&gt;As you see, people rely on some property of the filesystem being recovered to produce a strong signal that we can use to determine the correct RAID configuration. NTFS provides plenty of those. FAT provides even more. With EXT, hddguy probably knows more than I do, because I'm not aware of any strong singal in EXT. By and large, humans perfer to find a small bit of data with high signal-to-noise ratio, and use it. Understandable because it is limits amount of effort involved.&lt;br /&gt;&lt;br /&gt;The &lt;a href="http://www.FreeRaidRecovery.com"&gt;RAID recovery software&lt;/a&gt;, on the other hand, mostly works with weaker signals. Weaker signals have far worse SNR, but they are in plenty. For example, you can calculate entropy values for any data. Obvious computer strength is to quickly process large arrays of data, which the software exploits in full. It just crunches through a sheer number of weak signals to produce the RAID layout.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-9027512488777919877?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/9027512488777919877/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/11/human-vs-computer-in-raid-recovery.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/9027512488777919877'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/9027512488777919877'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/11/human-vs-computer-in-raid-recovery.html' title='Human vs. computer in RAID recovery.'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-1500179827814024253</id><published>2011-10-31T01:18:00.000-07:00</published><updated>2011-10-31T01:18:01.074-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid reconstructor'/><title type='text'>Shopping comparison</title><content type='html'>Did a shopping comparison of ReclaiMe Free RAID Recovery vs Runtime's RAID Reconstructor the other day. Looks kind of grim &lt;a href="http://www.FreeRaidRecovery.com/Library/raid-reconstructor.aspx"&gt;for RAID Reconstructor&lt;/a&gt;.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-1500179827814024253?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/1500179827814024253/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/10/shopping-comparison.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1500179827814024253'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1500179827814024253'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/10/shopping-comparison.html' title='Shopping comparison'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-479486064403050667</id><published>2011-10-27T05:59:00.000-07:00</published><updated>2011-12-06T02:07:07.685-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='write hole'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid 6'/><title type='text'>Can I has a write hole?..</title><content type='html'>in a RAID 6? &lt;br /&gt;&lt;br /&gt;Actually, yes.&lt;br /&gt;&lt;br /&gt;&lt;a href="http://4.bp.blogspot.com/-W6swfoSeARo/TqlZ3Uff23I/AAAAAAAAAAQ/WDBl71sDmrI/s1600/cat.jpg"&gt;&lt;img style="cursor:pointer; cursor:hand;width: 269px; height: 300px;" src="http://4.bp.blogspot.com/-W6swfoSeARo/TqlZ3Uff23I/AAAAAAAAAAQ/WDBl71sDmrI/s320/cat.jpg" border="0" alt="RAID 6 WRITE HOLE"id="BLOGGER_PHOTO_ID_5668160412950977394" /&gt;&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;All it takes is large number of disks in array, intensive I/O, a power failure, and some bad luck.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-479486064403050667?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/479486064403050667/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/10/can-i-has-write-hole.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/479486064403050667'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/479486064403050667'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/10/can-i-has-write-hole.html' title='Can I has a write hole?..'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><media:thumbnail xmlns:media='http://search.yahoo.com/mrss/' url='http://4.bp.blogspot.com/-W6swfoSeARo/TqlZ3Uff23I/AAAAAAAAAAQ/WDBl71sDmrI/s72-c/cat.jpg' height='72' width='72'/><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-4538102994927814301</id><published>2011-10-17T05:45:00.000-07:00</published><updated>2011-12-06T02:07:07.687-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid 5'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='ure'/><category scheme='http://www.blogger.com/atom/ns#' term='raid 6'/><title type='text'>RAID 5 vs RAID 6</title><content type='html'>I'm getting tired of people advocating RAID 5 vs. RAID 6. They go on &lt;em&gt;like oh, in a RAID 5 a bit error URE will get you one day! We spent 10,000s dollars sending our RAID5s to OnTrack.&lt;/em&gt; Yes, that's tens of thousands of Uncle Sam Dollars.&lt;br /&gt;&lt;br /&gt;Single bit error in a RAID 5 is much cheaper to recover from than a RAID 6 controller failure or an operator accidentally deleting the array. Ever asked for a quote on RAID 6 recovery?&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-4538102994927814301?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/4538102994927814301/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/10/raid-5-vs-raid-6.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4538102994927814301'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4538102994927814301'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/10/raid-5-vs-raid-6.html' title='RAID 5 vs RAID 6'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-1076128305004422137</id><published>2011-10-11T00:14:00.000-07:00</published><updated>2011-12-06T01:51:48.462-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='zfs'/><category scheme='http://www.blogger.com/atom/ns#' term='data recovery'/><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>Non-standard configurations</title><content type='html'>Some do actually like non-standard hardware and software setups. &lt;br /&gt;&lt;br /&gt;&lt;em&gt;If we build a 16 TB RAID 5 (9x 2TB), can we then install Windows on it?&lt;/em&gt;&lt;br /&gt;&lt;br /&gt;Probably yes, with some U/EFI trickery, but then troubleshooting this contraption if hardware ever dies would be a nightmare with 9 drives. &lt;br /&gt;&lt;br /&gt;Now another try&lt;br /&gt;&lt;br /&gt;&lt;em&gt;We have a leftover of drives, like all sorts of 160GB to 2TB Parallel ATA, all sorts of Serial ATA, five RAID/HBA controllers, and a motherboard. We thought of putting it all together and deploying ZFS over it. Do you think it is a good idea?&lt;/em&gt;&lt;br /&gt;&lt;br /&gt;Actually, no. &lt;br /&gt;&lt;br /&gt;The complexity of the failure modes for the proposed design is just mind-boggling. First of all, when ZFS crashes, there is no reliable data recovery for it. Then, multiple HBA/RAID cards from different vendors in the same system are not going to work stable. More then, with a different size drives, no common RAID scheme can be applied. Should the RAID fail, the system is not recoverable. OK you can go with ZFS hybrid filesystem-RAID capability, but it is even less recoverable when failed. On top of that, this borderline weird configuration was never tested. The symmetric configurations with md-raid and ext-whatever used in stock NAS units like QNAP are at least well tested and understood (and &lt;a href="http://data-recovery-weekly.blogspot.com/search/label/QNAP%20suckage"&gt;still even these have problems&lt;/a&gt;)&lt;br /&gt;&lt;br /&gt;So, what comes of it - stick with simple and standard configurations. The increase in efficiency for a unique build is small and is not woth the problems you encounter when it fails.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-1076128305004422137?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/1076128305004422137/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/10/non-standard-configurations.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1076128305004422137'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1076128305004422137'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/10/non-standard-configurations.html' title='Non-standard configurations'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-3386413740745287901</id><published>2011-10-07T07:55:00.000-07:00</published><updated>2011-12-06T01:51:48.464-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='remote recovery'/><category scheme='http://www.blogger.com/atom/ns#' term='data recovery'/><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>Remote recoveries</title><content type='html'>Every once in a while we do a remote recovery session via TeamViewer. The most annoying thing in remote recoveries actually is &lt;em&gt;not knowing who is in control&lt;/em&gt;. TeamViewer does not provide any feedback when the other party is going to take over by pulling a mouse cursor away. &lt;br /&gt;&lt;br /&gt;The fact that someone is standing on the remote side watching what you doing, and you cannot even tell if they are there or not, is not very comforting but acceptable. With remote recoveries, it is a part of a job, actually. Someone may choose to ride the shotgun with you. &lt;br /&gt;&lt;br /&gt;The real problem starts when they interfere with what you are doing and there is no way to stop it. This is not really because people on the remote side are specifically evil, just because there is no convenient way to establish who is in control, and how to request or how to relinquish it. Damn annoying still.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-3386413740745287901?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/3386413740745287901/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/10/remote-recoveries.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3386413740745287901'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3386413740745287901'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/10/remote-recoveries.html' title='Remote recoveries'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-4233765106546473539</id><published>2011-10-06T10:59:00.000-07:00</published><updated>2011-10-06T11:01:48.044-07:00</updated><title type='text'>Windows Update Error 80072ee2</title><content type='html'>This comes unrelated to the data recovery, but still it did cost me about two hours of time. &lt;br /&gt;&lt;br /&gt;If you have a Windows Update Error 80072ee2 on a freshly installed Vista, install Internet Explorer 9 manually. Btw, installing SP2 does not help.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-4233765106546473539?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/4233765106546473539/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/10/windows-update-error-80072ee2.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4233765106546473539'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4233765106546473539'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/10/windows-update-error-80072ee2.html' title='Windows Update Error 80072ee2'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-833358820057893107</id><published>2011-09-29T03:47:00.000-07:00</published><updated>2011-09-29T04:04:04.817-07:00</updated><title type='text'>Omitting the key information is bad</title><content type='html'>A forum member goes to great length describing a hard drive problem, which sounds mechanical. Then follows a precise account of what they tried to fix the problem, including the fact they replaced a PCB from a same model drive and so on. The story goes for like a full page, still the actual model of the drive is never mentioned. In this case, the model number is probably the most important piece of data, because we can look up a typical failure modes with it.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-833358820057893107?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/833358820057893107/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/09/omitting-key-information-is-bad.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/833358820057893107'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/833358820057893107'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/09/omitting-key-information-is-bad.html' title='Omitting the key information is bad'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-3923908882602876406</id><published>2011-09-20T07:36:00.000-07:00</published><updated>2011-12-06T02:07:07.689-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>Tricks to determine the RAID type</title><content type='html'>If there is a set of disks, but the RAID type is not known, how do we determine what type of RAID is that? Most of the RAID recovery programs, including ours at &lt;a href="http://www.FreeRaidRecovery.com"&gt;www.FreeRaidRecovery.com&lt;/a&gt;, require the RAID type to be provided by the operator.&lt;br /&gt;&lt;br /&gt;In a most simple case, where all disks are available, one can get the idea of the RAID type by just plugging all the disks and looking at the Disk Management data.&lt;br /&gt;&lt;br /&gt;The following cases are most typical, &lt;br /&gt;&lt;br /&gt;1. One or multiple partitions on exactly one of the disks. This is a RAID 0 or a RAID 5, more likely RAID 0.&lt;br /&gt;2. One or multiple partitions, with two identical sets of partitions on two disks. With three disks, this is a RAID 5. With four or more disks, this is either a RAID 5 or a RAID 10. &lt;br /&gt;&lt;br /&gt;The above does not account for RAID 6 or exotics like RAID 3, and assumes MBR-style partitioning on the array, but nevertheless makes for a good start when working with an array of unknown type.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-3923908882602876406?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/3923908882602876406/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/09/tricks-to-determine-raid-type.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3923908882602876406'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3923908882602876406'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/09/tricks-to-determine-raid-type.html' title='Tricks to determine the RAID type'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-5397418186653324861</id><published>2011-09-19T22:34:00.000-07:00</published><updated>2011-12-06T02:07:07.691-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='data recovery'/><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>Problem isolation in RAID recovery</title><content type='html'>&lt;p&gt;A full, start-to-end RAID recovery is generally a three part process.&lt;/p&gt;&lt;ol&gt;&lt;br /&gt;&lt;li&gt;Determine status of the member disks and make clones when required.&lt;/li&gt;&lt;li&gt;Detect RAID parameters and perform &lt;a href="http://www.raid-recovery-guide.com/destriping.aspx"&gt;destriping&lt;/a&gt;&lt;/li&gt;&lt;li&gt;If the destriped volume is not readily mountable, perform filesystem recovery on it to pump out the data&lt;/li&gt;&lt;br /&gt;&lt;/ol&gt;&lt;p&gt;Now, if the above three steps fail to produce correct data, the question is &lt;i&gt;how do we tell if it is RAID recovery part, or filesystem analysis part that failed&lt;/i&gt;?&lt;/p&gt;&lt;p&gt;We tell if the RAID recovery is OK by looking at the sizes of the recovered files. If there are multiple good files recovered which are larger than twice the full row size (i.e. larger than 2 * block_size * num_disks), then the RAID recovery is almost certainly OK. However, if all good files are of the small size, the RAID parameters should be investigated. This also applies to the files found by raw scan; however, keep in mind that file sizes produced by raw scan are not reliable.&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-5397418186653324861?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/5397418186653324861/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/09/problem-isolation-in-raid-recovery.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/5397418186653324861'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/5397418186653324861'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/09/problem-isolation-in-raid-recovery.html' title='Problem isolation in RAID recovery'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-3885933510641604431</id><published>2011-09-01T04:58:00.001-07:00</published><updated>2011-12-06T02:07:07.692-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid5'/><title type='text'>The most common problem with RAID5 is...</title><content type='html'>... that one does a rebuild with the wrong order of disks. &lt;br /&gt;&lt;br /&gt;This is by far the most common scenario we at www.FreeRaidRecovery.com have for an unrecoverable RAID 5. Something bad happens and the configuration is lost. The operator then assembles the array in a way which &lt;em&gt;looks correct&lt;/em&gt;, and does a rebuild on it. The configuration which &lt;em&gt;looks&lt;/em&gt; correct is just not good enough. You need a configuration which &lt;em&gt;actually is&lt;/em&gt; correct.&lt;br /&gt;&lt;br /&gt;Doing a rebuild on a RAID 5 with wrong block size or disk order effectively destroys the data on the array. Theoretically, the data can still be restored, but practically the complexity of having two sets of parameters (with unknown block sizes, disk orders, and such) precludes any recovery.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-3885933510641604431?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/3885933510641604431/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/09/most-common-problem-with-raid5-is.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3885933510641604431'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3885933510641604431'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/09/most-common-problem-with-raid5-is.html' title='The most common problem with RAID5 is...'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-3109180816359881229</id><published>2011-08-31T11:31:00.000-07:00</published><updated>2011-12-06T02:07:07.694-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>Customers' requests revisited</title><content type='html'>The customer walks in and says something along the lines of &lt;em&gt;you should have more input options for your &lt;a href="http://www.freeraidrecovery.com/"&gt;RAID Recovery app&lt;/a&gt;&lt;/em&gt;.&lt;br /&gt;&lt;br /&gt;Unfortunately, it just does not work that way. As you add more options and combinations thereof, people starting to get lost among these fast. Interestingly, I recall once considering an automatic software to detect all RAIDs attached to the system with just one click of button. Something more along the lines of &lt;em&gt;All your RAID are belong to us&lt;/em&gt;, which would eliminate the requirements both to specify array type and to select a disk set. Just do all the probing and produce all possible RAIDs. Unfortunately, this did not work out for technical reasons.&lt;br /&gt;&lt;br /&gt;Actually, even providing a correct RAID type may prove difficult if the array was created five years ago, the person setting up the system retired four years ago, and noone even noticed the RAID until it failed. So now you have four disks, some of which may or may not work; so, RAID 0, RAID 10, RAID 5, or RAID 6? OK, RAID 6 can typically be ruled out based on the controller model alone, but the rest may not be that easy. &lt;br /&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-3109180816359881229?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/3109180816359881229/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/08/customers-requests-revisited.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3109180816359881229'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3109180816359881229'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/08/customers-requests-revisited.html' title='Customers&apos; requests revisited'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-6077562112740074634</id><published>2011-08-14T22:43:00.000-07:00</published><updated>2011-12-06T02:07:07.696-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid6'/><category scheme='http://www.blogger.com/atom/ns#' term='delayed parity'/><category scheme='http://www.blogger.com/atom/ns#' term='promise'/><category scheme='http://www.blogger.com/atom/ns#' term='jmb393'/><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><category scheme='http://www.blogger.com/atom/ns#' term='exfat'/><title type='text'>Exotics</title><content type='html'>A customer walks in and says: &lt;em&gt;We need to recover a FATX volume, can you do that? - Sorry, no. &lt;/em&gt;Various exotic filesystems, btrfs, logfs, and even ReiserFs have always been considered a job for a data recovery serivce, not an automated software. Software is cheap, but only resolves common cases by applying typical solutions. Data recovery service is expensive, and applies its high fees toward the difficult cases, e.g. writing custom software to deal with just one specific case.&lt;br /&gt;&lt;br /&gt;Lately, there is an influx of requests for something nonstandard. The latest hit was&lt;br /&gt;&lt;em&gt;- We have ReiserFs on the RAID5. &lt;/em&gt;&lt;br /&gt;&lt;em&gt;- Okay, no problem.&lt;/em&gt;&lt;br /&gt;Turns out there &lt;em&gt;was &lt;/em&gt;a problem. The RAID5 was using 512 bytes per block. JMB 393 controller. Oops.&lt;br /&gt;&lt;br /&gt;So far we have &lt;a href="http://www.freeraidrecovery.com/Library/delayed-parity.aspx"&gt;delayed parity&lt;/a&gt; (from HP SmartArray), Promise RAID 6 with its non-standard Reed-Solomon, Promise &lt;em&gt;&lt;a href="http://www.freeraidrecovery.com/Library/raid1e-recovery.aspx"&gt;1E interleaved&lt;/a&gt;&lt;/em&gt; layout, &lt;a href="http://reclaime.com/"&gt;exFAT filesystem recovery&lt;/a&gt;. The capability to recover RAID with a block size of 512 bytes is in the pipeline, currently undergoing testing.&lt;br /&gt;&lt;br /&gt;So what's next? The spec for JMB 393 lists RAID 3 as a possible option, anyone actually ever used that?&lt;br /&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-6077562112740074634?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/6077562112740074634/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/08/exotics.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/6077562112740074634'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/6077562112740074634'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/08/exotics.html' title='Exotics'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-8582917052222654355</id><published>2011-08-11T04:43:00.000-07:00</published><updated>2011-12-06T02:07:07.698-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>"Best guess" parameters in RAID recovery</title><content type='html'>Every once in a while, we get a feature request for our RAID recovery software (&lt;a href="http://www.freeraidrecovery.com/"&gt;http://www.freeraidrecovery.com/&lt;/a&gt;) to implement &lt;em&gt;the ability to interrupt the analysis midway and get a list of possible solutions, sorted by confidence level&lt;/em&gt;.&lt;br /&gt;&lt;br /&gt;There is some strong reservation against this would-be feature.&lt;br /&gt;&lt;br /&gt;Although it looks like a good idea, a very nice thing to have, it has some undesired consequences we cannot allow. The confidence thresholds are there for reason, and we put an effort to ensure they are balanced between faster analysis (lower thresholds) and reliability (higher thresholds). Once we make incomplete solutions accessible, people will start using these solutions on real data. Sooner than later, someone is going to destroy their RAID 5 by reassembling it on the controller using wrong parameters set. In RAID0, this would be no harm (just re-assemble again in correct order), but with RAID 5, incorrect assembly (automatically followed by a rebuild) destroys the array beyond any practical repair. This is similar to consuming unbaked or half-baked food. Sooner or later someone will get poisoned. Determining if RAID configuration is correct is even more difficult than telling baked food from raw meat.&lt;br /&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-8582917052222654355?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/8582917052222654355/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/08/best-guess-parameters-in-raid-recovery.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/8582917052222654355'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/8582917052222654355'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/08/best-guess-parameters-in-raid-recovery.html' title='&quot;Best guess&quot; parameters in RAID recovery'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-1324993578665992881</id><published>2011-08-01T05:33:00.001-07:00</published><updated>2011-12-06T02:07:07.699-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid1'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='mtbf'/><title type='text'>RAID increases failure rate</title><content type='html'>Surprising, isn't it? Actually, RAID does indeed increase failure rate. If you take MTBF, MTBF decreases with more disks. Even if RAID5, mean time between disk failures decreases.&lt;br /&gt;&lt;br /&gt;In a fault-tolerant storage, time between failures (MTBF) does not matter. What matters is &lt;em&gt;time between data loss events. &lt;/em&gt;This is called either mean time to data loss (MTTDL) or mean time between data losses (MTBDL).&lt;br /&gt;&lt;br /&gt;You know you can setup a three-way RAID1 (three mirrored copies instead of two), i.e. the mirror can have more than two disks. So, let's imagine a RAID1 of infinite number of disks. This unit will have an MTBF of zero, because at any given moment one of the infinite number of disks is failing. It will also be continuously rebuilding while still delivering infinite linear read speed. Still, this imaginary device will have zero probability of losing data because of the disk failure, because the infinite number of disks cannot all fail at the same time.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-1324993578665992881?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/1324993578665992881/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/08/raid-increases-failure-rate.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1324993578665992881'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1324993578665992881'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/08/raid-increases-failure-rate.html' title='RAID increases failure rate'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-4952761717417590569</id><published>2011-07-25T05:03:00.000-07:00</published><updated>2011-12-06T02:07:07.701-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid 6'/><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>Test runs</title><content type='html'>Did a RAID 6 test on an Intel SRCSASBB8I controller (LSI 1078 chipset, also used in Dell PERC 6/i), and it was successful save for a couple minor issues. First we got the R-Studio RAID matrix rendered wrong (data blocks are off by one), and also under the hood it looks like the analysis can use some more noise reduction. Still, the output image is OK. This applies to ReclaiMe Free RAID Recovery build 397 at &lt;a href="http://www.freeraidrecovery.com/"&gt;www.freeraidrecovery.com&lt;/a&gt;.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-4952761717417590569?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/4952761717417590569/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/07/test-runs.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4952761717417590569'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4952761717417590569'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/07/test-runs.html' title='Test runs'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-2185119216457386760</id><published>2011-07-20T03:13:00.000-07:00</published><updated>2011-12-06T02:07:07.703-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid1e'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='promise'/><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>RAID 1E analysis delayed</title><content type='html'>If you want some unusual RAID layouts, call Promise. So far, Promise controller has the most bizzare RAID 6 variation we've seen, and also gave us a nasty surprise with RAID 1E.&lt;br /&gt;&lt;br /&gt;Typically, RAID 1E would be laid out as follows&lt;br /&gt;&lt;br /&gt;1 1 2&lt;br /&gt;2 3 3&lt;br /&gt;4 4 5&lt;br /&gt;5 6 6&lt;br /&gt;&lt;br /&gt;(the above is so-called NEAR layout)&lt;br /&gt;&lt;br /&gt;or&lt;br /&gt;1 2 3&lt;br /&gt;4 5 6&lt;br /&gt;7 8 9&lt;br /&gt;3 1 2&lt;br /&gt;6 4 5&lt;br /&gt;9 7 8&lt;br /&gt;&lt;br /&gt;(the above is FAR layout).&lt;br /&gt;&lt;br /&gt;Now Promise combines the best of both worlds to produce a third variation (Promise 1E layout)&lt;br /&gt;&lt;br /&gt;1 2 3&lt;br /&gt;3 1 2&lt;br /&gt;4 5 6&lt;br /&gt;6 4 5&lt;br /&gt;&lt;br /&gt;Looks &lt;em&gt;promising&lt;/em&gt;, doesn't it?&lt;br /&gt;&lt;br /&gt;So, the implementation of RAID 1E recovery capability in ReclaiMe Free RAID Recovery (&lt;a href="http://www.freeraidrecovery.com/"&gt;www.FreeRaidRecovery.com&lt;/a&gt;) is delayed until we figure out how to handle this one.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-2185119216457386760?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/2185119216457386760/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/07/raid-1e-analysis-delayed.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/2185119216457386760'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/2185119216457386760'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/07/raid-1e-analysis-delayed.html' title='RAID 1E analysis delayed'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-7654020740284150535</id><published>2011-07-14T12:23:00.001-07:00</published><updated>2011-12-06T02:07:07.704-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>Detecting RAID0 where it is supposed to be RAID5</title><content type='html'>Recently, a question arose about our RAID recovery software (&lt;a href="http://www.freeraidrecovery.com/"&gt;www.freeraidrecovery.com&lt;/a&gt;), along the lines of "&lt;em&gt;There is a RAID5 array, but I get some results if I try to recover RAID0 as well, what's wrong?&lt;/em&gt;"&lt;br /&gt;&lt;br /&gt;Actually, there is nothing wrong. RAID Recovery requires the array type as outside input, along with the list of member disks. It has no way of determining if the provided array type is correct or not. Therefore, it tries to produce the closest possible layout for a given array type. There are certain cases (mostly involving RAID6) were nothing meaningful can be constructed, and it gives up with the appropriate error message. However, in most cases &lt;em&gt;some&lt;/em&gt; layout will be produced.&lt;br /&gt;&lt;br /&gt;If the original array type is not readily known and it is not possible to infer it from the number of disks and available capacity, the only solution is trial-and-error testing of all possible layouts (of which there are about four fundamentally different, RAID5/5E being practically equal).&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-7654020740284150535?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/7654020740284150535/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/07/detecting-raid0-where-it-is-supposed-to.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/7654020740284150535'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/7654020740284150535'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/07/detecting-raid0-where-it-is-supposed-to.html' title='Detecting RAID0 where it is supposed to be RAID5'/><author><name>Geek II</name><uri>http://www.blogger.com/profile/09972708819808068612</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-5383215446496842153</id><published>2011-07-07T03:56:00.000-07:00</published><updated>2011-07-07T03:56:44.125-07:00</updated><title type='text'>Mapping device identifiers to drive letters in Windows.</title><content type='html'>If you get an error message similar to &lt;em&gt;The file system structure on the disk is corrupt and unusable. Please run the chkdsk utility on the volume \Device\HarddiskVolume1&lt;/em&gt;. there may be trouble matching the identifier &lt;em&gt;\Device\HarddiskVolume1&lt;/em&gt; to a drive letter (is it C:?) or an actual physical device.&lt;br /&gt;&lt;br /&gt;Most of the time, finding the corresponding drive letter (X:) is good enough because you can then look it up in the Disk Management console.&lt;br /&gt;&lt;br /&gt;However, the trouble is that &lt;em&gt;\Device\HarddiskVolume1&lt;/em&gt; is not referenced outside the system event log.&lt;br /&gt;&lt;br /&gt;To find out the list of mappings, download and run the Microsoft Product Support Reports utility from &lt;a href="http://www.microsoft.com/download/en/details.aspx?DisplayLang=en&amp;amp;id=24745"&gt;http://www.microsoft.com/download/en/details.aspx?DisplayLang=en&amp;amp;id=24745&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;When it asks you what to collect, you only need the most basic option, something like "Basic information" or "General information".&amp;nbsp;When done, choose to "Open and view the result" - Windows Explorer will launch and open a folder with a file "Master Report.xml" and subfolder "General".&lt;br /&gt;&lt;br /&gt;Go down to "General" folder and find the file "ComputerName-DOSDevices.TXT". Open it and you get your mapping list at the very top of the file.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-5383215446496842153?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/5383215446496842153/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/07/mapping-device-identifiers-to-drive.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/5383215446496842153'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/5383215446496842153'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/07/mapping-device-identifiers-to-drive.html' title='Mapping device identifiers to drive letters in Windows.'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-3248017152413248210</id><published>2011-06-27T13:33:00.000-07:00</published><updated>2011-06-27T13:33:00.854-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='ext'/><title type='text'>Fragmentation on ext filesystems</title><content type='html'>Just had to increase the hard limit for a number of fragments per file on ext filesystem in our &lt;a href="http://www.reclaime.com/"&gt;ReclaiMe&lt;/a&gt; data recovery software, from 64K to 256K. On NTFS, it is not uncommon to see 20,000 or so fragments per file, but ext just beats the hell out of NTFS as far as fragmentation is concerned.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-3248017152413248210?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/3248017152413248210/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/06/fragmentation-on-ext-filesystems.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3248017152413248210'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3248017152413248210'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/06/fragmentation-on-ext-filesystems.html' title='Fragmentation on ext filesystems'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-4201898119988590913</id><published>2011-06-23T05:57:00.000-07:00</published><updated>2011-12-06T02:07:07.706-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid 10'/><title type='text'>Difference between RAID 1+0 and RAID 0+1</title><content type='html'>RAID 10, RAID 1+0, and RAID 0+1 are all the same thing, except for imlpementation details.&lt;br /&gt;All of these have the same data on disks; you cannot tell RAID 1+0 from RAID 0+1 if you just have the disks. Also, performance considerations and fault tolerance are the same for proper implementations of all of these, regardless of what Wikipedia says.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-4201898119988590913?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/4201898119988590913/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/06/raid-10-vs-raid-01.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4201898119988590913'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4201898119988590913'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/06/raid-10-vs-raid-01.html' title='Difference between RAID 1+0 and RAID 0+1'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-8697916689760345627</id><published>2011-06-13T23:16:00.000-07:00</published><updated>2011-06-13T23:16:00.160-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><title type='text'>What happens if</title><content type='html'>What happens if you swap two disks in RAID array while the system is powered down?&lt;br /&gt;If there were, say,&amp;nbsp;three disks A, B, C, on three channels 1, 2, and 3 respectively.&lt;br /&gt;Change the configuration so that disk A is now on channel 2 and disk B is now on channel 1, then power on. &lt;br /&gt;&lt;br /&gt;Most likely, nothing happens. &lt;br /&gt;&lt;br /&gt;The outcome depends on the method the controller uses to identify the disks. Most if not all modern controllers identify their disks by writing some identification data onto the disks. This way, the controller can tell what the order of disks is by looking at the disks themselves. In earlier days, there were some controllers identifying the disks by ports the disks are connected to. These would be fooled by the swap. Modern controllers&amp;nbsp;(in most cases) carry on just fine.&lt;br /&gt;&lt;br /&gt;I just tested it with Silicon Image Sil 3114, and Promise SureTrak EX4650, just in case. &lt;br /&gt;Also, all modern software RAIDs (Linux md-raid and Windows LDM/Dynamic) will also handle this just fine.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-8697916689760345627?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/8697916689760345627/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/06/what-happens-if.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/8697916689760345627'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/8697916689760345627'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/06/what-happens-if.html' title='What happens if'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-1875144189429384559</id><published>2011-06-05T13:01:00.000-07:00</published><updated>2011-12-06T02:07:07.708-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid6'/><category scheme='http://www.blogger.com/atom/ns#' term='promise'/><title type='text'>Promise and RAID6</title><content type='html'>Promise RAID6 array, 4x WD EARS (Green) drives, NTFS-formatted. Copying files to the array maxes out at&amp;nbsp;2 MB/sec. Quite painful as we already lost about a week trying to create a meaningful test sample.&lt;br /&gt;&lt;br /&gt;For reference, controller is Promise SuperTrak EX4650, flashed to the latest firmware.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-1875144189429384559?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/1875144189429384559/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/06/promise-and-raid6.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1875144189429384559'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1875144189429384559'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/06/promise-and-raid6.html' title='Promise and RAID6'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-2148263073613395389</id><published>2011-05-30T13:12:00.000-07:00</published><updated>2011-12-06T02:01:22.810-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='ext'/><category scheme='http://www.blogger.com/atom/ns#' term='ntfs'/><category scheme='http://www.blogger.com/atom/ns#' term='data recovery'/><title type='text'>Case-sensitive Filenames</title><content type='html'>Linux filenames are case-sensitive, and hence ext filesystems allow files which are only different by upper vs. lower case. Okay, this is to be expected. More interestingly, it is possible to have a directory &lt;em&gt;Test&lt;/em&gt; and a file &lt;em&gt;test&lt;/em&gt; within the sampe parent directory. &lt;br /&gt;&lt;br /&gt;Does not look like we can resolve it gracefully, because under Windows we have to rename one of those. Obviously, it&amp;nbsp;seems better to rename a file. However, this still breaks the program which used a file named &lt;em&gt;test&lt;/em&gt; to contain&amp;nbsp;some catalog of the folder named &lt;em&gt;Test&lt;/em&gt;.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-2148263073613395389?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/2148263073613395389/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/05/case-sensitive-filenames.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/2148263073613395389'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/2148263073613395389'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/05/case-sensitive-filenames.html' title='Case-sensitive Filenames'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-3474056794715046445</id><published>2011-05-25T05:12:00.000-07:00</published><updated>2011-12-06T02:07:07.709-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid6'/><title type='text'>RAID6 progress revisited</title><content type='html'>The automatic RAID6 recovery algorithm currently in the works will most likely require at least N-1 disks for successful recovery. This is because the Reed-Solomon calculation depends on the order of disks, from which the chicken-and-egg problem results. If two disks are missing, the chicken-and-egg problem seemengly cannot be resolved automatically. &lt;br /&gt;&lt;br /&gt;Even as it is with the N-1 requirement, the algorithm looks quite heavy CPU-wise. Looks like the RAID6 recovery implementation would be CPU-bound unlike all other RAID types, which are I/O-bound.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-3474056794715046445?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/3474056794715046445/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/05/raid6-progress-revisited.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3474056794715046445'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3474056794715046445'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/05/raid6-progress-revisited.html' title='RAID6 progress revisited'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-2322158803848914942</id><published>2011-05-17T14:56:00.000-07:00</published><updated>2011-05-17T14:57:05.022-07:00</updated><title type='text'>Uh oh.</title><content type='html'>Current progress on RAID6 is that just now looking at the log files I found the latest&amp;nbsp;48-hour test run botched.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-2322158803848914942?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/2322158803848914942/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/05/uh-oh.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/2322158803848914942'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/2322158803848914942'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/05/uh-oh.html' title='Uh oh.'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-8041186576804073877</id><published>2011-05-09T22:18:00.000-07:00</published><updated>2011-12-06T02:07:07.711-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>x64 data recovery</title><content type='html'>&lt;em&gt;We have a 5TB raid 5 ... I think the MBR got messed up and windows server 2003 no longer is able to view the contents of the virtual disk... &lt;/em&gt;&lt;em&gt;... recovery software ... will fail due to the large amount of files we have, about 64 million files.&lt;/em&gt;&lt;br /&gt;&lt;em&gt;Some raid software will save the recovered files to another disk.. however 5TB is a large amount of data to save and we do not have any disks or other virtual disks that large.&lt;/em&gt;&lt;br /&gt;(from &lt;a href="http://serverfault.com/questions/202068/how-to-recovery-a-5tb-raid-5"&gt;ServerFault&lt;/a&gt;)&lt;br /&gt;&lt;br /&gt;I suppose we can do that 64 million files, should be interesting to test. &lt;br /&gt;&lt;br /&gt;As far as pricing goes, 5 TB swap space is just 3x 2TB WD Caviar Green in RAID 0. At a cost of 4x Caviar Greens you get the same swap space protected by RAID5. At about $60 a pop, the entire lot would cost about $250. The initial cost of purchase is then further offset by putting the temporary drives to use as a backup media.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-8041186576804073877?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/8041186576804073877/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/05/x64-data-recovery.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/8041186576804073877'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/8041186576804073877'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/05/x64-data-recovery.html' title='x64 data recovery'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-7388387501991767754</id><published>2011-05-02T14:55:00.000-07:00</published><updated>2011-05-02T14:55:00.170-07:00</updated><title type='text'>Simple things first</title><content type='html'>What is the first troubleshooting step given the following situation&lt;br /&gt;&lt;br /&gt;&lt;em&gt;A drive&amp;nbsp;disappeared Windows Explorer. In Drive management the  drive are being detected but Volume and Filesystem Type are blank.  Everything  else is&amp;nbsp;OK (Simple, Basic, Healthy disk and Active, Primary  partition). &lt;/em&gt;&lt;br /&gt;&lt;br /&gt;Actually some of the fancy suggestions were flying around, including, but not limited to bad boot secotors, specific controller model issues, SATA 3 issues, and PSU problem.&lt;br /&gt;&lt;br /&gt;Select a white space below to see what was the correct troubleshooting action.&lt;br /&gt;&lt;br /&gt;&lt;span style="color: white;"&gt;In Disk Management, use Change Drive Letters and Paths and assign the drive letter.&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;.&lt;/span&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-7388387501991767754?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/7388387501991767754/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/05/simple-things-first.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/7388387501991767754'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/7388387501991767754'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/05/simple-things-first.html' title='Simple things first'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-4966782408807586677</id><published>2011-04-25T12:15:00.000-07:00</published><updated>2011-04-25T12:15:22.373-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='s.m.a.r.t.'/><title type='text'>Difference between raw data and interpretation</title><content type='html'>One should prefer to look at and to work with raw data, if at all possible.&lt;br /&gt;&lt;br /&gt;We got an example recently when an owner complained on a hard drive because SpeedFan reported &lt;em&gt;Fitness around 25%&lt;/em&gt;. This does not sound good. However, closer examination revealed that SpeedFan conclusion was based on an attribute with a value of 100 (raw value 0). There appeared to be no trouble at all from the raw SMART output. Upon further investigation I found that there are two versions of the firmware on the same model hard drive, one reporting a perfectly good condition&amp;nbsp;as value 253 (raw 0), and the other reporting the same perfectly good condition as value 100 (raw 0). SpeedFan sees both values as originating from a single model, and&amp;nbsp;decides 100 to be a failure indication.&lt;br /&gt;&lt;br /&gt;The more complex interpretation becomes, the more suspectible it is to all sorts of quirks and glitches. Unfrotunately, the more complex interpretation requires more human effort to work from raw data, but that's another matter entirely.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-4966782408807586677?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/4966782408807586677/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/04/difference-between-raw-data-and.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4966782408807586677'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4966782408807586677'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/04/difference-between-raw-data-and.html' title='Difference between raw data and interpretation'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-9210636633866533740</id><published>2011-04-18T09:07:00.000-07:00</published><updated>2011-04-18T09:07:24.621-07:00</updated><title type='text'>Phantom drives in Disk Management</title><content type='html'>Occasionally, you can get a hard drive which is indicated &lt;em&gt;Missing&lt;/em&gt; in Windows Disk Management. The reason for this behavior is simple: the information about the dynamic disks is replicated across all hard drives on a PC. The dynamic disks are assigned to "disk groups", and every disk in a group holds a copy of information about all the other disks in that group. &lt;br /&gt;&lt;br /&gt;This is useful in RAID setups: should a controller or channel fail taking two or more RAID 5 members with it, the array is declared failed and cannot be mounted. Once the controller problem is resolved, the member disks are recognized back and the RAID can be brought online again.&lt;br /&gt;&lt;br /&gt;The MBR-based (basic) disks, if removed, just disappear from the system, because these are not tracked.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-9210636633866533740?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/9210636633866533740/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/04/phantom-drives-in-disk-management.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/9210636633866533740'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/9210636633866533740'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/04/phantom-drives-in-disk-management.html' title='Phantom drives in Disk Management'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-3770027330529735001</id><published>2011-04-07T07:45:00.000-07:00</published><updated>2011-12-06T02:07:07.713-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid1'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><title type='text'>Moving RAID 1 between controllers</title><content type='html'>&lt;em&gt;Is it possible to move a RAID 1 (mirror) set between controllers?&lt;/em&gt;&lt;br /&gt;&lt;br /&gt;In RAID1, two disks are exact duplicates of each other as far as user data is concerned. The RAID controller metadata is probably disk-specific, but that does not practically matter.&lt;br /&gt;&lt;br /&gt;Because the disks are identical, there is no point in moving entire RAID 1. Move&amp;nbsp;one disk, then make a&amp;nbsp;mirror&amp;nbsp;from it.&amp;nbsp;The question should thus be restated as &lt;br /&gt;&lt;br /&gt;&lt;em&gt;Is it possible to use&amp;nbsp;one member disk of RAID 1 with a different controller?&lt;/em&gt;&lt;br /&gt;&lt;br /&gt;The answer depends on a controller in use. With most controllers, you can connect the RAID 1 member disk in whatever way you like and the data would be accessible. There are however some controllers which append their metadata &lt;em&gt;before&lt;/em&gt; the user data on the member disks. With these, the direct migration is not possible. Use either a same model or a compatible controller, or use something like TestDisk or DiskPatch to do a partition recovery and make the filesystem mountable again.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-3770027330529735001?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/3770027330529735001/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/04/moving-raid-1-between-controllers.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3770027330529735001'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3770027330529735001'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/04/moving-raid-1-between-controllers.html' title='Moving RAID 1 between controllers'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-5531996576187701241</id><published>2011-04-03T12:33:00.000-07:00</published><updated>2011-04-07T03:46:23.529-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>Models and feedback</title><content type='html'>The most significant problem we facing now is the lack of feedback. As it was earlier discussed, the RAID recovery software works with models, not actual data. Now the difficulty is to determine how good these models are in real-world application. Relying on people feedback does not look very promising. We'll consider incorporating certain automatic dial-home system sending statistical info we can use to get a clearer view of things. The obvious alternative of buying a sample of all possible RAID controllers and NAS units for tests looks prohibitively expensive, both in terms of money and effort.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-5531996576187701241?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/5531996576187701241/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/04/models-and-feedback.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/5531996576187701241'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/5531996576187701241'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/04/models-and-feedback.html' title='Models and feedback'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-1736365028778616072</id><published>2011-03-31T05:43:00.000-07:00</published><updated>2011-12-06T02:07:07.714-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='delayed parity'/><category scheme='http://www.blogger.com/atom/ns#' term='raid5'/><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>Automatic recovery of RAID 5 with delayed parity</title><content type='html'>&lt;span lang="EN-US" style="mso-ansi-language: EN-US;"&gt;&lt;span style="font-family: inherit;"&gt;Recently we set to develop the algorithm to automatically recover RAID 5 array with &lt;a href="http://www.freeraidrecovery.com/Library/delayed-parity.aspx"&gt;delayed parity&lt;/a&gt;, as implemented by HP SmartArrays. Today we have&amp;nbsp;mostly finalized the work. From this day on (build 306 onwards) &lt;a href="http://www.freeraidrecovery.com/"&gt;ReclaiMe Free RAID Recovery&lt;/a&gt; is capable of recovering such arrays. &lt;o:p&gt;&lt;/o:p&gt;&lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: inherit;"&gt;  &lt;/span&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-1736365028778616072?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/1736365028778616072/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/03/automatic-recovery-of-raid-5-with.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1736365028778616072'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1736365028778616072'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/03/automatic-recovery-of-raid-5-with.html' title='Automatic recovery of RAID 5 with delayed parity'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-6310879609063496703</id><published>2011-03-28T00:20:00.000-07:00</published><updated>2011-12-06T02:07:07.716-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid1'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid5'/><title type='text'>RAID 5 of two disks</title><content type='html'>The common wisdom says that RAID 5 requires a minimum of three disks.&lt;br /&gt;If one thinks of it, it is not true.&lt;br /&gt;You can create a RAID 5 of two disks. With even parity, the array becomes a mirror (RAID 1), and&amp;nbsp;with odd parity (although nobody ever uses that), becomes a RAID&amp;nbsp;4 of two disks.&lt;br /&gt;&lt;br /&gt;And yes, the same applies to a RAID 4 of two disks.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-6310879609063496703?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/6310879609063496703/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/03/raid-5-of-two-disks.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/6310879609063496703'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/6310879609063496703'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/03/raid-5-of-two-disks.html' title='RAID 5 of two disks'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-4671960126264575702</id><published>2011-03-26T05:54:00.000-07:00</published><updated>2011-12-06T02:07:07.718-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid 5'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='delayed parity'/><title type='text'>More modeling issues</title><content type='html'>I recall we discussed that earlier, that our ReclaiMe Free &lt;a href="http://www.freeraidrecovery.com/"&gt;RAID recovery&lt;/a&gt; software (and pretty much any generic RAID recovery software, like Runtime's RAID Reconstructor) does not actually work with RAIDs. It works with &lt;em&gt;models&lt;/em&gt; of RAIDs instead. Data recovery service view on RAID5 more like "disks (by specific vendor), controller (also by specific vendor), and cables". The software sees it like&lt;br /&gt;&lt;br /&gt;&lt;span style="font-family: &amp;quot;Courier New&amp;quot;, Courier, monospace;"&gt;1 2 P&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: &amp;quot;Courier New&amp;quot;, Courier, monospace;"&gt;3 P 4&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: &amp;quot;Courier New&amp;quot;, Courier, monospace;"&gt;P 5 6 &lt;/span&gt;&lt;br /&gt;&lt;br /&gt;and pretty much nothing else.&lt;br /&gt;&lt;br /&gt;The problem arises when the actual data does not match the model used in software. The synchronous array (below) cannot be described in terms of the asynchronous model (above).&lt;br /&gt;&lt;br /&gt;&lt;span style="font-family: &amp;quot;Courier New&amp;quot;, Courier, monospace;"&gt;1 2 P&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: &amp;quot;Courier New&amp;quot;, Courier, monospace;"&gt;4 P 3&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: &amp;quot;Courier New&amp;quot;, Courier, monospace;"&gt;P 5 6&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;So the software has to acount for all possible models of the RAID 5, of which there are quite a number.&lt;br /&gt;&lt;br /&gt;We're currently working on automatic analysis of the so-called &lt;em&gt;delayed parity&lt;/em&gt; arrays, used in HP SmartArray controllers. This subtype of RAID5 does effectively have two distinct stripe sizes, one for data and the other (larger) one for parity, with the array looking like&lt;br /&gt;&lt;br /&gt;&lt;span style="font-family: &amp;quot;Courier New&amp;quot;, Courier, monospace;"&gt;1 2 P&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: &amp;quot;Courier New&amp;quot;, Courier, monospace;"&gt;3 4 P&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: &amp;quot;Courier New&amp;quot;, Courier, monospace;"&gt;5 P 6&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: &amp;quot;Courier New&amp;quot;, Courier, monospace;"&gt;7 P 8&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;Would be nice to account for that, because I'm not aware of anything capable of recovering this type of array automatically.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-4671960126264575702?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/4671960126264575702/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/03/more-modeling-issues.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4671960126264575702'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4671960126264575702'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/03/more-modeling-issues.html' title='More modeling issues'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-229781346570318248</id><published>2011-03-24T06:33:00.000-07:00</published><updated>2011-12-06T02:01:22.812-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='overwritten data'/><category scheme='http://www.blogger.com/atom/ns#' term='2011'/><category scheme='http://www.blogger.com/atom/ns#' term='data recovery'/><title type='text'>Even in 2011..</title><content type='html'>... people &lt;a href="http://forums.anandtech.com/showpost.php?p=31402644&amp;amp;postcount=4"&gt;still believe&lt;/a&gt; you can get an electron microscope and &lt;a href="http://www.reclaime.com/library/recover-overwritten-data.aspx"&gt;recover overwritten data&lt;/a&gt;.&lt;br /&gt;&lt;ol&gt;&lt;li&gt;It is not an electron microscope, it should be an MFM, Magnetic Force Microscope. Electron beams are no good against the hard drive platter. Probably no harm either, just useless.&lt;/li&gt;&lt;li&gt;Even with MFM, no recovery of overwritten data on a modern hard drive is possible, because of various aspects of applied physics.&lt;/li&gt;&lt;/ol&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-229781346570318248?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/229781346570318248/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/03/even-in-2011.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/229781346570318248'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/229781346570318248'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/03/even-in-2011.html' title='Even in 2011..'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-4456470682757006382</id><published>2011-03-20T15:10:00.000-07:00</published><updated>2011-03-20T15:10:00.153-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='write hole'/><category scheme='http://www.blogger.com/atom/ns#' term='ntfs'/><category scheme='http://www.blogger.com/atom/ns#' term='fat'/><title type='text'>"Write hole" in filesystems</title><content type='html'>Unsurprisingly, filesystems are also suspectible to damage when the power failure occurs during write. The most simple example is the file being deleted. If the clusters are deallocated (marked free) first, and then a power failure occurs before the file record is removed, then we got a file having its data stored in free clusters on the disk. If a new file is subsequently created and uses the same cluster, the &lt;em&gt;cross-link&lt;/em&gt; siutation occurs, potentialy leading to data loss.&lt;br /&gt;&lt;br /&gt;There are several ways around this problem.&lt;br /&gt;&lt;br /&gt;&lt;em&gt;Careful write ordering&lt;/em&gt;. The sequence of operations can be ordered in such a way that the damage due to the incomplete write is predictable, easy to repair, and confined to a single file. This is the cheapest option. It does not require any change to the on-disk structures if you want to implement it on the existing filesystem.&lt;br /&gt;&lt;br /&gt;&lt;em&gt;Multisector transfer protections&lt;/em&gt; (used e.g. in NTFS). If several sectors are to be written out as a group, each sector in a group stores a specific signature. When the group is later read, the driver verifies signatures in all sectors of the group. Should the signatures not match, the data is rejected as corrupt. This only allows for error detection, but not correction.&lt;br /&gt;&lt;br /&gt;&lt;em&gt;Intention logging&lt;/em&gt; is the most complex option, similar to a database transaction logging. The filesystem driver ensures so called &lt;em&gt;atomicity&lt;/em&gt; of certain operations, meaning that the operation either completes entirely, or no change occurs at all. This option is implemented in most modern high-capacity filesystems, most widespread being NTFS and ext3/ext4.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-4456470682757006382?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/4456470682757006382/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/03/write-hole-in-filesystems.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4456470682757006382'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4456470682757006382'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/03/write-hole-in-filesystems.html' title='&quot;Write hole&quot; in filesystems'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-5371621537521838978</id><published>2011-03-16T15:10:00.000-07:00</published><updated>2011-12-06T02:07:07.719-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid1'/><category scheme='http://www.blogger.com/atom/ns#' term='write hole'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid5'/><title type='text'>Write hole in RAID 1</title><content type='html'>Actually, RAID 1 has the same &lt;span id="goog_1752992498"&gt;&lt;a href="http://www.raid-recovery-guide.com/raid5-write-hole.aspx"&gt;&lt;em&gt;write hole&lt;/em&gt;&lt;/a&gt;&amp;nbsp;problem as &lt;span id="goog_1752992497"&gt;&lt;/span&gt;RAID 5 does. Should the power fail after one disk is updated, but the other is not yet updated, and then the first disk fails, there will be data corruption. &lt;/span&gt;&lt;br /&gt;&lt;br /&gt;&lt;span&gt;As usual, scheduled synchronizations of the array reduce probability of this effect causing any practical trouble.&lt;/span&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-5371621537521838978?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/5371621537521838978/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/03/write-hole-in-raid-1.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/5371621537521838978'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/5371621537521838978'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/03/write-hole-in-raid-1.html' title='Write hole in RAID 1'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-6154561829301823161</id><published>2011-03-06T22:00:00.000-08:00</published><updated>2011-03-06T22:00:56.312-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>Activities</title><content type='html'>Improved memory usage in ReclaiMe Free RAID Recovery (&lt;a href="http://www.freeraidrecovery.com/"&gt;www.FreeRaidRecovery.com&lt;/a&gt;), by the factor of ten. The update is not yet live, but will be out shortly, probably no later than tomorrow. Surprisingly, there was not at all that much loss of speed.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-6154561829301823161?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/6154561829301823161/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/03/activities.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/6154561829301823161'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/6154561829301823161'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/03/activities.html' title='Activities'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-8084627818608954367</id><published>2011-03-05T23:55:00.000-08:00</published><updated>2011-03-05T23:55:01.039-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid1e'/><category scheme='http://www.blogger.com/atom/ns#' term='raid5ee'/><category scheme='http://www.blogger.com/atom/ns#' term='raid6'/><category scheme='http://www.blogger.com/atom/ns#' term='raid 10'/><category scheme='http://www.blogger.com/atom/ns#' term='raid5e'/><category scheme='http://www.blogger.com/atom/ns#' term='raid5'/><category scheme='http://www.blogger.com/atom/ns#' term='raid01'/><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>Exotic RAID types</title><content type='html'>With a &lt;a href="http://www.freeraidrecovery.com/"&gt;RAID recovery&lt;/a&gt;, certain exotic RAID types can be recovered using the same basic algorithms, because these exotic RAID types can be reduced to one of the three basic types (RAID0, RAID1, and RAID5). &lt;br /&gt;The list goes like this:&lt;br /&gt;&lt;ul&gt;&lt;li&gt;RAID 1+0 or 0+1 can either be reduced to RAID 0 by removing mirrors (&lt;em&gt;near&lt;/em&gt; layout), or can be recovered as a RAID 0 straight away (&lt;em&gt;far&lt;/em&gt; layout). &lt;br /&gt;&lt;/li&gt;&lt;li&gt;RAID 5E or RAID 6E can be recovered as a RAID 5 or RAID 6 respectively, because all the extra data is at the end of the array.&lt;br /&gt;&lt;/li&gt;&lt;li&gt;RAID 5EE can be recovered as RAID 6 with one of the sets of parity corrupt. &lt;br /&gt;&lt;/li&gt;&lt;li&gt;RAID 4 is actually a variation of RAID 5 where parity does not change position across rows.&lt;br /&gt;&lt;/li&gt;&lt;/ul&gt;The array types requiring special processing are RAID 1+0 using &lt;em&gt;offset&lt;/em&gt; layout and RAID 1E.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-8084627818608954367?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/8084627818608954367/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/03/exotic-raid-types.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/8084627818608954367'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/8084627818608954367'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/03/exotic-raid-types.html' title='Exotic RAID types'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-259686244803957543</id><published>2011-03-02T23:23:00.000-08:00</published><updated>2011-12-06T02:01:22.814-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='data recovery'/><title type='text'>Data recovery - probably cheaper than backup, ...</title><content type='html'>... but&amp;nbsp;less than 100% reliable, though.&lt;br /&gt;&lt;br /&gt;See this - &lt;a href="http://www.technibble.com/forums/showthread.php?t=24345"&gt;http://www.technibble.com/forums/showthread.php?t=24345&lt;/a&gt;.&lt;br /&gt;Given that you can literally burn the laptop in fire, and still recover all the significant data, why would anyone bother with backups at all?&lt;br /&gt;&lt;br /&gt;Disclaimer: just kidding&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-259686244803957543?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/259686244803957543/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/03/data-recovery-probably-cheaper-than.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/259686244803957543'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/259686244803957543'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/03/data-recovery-probably-cheaper-than.html' title='Data recovery - probably cheaper than backup, ...'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-1651403799693886656</id><published>2011-02-27T03:54:00.000-08:00</published><updated>2011-02-27T03:54:00.329-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='hot spare'/><category scheme='http://www.blogger.com/atom/ns#' term='hotswap'/><title type='text'>Hotspare vs. Hotswap</title><content type='html'>&lt;em&gt;What is the difference between &lt;strong&gt;hotspare&lt;/strong&gt; and &lt;strong&gt;hotswap&lt;/strong&gt;?&lt;/em&gt;&lt;br /&gt;&lt;br /&gt;&lt;strong&gt;Hotswap&lt;/strong&gt; is the capability to replace a failed part with a spare without having to shut down the system. To resolve a problem, somebody still has to bring the spare part and do the actual work replacing it.&lt;br /&gt;&lt;br /&gt;&lt;strong&gt;Hot spare&lt;/strong&gt; is the spare part that is placed into the system at build time, in anticipation that something will eventually fail. The hot spare ties the part which could be otherwise used, but instead sits idly waiting for something to fail. On the bright side, when something fails, there is no need for a human intervention because the spare part is already there and ready.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-1651403799693886656?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/1651403799693886656/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/02/hotspare-vs-hotswap.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1651403799693886656'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1651403799693886656'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/02/hotspare-vs-hotswap.html' title='Hotspare vs. Hotswap'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-616209281963745498</id><published>2011-02-24T14:16:00.000-08:00</published><updated>2011-02-24T14:16:00.509-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>On models in data recovery</title><content type='html'>The data recovery (be it filesystem parser or &lt;a href="http://www.freeraidrecovery.com/"&gt;RAID recovery&lt;/a&gt;)&amp;nbsp;software does not work based on the actual data alone. The equally important ingridient is the model of the correct state of the device being recovered.&lt;br /&gt;&lt;br /&gt;Take a RAID0 for example. The model of the RAID0 would include stripe size, disk order, and first disk. There are often some less than obvious requirements, like "a block size must be a power of two". This works just fine until someone decides to implement a software RAID with 3 sectors per block. The recovery software then fails because its internal model of a "correct" RAID does not match the reality any longer. &lt;br /&gt;&lt;br /&gt;Similarly with RAID5, the minimum practically useful model includes a notion of a possibly missing disk, to be reconstructed from the partity data. If you throw in a blank hot spare, the recovery fails because you just went outside of the design envelope - the model does not account for a possibility of a blank drive being included into the disk set for recovery.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-616209281963745498?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/616209281963745498/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/02/on-models-in-data-recovery.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/616209281963745498'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/616209281963745498'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/02/on-models-in-data-recovery.html' title='On models in data recovery'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-8355080184372123651</id><published>2011-02-21T15:30:00.000-08:00</published><updated>2011-02-21T15:30:00.941-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='seagate'/><category scheme='http://www.blogger.com/atom/ns#' term='s.m.a.r.t.'/><title type='text'>Seagate and Raw Read Error Rate</title><content type='html'>Seagate drives are known to report exacerbated S.M.A.R.T. data for Raw Read Error Rate. This is well-known, normal, and should just be&amp;nbsp;ignored.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-8355080184372123651?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/8355080184372123651/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/02/seagate-and-raw-read-error-rate.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/8355080184372123651'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/8355080184372123651'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/02/seagate-and-raw-read-error-rate.html' title='Seagate and Raw Read Error Rate'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-4996658689941714921</id><published>2011-02-17T12:13:00.000-08:00</published><updated>2011-12-06T02:07:07.721-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='disk image'/><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>Images of disks in RAID recovery</title><content type='html'>In &lt;a href="http://www.freeraidrecovery.com/"&gt;RAID recovery&lt;/a&gt;, if there is a controller failure, or a known software failure, there is no need to create the images of the RAID member disks. In single-disk operations, it is often considered a good practice to always make an image a disk. With RAID, this may be not so easy, considering sheer size of the modern arrays.&lt;br /&gt;&lt;br /&gt;Actually, if there is no reason to suspect the physical damage of the RAID member disks, the imaging may be skipped altougether or put off until the decision is made to modify the data on the disks (possibly to revive the controller metadata).&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-4996658689941714921?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/4996658689941714921/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/02/images-of-disks-in-raid-recovery.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4996658689941714921'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4996658689941714921'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/02/images-of-disks-in-raid-recovery.html' title='Images of disks in RAID recovery'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-7810556958260159862</id><published>2011-02-14T23:16:00.000-08:00</published><updated>2011-02-14T23:16:00.379-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='SSD'/><title type='text'>Ratings instead of numbers</title><content type='html'>Circa 1998, AMD used a "Performance Rating" or "Pentium Rating" (PR) to indicate their CPU's performance by comparing it to then-current Intel&amp;nbsp;Pentium. That was mostly because AMD could not deliver a CPU operating at frequencies matching these of Intel's, so they opted to move frequencies out of sight. Then, comparison shopping became little messy. And btw that did not help AMD much.&lt;br /&gt;&lt;br /&gt;Given &lt;a href="http://forums.anandtech.com/showthread.php?p=31033000"&gt;this thread on AnandTech&lt;/a&gt;, looks like we might get a similar issue with SSD benchmarks. Not that I &lt;br /&gt;particularly care about SSD benchmarks.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-7810556958260159862?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/7810556958260159862/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/02/ratings-instead-of-numbers.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/7810556958260159862'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/7810556958260159862'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/02/ratings-instead-of-numbers.html' title='Ratings instead of numbers'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-1815813002604325789</id><published>2011-02-11T15:31:00.000-08:00</published><updated>2011-12-06T02:07:07.723-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>Modern RAID recovery capabilities</title><content type='html'>Speaking of automatic RAID recovery software, there is still much to do.&lt;br /&gt;&lt;br /&gt;In ReclaiMe Free &lt;a href="http://www.freeraidrecovery.com/"&gt;RAID Recovery&lt;/a&gt;, we have the basics and classics pretty well covered, that includes RAID0, RAID5, and RAID 0+1/1+0 by reduction to RAID 0. There are a couple of other vendors out there who provide similar capabilities, so it is a done deal.&lt;br /&gt;&lt;br /&gt;There are other RAID levels, in which neither we nor other vendors offer anything automatic. We could probably do something of E-series layouts (RAID 1E or 5E/EE), but we don't see a real demand for it. Automatic RAID 6 recovery looks more interesting and maybe we'd even give it a shot someday.&lt;br /&gt;&lt;br /&gt;Also, all the current automatic RAID recovery tools rely on the RAID members having the same offset across all the physical disks. This works fine for hardware RAIDs, but can be a hinderance if you need a software RAID recovery. This requirement is not likely to go away in a near future because the computational power requirements to find offsets for array members exceed the available capabilities. Especially if we're talking something practical like 6x 2TB hard drives in the array.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-1815813002604325789?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/1815813002604325789/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/02/modern-raid-recovery-capabilities.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1815813002604325789'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1815813002604325789'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/02/modern-raid-recovery-capabilities.html' title='Modern RAID recovery capabilities'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-5662443557502847496</id><published>2011-02-08T03:18:00.000-08:00</published><updated>2011-12-06T02:01:22.815-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='ntfs'/><category scheme='http://www.blogger.com/atom/ns#' term='trim'/><category scheme='http://www.blogger.com/atom/ns#' term='SSD'/><category scheme='http://www.blogger.com/atom/ns#' term='data recovery'/><title type='text'>SSD, TRIM, and NTFS</title><content type='html'>Reading the &lt;a href="http://techgage.com/article/too_trim_when_ssd_data_recovery_is_impossible/4"&gt;article on NTCompatible&lt;/a&gt; as they test &lt;a href="http://www.reclaime.com/"&gt;data recovery software&lt;/a&gt; and fail to recover data from TRIM-enabled SSD (which is pretty much the expected behavior), I see they're a little bit puzzled because some data would still remain even on a TRIM-enabled SSD. &lt;br /&gt;&lt;br /&gt;&lt;em&gt;Interestingly, some traces to specific data remained, and that's one oddity I don't quite understand.&lt;/em&gt;&lt;br /&gt;&lt;br /&gt;The answer is actually pertty simple - these were NTFS resident files. On NTFS, when the file is deleted, its MFT record is marked "free, available for reuse", but never actually relinquished back to the free space. Because NTFS uses MFT entry numbers internally to address a parent-child relationships. Removing one entry would require an entire volume to be reunmbered, which is cost-prohibitve.&lt;br /&gt;&lt;br /&gt;So, the data outside MFT is zero-filled immediately once TRIM command is issued. The MFT entires however remain unchanged. This explains they were able to get file names and correct file sizes, but the data was all zeros. &lt;br /&gt;&lt;br /&gt;Now there is one special case called &lt;em&gt;resident file&lt;/em&gt;. If a file is small enough so that the file name, attributes, and data all fit into 1024-byte MFT record, the data is stored within the MFT record. This saves little bit of disk space, and, more importantly, saves one additional seek to get the data on the rotational hard drive.&lt;br /&gt;&lt;br /&gt;Since the MFT entires are not relinquished into free space, and for a resident file a file data is stored within its MFT entry, it is possibe to recover a resident file even on a TRIM-enabled SSD. However, this is of little practical applicability becase only files smaller than approximately 800 bytes can become resident.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-5662443557502847496?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/5662443557502847496/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/02/ssd-trim-and-ntfs.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/5662443557502847496'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/5662443557502847496'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/02/ssd-trim-and-ntfs.html' title='SSD, TRIM, and NTFS'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-191721200698668821</id><published>2011-02-05T02:54:00.000-08:00</published><updated>2011-02-05T02:54:00.649-08:00</updated><title type='text'>Computer Stress Syndrome</title><content type='html'>Came across a discussion of the Computer Stress Syndrome on TechNibble, that was just hilarious:&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.technibble.com/forums/showthread.php?p=178482#post178482"&gt;&lt;em&gt;are they ever going to do &lt;strong&gt;a test study on end user unrealistic expectations causing computer technician stress syndrome&lt;/strong&gt;??&lt;/em&gt; &lt;/a&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-191721200698668821?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/191721200698668821/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/02/computer-stress-syndrome.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/191721200698668821'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/191721200698668821'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/02/computer-stress-syndrome.html' title='Computer Stress Syndrome'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-8475458857075826860</id><published>2011-02-03T05:08:00.000-08:00</published><updated>2011-02-03T05:08:09.912-08:00</updated><title type='text'>Intel's new chipset</title><content type='html'>Intel reports there is a flaw in SATA controller on the SandyBridge chipset, &lt;em&gt;causing functionality to degrade over time&lt;/em&gt;. I suppose &lt;em&gt;functionality&lt;/em&gt; goes as in &lt;em&gt;functionality to store data&lt;/em&gt;, actually. They say &lt;br /&gt;&lt;ul&gt;&lt;li&gt;the flaw only affects 3 Gbps ports (SATA II), while 6 Gbps (SATA III) ports are OK, but I'd wait for further confirmation.&lt;/li&gt;&lt;li&gt;the revised chipset will hit the market April, 2011. &lt;/li&gt;&lt;/ul&gt;So we got quite a number of data-loss time bombs somewhere, and the number still grows.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-8475458857075826860?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/8475458857075826860/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/02/intels-new-chipset.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/8475458857075826860'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/8475458857075826860'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/02/intels-new-chipset.html' title='Intel&apos;s new chipset'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-2306755287702614615</id><published>2011-02-02T05:07:00.000-08:00</published><updated>2011-02-02T05:07:00.139-08:00</updated><title type='text'>Even in 2011..</title><content type='html'>some people are still concerned about &lt;em&gt;DoubleSpace&lt;/em&gt; and &lt;em&gt;Stacker&lt;/em&gt;.&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;div class="separator" style="clear: both; text-align: center;"&gt;&lt;a href="http://2.bp.blogspot.com/_lTyLE5Ssczg/TRH5FiOLjQI/AAAAAAAAACk/vxHBZsFCVDo/s1600/mfm-doublespace-stacker.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"&gt;&lt;img border="0" height="89" n4="true" src="http://2.bp.blogspot.com/_lTyLE5Ssczg/TRH5FiOLjQI/AAAAAAAAACk/vxHBZsFCVDo/s320/mfm-doublespace-stacker.gif" width="320" /&gt;&lt;/a&gt;&lt;/div&gt;&lt;br /&gt;Do you still remember using MS DOS in production?&lt;br /&gt;&lt;br /&gt;Bonus item: &lt;em&gt;MFM&lt;/em&gt; hard drive interface in the same screenshot.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-2306755287702614615?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/2306755287702614615/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/02/even-in-2011.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/2306755287702614615'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/2306755287702614615'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/02/even-in-2011.html' title='Even in 2011..'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><media:thumbnail xmlns:media='http://search.yahoo.com/mrss/' url='http://2.bp.blogspot.com/_lTyLE5Ssczg/TRH5FiOLjQI/AAAAAAAAACk/vxHBZsFCVDo/s72-c/mfm-doublespace-stacker.gif' height='72' width='72'/><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-3588594064308704015</id><published>2011-01-30T09:49:00.000-08:00</published><updated>2011-01-30T09:49:28.061-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='ubuntu'/><title type='text'>How to enable root login in Ubuntu</title><content type='html'>Open terminal, type &lt;strong&gt;sudo passwd root&lt;/strong&gt;, then enter the current password, then twice a new root password.&lt;br /&gt;System reports back &lt;em&gt;password updated successfully&lt;/em&gt;. Good.&lt;br /&gt;&lt;br /&gt;Unfortunately, I did not figure out autologin.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-3588594064308704015?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/3588594064308704015/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/how-to-enable-root-login-in-ubuntu.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3588594064308704015'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3588594064308704015'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/how-to-enable-root-login-in-ubuntu.html' title='How to enable root login in Ubuntu'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-3581612151260894564</id><published>2011-01-28T23:28:00.000-08:00</published><updated>2011-01-28T23:28:00.255-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='hfs'/><category scheme='http://www.blogger.com/atom/ns#' term='alignment'/><category scheme='http://www.blogger.com/atom/ns#' term='SSD'/><category scheme='http://www.blogger.com/atom/ns#' term='fat'/><title type='text'>Partition alignment</title><content type='html'>You can only align a partition (on a hardware block boundary) if a cluster size is an integral multiple of your hardware block size. This means you cannot align a HFS partition, because it would happily use 19 or 27 sectors per cluster. Most other filesystems would use a cluster size that is a power of two, matching the hardware block size.&lt;br /&gt;&lt;br /&gt;Another thing is that if&amp;nbsp;the boot sector and&amp;nbsp;the data area use different alignments, it is the data area that you align. On FAT, there may be 1025 or whatever odd number of sectors between the boot sector and the first cluster of actual data. If you align the FAT partition's boot sector, the data would then be offset by one sector.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-3581612151260894564?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/3581612151260894564/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/partition-alignment.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3581612151260894564'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3581612151260894564'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/partition-alignment.html' title='Partition alignment'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-4234223872030898203</id><published>2011-01-25T03:19:00.000-08:00</published><updated>2011-01-25T03:19:00.838-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='cluster size'/><category scheme='http://www.blogger.com/atom/ns#' term='tailpacking'/><title type='text'>Multiple cluster sizes on a single volume?</title><content type='html'>&lt;span style="font-family: Trebuchet MS;"&gt;&lt;a href="http://www.halfbakery.com/idea/multiple_20cluster_20size_20drive"&gt;&lt;em&gt;it's been 10 years and I've yet to hear of a filesystem that uses multiple cluster sizes on the same volume. Otoh, I don't see what benefit that could possibly give.&lt;/em&gt;&lt;/a&gt;&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;&lt;span style="font-family: Trebuchet MS;"&gt;With multiple cluster sizes on&amp;nbsp;the same volume, you can do &lt;strong&gt;tailpacking&lt;/strong&gt;. &lt;/span&gt;&lt;br /&gt;&lt;br /&gt;&lt;span style="font-family: Trebuchet MS;"&gt;Ext-series filesystems had a different block and fragment size, but never actually used it. Quite possible that was removed in ext4, although I'm not really sure.&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;&lt;span style="font-family: Trebuchet MS;"&gt;OLE Structured Storage actually uses two different block sizes (small block and big block).&lt;/span&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-4234223872030898203?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/4234223872030898203/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/multiple-cluster-sizes-on-single-volume.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4234223872030898203'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4234223872030898203'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/multiple-cluster-sizes-on-single-volume.html' title='Multiple cluster sizes on a single volume?'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-1248986277914015961</id><published>2011-01-22T11:59:00.001-08:00</published><updated>2011-01-22T11:59:15.821-08:00</updated><title type='text'>The coincidences</title><content type='html'>The Skype website was slow to load today. Went to tweet about that only to find that "Twitter is over capacity". Kind of ironic.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-1248986277914015961?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/1248986277914015961/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/coincidences.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1248986277914015961'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1248986277914015961'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/coincidences.html' title='The coincidences'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-8475296415767471027</id><published>2011-01-20T02:40:00.000-08:00</published><updated>2011-01-20T02:40:00.194-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid5'/><title type='text'>Is RAID5 faster?</title><content type='html'>&lt;em&gt;Is RAID5 faster than a single disk?&lt;/em&gt;&lt;br /&gt;&lt;br /&gt;On reads, yes.&lt;br /&gt;On writes, sometimes.&lt;br /&gt;On random writes, no.&lt;br /&gt;&lt;br /&gt;Check the &lt;a href="http://www.raid-calculator.com/"&gt;RAID Calculator&lt;/a&gt; if you need similar data on RAID 0 or RAID 6.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-8475296415767471027?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/8475296415767471027/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/is-raid5-faster.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/8475296415767471027'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/8475296415767471027'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/is-raid5-faster.html' title='Is RAID5 faster?'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-4293347132353253487</id><published>2011-01-17T14:52:00.000-08:00</published><updated>2011-01-17T14:52:00.628-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='boot sector'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='mbr'/><title type='text'>MBR/Boot in RAID</title><content type='html'>&lt;em&gt;Which drive in a RAID stripe contains the MBR?&lt;/em&gt;&lt;br /&gt;&lt;em&gt;&lt;/em&gt;&lt;br /&gt;The first drive.&lt;br /&gt;&lt;br /&gt;Bonus:&lt;br /&gt;&lt;br /&gt;&lt;em&gt;Which drive in a RAID stripe contains the boot sector?&lt;/em&gt;&lt;br /&gt;&lt;em&gt;&lt;/em&gt;&lt;br /&gt;On a hardware RAID, no specific location.&lt;br /&gt;On a software RAID, the first drive.&lt;br /&gt;&lt;br /&gt;RAID5:&lt;br /&gt;In RAID5, if there are mostly zeros at the start of the volume, the parity block may contain an exact duplicate of the MBR/boot sector.&lt;br /&gt;&lt;br /&gt;For other parameters, check &lt;a href="http://www.freeraidrecovery.com//library/raid0-recovery.aspx"&gt;RAID 0 Recovery&lt;/a&gt; primer.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-4293347132353253487?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/4293347132353253487/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/mbrboot-in-raid.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4293347132353253487'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4293347132353253487'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/mbrboot-in-raid.html' title='MBR/Boot in RAID'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-6802085091008067894</id><published>2011-01-14T03:39:00.000-08:00</published><updated>2011-01-14T03:39:00.311-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><title type='text'>RAID is for servers only?</title><content type='html'>Not true.&lt;br /&gt;&lt;br /&gt;As long as you do backups properly, you can use RAID on workstations (HTPCs, DIY servers, whatever) as you see fit. Depending on what RAID type you choose, it gives you a performance boost, more capacity, or some added convenience, or all of this at once.&lt;br /&gt;&lt;br /&gt;If you do not do backups properly, it does not really matter if you use RAID or not. Someday, you would evaluate our &lt;a href="http://www.reclaime.com/"&gt;data recovery software&lt;/a&gt;. While it is rather good, admittedly not all cases of data loss are recoverable.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-6802085091008067894?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/6802085091008067894/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/raid-is-for-servers-only.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/6802085091008067894'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/6802085091008067894'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/raid-is-for-servers-only.html' title='RAID is for servers only?'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-3149265383411357087</id><published>2011-01-11T03:34:00.000-08:00</published><updated>2011-01-11T03:34:00.846-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid1'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><title type='text'>Mixing disks in RAID</title><content type='html'>&lt;em&gt;Can I use one 10,000 RPM and one 7200 PRM hard drives in RAID 1?&lt;/em&gt;&lt;br /&gt;&lt;br /&gt;Yes. In RAID1, that would not cause any noticeable issues.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-3149265383411357087?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/3149265383411357087/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/mixing-disks-in-raid.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3149265383411357087'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3149265383411357087'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/mixing-disks-in-raid.html' title='Mixing disks in RAID'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-7378828272771407530</id><published>2011-01-08T05:44:00.000-08:00</published><updated>2011-01-08T05:44:00.747-08:00</updated><title type='text'>Incompatibilites</title><content type='html'>Got a DVD burner under Vista that would eject the drive if the card reader with a memory card in it is plugged into the USB port. The burner is internal (SATA). The disc would not stay in (gets ejected after about five seconds) until the card reader is disconnected. Go figure.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-7378828272771407530?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/7378828272771407530/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/incompatibilites.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/7378828272771407530'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/7378828272771407530'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/incompatibilites.html' title='Incompatibilites'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-1494861758056039207</id><published>2011-01-07T03:53:00.000-08:00</published><updated>2011-01-07T03:53:00.933-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='format'/><category scheme='http://www.blogger.com/atom/ns#' term='ntfs'/><category scheme='http://www.blogger.com/atom/ns#' term='zfs'/><category scheme='http://www.blogger.com/atom/ns#' term='nas'/><category scheme='http://www.blogger.com/atom/ns#' term='data recovery'/><title type='text'>What they don’t tell you about all the new technology</title><content type='html'>Some new technologies have side effects which decrease data redundancy. Such technologies are:&lt;br /&gt;&lt;ul&gt;&lt;li&gt;NTFS compression&lt;/li&gt;&lt;li&gt;Windows Vista/7 vs. Windows NT/2000/XP complete format&lt;/li&gt;&lt;li&gt;TRIM on SSDs&lt;/li&gt;&lt;li&gt;ZFS deduplication&lt;/li&gt;&lt;/ul&gt;Initially, the effect of decreasing redundancy is unnoticeable, but once the technology becomes popular, the unintended consequences appear.&lt;br /&gt;&lt;ul&gt;&lt;li&gt;Volume-level NTFS compression never became widespread among home users.&lt;/li&gt;&lt;li&gt;As Windows Vista and then Windows 7 become widespread, the number of cases when data is lost irreversibly due to reinstallation increased. You can recover some data after XP reinstallation, but not after Vista/7 reinstallation with a complete format.&lt;/li&gt;&lt;li&gt;SSDs with TRIM are not widespread enough (yet) to notice that &lt;a href="http://www.reclaime.com/"&gt;data recovery software&lt;/a&gt; does not properly work with them. &lt;/li&gt;&lt;li&gt;As for ZFS-based NASes, then on the one hand they are not widespread among the home users, on the other hand - even the first installations did not yet reach the end of their service life. &lt;/li&gt;&lt;/ul&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-1494861758056039207?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/1494861758056039207/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/what-they-dont-tell-you-about-all-new.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1494861758056039207'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1494861758056039207'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/what-they-dont-tell-you-about-all-new.html' title='What they don’t tell you about all the new technology'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-4456523499502463156</id><published>2011-01-03T03:50:00.000-08:00</published><updated>2011-12-06T02:01:22.817-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='ntfs'/><category scheme='http://www.blogger.com/atom/ns#' term='zfs'/><category scheme='http://www.blogger.com/atom/ns#' term='data recovery'/><title type='text'>Deduplication</title><content type='html'>Data recovery software is based on the filesystem and user data redundancy.&lt;br /&gt;&lt;br /&gt;In case of significant filesystem damage user data redundancy is often required for &lt;a href="http://www.reclaime.com/"&gt;data recovery software&lt;/a&gt;. Elimination of user data redundancy using a compression (as in NTFS) or a deduplication (as in ZFS) complicates automatic data recovery.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-4456523499502463156?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/4456523499502463156/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/deduplication.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4456523499502463156'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4456523499502463156'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2011/01/deduplication.html' title='Deduplication'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-5925904991378034156</id><published>2010-12-31T04:52:00.000-08:00</published><updated>2010-12-31T04:52:00.287-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid5'/><title type='text'>RAID5 write hole</title><content type='html'>RAID 5 "write hole" happens if a power failure occurs during the write, causing an incomplete parity block update.&lt;br /&gt;&lt;br /&gt;The more detailed analysis of a "write hole" and its consequences is available at the &lt;a href="http://www.raid-recovery-guide.com/raid5-write-hole.aspx"&gt;RAID Recovery Guide&lt;/a&gt;.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-5925904991378034156?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/5925904991378034156/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/12/raid5-write-hole.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/5925904991378034156'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/5925904991378034156'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/12/raid5-write-hole.html' title='RAID5 write hole'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-3445360908597630001</id><published>2010-12-27T03:05:00.000-08:00</published><updated>2010-12-27T03:05:00.408-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='fat32'/><title type='text'>Large disks and FAT32.</title><content type='html'>Microsoft Windows starting with Windows XP doesn't allow you to format a partition larger than 32 GB to FAT32. Note that if such partition has been created earlier, you can use the partition normally.&lt;br /&gt;&lt;br /&gt;However, there are situations when you need to format a large disk to FAT32, for example to use the disk in a standalone player. To do this, you can use the program which is called FAT32format (&lt;a href="http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm"&gt;http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm&lt;/a&gt;).&lt;br /&gt;&lt;br /&gt;Theoretically, the maximum size of FAT32 partition equals 2&lt;sup&gt;28&lt;/sup&gt;*32 KB = 8 TB (&lt;a href="http://support.microsoft.com/kb/314463"&gt;http://support.microsoft.com/kb/314463&lt;/a&gt;), but in practice (for the sake of compatibility) it would be better to limit yourself to 2TB.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-3445360908597630001?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/3445360908597630001/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/12/large-disks-and-fat32.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3445360908597630001'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3445360908597630001'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/12/large-disks-and-fat32.html' title='Large disks and FAT32.'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-6515822111935448896</id><published>2010-12-23T14:20:00.000-08:00</published><updated>2010-12-23T14:20:00.193-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='TLER'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><title type='text'>TLER in end-user systems</title><content type='html'>In your home PC, you're better off without TLER.&lt;br /&gt;&lt;br /&gt;TLER (Time Limited Error Recovery) is a feature of WD hard drives. It limits the time the hard drive spends attempting to recover from a read error. Most other manufacturers has similar options, under different names.&lt;br /&gt;&lt;br /&gt;TLER is designed to improve performance, not reliability. TLER kicks in when the hard drive experiences an uncorrectable read error (most likely due to a bad sector). The drive with a bad sector should generally be replaced as soon as possible, because it is likely to produce another bad sector soon. Pre-TLER result would be the RAID controller dropping the drive offline. With TLER, the missing data is recovered from RAID redundancy and the drive remains online.&lt;br /&gt;&lt;br /&gt;With a typical consumer-grade maintenance this effectively hides the problem until the drive fails completely, thereby increasing the vulnerability window of a fault tolerant arrays. In an enterprise-grade systems, where continuous availability is important, this is good. A consumer-grade system, where shutdown is not a problem, is better be shut down immediately once a read error occurs.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-6515822111935448896?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/6515822111935448896/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/12/tler-in-end-user-systems.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/6515822111935448896'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/6515822111935448896'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/12/tler-in-end-user-systems.html' title='TLER in end-user systems'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-328064568227078952</id><published>2010-12-21T04:05:00.000-08:00</published><updated>2010-12-21T04:05:00.178-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid tips'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='fail'/><category scheme='http://www.blogger.com/atom/ns#' term='raid5'/><title type='text'>RAID Tips Bonus - Unrecoverable Errors in RAID 5</title><content type='html'>There is a known issue with RAID 5 that if one drive in the array fails completely, then there may be a data loss during the rebuild if one of the remaining drives encounters an unrecoverable read error. These errors are relatively rare, but the size of arrays involved had increased to the point where one cannot even read the entire array without encountering a read error.&lt;br /&gt;&lt;br /&gt;There are some scary calculations available on the Internet (see an example &lt;a href="http://www.zdnet.com/blog/storage/why-raid-5-stops-working-in-2009/162"&gt;here&lt;/a&gt;), concluding that there is as much as 50% probability of failing the rebuild on the 12TB (6x2TB) RAID 5 if one disk fails. These calculations are based on somewhat naive assumptions, making the problem look worse than it actually is.&lt;br /&gt;&lt;br /&gt;First of all, the statement that "&lt;em&gt;There is a 50% probability of being not able to rebuild a 12TB RAID 5&lt;/em&gt;" is the same as "&lt;em&gt;If you have a 10TB RAID 0 array, there is a 50% probability of not getting back what you write to it, if you write the data and then read it back immediately.&lt;/em&gt;" That's assuming same amount of user data on both arrays and 2TB hard drives. Still, nobody declares RAID 0 dead.&lt;br /&gt;&lt;br /&gt;This can be reformulated even further. Assuming 100MB/sec sustained read speed, we can say "&lt;em&gt;There is a 50% chance that a hard drive cannot sustain a continuous sequential read operation for 30 hours non-stop&lt;/em&gt;", which just does not look right. 30 hours is the approximate time to read 10TB of data at 100MB/sec.&lt;br /&gt;&lt;br /&gt;The silent assumptions behind these calculations are that&lt;br /&gt;&lt;ol&gt;&lt;li&gt;read errors are distributed uniformly over hard drives and over time, and &lt;/li&gt;&lt;li&gt;the single read error on rebuild kills the entire array. &lt;/li&gt;&lt;/ol&gt;&lt;p&gt;both of these are not true, making the result useless. &lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-328064568227078952?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/328064568227078952/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/12/raid-tips-bonus-unrecoverable-errors-in.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/328064568227078952'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/328064568227078952'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/12/raid-tips-bonus-unrecoverable-errors-in.html' title='RAID Tips Bonus - Unrecoverable Errors in RAID 5'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-5607072881580013790</id><published>2010-12-17T04:05:00.000-08:00</published><updated>2010-12-17T04:05:00.385-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid tips'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>RAID Tips 10 of 10 - Recover a failed RAID.</title><content type='html'>If a disk fails in a fault-tolerant array such as RAID5, you just replace the disk an carry on.&lt;br /&gt;However, if there is a controller failure or an operator error, you might end up with a set of disks lacking the array configuration.&lt;br /&gt;&lt;br /&gt;You can then send the disk set to the data recovery lab, or try to get the data off yourself using &lt;a href="http://www.freeraidrecovery.com/"&gt;ReclaiMe Free RAID Recovery&lt;/a&gt;. The most difficult part of RAID recovery is the &lt;em&gt;destriping,&lt;/em&gt; the process of converting the striped array to the contiguous set of sectors as it is on a regular hard drive. ReclaiMe Free RAID Recovery does exactly that, giving you a choice of several output options, and at no cost.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-5607072881580013790?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/5607072881580013790/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/12/raid-tips-10-of-10-recover-failed-raid.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/5607072881580013790'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/5607072881580013790'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/12/raid-tips-10-of-10-recover-failed-raid.html' title='RAID Tips 10 of 10 - Recover a failed RAID.'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-4124059080242319712</id><published>2010-12-14T08:39:00.000-08:00</published><updated>2010-12-14T08:39:00.882-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid tips'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><title type='text'>RAID Tips 9 of 10 - Monitor the RAID performance</title><content type='html'>The ability of the RAID to handle failures of its hard drives relies on redundancy of the storage. Once redundancy is lost because of the first drive failure, the human intervention is needed to correct the problem and restore the required level of redundancy. Redundancy is to be restored quickly, or otherwise there is no point in having the RAID at all. However, you do not know when to act if you do not monitor the array and disks often enough.&lt;br /&gt;&lt;ul&gt;&lt;li&gt;Regularly check the SMART status on the drives using the appropriate software. With a software RAID, use SpeedFan or HDDLife. With a hardware RAID, use the vendor-supplied monitoring software. &lt;/li&gt;&lt;br /&gt;&lt;li&gt;Any unexplained drop in the throughput may indicate a problem with one of the hard drives. &lt;/li&gt;&lt;/ul&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-4124059080242319712?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/4124059080242319712/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/12/raid-tips-9-of-10-monitor-raid.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4124059080242319712'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4124059080242319712'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/12/raid-tips-9-of-10-monitor-raid.html' title='RAID Tips 9 of 10 - Monitor the RAID performance'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-5237473036444049468</id><published>2010-12-11T08:33:00.000-08:00</published><updated>2010-12-11T08:33:00.460-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid tips'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><title type='text'>RAID Tips 8 of 10 - Backup Often</title><content type='html'>&lt;p&gt;Even if your RAID is supposed to be fault tolerant, backup often. &lt;/p&gt;&lt;p&gt;Although the RAID is redundant with respect to hard drive failures, there are still issues that may bring down the entire array, requiring either a restore from a backup or a &lt;a href="http://www.freeraidrecovery.com/"&gt;RAID recovery&lt;/a&gt;. &lt;/p&gt;&lt;ul&gt;&lt;li&gt;The RAID controller itself is a single point of failure. &lt;/li&gt;&lt;li&gt;The failures of the hard drives may be correlated if they have a single root cause (like a power supply failure involving overvoltage). &lt;/li&gt;&lt;li&gt;Last not least, RAID does not protect you against human error. &lt;/li&gt;&lt;/ul&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-5237473036444049468?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/5237473036444049468/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/12/raid-tips-8-of-10-backup-often.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/5237473036444049468'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/5237473036444049468'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/12/raid-tips-8-of-10-backup-often.html' title='RAID Tips 8 of 10 - Backup Often'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-963949184866258307</id><published>2010-12-08T14:04:00.000-08:00</published><updated>2010-12-08T14:04:00.203-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid tips'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><title type='text'>RAID Tips 7 of 10 - Test your RAID</title><content type='html'>&lt;p&gt;The fault tolerance needs to be tested so that you &lt;/p&gt;&lt;ul&gt;&lt;li&gt;know exactly how the RAID behaves when a hard drive fails; &lt;/li&gt;&lt;li&gt;ensure that the RAID is actually capable of surviving a disk failure. &lt;/li&gt;&lt;/ul&gt;&lt;p&gt;When deploying a fault-tolerant array (RAID 1, RAID 5, or RAID 6), test the system with a simulated disk failure. &lt;/p&gt;&lt;ul&gt;&lt;li&gt;If you have hot swappable drive bays, just pick a random one and pull the hard drive on a live system. &lt;/li&gt;&lt;li&gt;If there is no hot swap available, then disconnect one of the disks with the system powered off. &lt;/li&gt;&lt;/ul&gt;&lt;p&gt;&lt;br /&gt;Obviously, you better do the testing before the array is loaded with the production data, or you'd have an unplanned &lt;a href="http://www.freeraidrecovery.com/"&gt;RAID recovery&lt;/a&gt; incident. &lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-963949184866258307?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/963949184866258307/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/12/raid-tips-7-of-10-test-your-raid.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/963949184866258307'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/963949184866258307'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/12/raid-tips-7-of-10-test-your-raid.html' title='RAID Tips 7 of 10 - Test your RAID'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-3935990465302176323</id><published>2010-12-05T13:58:00.000-08:00</published><updated>2010-12-05T13:58:00.367-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid1'/><category scheme='http://www.blogger.com/atom/ns#' term='raid tips'/><category scheme='http://www.blogger.com/atom/ns#' term='raid10'/><category scheme='http://www.blogger.com/atom/ns#' term='software RAID'/><category scheme='http://www.blogger.com/atom/ns#' term='raid0'/><title type='text'>RAID Tips 6 of 10 - Software RAID</title><content type='html'>&lt;p&gt;Do not underestimate the software RAID. &lt;/p&gt;&lt;ul&gt;&lt;li&gt;Software RAID would typically provide the same, of not better reliability than an entry-level server hardware RAID controller.&lt;/li&gt;&lt;li&gt;Software RAID is easier to move around from server to server. It does not require an identical replacement controller in case of a controller failure, which is sometimes a hinderance with server hardware.&lt;/li&gt;&lt;li&gt;In RAID 0, RAID 1, and RAID 10, the hardware RAID controller does not provide any computational power benefit because there is nothing to offload. &lt;/li&gt;&lt;li&gt;Most modern SOHO and small business NAS devices, like Synology, QNAP, or NetGear, use the software RAID (Linux/mdadm). &lt;/li&gt;&lt;/ul&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-3935990465302176323?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/3935990465302176323/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/12/raid-tips-6-of-10-software-raid.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3935990465302176323'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3935990465302176323'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/12/raid-tips-6-of-10-software-raid.html' title='RAID Tips 6 of 10 - Software RAID'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-4344851221243816576</id><published>2010-12-02T13:55:00.000-08:00</published><updated>2010-12-03T04:50:45.918-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid tips'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid6'/><category scheme='http://www.blogger.com/atom/ns#' term='hot spare'/><category scheme='http://www.blogger.com/atom/ns#' term='raid5'/><title type='text'>RAID Tips 5 of 10 - Hot Spares</title><content type='html'>Hot spares are a good addition to a fault-tolerant array.&lt;br /&gt;&lt;br /&gt;If a drive has failed in a fault-tolerant (RAID 1 or RAID 5) array, there is a vulnerability window. If another drive fails during this vulnerability window, the data is lost. Hot spare drives allow the controller to rebuild the array without administrator intervention, thereby reducing the vulnerability window.&lt;br /&gt;&lt;br /&gt;The need for a hot spare increases as the number of disks in array increases.&lt;br /&gt;&lt;br /&gt;Hot spares are most effective when a single hot spare drive is shared between several arrays. Consider for example an 8-bay NAS. If there is only one RAID 5 array in the NAS, then RAID 6 may be a better option than a hot spare. The hot spare drive just sits there idly. In a RAID 6 array, the same drive would be utilized to improve a read speed. However if you need two RAID 5 arrays, the hot spare drive is shared between these two arrays, reducing the disk space overhead.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-4344851221243816576?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/4344851221243816576/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/12/raid-tips-5-of-10-hot-spares.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4344851221243816576'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4344851221243816576'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/12/raid-tips-5-of-10-hot-spares.html' title='RAID Tips 5 of 10 - Hot Spares'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-7763488123332850212</id><published>2010-11-29T13:52:00.000-08:00</published><updated>2010-12-03T04:50:45.919-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid tips'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid5'/><title type='text'>RAID Tips 4 of 10 - RAID 5 uncorrectable error probability</title><content type='html'>If you plan on building RAID 5 with a total capacity of more than 10 TB, consider RAID 6 instead.&lt;br /&gt;&lt;br /&gt;The problem with RAID 5 is that once the member disk had failed, it is required to read the entire array in order to complete the RAID rebuild. Although the probability of encountering a read error in any particular read operation is very low, the chance of a read error occurring increases as the array size increases. It has been widely speculated that the probability of encountering the read error during rebuild becomes practically significant as the array size approaches 10TB. Although the speculation relies on certain assumption which is not likely to be true (we'll have a writeup on that later), consider being &lt;em&gt;better safe than sorry&lt;/em&gt;.&lt;br /&gt;&lt;br /&gt;RAID 6, being capable of correcting two simultaneous read errors, does not have this problem.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-7763488123332850212?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/7763488123332850212/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/raid-tips-4-of-10-raid-5-uncorrectable.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/7763488123332850212'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/7763488123332850212'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/raid-tips-4-of-10-raid-5-uncorrectable.html' title='RAID Tips 4 of 10 - RAID 5 uncorrectable error probability'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-4647707057639579176</id><published>2010-11-26T00:21:00.000-08:00</published><updated>2010-12-03T04:49:10.505-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid tips'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid0'/><title type='text'>RAID Tips 3 of 10 - RAID 0</title><content type='html'>If you are planning to build a RAID 0, consider using an SSD instead. Depending on what your requirements are, you may find a better bang for your buck with just one SSD. Also, higher RPM rotational drives (e.g. WD VelociRaptor series) or hybrid drives (like Seagate Momentus XT) may be interesting.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-4647707057639579176?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/4647707057639579176/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/raid-tips-3-of-10-raid-0.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4647707057639579176'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4647707057639579176'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/raid-tips-3-of-10-raid-0.html' title='RAID Tips 3 of 10 - RAID 0'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-7245623786623455583</id><published>2010-11-23T00:15:00.000-08:00</published><updated>2010-12-03T04:49:10.506-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid tips'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid triangle'/><title type='text'>RAID Tips 2 of 10 - The RAID Triangle</title><content type='html'>&lt;p&gt;The relationship between Speed, Price, and Fault Tolerance mostly determines the RAID level to use. Of these three parameters, pick any two. &lt;/p&gt;&lt;br /&gt;&lt;ul&gt;&lt;br /&gt;&lt;li&gt;Fast and Fault Tolerant - RAID 1+0 &lt;/li&gt;&lt;br /&gt;&lt;li&gt;Fast and Cheap - RAID 0 &lt;/li&gt;&lt;br /&gt;&lt;li&gt;Cheap and Fault Tolerant - RAID 5 or RAID 6. &lt;/li&gt;&lt;/ul&gt;&lt;img style="TEXT-ALIGN: center; MARGIN: 0px auto 10px; WIDTH: 300px; DISPLAY: block; HEIGHT: 246px; CURSOR: hand" border="0" alt="" src="http://raid-calculator.com/raid-triangle.gif" /&gt;&lt;br /&gt;&lt;p&gt;&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-7245623786623455583?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/7245623786623455583/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/raid-tips-2-of-10-raid-triangle.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/7245623786623455583'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/7245623786623455583'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/raid-tips-2-of-10-raid-triangle.html' title='RAID Tips 2 of 10 - The RAID Triangle'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-522223582867459103</id><published>2010-11-20T00:11:00.000-08:00</published><updated>2010-12-03T04:49:10.507-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid tips'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><title type='text'>RAID Tips 1 of 10 - Requirements</title><content type='html'>When you are about to build a RAID, make sure you understand your storage requirements. The following points are significant&lt;br /&gt;&lt;ul&gt;&lt;li&gt;Array capacity. Whatever your capacity requirements are, these are underestimated, most likely by the factor of two. &lt;/li&gt;&lt;li&gt;Budget limits. &lt;/li&gt;&lt;li&gt;Expected activity profile, especially read-to-write ratio. If there are mostly reads and few writes, then RAID 5 or RAID 6 would be OK. If significant random write activity is expected, consider RAID 10 instead. &lt;/li&gt;&lt;li&gt;Expected lifetime. Whatever the projected lifetime of the storage system is, it is underestimated. &lt;/li&gt;&lt;/ul&gt;&lt;p&gt;For a quick estimation of capacities for various RAID levels, check the online &lt;a href="http://www.raid-calculator.com/"&gt;RAID calculator&lt;/a&gt;.&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-522223582867459103?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/522223582867459103/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/raid-tips-1-of-10-requirements.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/522223582867459103'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/522223582867459103'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/raid-tips-1-of-10-requirements.html' title='RAID Tips 1 of 10 - Requirements'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-8152457758131110285</id><published>2010-11-17T04:13:00.000-08:00</published><updated>2010-11-17T04:13:00.524-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='s.m.a.r.t.'/><title type='text'>The effect of S.M.A.R.T.-reported temperatures on failure rate</title><content type='html'>It was previously thought that there was a clear correlation between disk temperatures and failure rates; however, the studies undertaken by Google Inc. on the large disk population have revealed that the correlation is not as strong as it was assumed earlier. In the studies, S.M.A.R.T. data which were collected every few minutes during 9-month window of observation have been analyzed. Only average temperatures were taken into account. It was found that failures don't increase when the temperature increases. Moreover, the higher probability of failure rates was observed for the lower temperature ranges. The positive correlation has been detected only for the disks with temperatures greater than 50&lt;sup&gt;0&lt;/sup&gt;C.&lt;br /&gt;&lt;br /&gt;However, 3 and 4 year old drives stand out. For such drives, the correlation between average temperatures and failure rates turned out to be more pronounced, probably due to then current HDD technology.&lt;br /&gt;&lt;br /&gt;Thus, the studies show that the disk temperature affects the failure rate directly only for old drives and high temperature ranges (above 50&lt;sup&gt;0&lt;/sup&gt;C). For the moderate temperatures other factors affect failure rates much more strongly than temperatures do.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-8152457758131110285?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/8152457758131110285/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/effect-of-smart-reported-temperatures.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/8152457758131110285'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/8152457758131110285'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/effect-of-smart-reported-temperatures.html' title='The effect of S.M.A.R.T.-reported temperatures on failure rate'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-5166852976279416567</id><published>2010-11-14T11:05:00.000-08:00</published><updated>2011-12-06T02:07:07.724-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>Why do we need as much information as possible?</title><content type='html'>Once there was a discussion on one of the repair forums, and one poster said something along these lines&lt;br /&gt;&lt;br /&gt;&lt;em&gt;The only information needed to recover a RAID are the RAID disks themselves. If the recovery lab asks something like controller model, they are not a professional outfit.&lt;/em&gt;&lt;br /&gt;&lt;em&gt;&lt;/em&gt;&lt;br /&gt;This guy has some merit. If you can get your hands on the actual drives, you do not really need anything else to do the recovery. This is true for the recovery lab, which works with the actual disks (or images thereof). When we are debugging our &lt;a href="http://www.freeraidrecovery.com/"&gt;RAID recovery freeware&lt;/a&gt;, there is one significant disadvantage. The actual disk images are always cost-prohibitively large to transfer, so we had to figure the problem out without these.&lt;br /&gt;&lt;br /&gt;Lacking the images, we still have our test data sets, crash dumps, whatever, but the customer description of the problem becomes more important.&lt;br /&gt;&lt;br /&gt;Consider the following problem report, just for an entertainment purpose:&lt;br /&gt;&lt;br /&gt;&lt;em&gt;We were running XP the software RAID5 volume holding the data failed. The array is 4x 1TB WD whatever model hard drives. The hard drives were verified separately with WD Lifeguard and tests returned no errors. However, Windows refuses to mount the array and ReclaiMe Free RAID Recovery fails to produce proper output.&lt;/em&gt;&lt;br /&gt;&lt;br /&gt;Now what is the problem with the recovery? (select whitespace below for an answer).&lt;br /&gt;&lt;br /&gt;&lt;span style="color:#ffffff;"&gt;There is a discrepancy between two statements 1. running XP and 2. using RAID5. They must have been using RAID0, because XP does not support software RAID5.&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;This illustrates the importance of all the details perfectly.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-5166852976279416567?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/5166852976279416567/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/why-do-we-need-as-much-information-as.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/5166852976279416567'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/5166852976279416567'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/why-do-we-need-as-much-information-as.html' title='Why do we need as much information as possible?'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-113962816629867953</id><published>2010-11-11T13:48:00.000-08:00</published><updated>2010-11-11T13:57:09.902-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='raid6'/><category scheme='http://www.blogger.com/atom/ns#' term='raid5'/><title type='text'>On RAID computational requirements</title><content type='html'>There is a widespread opinion that software RAID imposes significant processing power penalty on the host system, thereby decreasing overall performance.&lt;br /&gt;&lt;br /&gt;For a RAID 0, this is obviously not the case. The only overhead involved is to dispatch the sectors being read or written to their appropriate disk, requiring a fairly simple calculation once for every sector (512 bytes of data) written.&lt;br /&gt;&lt;br /&gt;RAID 5 and RAID  6 are more complicated. There is a requirement that parity data is computed for each write. However, the processing power requirements are modest and the resources are in abundance. Given the 100 MB/sec write speed, we need, say, 1,000 MIPS (Million Instructions Per Second) to calculate the parity. Also, there will be an additional memory bandwidth requirement of, say, 200 MB/sec (100 MB/sec in and out). Properly designed caching would alleviate the load even further. Still, a pretty modest CPU (made circa 2005) can provide about 15,000 MIPS and about 5,000 MB/sec memory bandwidth. So, the requirements of the RAID performing a sustained write at a rate of 100 MB/sec do not seem very high compared to the resources available.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-113962816629867953?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/113962816629867953/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/on-raid-computational-requirements.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/113962816629867953'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/113962816629867953'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/on-raid-computational-requirements.html' title='On RAID computational requirements'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-3621608629680117632</id><published>2010-11-11T09:50:00.000-08:00</published><updated>2011-12-06T02:07:07.726-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><title type='text'>On RAID diagnostic messages</title><content type='html'>Always check what your RAID controller says when a disk failure or other array failure occurs. You should verify by testing that such messages are difficult to miss.&lt;br /&gt;&lt;br /&gt;Error messages displayed during the boot sequence are no longer useful as the uptime is now measured in weeks even for the home PCs.&lt;br /&gt;&lt;br /&gt;If the controller doesn't report error messages or for some reason you don't take prompt action to restore the array redundancy once the disk failure has occurred, then there is no point in running a RAID. Using hot spares alleviates the problem for disk failures, but not for a silent controller malfunction.&lt;br /&gt;&lt;br /&gt;On one of the forums someone told a story about RAID 1 failure where one of the member disks had failed and later it was found out that the second member disk contained the two-month-old data. Two months before the disk failure, the controller lost the array for some reason but didn't report the error. So nobody bothered to restore the redundancy. As a result, when the only remaining disk failed, there was no redundancy and all the data had been lost.&lt;br /&gt;&lt;br /&gt;Remember that the &lt;a href="http://www.freeraidrecovery.com/"&gt;RAID recovery&lt;/a&gt; may be difficult if the array is seriously out of sync.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-3621608629680117632?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/3621608629680117632/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/on-raid-diagnostic-messages.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3621608629680117632'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3621608629680117632'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/on-raid-diagnostic-messages.html' title='On RAID diagnostic messages'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-7997585140287465223</id><published>2010-11-08T02:27:00.000-08:00</published><updated>2010-11-08T02:27:00.224-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='mdadm'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='ldm'/><title type='text'>Moving drives across ports in a RAID</title><content type='html'>Can I swap the disks in RAID (connect the disks to different ports) and don't lose the RAID data?&lt;br /&gt;&lt;br /&gt;There are two types of RAID implementation:&lt;br /&gt;&lt;strong&gt;&lt;/strong&gt;&lt;br /&gt;&lt;strong&gt;1.&lt;/strong&gt; Configuration-on-disks (COD) - in which the information about RAIDs along with the data about to what array exactly the current disk belongs to is stored on the disk itself.&lt;br /&gt;In this case you can transfer the disks between the ports and even between the controllers of the same model. Such a scheme is implemented in modern software RAIDs (Windows LDM and Linux mdadm) and in most hardware controllers as well. Sometimes you can even transfer the array between the different controller models, for example Intel ICH9R and Intel ICH10R.&lt;br /&gt;&lt;br /&gt;&lt;strong&gt;2.&lt;/strong&gt; RAID implementations in which the information about member disks is stored in the controller memory. Here, the controller actually monitors not the disks, but the ports and so you cannot swap the disks. Othewise, you lose the array and then you need a &lt;a href="http://www.freeraidrecovery.com/"&gt;RAID recovery&lt;/a&gt;.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-7997585140287465223?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/7997585140287465223/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/moving-drives-across-ports-in-raid.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/7997585140287465223'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/7997585140287465223'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/moving-drives-across-ports-in-raid.html' title='Moving drives across ports in a RAID'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-7498401582799105304</id><published>2010-11-03T02:01:00.000-07:00</published><updated>2010-11-03T02:01:00.546-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='BigLBA'/><title type='text'>Installing XP on a hard drive larger than 128/137GB limit</title><content type='html'>If Windows XP doesn't see more than 137 (or 128) GB of disk space on the large disk, then you need to &lt;a href="http://www.reclaime.com/library/hard-disk-capacity-clipping.aspx"&gt;turn on BigLBA&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;To enable BigLBA on an XP computer, it is needed to change the parameter in the registry. Such an approach works well when the XP has been already installed, but if you need to make a fresh installation on the large disk, you can't change the parameter because the registry does not yet exist.&lt;br /&gt;&lt;p&gt;To work around this issue, you can do one of the following:&lt;br /&gt;&lt;/p&gt;&lt;ol&gt;&lt;li&gt;Include the latest Service Park into the installation CD (this process is called "slipstreaming"), and then the full disk capacity will be available during install. &lt;/li&gt;&lt;li&gt;Install the XP on a partition with the size, say, 100 GB, then install the latest Service Pack, &lt;a href="http://www.reclaime.com/library/hard-disk-capacity-clipping.aspx"&gt;enable BigLBA&lt;/a&gt;, and use a tool like Partition Magic to extend the partition onto the remaining space. Normally, we'd recommend that you backup before resizing a partition, but since this is a new install anyway, there is nothing useful to backup.&lt;br /&gt;&lt;/li&gt;&lt;/ol&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-7498401582799105304?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/7498401582799105304/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/installing-xp-on-hard-drive-larger-than.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/7498401582799105304'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/7498401582799105304'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/installing-xp-on-hard-drive-larger-than.html' title='Installing XP on a hard drive larger than 128/137GB limit'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-693969346265392210</id><published>2010-11-02T23:21:00.001-07:00</published><updated>2010-11-02T23:21:57.798-07:00</updated><title type='text'>Hard disk sounds</title><content type='html'>&lt;p&gt;&lt;i&gt;what does spindle motor damage sound like?&lt;/i&gt;&lt;/p&gt;&lt;br /&gt;&lt;p&gt;Silence.&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-693969346265392210?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/693969346265392210/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/hard-disk-sounds.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/693969346265392210'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/693969346265392210'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/11/hard-disk-sounds.html' title='Hard disk sounds'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-4134738299856472331</id><published>2010-10-30T01:55:00.000-07:00</published><updated>2011-12-06T02:07:07.728-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='mdadm'/><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><title type='text'>mdadm</title><content type='html'>Software RAID in Linux (mdadm) implements many possibilities to reshape the array including&lt;br /&gt;&lt;ul&gt;&lt;li&gt;changing the type of the array, &lt;/li&gt;&lt;li&gt;changing the array size (by adding new disks), &lt;/li&gt;&lt;li&gt;and even changing the block size in &lt;a href="http://www.freeraidrecovery.com/library/raid-5-6.aspx"&gt;RAID 5 or RAID 6&lt;/a&gt;.&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;&lt;br /&gt;&lt;a href="http://neil.brown.name/blog/20090817000931#4"&gt;http://neil.brown.name/blog/20090817000931#4&lt;/a&gt;.&lt;br /&gt;&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-4134738299856472331?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/4134738299856472331/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/10/mdadm.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4134738299856472331'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/4134738299856472331'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/10/mdadm.html' title='mdadm'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-854277706266895718</id><published>2010-10-26T01:44:00.000-07:00</published><updated>2011-12-06T02:07:07.729-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><title type='text'>RAID type migrations</title><content type='html'>&lt;p&gt;&lt;i&gt;Can I change the RAID type after the data was written on the array?&lt;/i&gt; &lt;/p&gt;&lt;p&gt;&lt;a href="http://www.tomshardware.com/forum/259807-32-raid"&gt;Tom's Hardware answers "No"&lt;/a&gt; &lt;/p&gt;&lt;p&gt;In fact, it depends on the particular RAID implementation. &lt;/p&gt;&lt;ul&gt;&lt;li&gt;In some implementations you can change nothing.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;In others, you can extend an array by adding new disks.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;There are also the implementations which allow you to even change the array&lt;br /&gt;type (although not in all combinations). &lt;/li&gt;&lt;/ul&gt;&lt;p&gt;You need to consult your particular hardware and/or software manual for a list of available options before committing to a certain expansion plan. In any case, make sure to backup the array contents before expanding or migrating to the different array type. Should the migration process fail midway, the &lt;a href="http://www.FreeRaidRecovery.com"&gt;RAID recovery&lt;/a&gt; is not going to be cheap.&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-854277706266895718?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/854277706266895718/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/10/raid-type-migrations.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/854277706266895718'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/854277706266895718'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/10/raid-type-migrations.html' title='RAID type migrations'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-3064064697496109875</id><published>2010-10-22T01:40:00.000-07:00</published><updated>2010-10-22T01:42:57.119-07:00</updated><title type='text'>On critical error messages</title><content type='html'>If a situation occurs that requires immediate user response, then the error message should exactly describe the situation and possible courses of action.&lt;br /&gt;&lt;br /&gt;The warning message should be displayed explicitly, because one cannot expect that the user is able to reliably draw conclusions by comparing several independent parameters.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-3064064697496109875?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/3064064697496109875/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/10/on-critical-error-messages.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3064064697496109875'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/3064064697496109875'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/10/on-critical-error-messages.html' title='On critical error messages'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-8591034134390106024</id><published>2010-10-05T02:56:00.000-07:00</published><updated>2011-12-06T02:07:07.731-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='image file'/><category scheme='http://www.blogger.com/atom/ns#' term='disk image'/><category scheme='http://www.blogger.com/atom/ns#' term='raid recovery'/><title type='text'>Imaging RAIDs</title><content type='html'>If you recover RAID and need to create a RAID image file, you should create the image files of the member disks rather than the whole array. Generally, it is not possible to restore the original array state using a RAID image file.&lt;br /&gt;&lt;br /&gt;As for RAID0, the original state can be restored by writing the image to the array provided that the controller's settings (and thus the array parameters) have not been changed. If the controller's settings have been changed between reading and writing the image file, then image file data doesn't go to the original place on the member disks.&lt;br /&gt;&lt;br /&gt;For RAID5 it is not enough to have a RAID image file of the entire array even if the controller's settings have not been changed. This is because the parity data is not written to the image file. If the array works properly, the parity data is not used, but for the &lt;a href="http://www.freeraidrecovery.com/"&gt;RAID recovery&lt;/a&gt; you need the parity data. A RAID5 consisting of 3x1TB disks contains 3TB of raw data (with parity), while the array image file will be 2TB in size and, obviously, does not contain all the data.&lt;br /&gt;&lt;br /&gt;The image file of the whole RAID, which was copied using an incorrectly configured controller, is a mess of the block parts and it can only be used provided that you know what the controller's settings were when creating the RAID image file. As of 2010, we know of no software capable of recovering such array image files.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-8591034134390106024?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/8591034134390106024/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/10/imaging-raids.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/8591034134390106024'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/8591034134390106024'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/10/imaging-raids.html' title='Imaging RAIDs'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-7438926504781747331</id><published>2010-10-02T02:13:00.000-07:00</published><updated>2010-10-02T02:13:00.380-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='raid'/><category scheme='http://www.blogger.com/atom/ns#' term='chkdsk'/><title type='text'>CHKDSK is not the tool to check the disk.</title><content type='html'>&lt;p&gt;In fact, CHKDSK only checks the filesystem, regardless of where it is located and what state of corresponding physical storage is. The filesystem may be located on a RAID 5 in which one of the member disks has already failed. In this case, from the CHKDSK's point of view, the filesystem is still OK.&lt;/p&gt;&lt;p&gt;One should understand that the data storage system consists of several levels and every level should be checked using the appropriate tools and techniques. For example,&lt;/p&gt;&lt;ol&gt;&lt;li&gt;A database should be checked using whatever tool is provided with the SQL server.&lt;/li&gt;&lt;li&gt;The volume that stores the database should be checked by CHKDSK.&lt;/li&gt;&lt;li&gt;The RAID that contains the volume should be checked using diagnostic tools provided with the RAID controller. &lt;/li&gt;&lt;li&gt;The member disks, should the need arise, should be checked by their corresponding vendor diagnostic tools.&lt;/li&gt;&lt;/ol&gt;&lt;p&gt;Sounds a bit like "&lt;i&gt;The House that Jack Built&lt;/i&gt;".&lt;br /&gt;&lt;br /&gt;&lt;/p&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-7438926504781747331?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/7438926504781747331/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/10/chkdsk-is-not-tool-to-check-disk.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/7438926504781747331'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/7438926504781747331'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/10/chkdsk-is-not-tool-to-check-disk.html' title='CHKDSK is not the tool to check the disk.'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-8012568243058880053.post-1989257197182838143</id><published>2010-09-29T22:57:00.000-07:00</published><updated>2010-09-29T22:57:00.970-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='photo recovery'/><title type='text'>Nikon internal memory</title><content type='html'>If you need to access Nikon's camera (similar to Nikon Coolpix S200) internal memory for &lt;a href="http://www.reclaime.com/library/photo-recovery.aspx"&gt;photo recovery&lt;/a&gt;, just eject the memory card from the camera and connect the camera to the PC using the USB cable. You'd better not to lose the cable supplied with the camera - Nikon USB connectors are something non-standard and spare cables are hard to come by.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/8012568243058880053-1989257197182838143?l=data-recovery-weekly.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://data-recovery-weekly.blogspot.com/feeds/1989257197182838143/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/09/nikon-internal-memory.html#comment-form' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1989257197182838143'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/8012568243058880053/posts/default/1989257197182838143'/><link rel='alternate' type='text/html' href='http://data-recovery-weekly.blogspot.com/2010/09/nikon-internal-memory.html' title='Nikon internal memory'/><author><name>Geek</name><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry></feed>
