Jean-Louis Martineau <[EMAIL PROTECTED]> writes:

> On Tue, Mar 06, 2001 at 12:44:33PM +0100, Johannes Niess wrote:
> > Hi,
> > 
> > I had dumps from two different configurations dumped to the same
> > holding disk, but to two directories as usual. Beeing too lazy to sort
> > out what date belongs to what configuration, I decided to flush all
> > directories.
> 
> Why do you use the same directory for both configuration?
> You should use different directory.

I used /tmp/amanda-holdingdisk as holding disk entry in both
amanda.conf files. /tmp/amanda-holdingdisk/20010301 and
/tmp/amanda-holdingdisk/20010302 where created.

> 
> > I expected Amanda to flush only the directory belonging
> > to the configuration given on the command line and leave the other one
> > alone for a later flush.
> 
> Amanda don't know the config of a holding image.

>From the amflush man page:

"
Amflush will look in the holding disks specified by the amanda.conf
file in /etc/amanda/config for any non-empty Amanda work directories.
It then prompts you to select a directory or to process all of the
directories.  The work directories in the holding disks are named by
the date at the time amdump was run, e.g. 19910215.
"

IMHO the tiny word ANY needs bold uppercase letters. Looks like a
typical man page written by the programmer himself: it's logically
correct but hides the features :-) I've often made the experience that
only semi-experts are good at documenting and explaining.

Why do I need to give a configuration in the command line? Looks like
it's only used to check the tape label. As I said in my first post, I
see that as a design error (at least psychologically).
                                                        
[...]

> > I'd like to see amflush asking "Do you really want to flush different
> > config's to the same tape?" in this case. I'm sure there are uses for
> > that "feature" the way it is...
> 
> Amanda can't do that.

There should be some bytes left unused in the 32 kB header of dump
files, that can get used to write the configuration name to it. I can
imagine a complicated restore, where several dump files from several
config's are written to the same parent directory before the restore
procedure itself. Having the config in them and checks done
automatically would greatly reduce chaos and administrator stress. The
features are needed for append to tape anyway.

The easier approach would be to use /holdingdisk/config/dumpdir, but
would not help in restores. In the meanwhile I'll use different
directories for holding disks.


The current behavior allows to do some usefull stuff:

Config A: normal disk list entries etc., but no tapes labeled
config B: ditto
Config C: no disk list entries, just tapes

"amflush C" to write two configs to the same tape by answering
"all". Indexes for C could be used in restores.

Johannes Niess

Reply via email to