Discussion:
Bug#869515: amanda-server: Amanda taper does not respect taperflush criteria
Winston Sorfleet
2017-07-23 20:58:11 UTC
Permalink
Package: amanda-server
Version: 1:3.3.9-5
Severity: normal
Tags: newcomer

Dear Maintainer,

Amdump leaves dumps on holding disk despite taperflush being 0 (and thus
anything above 0% capacity of a single volume is supposed to be flushed
to tape).

E.g.

/usr/sbin/amdump vtl

Mailed output at job completion:

Hostname: flamen
Org : Romanus
Config : vtl
Date : July 20, 2017

These dumps were to tapes vtl36, vtl37.
Not using all tapes because taperflush criteria not met.
Run amflush to flush them to tape.

The next 6 tapes Amanda expects to use are: vtl38, vtl39, vtl40, vtl1,
vtl8, vtl9.
...


FAILURE DUMP SUMMARY:
flamen.romanus.ca / lev 1 partial taper: taperflush criteria not met

STRANGE DUMP SUMMARY:
forum.romanus.ca / lev 1 STRANGE (see below)
pomerium.romanus.ca / lev 1 STRANGE (see below)
flamen.romanus.ca / lev 1 STRANGE (see below)
flamen.romanus.ca /home lev 0 STRANGE (see below)


STATISTICS:
Total Full Incr. Level:#
-------- -------- -------- --------
Estimate Time (hrs:min) 0:06
Run Time (hrs:min) 3:10
Dump Time (hrs:min) 2:02 1:33 0:29
Output Size (meg) 44907.1 36394.2 8512.8
Original Size (meg) 57055.0 43962.1 13092.9
Avg Compressed Size (%) 78.7 82.8 65.0
DLEs Dumped 4 1 3 1:3
Avg Dump Rate (k/s) 6265.9 6672.3 4971.4

Tape Time (hrs:min) 1:31 1:26 0:05
Tape Size (meg) 38608.4 36394.2 2214.2
Tape Used (%) 200.0 188.5 11.5
DLEs Taped 4 1 3 1:3
Parts Taped 81 74 7 1:7
Avg Tp Write Rate (k/s) 7247.5 7237.9 7409.6

USAGE BY TAPE:
Label Time Size % DLEs Parts
vtl36 0:45 19G 100.0 3 41
vtl37 0:45 19G 100.0 1 40


Expected outcome:
Amtape should completely fill vtl36 and vtl37, and partially fill vtl38.

Workaround is to manually run amflush afterwards.

This is likely related to upstream report "Data stuck on holding disk"
https://github.com/zmanda/amanda/issues/69



-- System Information:
Debian Release: 9.0
APT prefers stable
APT policy: (900, 'stable'), (800, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages amanda-server depends on:
ii amanda-common 1:3.3.9-5
ii bsd-mailx [mailx] 8.1.2-0.20160123cvs-4
ii libc6 2.24-11
ii libcurl3 7.52.1-5
ii libglib2.0-0 2.50.3-2
ii libssl1.1 1.1.0f-3
ii perl 5.24.1-3

amanda-server recommends no packages.

Versions of packages amanda-server suggests:
ii amanda-client 1:3.3.9-5
ii cpio 2.11+dfsg-6
ii gnuplot 5.0.5+dfsg1-6
ii mt-st 1.3-1

-- no debconf information
Jose M Calhariz
2017-07-24 12:17:09 UTC
Permalink
Hi,

Can you please attach your amanda,conf file and a listing of the
contents of your
holdingdisk?

Kind regards
Jose M Calhariz
Post by Winston Sorfleet
Package: amanda-server
Version: 1:3.3.9-5
Severity: normal
Tags: newcomer
Dear Maintainer,
Amdump leaves dumps on holding disk despite taperflush being 0 (and thus
anything above 0% capacity of a single volume is supposed to be flushed
to tape).
E.g.
/usr/sbin/amdump vtl
Hostname: flamen
Org : Romanus
Config : vtl
Date : July 20, 2017
These dumps were to tapes vtl36, vtl37.
Not using all tapes because taperflush criteria not met.
Run amflush to flush them to tape.
The next 6 tapes Amanda expects to use are: vtl38, vtl39, vtl40, vtl1,
vtl8, vtl9.
...
flamen.romanus.ca / lev 1 partial taper: taperflush criteria not met
forum.romanus.ca / lev 1 STRANGE (see below)
pomerium.romanus.ca / lev 1 STRANGE (see below)
flamen.romanus.ca / lev 1 STRANGE (see below)
flamen.romanus.ca /home lev 0 STRANGE (see below)
Total Full Incr. Level:#
-------- -------- -------- --------
Estimate Time (hrs:min) 0:06
Run Time (hrs:min) 3:10
Dump Time (hrs:min) 2:02 1:33 0:29
Output Size (meg) 44907.1 36394.2 8512.8
Original Size (meg) 57055.0 43962.1 13092.9
Avg Compressed Size (%) 78.7 82.8 65.0
DLEs Dumped 4 1 3 1:3
Avg Dump Rate (k/s) 6265.9 6672.3 4971.4
Tape Time (hrs:min) 1:31 1:26 0:05
Tape Size (meg) 38608.4 36394.2 2214.2
Tape Used (%) 200.0 188.5 11.5
DLEs Taped 4 1 3 1:3
Parts Taped 81 74 7 1:7
Avg Tp Write Rate (k/s) 7247.5 7237.9 7409.6
Label Time Size % DLEs Parts
vtl36 0:45 19G 100.0 3 41
vtl37 0:45 19G 100.0 1 40
Amtape should completely fill vtl36 and vtl37, and partially fill vtl38.
Workaround is to manually run amflush afterwards.
This is likely related to upstream report "Data stuck on holding disk"
https://github.com/zmanda/amanda/issues/69
Debian Release: 9.0
APT prefers stable
APT policy: (900, 'stable'), (800, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
ii amanda-common 1:3.3.9-5
ii bsd-mailx [mailx] 8.1.2-0.20160123cvs-4
ii libc6 2.24-11
ii libcurl3 7.52.1-5
ii libglib2.0-0 2.50.3-2
ii libssl1.1 1.1.0f-3
ii perl 5.24.1-3
amanda-server recommends no packages.
ii amanda-client 1:3.3.9-5
ii cpio 2.11+dfsg-6
ii gnuplot 5.0.5+dfsg1-6
ii mt-st 1.3-1
-- no debconf information
Winston Sorfleet
2017-07-24 15:05:01 UTC
Permalink
Hi, > > Can you please attach your amanda,conf file and a listing of the >
contents of your > holdingdisk? > > Kind regards > Jose M Calhariz Hi,

The holding disk is just a pile of TARs in DLE format, e.g.

***@flamen:/amanda-holding-disk/20170720024701# ls
flamen.romanus.ca._.1 flamen.romanus.ca._.1.3 flamen.romanus.ca._.1.6
flamen.romanus.ca._.1.1 flamen.romanus.ca._.1.4 flamen.romanus.ca._.1.7
flamen.romanus.ca._.1.2 flamen.romanus.ca._.1.5 flamen.romanus.ca._.1.8

***@flamen:/amanda-holding-disk/20170720024701# head flamen.romanus.ca._.1
AMANDA: FILE 20170720024701 flamen.romanus.ca / lev 1 comp .gz program
/bin/tar
CONT_FILENAME=/amanda-holding-disk/20170720024701/flamen.romanus.ca._.1.1
ORIGSIZE=12540070
DLE=<<ENDDLE
<dle>
<program>GNUTAR</program>
<disk>/</disk>
<level>1</level>
<auth>bsdtcp</auth>
<compress>FAST</compress>

And just to be certain...

***@flamen:/etc/amanda/vtl# amgetconf vtl taperflush
0


Attached are amanda.conf and advanced.conf (the template dumptypes and
tapetypes are the standard distribution).

Many thanks,
Jose M Calhariz
2017-07-24 15:29:30 UTC
Permalink
I am not certain that I understand your problem, so beer with me.
# reserve 30 # percent
# This means save at least 30% of the holding disk space for degraded
# mode backups.
autoflush no
# if autoflush is set to yes, then amdump will schedule all dump on
# holding disks to be flush to tape during the run.
Can you turn "autoflush yes", and check if it solves your problem.


Kind regards

Jose M Calhariz
Jose M Calhariz
2017-07-30 19:30:05 UTC
Permalink
I think the bug you describe is fixed in the new amanda 3.4.x. I am
preparing a new package for sid and for stretch-backports.
Are you interested in testing it?
Tried this in yesterday's cron job, but turning autoflush to "yes" did
not fix the problem. My understanding is that it shouldn't anyways;
autoflush must be set to "yes" if taperflush is greater than 0, but that
wasn't the case.
I am not certain that I understand your problem, so beer with me. >
# reserve 30 # percent >> # This means save at least 30% of the
holding disk space for degraded >> # mode backups. >> >> autoflush no >>
# if autoflush is set to yes, then amdump will schedule all dump on >> #
holding disks to be flush to tape during the run. > > Can you turn
"autoflush yes", and check if it solves your problem. > > > Kind regards
Jose M Calhariz > > >
Kind regards
Jose M Calhariz

Loading...