Re: PARTIAL dump on my Fedora 26

[Jason L Tibbitts III]

> "HJ" == Henrik Johansson  writes:

HJ> How old are version 3.3.3?

It's pretty old, but Red Hat is incredibly conservative regarding
updates.  It was released on January 10, 2013 but Red Hat has almost
certainly applied multiple patches to it.

HJ> The version in Fedora 26 are 3.4.5 and version 3.5 was released
HJ> 2017-09-28?

Yes.  3.5 is in Fedora rawhide and will hopefully be in Fedora 27 when
it is released.  (I have been out of town for a week and haven't had a
chance to do much testing on it but I will try to get an update
generated tomorrow.)  If you want 3.5 for Fedora 26 then I can give you
packages, but I don't think we'll be upgrading F26 (or F25) because of
the requirement for tcp_port_range in amanda-security.conf.  It's not
nice when an update causes your machine to start spamming you.

(In case it isn't obvious, I help maintain Amanda in Fedora.)

 - J<

Re: dump failed: [request failed: No route to host](too)

[Tom Robinson]

I've updated the server to amanda-backup_server-3.5-1 (64bit) which appears to 
have fixed the issue.
The client that failed most regularly is running amanda-backup_client-3.3.9-1 
(32bit).

I'll keep monitoring this in case the situation changes but it looks like it's 
working properly now.

On 05/10/17 08:58, Tom Robinson wrote:
>
> It may well be just that I can't see the wood for the trees when looking at 
> logging but I can't
> find the problem :-(
>
> I'm running daily manual dumps of the FAILED DLE's to keep backups intact!
>
> I'm still getting the following:
>
> FAILURE DUMP SUMMARY:
>   bentley Resources lev 1  FAILED [too many dumper retry: [request failed: No 
> route to host]]
>   bentley sysadmin lev 1  FAILED [too many dumper retry: [request failed: No 
> route to host]]
>
> Apart from the two KVM hosts, all these systems are KVM Guests. The backup 
> server is a KVM guest.
> Has anyone seen or know of issues that may occur with amanda on virtualised 
> infrastructure?
>
> From my understanding of KVM networking between guests, whole network frames 
> are dumped and picked
> up between them. This allows higher transport speeds. I've tested the 
> throughput with iperf and
> have seen througput as high as 25Gbps. The following ipef session shows the 
> connection between the
> failed guest, bentley, and the backup server. I've only shown the 'server' 
> side results for iperf
> below:
>
> # systemctl stop xinetd
>
> # iperf -p 10080 -s
> 
> Server listening on TCP port 10080
> TCP window size: 85.3 KByte (default)
> 
> [  4] local 10.0.19.21 port 10080 connected with 192.168.0.3 port 39214
> [ ID] Interval   Transfer Bandwidth
> [  4]  0.0-10.0 sec  20.5 GBytes  17.6 Gbits/sec
> [  4] local 10.0.19.21 port 10080 connected with 192.168.0.3 port 39215
> [  4]  0.0-10.0 sec  20.7 GBytes  17.8 Gbits/sec
> [  4] local 10.0.19.21 port 10080 connected with 192.168.0.3 port 39218
> [  4]  0.0-10.0 sec  21.3 GBytes  18.3 Gbits/sec
> [  4] local 10.0.19.21 port 10080 connected with 192.168.0.3 port 39223
> [  4]  0.0-10.0 sec  21.4 GBytes  18.4 Gbits/sec
>
> Any clues/help for the above are appreciated.
>
> I'm now also getting some other strange errors that I've never seen before. 
> These report as
> 'FAILED' but further on into the report they appear to have completed without 
> issue. What do the
> error codes signify (e.g. FAILED [02-00098] etc.)?
>
> ---8<---
>
> FAILURE DUMP SUMMARY:
> ---8<---
>   bentley ECN lev 0  FAILED [02-00098]
>   bentley Repair lev 1  FAILED [06-00229]
>   garage /var lev 1  FAILED [shm_ring cancelled]
>   modena /usr/src lev 1  FAILED [12-00205]
>
> ---8<---
> NOTES:
>   planner: Last full dump of bentley:ECN on tape daily02 overwritten in 5 
> runs.
>   planner: Last level 1 dump of bentley:ECN on tape daily01 overwritten in 4 
> runs.
>   planner: Last full dump of bentley:Repair on tape daily07 overwritten in 2 
> runs.
>   planner: Last full dump of garage:/var on tape daily01 overwritten in 4 
> runs.
>
> ---8<---
> DUMP SUMMARY:
>  DUMPER STATS 
> TAPER STATS
> HOSTNAME DISK  L   ORIG-KB OUT-KB  COMP%  MMM:SS
> KB/s MMM:SS KB/s
>  --- 
> --- ---
> ---8<---
> bentley  ECN   0 19790  19790-- 0:03  
> 7325.0   0:00 197900.0
> bentley  Repair110   0.00:00 
> 4.2   0:00  0.0
> garage   /var  1  7000   7000-- 0:00 
> 33341.0   0:00  7.0
> modena   /usr/src  1   190 147.40:04 
> 3.3   0:00140.0
> ---8<---
>
>
> What are the error codes and did amanda dump these OK or not?
>
> Kind regards,
> Tom
>
>
> Tom Robinson
> IT Manager/System Administrator
>
> MoTeC Pty Ltd
>
> 121 Merrindale Drive
> Croydon South
> 3136 Victoria
> Australia
>
> T: +61 3 9761 5050
> F: +61 3 9761 5051   
> E: tom.robin...@motec.com.au
> On 13/09/17 23:09, Jean-Louis Martineau wrote:
>> Tom,
>>
>> It is the system that return the "No route to host" error.
>> You should check your system log (on server, client, router, firewall, nat, 
>> ...) for network error.
>>
>> Jean-Louis
>>
>> On 12/09/17 06:01 PM, Tom Robinson wrote:
>>> bump
>>>
>>> On 11/09/17 12:45, Tom Robinson wrote:
>>> > Hi,
>>> >
>>> > I've recently migrated our backup server from CentOS 5 to CentOS 7. I've 
>>> > also upgraded from amanda
>>> > 3.3.7 to 3.4.5
>>> >
>>> > The amcheck works fine and reports no issues. Yet, on backup runs on some 
>>> > DLEs I get the error:
>>> >
>>> > dump failed: [request failed: No route to host](too)
>>> >
>>> > It also appears to be random as to which DLEs fail. Sometimes it's just 
>>> > one or two on a client.
>>> > 

Re: PARTIAL dump on my Fedora 26

[Henrik Johansson]

Hi,

Extract some lines from the report:
...
*** A TAPE ERROR OCCURRED: [/usr/lib64/amanda/chg-disk: need 'rwx' 
access to '/etc/amanda/DailySet1'].

There are 76842540K of dumps left in the holding disk.
Run amflush to flush them to tape.

The next tape Amanda expects to use is: DailySet1-18.
STRANGE DUMP SUMMARY:
  uw000140.kank.se / lev 1  STRANGE (see below)
  uw000140.kank.se /home lev 1  STRANGE (see below)

uw000140.kank.se    /   1  3703760  3703760 --    8:12 7525.0
uw000140.kank.se    /boot   1   40   40 --    0:00 347.0
uw000140.kank.se    /home   1 72334740 72334740 --  136:56 8803.9

I've changed owner and group of /etc/amanda/DailySet1, and started 
'amflush DailySet1'.

'amflush DailySet1' moved 46 GB to DailySet1-18.

Henrik


On 2017-10-08 22:33, Jon LaBadie wrote:

On Sun, Oct 08, 2017 at 10:53:35AM +0200, Henrik Johansson wrote:

Hi again,

I checked this list once again and a similar problem (attached).
My server has CentOS-7 and the problem started after the upgrade:
     Updated amanda-3.3.3-17.el7.x86_64   @base
     Update 3.3.3-18.el7.x86_64   @base
     Updated amanda-client-3.3.3-17.el7.x86_64    @base
     Update 3.3.3-18.el7.x86_64    @base
     Updated amanda-libs-3.3.3-17.el7.x86_64  @base
     Update 3.3.3-18.el7.x86_64  @base
     Updated amanda-server-3.3.3-17.el7.x86_64    @base
     Update 3.3.3-18.el7.x86_64    @base

I've tried to downgrade, but the old package aren't available.

Henrik,

I too am running my amanda server on CentOS7.

I do not remember the symptoms but I could not get the CentOS
packages running to my satisfaction.  It may have been that
I could not get "on demand" backup from laptops with the
CentOS packages.

I elected to remove the CentOS packages and install a package
from the Zamanda website built for RHEL7.  The version I
installed was 3.4.1-1 and there are several newer versions
available now.

The changeover for me was painless.  I don't think I had to
make a single configuration change.  YMMV.

BTW I run with both user "amanda" and "amandabackup".  I.e.
separate /etc/{passwd,group} entries but same user data.
I started this at a time when the OS packages used amanda
and the Zmanda packages used amandabackup.  Now it is just
easier to "su amanda" rather than "su amandabackup"  :))

Jon


--

Henrik Johansson

E-mail:   henrik.johansson.k...@mail.se
Voice:+46 924 50129
Mobile:   +46 70 555 9998
S Prästholm 799, S-955 91 Råneå, Sweden