Re: Always fill every tape

[Jason L Tibbitts III]

> "DSB" == Debra S Baddorf  writes:

DSB> Well, if it’s already not doing what you want, you might read
DSB> these.

Well, yeah, that's pretty much the same as I indicated that I'm using
now, except that I'm using different thresholds.  My problem is that I
asked for at least 70% usage and it's giving me just about 50%.  I also
checked the logs and it seems that it basically flushes every other day,
which is consistent with it always flushing existing dumps to tape at
startup.  So I'll turn off autoflush and see if that makes any
difference.

 - J<

Re: Always fill every tape

[Debra S Baddorf]

> On Mar 9, 2018, at 1:43 PM, Jason L Tibbitts III  wrote:
> 
> With tape sizes what they are now I'm finally at the point where I have
> way more tape than stuff to back up.  To satisfy my inherent laziness,
> I'd like to actually fill every tape (or at least come close to filling
> them).  And then just leave my library full of tapes without ever
> needing to change them out.
> 
> My understanding is that Amanda has no way to append to tapes; once it
> has started writing to a tape, that tape won't be used again until the
> next pass through the tapecycle.  That implies that you must keep
> backups on the holding disk and write them only when you'll have a
> nearly-full tape.  I have plenty of holding disk (at least until I move
> to LTO8) so that isn't an issue.
> 
> Currently I have these in amanda.conf:
> 
> tapecycle 47 tapes
> autoflush yes
> taperflush 70
> flush-threshold-dumped 70
> flush-threshold-scheduled 90
> 
> Is that basically all I'm supposed to do?  Because according to the
> reports, each tape is only getting about 50% full.  So I think I must be
> missing something about how those four flush-related parameters
> interact.
> 
> - J<

Well, if it’s already not doing what you want,  you might read these.  They’re 
from an
example  amanda.conf,   but I don’t know how current my copy is.

# You don't want to use a new tape for every run, but want to start writing
# to tape as soon as possible:
# flush-threshold-dumped0   # (or more)
# flush-threshold-scheduled 100 # (or more)
# taperflush100
# autoflush yes
# maxdumpsize   100k # amount of data to dump each run; see above.
#
# You want to keep the most recent dumps on holding disk, for faster recovery.
# Older dumps will be rotated to tape during each run.
# flush-threshold-dumped300 # (or more)
# flush-threshold-scheduled 300 # (or more)
# taperflush300
# autoflush yes

Deb Baddorf

Always fill every tape

[Jason L Tibbitts III]

With tape sizes what they are now I'm finally at the point where I have
way more tape than stuff to back up.  To satisfy my inherent laziness,
I'd like to actually fill every tape (or at least come close to filling
them).  And then just leave my library full of tapes without ever
needing to change them out.

My understanding is that Amanda has no way to append to tapes; once it
has started writing to a tape, that tape won't be used again until the
next pass through the tapecycle.  That implies that you must keep
backups on the holding disk and write them only when you'll have a
nearly-full tape.  I have plenty of holding disk (at least until I move
to LTO8) so that isn't an issue.

Currently I have these in amanda.conf:

tapecycle 47 tapes
autoflush yes
taperflush 70
flush-threshold-dumped 70
flush-threshold-scheduled 90

Is that basically all I'm supposed to do?  Because according to the
reports, each tape is only getting about 50% full.  So I think I must be
missing something about how those four flush-related parameters
interact.

 - J<

constant crash on arm64

[Gene Heskett]

On a rock64 TBE. Locally built 3.3.7p1 here as master, client is whatever 
is in the debian stretch repo's. 

I will reboot it, and compose an excludes file by the time another dump 
starts. There is an excludes file now, but it exists because it was 
touched, by amanda. That got rid of the last amcheck fuss.
 
More tommorrow I expect. Its running fine on a pi, which is armhf. But 
this arm64 seems to be a bit fussier. It also has 20x the i/o bandwidth 
the pi has.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Community ZWC Issue

[Paddy Sreenivasan]

   1. Open the ZWC Config Utility: Start Menu → All Programs → Zmanda → Zmanda
   Client for Windows → ZWC Config Utility
   2. Select the Logging tab
   3. Set Log Level to 5
   4. Click Save
   5. Click Exit



On Fri, Mar 9, 2018 at 5:59 AM, Chris Nighswonger <
cnighswon...@foundations.edu> wrote:

> Jean-Louis can you help with this? Is there a way to up the verbosity
> level of the ZWC log?
>
>
> On Tue, Feb 27, 2018 at 10:43 AM, Chris Nighswonger <
> cnighswon...@foundations.edu> wrote:
>
>> No takers?
>>
>> The ZWC is always a hard one to gin up help for.
>>
>> An additional piece of information: DNS resolution seems to be working
>> fine both server and client side.
>>
>>
>>
>> On Fri, Feb 23, 2018 at 8:34 AM, Chris Nighswonger <
>> cnighswon...@foundations.edu> wrote:
>>
>>> Any thoughts on what might be going on here?
>>>
>>> Last week I began to have numerous Win10 clients failing in this fashion:
>>>
>>> backup@scriptor:/home/manager amcheck -c campus shipping.foo.bar
>>>
>>> Amanda Backup Client Hosts Check
>>> 
>>> ERROR: shipping.foo.bar: Server validation Failed. Please register
>>> server with client.
>>> Client check: 1 host checked in 0.072 seconds.  1 problem found.
>>>
>>> Taking a look at the ZWC debug log on that client, I see the following:
>>>
>>> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Entering
>>> ExecuteValidateServerJob
>>> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Server address to be
>>> validated from the list of authentic server = 192.168.x.x
>>> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Server name =
>>> 192.168.x.x
>>> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Authentic Server name
>>> = scriptor.foo.bar
>>> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Server Validation
>>> Failed - Server 192.168.x.x With IP 192.168.x.x is not registered
>>> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Leaving
>>> ExecuteValidateServerJob
>>>
>>> However, the server is registered with the client:
>>>
>>> Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Zmanda\ZWC\1.0\Install\Servers
>>> value is 'scriptor.foo.bar'
>>>
>>> If I add the server IP (192.168.x.x) to the list of registered Servers,
>>> everything checks out fine:
>>>
>>> backup@scriptor:/home/manager amcheck -c campus shipping.foo.bar
>>>
>>> Amanda Backup Client Hosts Check
>>> 
>>> Client check: 1 host checked in 0.071 seconds.  0 problems found.
>>>
>>> (brought to you by Amanda 3.3.6)
>>>
>>> And the ZWC debug log says:
>>>
>>> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Entering
>>> ExecuteValidateServerJob
>>> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Server address to be
>>> validated from the list of authentic server = 192.168.2.203
>>> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Server name =
>>> 192.168.x.x
>>> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Authentic Server
>>> name = scriptor.foo.bar
>>> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Authentic Server
>>> name = 192.168.x.x
>>> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Leaving
>>> ExecuteValidateServerJob
>>>
>>> Thanks,
>>> Chris
>>>
>>
>>
>

Re: Community ZWC Issue

[Chris Nighswonger]

amservice must be run as root

root@scriptor:/home/manager# amservice shipping.foo.bar
 bsdtcp noop  wrote:

> More (apparently conflicting) information. A noop works in amcheck, but
> not directly from amservice.
>
> Packet Dump server-side:
>
> ...Q.SECURITY USER backup
>
> SERVICE noop
>
> OPTIONS features=9efefbff3f;
>
> ..,.OPTIONS features=ff7f9cfed3cf1300;
>
> ...SECURITY USER backup
>
> SERVICE selfcheck
>
> OPTIONS features=9efefbff3f;maxdumps=1;hostname=
> shipping.foo.bar;config=campus;
>
> 
>
> DUMP
>
> SERVER
>
> C:/Program_
> Files_(x86)/Stamps.com_Internet_Postage
>
> bsdtcp
>
> FAST
>
> YES
>
> YES
>
> 
>
> 
>
> DUMP
>
> SERVER
>
> C:/Users/auser
>
> bsdtcp
>
> FAST
>
> YES
>
> YES
>
> 
>
> C:_Users_auser_AppData_Local_Temp
>
> 
>
> 
>
> ..E.ERROR Server validation Failed. Please register
> server with client.
>
> ..
>
> The results of an amservice noop server-side:
>
> backup@scriptor:~ amservice shipping.foo.bar bsdtcp noop  Request failed: Permission denied
>
>
> On Fri, Mar 9, 2018 at 9:20 AM, Chris Nighswonger <
> cnighswon...@foundations.edu> wrote:
>
>> One additional note: The wiki seems to think that name resolution has not
>> been working since sometime in 2010. However, it has worked fine for me for
>> years up until about a month ago.
>>
>>
>>
>> On Fri, Mar 9, 2018 at 8:59 AM, Chris Nighswonger <
>> cnighswon...@foundations.edu> wrote:
>>
>>> Jean-Louis can you help with this? Is there a way to up the verbosity
>>> level of the ZWC log?
>>>
>>>
>>>
>>> On Tue, Feb 27, 2018 at 10:43 AM, Chris Nighswonger <
>>> cnighswon...@foundations.edu> wrote:
>>>
 No takers?

 The ZWC is always a hard one to gin up help for.

 An additional piece of information: DNS resolution seems to be working
 fine both server and client side.



 On Fri, Feb 23, 2018 at 8:34 AM, Chris Nighswonger <
 cnighswon...@foundations.edu> wrote:

> Any thoughts on what might be going on here?
>
> Last week I began to have numerous Win10 clients failing in this
> fashion:
>
> backup@scriptor:/home/manager amcheck -c campus shipping.foo.bar
>
> Amanda Backup Client Hosts Check
> 
> ERROR: shipping.foo.bar: Server validation Failed. Please register
> server with client.
> Client check: 1 host checked in 0.072 seconds.  1 problem found.
>
> Taking a look at the ZWC debug log on that client, I see the following:
>
> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Entering
> ExecuteValidateServerJob
> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Server address to
> be validated from the list of authentic server = 192.168.x.x
> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Server name =
> 192.168.x.x
> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Authentic Server
> name = scriptor.foo.bar
> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Server Validation
> Failed - Server 192.168.x.x With IP 192.168.x.x is not registered
> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Leaving
> ExecuteValidateServerJob
>
> However, the server is registered with the client:
>
> Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Zmanda\ZWC\1.0\Install\Servers
> value is 'scriptor.foo.bar'
>
> If I add the server IP (192.168.x.x) to the list of registered
> Servers, everything checks out fine:
>
> backup@scriptor:/home/manager amcheck -c campus shipping.foo.bar
>
> Amanda Backup Client Hosts Check
> 
> Client check: 1 host checked in 0.071 seconds.  0 problems found.
>
> (brought to you by Amanda 3.3.6)
>
> And the ZWC debug log says:
>
> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Entering
> ExecuteValidateServerJob
> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Server address to
> be validated from the list of authentic server = 192.168.2.203
> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Server name =
> 192.168.x.x
> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Authentic Server
> name = scriptor.foo.bar
> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Authentic Server
> name = 192.168.x.x
> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Leaving
> ExecuteValidateServerJob
>
> Thanks,
> Chris
>


>>>
>>
>

Re: Community ZWC Issue

[Chris Nighswonger]

More (apparently conflicting) information. A noop works in amcheck, but not
directly from amservice.

Packet Dump server-side:

...Q.SECURITY USER backup

SERVICE noop

OPTIONS features=9efefbff3f;

..,.OPTIONS features=ff7f9cfed3cf1300;

...SECURITY USER backup

SERVICE selfcheck

OPTIONS
features=9efefbff3f;maxdumps=1;hostname=shipping.foo.bar;config=campus;



DUMP

SERVER

C:/Program_Files_(x86)/Stamps.com_Internet_Postage

bsdtcp

FAST

YES

YES





DUMP

SERVER

C:/Users/auser

bsdtcp

FAST

YES

YES



C:_Users_auser_AppData_Local_Temp





..E.ERROR Server validation Failed. Please register server
with client.

..

The results of an amservice noop server-side:

backup@scriptor:~ amservice shipping.foo.bar bsdtcp noop  wrote:

> One additional note: The wiki seems to think that name resolution has not
> been working since sometime in 2010. However, it has worked fine for me for
> years up until about a month ago.
>
>
>
> On Fri, Mar 9, 2018 at 8:59 AM, Chris Nighswonger <
> cnighswon...@foundations.edu> wrote:
>
>> Jean-Louis can you help with this? Is there a way to up the verbosity
>> level of the ZWC log?
>>
>>
>>
>> On Tue, Feb 27, 2018 at 10:43 AM, Chris Nighswonger <
>> cnighswon...@foundations.edu> wrote:
>>
>>> No takers?
>>>
>>> The ZWC is always a hard one to gin up help for.
>>>
>>> An additional piece of information: DNS resolution seems to be working
>>> fine both server and client side.
>>>
>>>
>>>
>>> On Fri, Feb 23, 2018 at 8:34 AM, Chris Nighswonger <
>>> cnighswon...@foundations.edu> wrote:
>>>
 Any thoughts on what might be going on here?

 Last week I began to have numerous Win10 clients failing in this
 fashion:

 backup@scriptor:/home/manager amcheck -c campus shipping.foo.bar

 Amanda Backup Client Hosts Check
 
 ERROR: shipping.foo.bar: Server validation Failed. Please register
 server with client.
 Client check: 1 host checked in 0.072 seconds.  1 problem found.

 Taking a look at the ZWC debug log on that client, I see the following:

 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Entering
 ExecuteValidateServerJob
 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Server address to be
 validated from the list of authentic server = 192.168.x.x
 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Server name =
 192.168.x.x
 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Authentic Server
 name = scriptor.foo.bar
 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Server Validation
 Failed - Server 192.168.x.x With IP 192.168.x.x is not registered
 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Leaving
 ExecuteValidateServerJob

 However, the server is registered with the client:

 Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Zmanda\ZWC\1.0\Install\Servers
 value is 'scriptor.foo.bar'

 If I add the server IP (192.168.x.x) to the list of registered Servers,
 everything checks out fine:

 backup@scriptor:/home/manager amcheck -c campus shipping.foo.bar

 Amanda Backup Client Hosts Check
 
 Client check: 1 host checked in 0.071 seconds.  0 problems found.

 (brought to you by Amanda 3.3.6)

 And the ZWC debug log says:

 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Entering
 ExecuteValidateServerJob
 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Server address to
 be validated from the list of authentic server = 192.168.2.203
 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Server name =
 192.168.x.x
 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Authentic Server
 name = scriptor.foo.bar
 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Authentic Server
 name = 192.168.x.x
 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Leaving
 ExecuteValidateServerJob

 Thanks,
 Chris

>>>
>>>
>>
>

Re: Community ZWC Issue

[Chris Nighswonger]

One additional note: The wiki seems to think that name resolution has not
been working since sometime in 2010. However, it has worked fine for me for
years up until about a month ago.


On Fri, Mar 9, 2018 at 8:59 AM, Chris Nighswonger <
cnighswon...@foundations.edu> wrote:

> Jean-Louis can you help with this? Is there a way to up the verbosity
> level of the ZWC log?
>
>
>
> On Tue, Feb 27, 2018 at 10:43 AM, Chris Nighswonger <
> cnighswon...@foundations.edu> wrote:
>
>> No takers?
>>
>> The ZWC is always a hard one to gin up help for.
>>
>> An additional piece of information: DNS resolution seems to be working
>> fine both server and client side.
>>
>>
>>
>> On Fri, Feb 23, 2018 at 8:34 AM, Chris Nighswonger <
>> cnighswon...@foundations.edu> wrote:
>>
>>> Any thoughts on what might be going on here?
>>>
>>> Last week I began to have numerous Win10 clients failing in this fashion:
>>>
>>> backup@scriptor:/home/manager amcheck -c campus shipping.foo.bar
>>>
>>> Amanda Backup Client Hosts Check
>>> 
>>> ERROR: shipping.foo.bar: Server validation Failed. Please register
>>> server with client.
>>> Client check: 1 host checked in 0.072 seconds.  1 problem found.
>>>
>>> Taking a look at the ZWC debug log on that client, I see the following:
>>>
>>> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Entering
>>> ExecuteValidateServerJob
>>> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Server address to be
>>> validated from the list of authentic server = 192.168.x.x
>>> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Server name =
>>> 192.168.x.x
>>> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Authentic Server name
>>> = scriptor.foo.bar
>>> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Server Validation
>>> Failed - Server 192.168.x.x With IP 192.168.x.x is not registered
>>> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Leaving
>>> ExecuteValidateServerJob
>>>
>>> However, the server is registered with the client:
>>>
>>> Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Zmanda\ZWC\1.0\Install\Servers
>>> value is 'scriptor.foo.bar'
>>>
>>> If I add the server IP (192.168.x.x) to the list of registered Servers,
>>> everything checks out fine:
>>>
>>> backup@scriptor:/home/manager amcheck -c campus shipping.foo.bar
>>>
>>> Amanda Backup Client Hosts Check
>>> 
>>> Client check: 1 host checked in 0.071 seconds.  0 problems found.
>>>
>>> (brought to you by Amanda 3.3.6)
>>>
>>> And the ZWC debug log says:
>>>
>>> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Entering
>>> ExecuteValidateServerJob
>>> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Server address to be
>>> validated from the list of authentic server = 192.168.2.203
>>> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Server name =
>>> 192.168.x.x
>>> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Authentic Server
>>> name = scriptor.foo.bar
>>> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Authentic Server
>>> name = 192.168.x.x
>>> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Leaving
>>> ExecuteValidateServerJob
>>>
>>> Thanks,
>>> Chris
>>>
>>
>>
>

Re: Community ZWC Issue

[Chris Nighswonger]

Jean-Louis can you help with this? Is there a way to up the verbosity level
of the ZWC log?


On Tue, Feb 27, 2018 at 10:43 AM, Chris Nighswonger <
cnighswon...@foundations.edu> wrote:

> No takers?
>
> The ZWC is always a hard one to gin up help for.
>
> An additional piece of information: DNS resolution seems to be working
> fine both server and client side.
>
>
>
> On Fri, Feb 23, 2018 at 8:34 AM, Chris Nighswonger <
> cnighswon...@foundations.edu> wrote:
>
>> Any thoughts on what might be going on here?
>>
>> Last week I began to have numerous Win10 clients failing in this fashion:
>>
>> backup@scriptor:/home/manager amcheck -c campus shipping.foo.bar
>>
>> Amanda Backup Client Hosts Check
>> 
>> ERROR: shipping.foo.bar: Server validation Failed. Please register server
>> with client.
>> Client check: 1 host checked in 0.072 seconds.  1 problem found.
>>
>> Taking a look at the ZWC debug log on that client, I see the following:
>>
>> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Entering
>> ExecuteValidateServerJob
>> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Server address to be
>> validated from the list of authentic server = 192.168.x.x
>> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Server name =
>> 192.168.x.x
>> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Authentic Server name
>> = scriptor.foo.bar
>> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Server Validation
>> Failed - Server 192.168.x.x With IP 192.168.x.x is not registered
>> 11020:9144:23/2/2018:08:16:7:22::CZWCJobHandler : Leaving
>> ExecuteValidateServerJob
>>
>> However, the server is registered with the client:
>>
>> Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Zmanda\ZWC\1.0\Install\Servers
>> value is 'scriptor.foo.bar'
>>
>> If I add the server IP (192.168.x.x) to the list of registered Servers,
>> everything checks out fine:
>>
>> backup@scriptor:/home/manager amcheck -c campus shipping.foo.bar
>>
>> Amanda Backup Client Hosts Check
>> 
>> Client check: 1 host checked in 0.071 seconds.  0 problems found.
>>
>> (brought to you by Amanda 3.3.6)
>>
>> And the ZWC debug log says:
>>
>> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Entering
>> ExecuteValidateServerJob
>> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Server address to be
>> validated from the list of authentic server = 192.168.2.203
>> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Server name =
>> 192.168.x.x
>> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Authentic Server name
>> = scriptor.foo.bar
>> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Authentic Server name
>> = 192.168.x.x
>> 11020:8956:23/2/2018:08:21:17:29::CZWCJobHandler : Leaving
>> ExecuteValidateServerJob
>>
>> Thanks,
>> Chris
>>
>
>

Re: installing on Centos 7 - some newbee questions

[Austin S. Hemmelgarn]

On 2018-03-07 21:30, Ryan, Lyle (US) wrote:
Hello all.  I’m getting my first Amanda server running on Centos 7 and 
have a few questions:


- Centos is packaged with 3.3.3   Is that good enough or should I build 3.5?
Provided it's not missing any features you need and doesn't have any 
bugs that affect you, yeah it should be fine (and assuming of course 
you're not exposing it to the internet).  This applies even if you've 
got other versions on the network too (provided the protocols match up, 
it's perfectly possible to run differing versions of Amanda throughout 
the network).


- the server will use only disks, no tapes.   10TB, mostly all devoted 
to /home (though I could repartition)


- I believe I still use vtapes and a holding disk, even though they’ll 
all just be directories on the main partition.  sound right?
Yes.  The holding disk is actually pretty important even when using 
vtapes for two reasons:


1. It allows you to back-up DLE's that are larger than the size you've 
specified for your vtapes.
2. It lets you run multiple backups in parallel without having to jump 
through hoops to allow Amanda to write to multiple vtapes in parallel.


One quick tip regarding this type of configuration:  Try to match the 
part-size tapetype option and the chunksize option for the holding disk. 
 As stupid as it sounds, matching these actually improves performance 
by a measurable amount in most cases.  If you've got a bunch of big 
backups, 1GB is generally a reasonable size for both.


- I follow the instructions at 
https://wiki.zmanda.com/index.php/GSWA/Build_a_Basic_Configuration but 
when running amcheck get the error:


    can not stat /var/lib/Amanda/gnutar-lists

- indeed there is no file present there.  any ideas?
Just create it and set the correct permissions.  Strictly speaking, the 
package should create this when installed, but it seems a number of 
distributions' packages don't do so.