Veeam 7 tape and verify

[csydas]

Things have changed a little bit since 1987 -- CRC on the fly is possible with modern CPUs and the network stack, and you can do such checks in-flight. I've seen Veeam throw CRC error when we had a faulty drive, so I'm not sure what the benefit is aside from just not trusting the storage medium.

[pshute]

Things have changed a little bit since 1987 -- CRC on the fly is possible with modern CPUs and the network stack, and you can do such checks in-flight. I've seen Veeam throw CRC error when we had a faulty drive, so I'm not sure what the benefit is aside from just not trusting the storage medium.

It's not about trusting the storage medium, it's about trusting Veeam. Even if we can be reasonably sure that what's being sent to the tape drive is ending up on the tape in a readable state, how can we be sure Veeam is sending the right data? There can be software bugs today, just like there could be in 1987.

They say the only true verification is a restore, but I think a verify stage after backup to tape is not a bad compromise.

[zoltank]

The built in mechanism on the tape drive only confirms what the drive received was written to the tape.

SureBackup only confirms what was written to the hard drive is viable.

Verify is needed to confirm what was read from the hard drive is what was written to the tape.

I don't understand how Veeam doesn't see that as a glaring oversight. What kills me is until verify is implemented, I'll need to continue licensing, using, and maintaining Backup Exec alongside Veeam, just to handle our tapes. That just sucks.

[srdegeus]

Backup Exec does not verify if the tape content is the same as on disk, it verifies that the tape can be read:
"Backup Exec can perform a verify operation to make sure that the media can be read after a backup job has been completed."
https://www.veritas.com/support/en_US/d ... 0-99535599

The whole "if the data on tape is the same as that was sent to tape" is already caught in the checksums of the data (blocks.)

[csydas]

Thank you srdegus, I was going to say, I highly doubt that any backup vendor is doing a full read/verify of the tape because that would be hell on the drive + tape media.

This is what CRC is for, and it's exactly what Zoltank wants, I think. Tape is a pretty proven technology...a special fancy job to check the contents isn't really necessary.

[pshute]

Backup Exec does not verify if the tape content is the same as on disk, it verifies that the tape can be read:

That's the first I've heard of it. On my version at least, it runs as a separate operation after the backup. It tells me how many files have verified. If a user or the system changes a file in the meantime, Backup Exec reports that it's failed verification. I can't believe it's not reading the data from the tape and comparing to every file it backed up.

[pshute]

Thank you srdegus, I was going to say, I highly doubt that any backup vendor is doing a full read/verify of the tape because that would be hell on the drive + tape media.

Of course it's hell on the drive and tape. It doubles their usage.

[csydas]

But we already have inflight checks for virtually every protocol out there -- I'm not sure I see the point of stressing the hardware like that except to have an extra Green report appear when we already will see such errors from built in verification. Granted, CRC has limitations on what it can and can't see and it can be compromised, but I can't imagine that this is the target an attacker goes for if they have that kind of access.

If a user or the system changes a file in the meantime, Backup Exec reports that it's failed verification. I can't believe it's not reading the data from the tape and comparing to every file it backed up.

Maybe I'm not understanding correctly what you're describing, but how is this validation of a proper write to the tape? It sounds more like it's comparing the source data to the written data and seeing if there is parity across the mediums, but maybe you can clarify what you're observing.

To me the request seems silly - the true test of tape isn't "can I read from the tape immediately after I write it", it's "Can I read from it 6 months from now when script kiddies from Slovenia have fscked absolutely every digital storage in my environment and the only backups I have left are on tape?" (With all apologies to our fellow Veeam users from Slovenia)

A million and one things happen to the tape in that 6 months after the test is run; CRC is already doing what is necessary to ensure that the data written is consistent; where is the value in an extra full read + stress on a tape when it does nothing to help offset the odds against the tape spoiling as it sit in a truck going to cold storage?

[pshute]

cysdas wrote:

But we already have inflight checks for virtually every protocol out there -- I'm not sure I see the point of stressing the hardware like that except to have an extra Green report appear when we already will see such errors from built in verification. Granted, CRC has limitations on what it can and can't see and it can be compromised, but I can't imagine that this is the target an attacker goes for if they have that kind of access.

I wonder if we're talking about two different things. I'm talking about making sure that the files we're writing to a tape end up written correctly on the tape. You're talking about an attacker, and I don't see how that's relevant to what I'm talking about, so I think you're talking about something else. Please clarify so we can get on the same track.

Maybe I'm not understanding correctly what you're describing, but how is this validation of a proper write to the tape? It sounds more like it's comparing the source data to the written data and seeing if there is parity across the mediums, but maybe you can clarify what you're observing.

Yes, that's exactly what it would be doing. I don't see how comparing the source data to the written data wouldn't be a verification of a proper write.

[zoltank]

Backup Exec calculates the checksum of the files as it writes them to the tape, it then also writes that checksum to the tape. Verify then go and recalculates the checksum of the data written to the tape and compares it against the original checksum. Therefore if something was corrupted in transit (something a dodgy SCSI controller and cable can easily do) then the verify will catch it. Yes, it's extra wear on the tape and tape drive, but that's a small price to pay for knowing your tapes are viable.

So far as I know, this is something Veeam's tape support doesn't do but is a critical step in protecting your data with tapes. Until Veeam adds this feature I'd be shirking my responsibilities to my company by using Veeam for our tape backups, regardless of how much I want to get rid of Backup Exec.

Regarding Csydas' comment about the true test of reading from a tape 6 months down the road, a high quality tape stored in an environmentally controlled space will have no issues being read 6 months later (or even 2 years later), but even then you should, and we do, keep multiple backup tapes just in case one tape does somehow go bad. This does not IN ANY WAY mitigate the requirement for a tape verify after the tape is written.