Relationship between BACKUP qualifiers, /CRC and /GROUP

[Clark Powell]

On the BACKUP command, if /NOCRC is set then is the /GROUP qualifier irrelevant? We were using /NOCRC and then added /GROUP=0 but saw no increase in performance. One opinion was that since we were already using /NOCRC that the /GROUP qualifier was irrelevant. Is this correct?

wcp

[David Jones_21]

The CRC is used to detect data transfer errors writing or reading the tape. The redundancy group adds parity data to let you recover from one bad block within the group.

[Ian McKerracher_1]

There are a number of HP manuals, journals and ECO summaries that explicitly state both the /NOCRC and /GROUP=0 qualifiers in the same Backup command. I have also seen examples that use the /NOCRC and /GROUP= qualifiers in the same command. I think we can assume that the CRC and GROUP qualifiers are not related and that /NOCRC/GROUP=0 is a meaningful combination.


Regards,

Ian

[Volker Halle]

wcp,

/CRC and /GROUP_SIZE are 2 different mechanisms to protect against data corruption or loss in backup savesets.

/CRC creates a CRC checksum over each backup block being written. Using /NOCRC does not create (when writing a saveset) or check (when reading the saveset) the CRC. This saves some CPU cycles, but does not protect against detecting bad data in backup saveset blocks.

/GROUP=n writes a redundant backup block every n backup blocks, which allows recovery of ONE uncorrectable read error inside each redundancy group. Using /GROUP=0 will reduce the no. of backup blocks written by 1/11th (default is /GROUP=10). You should be able to see a slight reduction in the DIRIO count. If the input disk is the bottleneck, you won't see any performance increase.

Volker.

[comarow]

It has been recommended with modern backup devices to set group=0
However, while many don't use CRC, CRC is software to software checking. It does consume CPU cycles. It is your choice but the reliability of backups is improved with CRC checking.

Please see the new standards for tuning backup.

You should note that diolm with SAN devices should be reduces to 100. Below 100 Xwindows won't start, but if you are running batch backups you can reduce it to a much lower number, such as 32. There is a problem with Cache thrashing. Engineering is aware of the problem. But for better performance reduce your diolm.


Here is the new backup recommendations, and those are conservative so windows will start.

http://h71000.www7.hp.com/doc/82FINAL/aa-pv5mj-tk/00/01/117-con.html

[Wim Van den Wyngaert]

I would re-verify your test result.

/group=0 will decrease the traffic to your drive with 10% and cpu load on VMS will be lighter because no raid-like computations must be done.

We saw the differce very clear.

Wim

[Bart Zorn_1]

I am not so sure if you can do entirely without /GROUP redundancy. Although no doubt modern tapedrives provide the necessary redundancy, /GROUP may be helpful if tapes are getting older and are possibly not stored in optimal conditions. In this case BACKUP may be able to restore valuable files when some blocks on the tape are no longer readable.

Of course, it is rather difficult to test this, but it is my belief that that I prefer to have the redundancy blocks and never need them than the other way around!

YMMV,

Bart Zorn

[comarow]

The documentation specifically recommends
/group=0

[Wim Van den Wyngaert]

Because all modern drives have a some kind of /group=4 built in. And when recovery is not possible, data is not returned to the backup process so backup can't recover. Only "modern" is not defined ...

Wim

[Jan van den Ende]

Define "modern" as "SCSI", and any recovery processing is simply IMPOSSIBLE because the first parity error found will simply ABORT data transfer. Unrecoverable. Period. (unless you are able to locate a DSA compliant tape for the tape format).

SCSI = Scuzi = Sorry for this functionality-lacking implementation.

fwiw,

Proost.

Have one on me.

jpe