The result: -bash-3.00$ /usr/sbin/amadmin Daily tape The next Amanda run should go onto a new tape. The next Amanda run should go onto a new tape. The next 2 new tapes already labelled are: Daily029, Daily028. -bash-3.00$ /usr/sbin/amflush -f Daily Scanning /var/tmp/amanda... Could not find any Amanda directories to flush. -bash-3.00$
-----Original Message----- From: [EMAIL PROTECTED] To: '[email protected]' Sent: 6/11/2005 11:50 PM Subject: RE: amdump waits forever for estimates from one host It was a firewall problem, though it's a little odd that one client had no problem and another did, since the firewall was on the backup server. With the firewall disabled (I'll attend to that later--the server and all the hosts are on a non-routable "inside" network) there's a new problem: a tape error. So I guess I have to do amadmin Daily tape amflush -f Daily These are the errors (slightly edited Subject: CUNY Graduate Center AMANDA MAIL REPORT FOR June 11, 2005 *** A TAPE ERROR OCCURRED: [new tape not found in rack]. Some dumps may have been left in the holding disk. Run amflush to flush them to tape. The next 2 tapes Amanda expects to used are: a new tape, a new tape. The next 2 new tapes already labelled are: Daily029, Daily028. FAILURE AND STRANGE DUMP SUMMARY: neptune-gw hda1 lev 0 FAILED [can't switch to incremental dump] m254.gc.cu sda1 lev 0 FAILED [can't switch to incremental dump] neptune-gw hda7 lev 0 FAILED [can't switch to incremental dump] neptune-gw hda6 lev 0 FAILED [can't switch to incremental dump] m254.gc.cu sda5 lev 0 FAILED [can't switch to incremental dump] neptune-gw hda5 lev 0 FAILED [can't switch to incremental dump] ... STATISTICS: Total Full Daily -------- -------- -------- Estimate Time (hrs:min) 0:03 Run Time (hrs:min) 0:07 Dump Time (hrs:min) 0:00 0:00 0:00 Output Size (meg) 0.0 0.0 0.0 Original Size (meg) 0.0 0.0 0.0 Avg Compressed Size (%) -- -- -- Filesystems Dumped 0 0 0 Avg Dump Rate (k/s) -- -- -- Tape Time (hrs:min) 0:00 0:00 0:00 Tape Size (meg) 0.0 0.0 0.0 Tape Used (%) 0.0 0.0 0.0 Filesystems Taped 0 0 0 Avg Tp Write Rate (k/s) -- -- -- ^L DUMP SUMMARY: DUMPER STATS TAPER STATS HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -------------------------- --------------------------------- ------------ m254.gc.cuny sda2 0 FAILED --------------------------------------- m254.gc.cuny sda3 0 FAILED --------------------------------------- .... neptune-gw.g hda6 0 FAILED --------------------------------------- everything in disklist 0 FAILED --------------------------------------- (brought to you by Amanda version 2.4.4p3) -----Original Message----- From: Frank Smith To: Lengyel, Florian; ''[email protected]' ' Sent: 6/11/2005 11:21 PM Subject: RE: amdump waits forever for estimates from one host --On Saturday, June 11, 2005 23:03:22 -0400 "Lengyel, Florian" <[EMAIL PROTECTED]> wrote: > This is what I have in m254:/tmp/amanda/amandad.20050611172037000.debug > > ... > /home/m254/yfsong/ 0 SIZE 91630 > /home/m254/yzhu/ 0 SIZE 10 > ---- > > amandad: time 260.577: dgram_recv: timeout after 10 seconds > amandad: time 260.577: waiting for ack: timeout, retrying > amandad: time 270.577: dgram_recv: timeout after 10 seconds > amandad: time 270.577: waiting for ack: timeout, retrying > amandad: time 280.577: dgram_recv: timeout after 10 seconds > amandad: time 280.577: waiting for ack: timeout, retrying > amandad: time 290.577: dgram_recv: timeout after 10 seconds > amandad: time 290.577: waiting for ack: timeout, retrying > amandad: time 300.577: dgram_recv: timeout after 10 seconds > amandad: time 300.577: waiting for ack: timeout, giving up! > amandad: time 300.577: pid 15364 finish time Sat Jun 11 17:25:37 2005 > [EMAIL PROTECTED] amanda]# > > I previously set > > etimeout 400 > > up slightly from the original 300 seconds. > > So it looks like a UDP packet never made it...Oh woe. Looks like a firewall problem. Do you have one on either machine and/or one in between them? Frank > > -----Original Message----- > From: Frank Smith > To: Lengyel, Florian; '[email protected]' > Sent: 6/11/2005 10:35 PM > Subject: Re: amdump waits forever for estimates from one host > > --On Saturday, June 11, 2005 17:45:17 -0400 "Lengyel, Florian" > <[EMAIL PROTECTED]> wrote: > >> Amanda version: amanda-2.4.4p3-1 >> OS: CentOS >> Kernel: uname -a >> Linux amanda.grid.cuny.edu 2.6.9-5.0.3.ELsmp #1 SMP Sat Feb 19 > 19:38:02 CST >> 2005 i686 i686 i386 GNU/Linux >> >> Trouble: amanda is set up on a tape server; there are two clients so > far. >> One is running RH linux 7.3 but has the latest (2.4.4) amanda code > built >> from >> source...the other is using an older rpm under RH linux 9. The source > build >> machine >> gives estimates for its DLEs, and the other seems to want to wait > until >> grass to grows >> under its mounting bracket, according to amstatus Daily, part of which >> reads: >> >> m254.gc.cuny.edu:/home/m254/yzhu/ getting > estimate >> m254.gc.cuny.edu:/home/www getting > estimate >> m254.gc.cuny.edu:sda1 getting > estimate >> m254.gc.cuny.edu:sda2 getting > estimate >> m254.gc.cuny.edu:sda3 getting > estimate >> m254.gc.cuny.edu:sda5 getting > estimate >> m254.gc.cuny.edu:sda7 getting > estimate >> neptune-gw.gc.cuny.edu:hda1 0 8390k estimate done >> neptune-gw.gc.cuny.edu:hda5 0 6361840k estimate done >> neptune-gw.gc.cuny.edu:hda6 0 1361030k estimate done >> neptune-gw.gc.cuny.edu:hda7 0 163620k estimate done >> >> I'm checking through the documentation...amcheck succeeds. Have I made > one >> of the usual configuration oversights? > > Try checking the debug files on m254.gc.cuny.edu (default is in > /tmp/amanda) > and see if there is more information there. > > One possibility is a firewall blocking the estimate response, since the > response usually occurs long after most firewall connection timeouts. > Look for 'no response' errors in the client debg files. > > Just so your backups don't hang forever you might want to make sure your > etimout isn't set larger than necessary. Don't forget it is multiplied > by > the number of DLEs on the host, so a setting of 1 hour on your m254 host > could result in a wait of up to 7 hours. You can use a negative number > it will be the per host timeout instead of per DLE. > > Frank > > > -- > Frank Smith > [EMAIL PROTECTED] > Sr. Systems Administrator Voice: > 512-374-4673 > Hoover's Online Fax: > 512-374-4501 -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
