Re: tar and tape changers

[Tavis Barr]

On Sun, 11 Mar 2001, Paul Eggert wrote:

> > (2) If we're out of new tapes to write to, the call to tar really should
> > fail.  Right now, tar just runs the script and continues about its
> > business.  While I can cause tar to exit by leaving the loader unloaded
> > (giving me a device not ready error), it seems like bad form to exit with
> > the wrong error.
> 
> Tar should check the exit status of the script.  I'll fix that in the
> next version.

Great.  I was going to ask about that but figured the solution I suggested
would work for me without it.  In any event, it seems like a good idea as 
a general case.


> I like the general idea, but have some suggestions:
> 
> * I don't yet see why --pre-load is needed.
> 
> * I don't see why --sleep-on-load is needed.
>   The --tape-load-program can sleep if needed.
> 
> * We shouldn't need a --tape-list option.  Just let the user specify
>   multiple -f options, as is already done with GNU tar.
> 
> * I'd rather not use "tape" in the option name, as the devices might
>   not be tape devices.
> 
> So, how about the following suggestion instead.  Add two new options:
> 
> --pre-archive=COMMAND
>   Run "COMMAND ARCHIVE" just before opening ARCHIVE.
> 
> --post-archive=COMMAND
>   Run "COMMAND ARCHIVE" just after closing ARCHIVE.


I'm perhaps being too specific to the case of using a tape library.
Nevertheless, I think it's an important case, and doesn't _quite_ work
with this.  (Though we're getting closer.)  Right now, the way I do my
backups is something like this:

mtx /dev/sg0 load 1
sleep 5m
tar -cvf /dev/st1 first-archive
mtx /dev/sg0 unload
mtx /dev/sg0 load 2
sleep 5m
tar -cvf /dev/st1 second-archive

So I'm using the same archive device over and over again, but each time I
use it, I'm having my loader load a different tape into it.  So your
pre-archive option would work, except that I would have to enter it once
for each archive.  For example, it would have to be able to look like
this:

tar -cvf /dev/st1 --pre-archive="mtx load 1 && sleep 5m" 
    --post-archive="mtx unload" first-archive -f /dev/st1
    --pre-archive="mtx load 2 && sleep 5m" --post-archive="mtx unload"
    second-archive

So the --pre-archive and --post-archive would have to be different for
each archive.  If they could be, then this would solve my problem.  I
don't know if tar is capable of handling options in that way, or if
doing it is desireable.  

> Sure!  Volunteers are always welcome.  We'd need the usual copyright
> assignments (contact me if you don't know about those).

Couldn't care less about copyright.  (Though obviously I care that the
program is GPL'ed, which it already is.)  Do what you want with whatever I
code up, copyright it yourself if you want, etc.


I have two more questions about things that tar might need to do to suit
my purposes:

(1) The manual suggests (I've never tried it) that you can specify NFS
volumed explicitly.  Would it also be possible to add smbfs mounting (on
systems that support it) to back up windows shares?  The idea that I have
in mind is that anything that begins with a double-slash (e.g., 
//machine/sharename/directory) could recognized as smbfs.  But I haven't
gone through the code to see how this works.

(2) I know that it's possible to compress an entire archive by specifying
a flag to call gzip.  What about file-by-file compression?  gzip does have
an option to write to stdout (which could then by piped), so this should
be doable.  It wouldn't be as efficient as gzipping an entire archive, but
it should be more robust to failure and also be able to span multi-volume
archives more easily.

(3) What's the status of the backup scripts that are provided?  I'm trying
to write something that's generic enough that it could become a standard
way to create scheduled backups.  It could be specified in text files but
would also have a GTK+/gnome front end.  (But the text files would be
general enough that someone could edit them directly or write, say, a Qt
front end if they have a fancy for that toolkit or simply want to write
something that looks nicer under KDE.)  It it worth picking up on this, or
should I just start over from scratch?


Thanks,
Tavis