Here are a couple of data points. Since I like backups and nature abhors an empty drive, I cloned my Premiere's WD20EVDS to a new WD20EURS using the ddrescue copy function of Comer's JMFS CD. It took about 18.2 hours (on my old Asus P4C800-E motherboard), and the new drive booted OK (cold and warm) and ran without incident for the several hours I tested it, including at least one point at which it was making two recordings while I watched a third one. I used the HDUI (which I'm evaluating) with no network connection, ignoring the C130 errors. While the EURS was in the Premiere, I copied again to a new WD20EFRX (WD Red drive designed for NAS) using the ddrescue on the Ubuntu Rescue Remix 12.04 CD. That copy took only about 7.2 hours (why?), and the new drive behaved similarly to the EURS as far as I can tell. One bit of strangeness is that during the copy operation the EFRX's activity LED (on the drive dock, I guess) would stutter and stop briefly every 25 to 30 seconds causing the current rate to plunge briefly. During the copy to the EURS, the current rate would jump around within a window from about 75% to 100% of maximum, but it never plunged. I thought the difference in average rates could be due to a difference in ddrescue block size used, but the GNU ddrescue online manual indicates that it defaults to only 64K blocks just like the version the JMFS CD uses. Could this mean that the JMFS CD is actually using the older dd_rescue but calling it "ddrescue"? Or is it just using an older release? To verify that the difference wasn't caused by the drive, I copied a third time onto another EURS, and that also took about 7.2 hours and behaved similarly. I've had both WD20EURS drives for several months and had run only the WD long diagnostic test on them before. I think I'll use the (presumably newer) ddrescue version on the Ubuntu Rescue Remix CD for any multi-terabyte copies I do in the future.