Backups Never Failed Before and Now They Aways Fail
Running Acronis TrueImage 2010 Build 7160. I'm backing up from a 2 drive, RAID 0 setup (2 TB) to a eSata BlacX docking station with a 2 TB Western Digital Caviar Green drive in it. I keep getting Event code: 0x0004000D and Event code: 0x013C0005.
Here's what I've done to try to fix the problem:
I've tested the RAM with memtest for 12 hrs-no errors.
I have changed the SATA cables on the RAID drives.
I have even backed up to the RAID Drive itself -still I get errors.
I ran drive tests & scan disk on the RAID drives and the External Drive--PASS.
The only thing that is different then before is the RAID 0 drives were upgraded (which was a smaller capacity, 2 drive, RAID 0 (500GB).
Running Windows 7 Pro x64
Thanks.
Ron
Yes, here it is.
The D drive is the RAID drive.
That's a tough one. It looks like your error codes can be linked to a variety of hard drive or connection and hardware issues.
You should contact Acronis support.
One way to troubleshoot this is to move the data from D to another disk, break the array and then test one disk after the other.
I suspected I might have to break the array and test. It is definitely the RAID disk that is causing the problem as I am backing up the same data between the main drive and another external eSata HDD with no problems.
So you can't trust scandisk on a RAID array, huh?
Did you run chkdsk /f /r ?
We have seen cases where ATi was complaining about a disk, but chkdsk was not finding anything wrong, but then some manufacturer utility would find issues. When the user replaces the drive, the problem is gone.
No, I ran scandisk from Windows 7. The manufacturers utility (Western Digital) doesn't recognize a RAID drive for testing, so I couldn't use it. Yes, I should have tested the drives before using them!!
OK. So your RAID0 is good.
Are you backups full backups or incremental/differential? If you create a new backup task, do you have the same problem?
Actually, I was right the first time. I was NOT able to run a manufacturer utility on the individual drives on the RAID setup-only scandisk. I best break the array and test them individually.
As far as backup type , backups are incremental. New backup tasks also create the same error.
By the way, would any unusual sector sizes or stripe sizes make any difference to ATi?
I don't know, but that wouldn't be surprising.
I used a large sector size (64k) for better performance as it is a media drive. This is another thing to check after testing drives.
Absolutely. Test the drives separately (using test utilities), then set up a RAID with default settings.
Hello Pat,
I think I narrowed the problem down. I tested the RAID0 drives seperately with manufacturer utilities-no problems. Used HD Tune Pro on the RAID0 and no problems. I also ran the boot time backup off the rescue CD and it failed. By the way, I'm using a 64K sector size on the RAID drives, as opposed to the default setting.
With that said, I found the backup consistently fails for a set of folders with large (12gB) .avi files which are on the RAID0. It does not fail ever for other folders which are on the RAID0.
Why would this be?
The only hint I can offer would be that the file names have spaces and are rather long (ie,. "Tape 1 B17 flight RAW FOOTAGE.avi").
I don't know. I know some users have had issues with folders with a lot of files, but I don't remember the case of big files.
Not that I want to dodge the issue at hand, but you might want to consider some replication software for this kind of file. They are bid, compressed and don't change. Keeping a single copy on another drive should be enough of a backup. Software like SyncBack, PureSync or even SyncToy or Karen's replicator could answer your need. The first one includes upon-copy verification to make sure the copy is correct.
I'm pretty sure its not big files now, but the very long path names or possibly the use of spaces or commas in the path name of some of the files/folders I'm backing up. I shortened the folder name of the problem folder and the backup is validating.
This problem crops up every once in a while with other software, too--like Winrar, etc--during extractions to very long path name destinations. Don''t ask me why.