Re: querying device-side compression setting

2014-01-09 Thread Jean-Louis Martineau

On 01/09/2014 01:44 PM, Michael Stauffer wrote:


Hi,


I'm setting up amanda 3.3.4 with a Quantum Scalar i500 tape library.


Regrading compression options, I'll go with the recommendation in the 
documentation to let Amanda do the compression client-side.


How can I determine if hardware compression is enabled on my tape 
library? I can't find anything about it in the library. Is this option 
controlled by amanda or other mtx settings? Thanks.




Amanda do not set/unset hardware compression, it could be a feature to 
add to amanda.


The hardware compression is controlled by mt.

Jean-Louis


Re: 'labelstr' param in amanda.conf

2014-01-09 Thread Gerrit A. Smit TI
op 09-01-14 19:47, Michael Stauffer schreef:
> Does this mean that if I have multiple configurations in order to
> break up a large 30TB data set into managable chunks, each
> configuration will have to have a particular set of tapes assigned to
> it? That seems very awkward if so.
Why would you make multiple configurations for that?


Gerrit


Re: 'changerfile' param for tape robots

2014-01-09 Thread Jean-Louis Martineau

The global changerfile is is a configuration file for the old changer API

The changer changerfile is used as a state file by some of the new changer.

Jean-Louis

On 01/09/2014 01:48 PM, Michael Stauffer wrote:

Hi,

I'm working on setting up a robot tape changer.
The docs for "chg-robot:DEVICE" say this:"the changerfile parameter 
can be used to specify a filename at which it should store its state. 
Ordinarily, this state is stored in a file named after the changer 
device under $localstatedir/amanda, e.g., 
/var/amanda/chg-robot-dev-sg0. There should be a single such statefile 
for each distinct tape library attached to the Amanda server, even if 
multiple Amanda configurations reference that library."


Is this saying I have to define 'changerfile', or that it will default 
to placing it in $localstatedir/amanda?


Also, some other refs to this param on the web say that it's for a 
configuration file, not a state file. Can I ignore those?


Thanks.

-M




Re: 'labelstr' param in amanda.conf

2014-01-09 Thread Jean-Louis Martineau

On 01/09/2014 01:47 PM, Michael Stauffer wrote:


Hi,

I'm setting up amanda 3.3.4.

Regarding 'labelstr' in amanda.conf:

The documentation says: "If multiple configurations are run from the 
same tape server host, it is helpful to set their labels to different 
strings (for example, "DAILY[0-9][0-9]*" vs. "ARCHIVE[0-9][0-9]*") to 
avoid overwriting each other's tapes."


Does this mean that if I have multiple configurations in order to 
break up a large 30TB data set into managable chunks, each 
configuration will have to have a particular set of tapes assigned to 
it? That seems very awkward if so.




yes

Why do you have multiple configurations?
You should do it with one configuration and multiple dle.

Jean-Louis


'changerfile' param for tape robots

2014-01-09 Thread Michael Stauffer
Hi,

I'm working on setting up a robot tape changer.
The docs for "chg-robot:DEVICE" say this:"the changerfile parameter can be
used to specify a filename at which it should store its state. Ordinarily,
this state is stored in a file named after the changer device under
$localstatedir/amanda, e.g., /var/amanda/chg-robot-dev-sg0. There should be
a single such statefile for each distinct tape library attached to the
Amanda server, even if multiple Amanda configurations reference that
library."

Is this saying I have to define 'changerfile', or that it will default to
placing it in $localstatedir/amanda?

Also, some other refs to this param on the web say that it's for a
configuration file, not a state file. Can I ignore those?

Thanks.

-M


'labelstr' param in amanda.conf

2014-01-09 Thread Michael Stauffer
Hi,

I'm setting up amanda 3.3.4.

Regarding 'labelstr' in amanda.conf:

The documentation says: "If multiple configurations are run from the same
tape server host, it is helpful to set their labels to different strings
(for example, "DAILY[0-9][0-9]*" vs. "ARCHIVE[0-9][0-9]*") to avoid
overwriting each other's tapes."

Does this mean that if I have multiple configurations in order to break up
a large 30TB data set into managable chunks, each configuration will have
to have a particular set of tapes assigned to it? That seems very awkward
if so.

-M


querying device-side compression setting

2014-01-09 Thread Michael Stauffer
Hi,


I'm setting up amanda 3.3.4 with a Quantum Scalar i500 tape library.


Regrading compression options, I'll go with the recommendation in the
documentation to let Amanda do the compression client-side.

How can I determine if hardware compression is enabled on my tape library?
I can't find anything about it in the library. Is this option controlled by
amanda or other mtx settings? Thanks.


-M


Re: Amanda integrity and erc

2014-01-09 Thread Jean-Louis Martineau

amanda 3.3 and before do not have crc check.

crc check is already in the development tree and will be included in the 
next major release.


Restoring from a corrupted archive depend of the tool used.
  gtar can generally restore corrupted archive, some manual 
intervention can be required.

  software compressed dump are not recoverable.

Jean-Louis

On 01/08/2014 08:57 PM, Schlacta, Christ wrote:


What mechanisms does amanda provide to guarantee the following:

1) what was on the original drive is what is sent to the backup server
2) what was sent to the backup server is what's written to the archive
3) what's written to the archive is what's rerouted from backup
4) that any errors encountered at any of the above, or any other step 
in the backup process can be recovered from, at least up to a certain 
level of resiliency


I've scoured the faq and manuals and don't recall seeing answers to 
any of this.






Amanda integrity and erc

2014-01-09 Thread Schlacta, Christ
What mechanisms does amanda provide to guarantee the following:

1) what was on the original drive is what is sent to the backup server
2) what was sent to the backup server is what's written to the archive
3) what's written to the archive is what's rerouted from backup
4) that any errors encountered at any of the above, or any other step in
the backup process can be recovered from, at least up to a certain level of
resiliency

I've scoured the faq and manuals and don't recall seeing answers to any of
this.