Backup / verify

[Wim Van den Wyngaert]

Is there still any need to do backup /verify with modern tape drives and when doing backups while files are being created/removed ?

Would it ever report differences due to tape errors and how could I be sure that it's the tape's fault and not a file modif ?

Wim

[Ian Miller.]

Its the only way you know the data is on the tape.
I think the verify pass reports differences but how can it tell which has changed?

[Lawrence Czlapinski]

Wim,
1. There is probably more of a need since most tapes on modern tape drives are written at higher densities than in the past. Tapes written at higher density are more sensitive to dirty tape drives.
2. I would think the files would be compared against the same version number. So it would only be a problem if you're renaming file version numbers while doing backup :(
Lawrence

[Jan van den Ende]

@Lawrence:


I would think the files would be compared against the same version number. So it would only be a problem if you're renaming file version numbers while doing backup :(


... or append to the file
... or add a record to an indexed file
... or mutate a record in an indexed file
... or delete a file
... or modify a file attribute
... or change the content of a directory (which changes the .DIR file)
... and I am sure the list will grow if given some more thought

And the issue of the sensitivity to dirty tapes is a non-issue.
The chance of picking up dirt on a later READ is not related to that of picking up dirt on an immediate re-read..
And SHOULD anything turn up, that will VERY likely turn up as a parity error before BACKUP can even DO a comparison.

I tend to abree with Wim!!

Any arguments with a solid foundation from the insiders?

Proost.

Have one on me.

jpe

[Wim Van den Wyngaert]

Did some testing.

First of all : the exit status of the command changes when e.g. a file was deleted between backup and verification. So, don't add /verify to working procedures without checking the procedure.

Not posted modifications are not seen (did a write in dcl to a file that was open).

Files closed between backup and verification result in EOFMISMATCH.

File characteristics are also written to tape but no verification is done of that info.

Pitty I can't simulate tape errors ...

Wim

[Graham Jagger]

I stopped using /verify back when we went from Mag Tapes and TK50/70 tapes to DLT III. For DLT III, IV, and so on I see no need. In fact using /NOCRC saves cpu cycles and increase your /BLOCK= to something that keeps the tape streaming. Like at least 32K.

I've sucessfully read tapes we have vaulted for 5+ years on DLT III media. If you have a file that is that critical then the only real guarantee is; shutdown the app so the files are closed; do a backup, dismount tape, remount, do a backup/compare, start app. Now you have verified the media and drive and your copy. Beyond that I wouldn't put any faith in backup/verify.

Graham

[Ian Miller.]

Graham, I thought /compare and /verify are basically going to do the same thing.

/nocrc does not gain you anything except a tiny bit of cpu time and removes a end to end check which may detect something - there has been much debate on this already.

[Graham Jagger]

Ian,

Oh yeah. There will always be debates on the best way to do backups. From my experience dropping /verify and /crc many years ago has not caused me any problems. While I agree with you that /crc does an end to end check I just haven't found it to help me. On older versions of VMS and older hardware /CRC was a costly switch. It's now a fairly negligable hit on the cpu.

As far as /verify vs /compare. They do the same thing to a point. If it is that critical to me I like to dismount and remount the tape to make sure it will mount again. Then do a compare. It may not be as big a value today but it used to be that verify would still work on a weak write to tape media. Where compare seemed to catch the corruption.

It's been our experience with DLT III and IV that either the tape won't init, or won't mount after init, or flat out fails with parity errors during backup. None of which require /verify or /crc to catch.