[Info-vax] strange backup behavior

[B Hobbs]

On Aug 10, 10:10 am, AEF <spamsink2... at yahoo.com> wrote:
> On Aug 10, 11:48 am, B Hobbs <bdhobb... at acm.org> wrote:
> > On Aug 8, 9:42 am, AEF <spamsink2... at yahoo.com> wrote:
> > > On Aug 8, 9:07 am, sapienzaf <sapie... at noesys.com> wrote:
> > > > On Aug 7, 11:55 pm, David J Dachtera <djesys... at spam.comcast.net>
> > > > wrote:
>
> > > > > The OP may be looking for info relating to "fast skip".
>
> > > > I'm sure this is an emulation problem.
>
> > > > He's running Charon-VAX which makes OpenVMS think the SDLT tape drive
> > > > is a TK50.  I don't believe fast skip is an option for a TK50, and
> > > > furthermore he's running VAX/VMS v7.1 which (IIRC) does not have the
> > > > $SET MAGTAPE/FAST_SKIP command.
>
> > > But the tape must be being rewound between each BACKUP save operation.
> > > It appears that /VERIFY is not present. Perhaps he is MOUNT-ing and re-
> > > MOUNT-ing between each BACKUP operation? We need to see his command
> > > procedure.
>
> > In the procedure, allocate the tape drive, mount/foreign the tape,
> > position to the end, loop thru the backups, dismount/nounload the
> > tape, mount, directory of the files, dismount/nounload, deallocat,
> > exit procedure.  No, the tape is not mounted and dismounted between
> > backup steps.  There are only two pairs of mount and dismount, one
> > pair as /foreign for the backups, one pair without /foreign for the
> > directory list.
>
> > The backup procedure is 36 blocks, I'll post the complete procedure if
> > requested.  The log files range between 300 and 35,000 blocks, I think
> > I'll be butchering those as needed.
>
> The .com file would be helpful.

Posted separately.

>
> > I only *suspect* the tape is rewinding between backup commands, but I
> > can't think of anyway to confirm this except the amount of time the
> > marker files take to backup.  Tell me again why cartridge tapes are so
> > much better than nine-track tapes where one can actually observe the
> > tape rewinding between backup steps?  :-(
>
> I don't see how it couldn't be rewinding for each save set. Maybe
> there's a bug in BACKUP or your tape drive or controller.

Bugs are always possible.  It would be nice if someone with a similar
system could confirm the same behavior.

>
> Are you perhaps running $ set magtape/log/skip=end_of_tape mua0:
> between each backup? You don't need to do that, though I don't know if
> this might be causing your problem.

Just the one skip after the initial MOUNT/FOREIGN.  This is so backups
are added to the tape and not written over existing files.  I
INITIALIZE the tapes manually when needed.

Hmmm, maybe I should try SET MAGTAPE/SKIP=END_OF_TAPE between each
backup step ...  Suggestions or thoughts?

>
> > > To the OP: Why are you not using /IMAGE instead of /FAST [000000...]?
> > > Why are you making both a journal file and listing file of each save
> > > set?
>
> Come to think of it, I don't think /FAST buys you anything for full
> backups. It's really useful  as follows:
>
> A fast file scan is most useful when the input specifier includes most
> of the files on the volume, and file-selection qualifiers (such as
> those that pertain to date or owner) specify a relatively small set of
> the files named. Because image operations implicitly use the fast file
> scan, the /FAST qualifier is ignored if used with the command
> qualifier /IMAGE.
>
> > The procedure loops thru the disks, executing pretty much the same
> > backup command on each disk.  There is an embedded symbol in the
> > backup command that shows up as an empty continuation line for most of
> > the disks, for some disks this symbol contains an /exclude.  /Image
> > ignores /exclude, it was simpler to use the same command for all
> > disks.  It wouldn't be difficult to change to /image for some disks,
> > but I didn't see much advantage from reading the documentation.
>
> BACKUP/IMAGE preserves volume characteristics (everything you specify
> with the INIT command, and subsequent SET VOLUME commands). It also
> preserves aliases. Lost files and files marked for deletion are also
> saved. It also provides a functionally equivalent copy. This is not
> necessarily the case with non-image backups.
>
> I would also guess that restore operations from /image backups would
> go faster as directories don't need to be updated for each file
> restored.
>
> You can set the files to exclude as "backups disabled" using SET FILE/
> NOBACKUP depending on the nature of the files. This is done by default
> for page, swap, and system dump files on the system disk, as data in
> them is useless after a crash or shutdown. If this is not the case for
> these files, then why aren't you backup them up? I'm just asking.
> Perhaps they're easier to regenerate than to restore from tape.

Maybe I'll switch to /IMAGE and do a SET FILE/NOBACKUP on the
offending files ... I need to consult with the powers that be.

>
> Why to you use /LOG, /JOURNAL, and /LIST? Isn't that rather redundant?

This command procedure replaces three procedures from a third party.
I'm trying to do what they did, with more control, and using a single
tape drive.  Their procedures ran independent of each other and used
two tape drives.  Their procedures had "belts *and* suspenders", so I
did the same.