Vista - Vista File backup failing with 0x80004005

This one has Microsoft scratching various portions of thier anatomy. Vista
file backup to an external drive has been working on my laptop for over a
year. Flawlessly. Suddenly I have not been able to do a backup for almost a
month. Complete PC Backup still works, but file back up fails with
0x80004005. That status means 'Unspecified error". I've tried it to the
external HDD, formatted that external drive and tried it again, and tried it
to two different network drives on 2 different IP addresses, but no joy.

The only thing I can relate this too is that about the same time our IT
department remapped some network drives and we now run a script at login and
the laptop is now in a domain.I strongly suspect that is the cause and would
notify our IT department ... but Vista is not a "blessed" OS by IT yet and
hence I tend to get "Sorry charlie" when I report problems.

Anyone encountered this issue?

--
The personal opinion of
Gary G. Little

"Gary G. Little" <gary.g.little@xxxxxx> wrote in message
news:uUWKes$xIHA.2184@xxxxxx
Yes, I have eSata failures with backup. Right now I don't know who to point
a finger at.

Using Vista Ultimate Complete Backup with a 500GB eSata external disk
backing up my 100GB on my desktop internal drive, I would have BSOD crashes.
Nothing significant showed up in Event Viewer; I was looking primarily at
the system log. Since the Vista backup system is a "trust me" thing, I got
nervous about that and tried some outside products.

I really can't afford it, but I am testing Shadow Protect desktop. With
thirty years' experience with various backups, I think this is the least I
would trust. More than that, it is the only one I have found that has first
class support, though mainly in a forum format. The main thing is that the
advice I am getting is good advice, not your typical "OK, now, the ball is
back in your court" type of response.

What ShadowProtect found was that the file wrote OK, but in trying to read
it, it got a "Chunk failed due to malformed data" error. The log file on
the backup was good; no errors were detected. But the verify failed.

All right, it sounds like a bad disk, right? Well, Chkdsk tried as hard as
it could but could find no errors.

The same backup on another disk, though USB, was performed without error,
thus verifying somewhat that the process that Storage Protect uses is good.

One possibility I considered with the BSOD crashes using Vista Complete
backup was that perhaps the defrag was automatically running in the
background. After totally disabling it, I'd say it isn't that.

The only guess I have left is that the timing of the checksum of the disk is
done at the wrong time. Now, this may not even apply today, but many, many
years ago I remember reading how the disk folks maintain integrity with
disks. It's all about adding up the data in a sector, then storing it
somewhere else. It it fails a read later, it can restore the sector using
the checksum. And, I think this is also used to verify a write; I don't
know, though. It always sounded to me like there are many more errors on
disks than we'll ever know about, but since they are corrected on the fly,
we never have problems--until now. Now, my current idea is that this
checksum procedure is done at the wrong time; perhaps in verifying a write,
it looks at the checksum which hasn't been written yet and is still in
memory. Then, it normally then writes the checksum to its separate storage
location on the disk; however, in certain unusual circumstances, the
programmer didn't include this write-to-disk in his program. So, the next
time it does a read, it also checks the checksum and it doesn't verify. At
some point it may recreate the sector using the wrong checksum and then I
would get a "Chunk failed due to malformed data" error.

Now, I don't know if that guess would be eSata-specific or not, but I think
both of ours' next approach would be to try it with something other than
eSata. Good drives now have a multiplicity of connection alternatives--USB,
eSata, FireWire, etc. I'm going to see if I still have that FireWire cable;
if not, I'll try USB since I know another drive that uses USB works. USB is
slower, so it's not my connection of choice. Further, I think USB's days
are numbered.

John

Gary G. Little wrote:Ms Shadow copy and Volume shadow copy services need to be running
Both should be set to Automatic