Bug 1414520 - amanda-server does not work properly for disk backups
Summary: amanda-server does not work properly for disk backups
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: amanda
Version: 27
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Josef Ridky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-18 17:42 UTC by Ed Friedman
Modified: 2018-11-30 22:01 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-30 22:01:55 UTC
Type: Bug


Attachments (Terms of Use)
amanda.conf file (27.38 KB, text/plain)
2017-06-27 21:44 UTC, Ed Friedman
no flags Details

Description Ed Friedman 2017-01-18 17:42:16 UTC
Description of problem: 
Using the new amanda-server, the disk becomes filled up, although I'm not positive that this was due to the new version. When trying to run amflush, I received the error message " A TAPE ERROR OCCURRED: [No acceptable volumes found]" sent in the AMFLUSH MAIL REPORT. When I downgraded to amanda-server-3.3.9-3.fc25.x86_64, everything worked perfectly.

Version-Release number of selected component (if applicable):
amanda-server-3.4.1-1.fc25.x86_64

How reproducible:
Always

Steps to Reproduce:
1.Use a hard disk properly configured for amanda backups
2.Generate backups that require amflush to finish up
3.Run amflush

Actual results:
Amflush fails with an error message: A TAPE ERROR OCCURRED: [No acceptable volumes found]. No files in the target slot were deleted.

Expected results:
Amflush should work properly. All of the previous saved backups should be deleted in the target slot (and were when using amanda-server-3.3.9-3.fc25.x86_64)

Additional info:
Also, backups failed for a system running Solaris 5.10 with the SFWamnda amanda package, with the error message: badly formatted response from machinename. This error never occurred with amanda-server-3.3.9-3.fc25.x86_64.

Comment 1 Jason Tibbitts 2017-06-08 21:55:43 UTC
There have been several new versions since 3.4.1.  Currently 3.4.5 is on its way to updates-testing.  Please test these updates and let us know if the problem is still present.  And please do attach the relevant debug logs so we have something to examine, since there isn't much we can do without them besides look for anything which might look to be related in the release notes.

Also, please open a separate ticket for the second problem if it still exists.  Reporting two problems in one ticket just leads to confusion.

Comment 2 Ed Friedman 2017-06-27 16:37:09 UTC
How exactly do I get this 3.4.5 version?

Comment 3 Jason Tibbitts 2017-06-27 16:42:07 UTC
At this point you just update your system.  3.4.5 is the current version of the amanda packages in Fedora 24, 25, 26 and rawhide.

Comment 4 Ed Friedman 2017-06-27 21:04:51 UTC
I just install 3.4.5 and ran amcheck -s

The result was:

'/etc/amanda/ms/amanda.conf', line 73: warning: Keyword usetimestamps is deprecated.
Amanda Tape Server Host Check
-----------------------------
NOTE: Holding disk '/home/scratch/amanda': 127459328 KB disk space available, using 127356928 KB
'/etc/amanda/ms/amanda.conf', line 73: warning: Keyword usetimestamps is deprecated.
slot 1: Can't open tape device chg-disk: No such file or directory
all slots have been loaded
Taper scan algorithm did not find an acceptable volume.
    (expecting volume 'VOL16' or a new volume)
ERROR: No acceptable volumes found
Server check took 0.543 seconds
(brought to you by Amanda 3.4.5)

Needless to say, there are no problems at all with amanda 3.3.9 in backing up to my hard drive with using the file:// description for the tapedev.

Comment 5 Jason Tibbitts 2017-06-27 21:23:34 UTC
Well, that output is far more than has been provided previously in this ticket.

Obviously the 'usetimestamps' thing is merely a warning; it will be set to 'yes' regardless of what you specify.  It should simply be removed from your config to quiet the complaint.

I don't use vtapes myself, but I recall that the old chg-disk setting has been deprecated for some time and I believe it was finally removed in 3.4.  I have no idea what you have in your configuration since you have not provided it, but have you read through amanda-changers and adapted to the new chg-disk:VTAPEROOT driver?

Comment 6 Ed Friedman 2017-06-27 21:44:07 UTC
Created attachment 1292474 [details]
amanda.conf file

Here is my amanda.conf file

Comment 7 Ed Friedman 2017-06-27 21:46:23 UTC
I changed the tpchanger setting so that I no longer get the "Can't open tape device chg-disk" error message.

Here is the current error message that I get:

'/etc/amanda/ms/amanda.conf', line 73: warning: Keyword usetimestamps is deprecated.
Amanda Tape Server Host Check
-----------------------------
NOTE: Holding disk '/home/scratch/amanda': 127459328 KB disk space available, using 127356928 KB
'/etc/amanda/ms/amanda.conf', line 73: warning: Keyword usetimestamps is deprecated.
Searching for label 'VOL16':Label 'VOL16' not found
slot 0:Slot 0 not found
slot ?:Slot  not found
ERROR: Slot  not found

Comment 8 Jason Tibbitts 2017-06-27 22:47:18 UTC
I really have no experience with vtapes but it appears that by using

tapedev "file://backup/vtapes/ms/slots"

You're telling everything to use one single vtape.  I'm not sure the previous tpchanger line is even used at that point.  You're generally supposed to define a changer that has multiple vtapes and then reference the defined changer in a tapedev line.  But since my personal setup uses an actual tape drive and library, I'm just going by what I read at https://wiki.zmanda.com/index.php/How_To:Set_Up_Virtual_Tapes

I'm still not seeing where there's an actual bug here, though; this still appears to me to be a configuration issue.  You could argue that 3.4 should never been pushed to a stable release since it deprecated things which were working with older versions and I wouldn't disagree.  However, I wasn't involved with that and in fact got involved partly to sort out the issues which I personally ran into when 3.4 was pushed.  In any case, there's no way to go back now though you can of course use the dnf versionlock plugin to ensure that the amanda package is not updated on your machine(s).

If we could isolate an actual bug then I would be happy to coordinate with upstream to get a fix to you in a format you could test.

I would suggest at this point that you might have better luck with an email to the amanda-users list with your current config file and error output.

Comment 9 Ben Cotton 2018-11-27 15:07:44 UTC
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 10 Ben Cotton 2018-11-30 22:01:55 UTC
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.