No disagreement here. Obviously, the sequential method is easiest to
implement. I was just pointing out that with a little effort you can get a
lot more bang for the buck - which might be useful in justifying the
expenditure.

I also do not mean to minimize the effort necessary to implement a multiple
concurrent backup strategy. You must be very careful that you do not miss
anything, which means you must have control of, or at least a very good
understanding of, how groups, accounts and directories get added to your
system. It would be more than just embarrassing to discover something was
not being backed up.

John Burke

> -----Original Message-----
> From: Doug Werth [mailto:[log in to unmask]]
> Sent: Tuesday, November 21, 2000 2:06 PM
> To: [log in to unmask]
> Subject: Re: [HP3000-L] Turbostore question
>
>
> John Burke <[log in to unmask]> writes:
>
> > I agree that two (or more, we use five) tape drives are
> better than one;
> > however, rather than a sequential backup (still takes as long) or a
> parallel
> > backup (too complex when a restore is required) why not two
> separate,
> > independent, backup jobs?
> >
> > We actually do five simultaneous backups to five tape
> drives. The obvious
> > advantage this has over a sequential backup is the time factor. The
> obvious
> > advantage over a parallel backup is ease of restore.
> Perhaps less obvious,
> > since the backups are independent, if one fails for any
> reason, we still
> > have a good backup of 4/5's of our system
> >
> > The downside to this scheme is you have to manually
> determine how to split
> > your system and periodically monitor how much is backed up by each
> process;
> > however, it has served us well for many years and once set
> up requires
> only
> > minimal attention.
>
> Exactly. My assumption is that this is a single tape backup that was
> spilling over onto a second tape. The *easiest* thing to do
> (besides just
> manually changing tapes) without introducing other
> complexities would be a
> sequential backup. Anything else would require deeper analysis and an
> overhaul of the backup procedure.
>
> Doug.
>
> Doug Werth                             Beechglen Development Inc.
> [log in to unmask]                               Cincinnati, Ohio
>