vca

When the tape drive I was using for backups started to die back in about 2004 or 2005 I ended up writing my own backup utility, initially to store the backups to DVDs and then as the cost of hard drives dropped I switched to using external drives. This utility is written in Python and I use it to backup my unRAID server to removable drives attached to my Windows desktop. It is built on the notion of a single full backup followed by an unlimited number of incrementals, so while the first backup takes a lot of time the incrementals run pretty quick. Typically I run an incremental pass on the weekend to grab all the new media files, a process that might take a half hour or so. The backups are written in user-configurable chunks, typically about 500MB (the system will automatically split large files across multiple chunks), to a drive in my Windows desktop machine. From there they get copied to an external drive in one of my backup media sets. I have two media sets, one is kept at a remote location (to further protect against fire, flood or theft - but not far enough away to protect against a meteor strike). Periodically I will take the external drive I am currently saving backups to over to the external location, swap it for the last disk in that set and bring that disk back. When I return with the swapped disk I then update it with the backup chunks that were kept on the workstation in its absence and then I can delete those from the work station and repeat the process. In this way I have quadruple redundancy for all the backed up data almost all the time: 1. the unraid disk where the data resides 2. the unraid parity protection (not truly a copy, but close) 3. the copy on the workstation internal cache drive 4. the copy on the local external drive once the data is swapped to site the items 3 and 4 become the local external drive and the remote external drive. About once every year or two I restart the whole process, because by then I'll have some higher capacity drives that I can use to remove the older (and smaller) back up drives from service. The last time I did this I was able to retire a handful of 500GB drives, replacing them with 2TB units that I had removed from the unRAID box when I started moving to 4TB drives. The data on the external drives is check summed both at the chunk level and at the individual file level. And the database that manages this has a SHA1 hash of all the individual files as well, so in theory I could use it to check against the current contents of the unRAID server without having to access any of the external drives. But I've not written that code yet. The backup utility is called ArcvBack and is available on: http://arcvback.com/arcvback.html It currently uses Python 2.5, one of these days I'll have to update it to the Python 3.x series. Regards, Stephen

The point is that I, and probably others, would worry about it. Yes, there's a two year warranty, but the fact is that they specify a two year warranty constrained by a ridiculously low power on hours figure, bearing in mind that they also promote (in the first document quoted) the drives as suitable for home servers and NAS devices, which are typically powered 24/7. It simply does not make sense. I would generally prefer to buy drives and other parts where I know for sure what I am getting. I agree, I had bought the first drive on the basis of their "Best-fit applications" list and that it had a 2 year warranty, it was when I was considering buying a second that I looked further (I wanted to check the power requirements) and saw the odd 2400 hour issue and this has made me stop to consider what to do. Heck I'm spending the first 100 hours (4.2%) of the drive's life just running a 2-cycle preclear... Regards, Stephen

I picked up one of these Seagate 4TB drives (internal packaging) and verified that it has a 2 year warranty (via Seagate's web site). Reading the "Desktop HDD Data Sheet": http://www.seagate.com/files/staticfiles/docs/pdf/datasheet/disc/barracuda-desktop-hdd-ds-1770-1-1212us.pdf I saw them list "Best-Fit Applications": -Desktop or all-in-one PCs -Home servers -PC-based gaming systems -Desktop RAID -Direct-attached external storage devices (DAS) -Network-attached storage devices (NAS) So sounds like a good choice for my unRAID box... But on the next page they list the detailed specs and here they quote "Power-On Hours: 2400", which is only 100 days in 24x7 mode. My guess is that they might use this as a get out of warranty card. So time to turn the drive spin down mode back on. Regards, Stephen

Yup, sounds correct. The most likely cause of this sort of suddenly appearing parity errors is an unclean machine shutdown - such as a power issue or someone just hitting the ctrl-alt-del to get a Windows login prompt. At this point it would be useful if there was a utility that could take the list of parity error locations and output a list of the files (on all your disks) that occupy those locations, then you would have a short list of things to check for possible corruption. Other than that, unless you have a backup that you can compare to you are probably out of luck. Stephen

Yes, if you have two memory sticks you should be able to run the system on one at a time to see if that improves things. Most of the past recommendations are to run the memtests for at least a night, though in the two cases I have encountered personally where a memory stick went bad memtest was able to detect the issue in one or two passes (usually one of the 8 tests it runs will fail). So, if you've already done 10 full passes (say about 5 hours or so of testing) I would say your memory (and probably also the CPU) are fine. Regards, Stephen

It is telling you the sector relative to the start of the partition where the parity error was detected. The unRAID software has absolutely no way to know which bit(s) are wrong. Just that an exclusive or of all the bits of some word in the sector did not end up with an even number of bits set to a "1" It could be a but set to zero when it should be a one, or a bit set to one when it should be zero, and it could be on any of your disks, or it could be transposed in RAM if memory is flaky, or in the disk controller chipset, or on the motherboard itself. It is VERY hard to diagnose. It is one reason why old Nforce4 chipsets are to be avoided. They exhibited random parity errors that caused some to lose their hair. Many time is is a single disk, and repeated md5sums of the same data on a single disk result in different results. The fix, replace the disk. These disks often show no errors otherwise. Joe L. In this post: http://lime-technology.com/forum/index.php?topic=10364.msg98580#msg98580 I reported my experiences with resolving an ongoing parity error issue. You might be experiencing something similar, but you need to do further tests. First run some more parity checks in the "nocorrect" mode. If these show exactly the same errors (to the block) then what you probably have is an issue where data was being written to the drives when the machine got shut down unexpectedly. This will leave the parity drive out of sync with the data. Doing a parity check (in the normal check and update mode) will bring the parity disk back up to date with the contents of the drives and further partiy checks should show no more errors. If the errors go away by themselves (for a few parity checks) or change locations between checks - which was what was happening to me - then you have a harder to diagnose problem. It might be as simple as faulty cable/connector or it might be flaky memory, motherboard chip set or a drive. In my case it turned out to be one of my 8 drives and the SMART tests (both long and short) gave no indication that the drive was acting up. Anyway, don't panic, run one test at a time and keep a written log of what you test along the way and relevant results (like SMART test logs and the reported locations of the parity errors) of the tests and you should sort it out in time. Regards, Stephen