Hi Nathan,

Thanks for the response!

> On Nov 28, 2018, at 7:02 PM, Nathan Stratton Treadway <natha...@ontko.com> 
> wrote:
> 
> On Wed, Nov 28, 2018 at 16:54:08 -0800, Chris Deiss wrote:
>> Hi,
>> 
>> Under previous version of amvault, I was able to do this:
>> 
>> 
>> amvault -o diskfile=/usr/local/etc/amanda/daily/disklist.drs . . .
>> 
>> 
>> and it worked great!  Was an excellent was to vault only a subset of DLEs to 
>> special media/storage.
> 
> What version were you using when this worked?

I have two active AMANDA servers, one running 3.3.6, the other at 3.5.1.  The 
“-o diskfile=...” option works as desired in 3.3.6.

>> It???s not working under 3.5.1, instead it defaults to the disklist
>> parameter defined in amanda.conf.  Other options like '-o tapecycle=2'
>> _do_ work with the latest amvault, so it???s not a total failure to
>> modify the config, just appears to be a problem which includes the
>> ???disklist' parameter.
> 
> There were some fixes to config-parameter processing in the versions
> leading up to v3.5.1.  Off hand I wouldn't expect those changes to cause
> the symptoms you describe, but it's possible.  I will try to look at the
> code for amvault and see if anything obvious is going on.
> 
> I take it there is no error message?

Nope, no error.  Instead, when I specify “-o 
diskfile=/usr/local/etc/amanda/daily/disklist.drs“ on the command-line under 
3.5.1, amvault vaults all DLEs in the file specified by the default ‘diskfile’ 
parameter defined in amanda.conf (that file is 
"/usr/local/etc/amanda/daily/disklist").

> What happens if you specify a path to a non-existant file, or something
> like that?

In that case (e.g. “disklist.foo" which doesn’t exist), it produces "errors 
processing disklist” and exits.

> Depending on what I find in the code for amvault, it might help narrow
> in on the problem to have the full command line you are trying to run,
> as well as a bit more information on what list of DLEs you want to vault
> and which ones are actually getting vaulted instead….

On 3.3.6, I’m exec’ing:

`amvault -o tapedev=vtape-fs1 -o tapetype=LTO6-2Gbfc -o tapecycle=1 -o 
diskfile=/usr/local/etc/amanda/daily/disklist.drs \
--autolabel any --latest-fulls --label-template "drs-tape-%" --dst-changer 
tapelib2 daily`

On 3.5.1, I’m exec'ing:

`amvault -o tapedev=vtape-fs1 -o tapecycle=2 -o 
diskfile=/usr/local/etc/amanda/daily/disklist.drs --src-storage=daily \
--dest-storage s3-vault --latest-fulls daily`

When I issue that, amvault vaults all DLEs in the default ‘diskfile' file 
("/usr/local/etc/amanda/daily/disklist”), which BTW contains the line:

includefile disklist.drs

That way, a normal amdump run includes all DLEs, both the ones I want vaulted 
offsite (listed in “disklist.drs”) and all the rest (listed in the default file 
“disklist”).

Another aside: it doesn’t seem to matter whether I specify the full path of the 
diskfile file or not . . . presumably AMANDA commands prepend the path at which 
amanda.conf resides if a relative filename is given?  All of my diskfile files 
are in the same directory as amanda.conf.

>> If anyone has alternative ways to vault a subset of DLEs, or an
> 
> 
> Well, amvault does accept a number of parameters and arguments to
> control what gets vaulted, but I guess those might not be sufficient if
> your disklist.drs list is long and arbitrary…

Yes, in this use-case, we’re trying to send an arbitrary set of DLE’s off-site 
for DRS, and the DLEs span multiple hosts but not all filesystems on any given 
host.

> 
>> effective way to report a bug, please let me know.
> 
> (This mailing list is currently the best way to report a bug...)
> 
>                                                       Nathan
> 
> ----------------------------------------------------------------------------
> Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
> Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
> GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
> Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239


Reply via email to