You're absolutely right.  Of course, every time you copy data, you face
a similar risk.  Every single time you copy data from one device to
another, multiple levels of CRC/ECC are used to make sure that the
target copy is the same as the source copy, and there is a chance
(however small) every time you make a copy that the copy will make a
mistake and CRC/ECC will not pick it up.

That was part of my original point that I made in the first article I
wrote on the subject.  Yes, I know there is a chance for a hash
collision and data corruption, but there is a chance of that every time
you copy data anywhere, disk to disk, disk to tape, etc -- and there's a
chance you'll never know it.  I just don't understand all the vitriol
aimed at this particular method.

I did read the paper that someone forwarded, and while the paper is
quite old, I think his arguments still hold true.  (He also used the
birthday paradox in the same way I did, BTW.)

The only part I didn't quite understand was the part where he said that
you can't compare hash collisions with hardware errors (like I'm doing
above).  I read that part a couple of times and didn't get it.  I'm not
saying I understood his argument and disagree with it, mind you.  I'm
saying he spent only two or three paragraphs explaining that part, and
at the end I didn't understand what he said.

---
W. Curtis Preston
Backup Blog @ www.backupcentral.com
VP Data Protection, GlassHouse Technologies 

-----Original Message-----
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of A Darren
Dunham
Sent: Thursday, October 25, 2007 1:02 PM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Tapeless backup environments

> Did I read in this list that netbackup was supposed to do some kind of
> checksum on the data written to tape?
> If so would a bpverify check this. I would assume that if netbackup
does
> this it would find the error.
> because netbackup would do it's calc before passing the block to the
> dedupe hardware/software. And the block that it gets back from the
> dedupe hardware/software would be different.

Even if bpverify did checksum in this manner, you can't assume that it
would find all such errors.  The checksum can collide in a manner
identical to the hash.  Unless it lined up exactly with the hash
algorithm, it would likely provide some additional protection, but at
the same time it must include some collisions where both the block hash
and the overall checksum give identical values for a replacement block.
The presense of an additional checksum like this changes the specific
numbers, but does not change the essential character of the issue.

-- 
Darren Dunham                                           ddunham AT taos DOT com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >
_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu