Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!think!ames!oliveb!felix!chuck From: chuck@felix.UUCP (Chuck Vertrees) Newsgroups: comp.sys.dec Subject: Re: halve BACKUP times easily Message-ID: <3427@felix.UUCP> Date: Fri, 10-Jul-87 13:41:09 EDT Article-I.D.: felix.3427 Posted: Fri Jul 10 13:41:09 1987 Date-Received: Sun, 12-Jul-87 16:01:23 EDT References: <51700001@uicsrd> Sender: daemon@felix.UUCP Reply-To: chuck@felix.UUCP (Chuck Vertrees) Organization: FileNet Corp., Costa Mesa, CA Lines: 41 Summary: but there are consequences... In article <51700001@uicsrd> kai@uicsrd.CSRD.UIUC.EDU writes: >Using the following VMS/BACKUP switches can HALVE your cpu and elapsed time. >I tried this on a one of my VAX 750's Massbus disks (approx. 65 Mb) to a CDC >92185 tape drive at 6250 bpi, and cut the full disk backup elapsed time from >35 minutes to 17 minutes (on an unloaded system) and cputime used from 10 >minutes to 5 minutes. > BACKUP/IMAGE/NOCRC/BUFFERS:5/BLOCKSIZE:16384 dra2: msa0:dra2.bck >The idea behind this is that BACKUP was written a long time ago, when 6250 >bpi tape drives were non-existent or very expensive. 1600 bpi tape drives do >not have the hardware built in for performing CRC checking of the data, >however 6250 bpi tape drives DO. So why have your VAX waste it's time doing >double CRC checking? These twiddles of the qualifiers come up every so often, and are usually not accompanied by the consequences of each modification. I am remembering this from the response to a question/answer at a DECUS several years ago, so I may not have it totally right. The major problem is created by the use of /BUFFERS and /BLOCKSIZE. When BACKUP is writing a saveset and EOT is detected, it must write all current buffers before it unloads the tape. By specifying a 16k block size (default is 8k), and 5 buffers (I think the default is 3) you have increased the amount of data that must be written before the tape runs out from 24k to 80k. While this may not be a problem at 6250 bpi, it could be one at 1600 bpi. If the tape run out, the saveset is not complete, you will get a fatal error and can not continue. As far as using /NOCRC, I cannot comment on the long term consequences here. While GCR tape drives are inherently more reliable than 1600 bpi, being able to detect (and correct to a certain extent) a much larger class of errors, I don't know how not having BACKUP calculate crc's effects its overall capability to give back what you intrust to it. I do know that after using BACKUP for over 5 years, with in some cases some questionable tapes, and with defaults for crc and buffers, I was always able to "get it back." While faster is usually nicer, I never found the speed of BACKUP to be an overriding concern. I managed about 3 1/2 gigabytes, and with properly designed backup procedures, never spent more than about 30 minutes a day on incremental backups. Weekly backups which covered everything modified in the last week took a little over an hour. Once a month we captured everything with /IMAGE, which is the only place time was an issue. We could spend 10 to 12 hours on this. But this is also where I wanted every assurance I could get that "I could get it back." The time involved was not an issue.