1/7/2024 0 Comments Silverstack lto write timesThis ensures that data that was reported as good on write, will always be readable. All this is done inside the tape drive, without any involvement from the tape server. If a tape hits a dubious section and the block doesn't properly check out, that same block is written to tape again, a little further down the track. Any write is immediately read back and compared as it is written to tape. The head consists of a center write section, and two read heads next to it (one for each tape direction). All modern tape drives (LTO, IBM Enterprise) have full read-after-write verification built in. A verify pass was the only end-to-end test to ensure your data was actually on tape, and skipping it was a no-no. We're talking QIC, DLT, 4mm DAT and 8mm Exabyte times, and parallel SCSI flatcables with questionable termination creating ugly error patterns. A scratch, a dropout or a bad connection would be enough to hit a media error on tape. Personal experience here, not company party line Ī couple of decades ago, a verify pass was the right thing to do, as tape drives didn't have much sophistication in terms of error handling. Really, you're just playing that straw man game here, coming up with things outside the scope of tape verification, then saying it's worthless having it because it doesn't protect you in those situations. Just because there are scenarios it doesn't protect you doesn't mean there aren't scenarios where it does protect you, or that it's not worth having. It does not protect you from writing data that's already bad to the tape, but then it was never meant to do that. Tape verify helps protect you from a bad SCSI controller, cable, or tape drive, etc. Tape verify is just a tool to insure that data then gets onto the tape correctly and readably. You cannot truly prevent it, you can only mitigate the effects.ĭon't assume because I want tape verify that I haven't already take other measures to ensure the backup data is viable and not corrupt all my backups automatically go through SureBackup to insure viability. I've had this argument with other forum users, but I see such a request as the emperor's clothes you can verify the data on disk is what got written to tape, but ultimately, you're relying on the fact that what is on disk is legitimate this is a foregone assumption, imo.,m ad to argue it is just an exercise more than anything.Īvoiding data corruption for real is just and odd game. We hit ESXi CBT bugs which wrote bad data, but CRC returned no errors, and rightfully so - Veeam wrote exactly what CBT fed it, and there was no reason for the software to second guess the data provided to it. To be clear, the reason I have such an issue with this is that if you have bad data written, the checksum isn't going to help you here.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |