Amanda-Users

Re: Resuming amanda after 2 week hiatius due to upgrading to F10.

2009-03-07 12:52:31
Subject: Re: Resuming amanda after 2 week hiatius due to upgrading to F10.
From: Gene Heskett <gene.heskett AT verizon DOT net>
To: amanda-users AT amanda DOT org
Date: Sat, 07 Mar 2009 12:44:47 -0500
On Saturday 07 March 2009, Gene Heskett wrote:
>Greetings;
>
>I managed to destroy X somehow, and since I was running F8, it was time to
>update to F10, so I did, but turned amanda off till things settled a bit and
>some of the 'infant mortality' associated with an upgrade were sorted
>I am about to restart my backup scheme, and was wondering if I should just
>restore the line in amanda's crontab after I change the disk size in
>amanda.conf to something on the order of 80GB so it will get all 80 some GB
> of data in one pass, or should I leave it set at its present 15GB and pre
> run my chatchup script which will run a backup an arbitrary number of
> times, then enable the crontab entry once that has finished and a sort of
> schedule established.
>
>Since I now have a 1TB disk for amanda to play in,, I'm inclined to try the
>one pass gets it all, then reduce the disk size setting to something more
>reasonable after the actual size settles some.
>
>This new disk is faster:
>===============
>[root@coyote amanda-2.6.2alpha-20090227]# hdparm -tT /dev/sdc
>/dev/sdc:
> Timing cached reads:   4916 MB in  2.00 seconds = 2458.87 MB/sec
> Timing buffered disk reads:  332 MB in  3.01 seconds = 110.21 MB/sec
>===============
>than the /dumps disk is but not by much.  What would be the effect of de-
>specing the holding disk and let it write directly to this bigger disk?
>
>And I just built the 0227 version of 262alpha and ran amccheck of course,
> and I'll make a comment re speed:  2 years ago, amcheck usually completed
> in some random period averaging about .9 seconds.  As 262 has progressed,
> that is getting slower, TBE its about 2.4 seconds now, and the machine is
> about 4-5x faster now cuz its a 2.2Ghz AMD 9550 Quad core, with 4Gb of 800
> mhz ram to play in, where 2 years ago it was an XP-2800 single core running
> at 1.6GHZ actual, with only a gig of 333mhz ram.
>
>That seems like its going backwards to me.
>
>Comments anyone?
>
>Thanks.

Mmm, looks like I'm talking to myself.

The first backup went well ANAICT.  It smunched the whole thing down into 44 
gigabytes and change.  And it emailed me a report as if everything worked.  So 
that part of amreport worked.  However, it is also supposed to be printing 
that report, and it did not.  There have been other occasions when it didn't 
print, but they seem to be at maybe monthly intervals, and might be related to 
something I was doing.  Using FF, whose home page I have set to 
localhost:6311/printers, I found a job from amanda that wasn't printed on Dec 
31st 2008, so I emptied that queue.  Nothing else pending, and neither htop 
nor lsof can find any trace of a running amanda related function on the system 
now, so I assume it finished the amverify run also, which I am doing in my 
wrapper script.

Looking up the manpage for amreport, I issued the command (as amanda) 
"amreport Daily" and got this error:
/usr/bin/lpr: Error - no default destination available.
amreport: printer command failed: /usr/bin/lpr

But looking at the cups web page, lp1 is defined as the default printer.

An lpstat -a (as amanda) returns this:
[amanda@coyote amanda-2.6.2alpha-20090227]$ lpstat -a
CUPS-PDF accepting requests since Thu 08 Jan 2009 01:02:22 AM EST
lp0 accepting requests since Sun 04 Jan 2009 01:37:33 PM EST
lp1 accepting requests since Sat 07 Mar 2009 11:57:54 AM EST
lp2 accepting requests since Fri 28 Nov 2008 11:33:50 AM EST

Which are in fact all the same printer, just different performance profiles.
This is Fedora 10, and
[amanda@coyote amanda-2.6.2alpha-20090227]$ ls -l /usr/bin/lpr
lrwxrwxrwx 1 root root 23 2008-11-18 11:33 /usr/bin/lpr -> 
/etc/alternatives/print
A link.

Ok, still as amanda, I cd to /etc/alternatives and do another ls -l, which 
returns a very long list of links, and 'print' is a link to /usr/bin/lpr.cups.

cd'ing to /usr/bin, an ls -l lpr.cups finally gets me to what should be the 
file that does the work.
[amanda@coyote bin]$ ls -l lpr.cups
-rwxr-xr-x 1 root root 13868 2009-01-28 13:19 lpr.cups

This looks like a cups problem to me.  Permissions look ok.
And if I try to run amreport as root, it fusses at me just like its supposed 
to.

Has anyone else run into this yet?

Thanks.

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