Re: Flushing incrementals on Friday (was Re: strange dump summary)
Don't run amflush after amdump runs. You can run amflush whenever you're ready to drain the holding disk to tape, and you can even restrict amflush to specific hosts or host:disk combinations. - Original Message - From: "David Barcelo" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, September 02, 2003 6:51 PM Subject: Re: strange dump summary > Is there a way to force a backup to the holding disk? I want to keep > several days worth of incrementals on disk and then flush them to disk > on Friday.
Re: strange dump summary
Hi, Ben Elliston, on Mittwoch, 03. September 2003 at 00:49 you wrote to amanda-users: BE> Hi, BE> I recently upgraded a system from RHL8 to RHL9 and am seeing the BE> following errors from Amanda's mailed backup report. I'm not sure if BE> it's Amanda or some of the underlying tools like dump(1) involved BE> here: BE> FAILURE AND STRANGE DUMP SUMMARY: BE> localhost feff9f0 lev 0 ERROR [not in disklist] What does your disklist look like? And PLEASE don´t use "localhost", use the FQDN instead (myhost.mydomain.com or something like that ...) Using localhost does no good ... ;-) -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Storing Multiple Runs on Disk (was Re: strange dump summary)
Matt Hyclak <[EMAIL PROTECTED]> writes: > I do the same thing by just leaving the tape out of the drive. The other > option is to configure amanda to use for example, /dev/amtape as its no > rewind device. Might want to search the archives for /dev/fridaytape, we've discussed this before. > Run a cron job that points /dev/amtape to /dev/nst0 (or > whatever is appropriate) on friday, then after the dumps, points it to some > non-existent device (NOT /dev/null!!!), Such as: 0 15 * * 5 ln -s /dev/nst0 /dev/fridaytape; /usr/local/sbin/amcheck -m 0 19 * * 5 /usr/local/sbin/amdump ; rm /dev/fridaytape > You may get some complaints in the e-mails from amanda about not being > able to access the tape device, but it gets the job done. You can avoid this by using -c (client check only): 0 15 * * 1-4 /usr/local/sbin/amcheck -c -m One caveat is you must create /dev/fridaytape in order to label tapes... Steve
Re: strange dump summary
Is there a way to force a backup to the holding disk? I want to keep several days worth of incrementals on disk and then flush them to disk on Friday. Tks, David
Re: strange dump summary
On Tue, Sep 02, 2003 at 06:51:43PM -0500, David Barcelo enlightened us: > Is there a way to force a backup to the holding disk? I want to keep > several days worth of incrementals on disk and then flush them to disk > on Friday. > I do the same thing by just leaving the tape out of the drive. The other option is to configure amanda to use for example, /dev/amtape as its no rewind device. Run a cron job that points /dev/amtape to /dev/nst0 (or whatever is appropriate) on friday, then after the dumps, points it to some non-existent device (NOT /dev/null!!!), so that it will leave the dumps on disk. You may get some complaints in the e-mails from amanda about not being able to access the tape device, but it gets the job done. Matt -- Matt Hyclak Department of Mathematics Department of Social Work Ohio University (740) 593-1263 pgp0.pgp Description: PGP signature
Re: Strange DUMP Summary
On Wed, 15 May 2002 at 8:53am, Almeida Ed wrote > I've inherited an AMANDA backup solution and am trying to work through some > problems. > I get this report when running amdump to perform a full dump of these > machines. > Can someone tell me what "RESULTS MISSING" means? I'm new to AMANDA and > don't have much of a clue > as to what could be happening. > Thank you, > ed > > FAILURE AND STRANGE DUMP SUMMARY: > mov/ RESULTS MISSING *snip* > rst/ RESULTS MISSING Basically, amanda was able to communicate with those clients but didn't get anything meaningful back. Look in /tmp/amanda/amandad*debug, /tmp/amanda/sendsize*debug, and /tmp/amanda/sendbackup*debug on mov and rst and see if they shed any more light on what's going on. For completeness, what OS(s) are we talking about here, and what version of amanda? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: "STRANGE DUMP SUMMARY"
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> (Thu, Apr 26, 2001 at 04:36:29AM -0700) > HI, > I got the following, and was wondering what the "Strange" meant, and what I could do >about the "File too large" failures : File too large: _> your dumping a >2G file to your linux holding disk, Either upgrade your linux kernel to 2.4 (e.g. suse 7.1) or set the chunksize for your holding disk to something less than 2G. As for the error messages on pipe10's /dev/hda1 either you were dumping a disk that had activity (lot of deleting of files from the looks of it (e.g. an overnight make job) or your disk is dying. Kind regards, -- Gerhard den Hollander Phone +31-10.280.1515 Technical Support Jason Geosystems BV Fax +31-10.280.1511 (When calling please note: we are in GMT+1) [EMAIL PROTECTED] POBox 1573 visit us at http://www.jasongeo.com 3000 BN Rotterdam JASON...#1 in Reservoir CharacterizationThe Netherlands This e-mail and any attachment is/are intended solely for the named addressee(s) and may contain information that is confidential and privileged. If you are not the intended recipient, we request that you do not disseminate, forward, distribute or copy this e-mail message. If you have received this e-mail message in error, please notify us immediately by telephone and destroy the original message.
Re: Strange dump summary...
>BTW, I can backup "/etc" filesystem using dump on the client machines. >But no luck from Amanda server. Can you do those backups as the Amanda user? Is the group that owns the disks the primary Amanda user group or an alternate? If an alternate and you're using xinetd, are you using the option that has it set up the group membership (the default is to only run services with the primary group, not the alternates)? >Suman John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Strange dump summary...
Yes. BTW, I can backup "/etc" filesystem using dump on the client machines. But no luck from Amanda server. - Suman On Fri, 2 Feb 2001 12:18:56 -0800 (PST), David Wolfskill wrote: > >Date: Fri, 2 Feb 2001 11:51:37 -0800 (PST) > >From: smallA <[EMAIL PROTECTED]> > > >/usr/local/libexec/sendsize: version 2.4.1p1 > >calculating for amname '/etc', dirname '/etc' > >sendsize: getting size via dump for /etc level 0 > >sendsize: running "/sbin/dump 0sf 1048576 - /etc" > >running /usr/local/libexec/killpgrp > > DUMP: Date of this level 0 dump: Thu Feb 1 23:45:01 2001 > > DUMP: Date of last level 0 dump: the epoch > > DUMP: Dumping /dev/hda9 (/ (dir etc)) to standard output > > DUMP: Label: none > >/dev/hda9: Permission denied while opening filesystem > > Is the amanda user a member of a group that has read access to the raw > disk device? > > Cheers, > david > -- > David Wolfskill [EMAIL PROTECTED] UNIX System Administrator > Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823 ___ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/
Re: Strange dump summary...
>Thank you all for your prompt reply. ... BTW, your E-mail address to reply to is "[EMAIL PROTECTED]", but that seems to be bouncing: ... while talking to mta.excite.com.: >>> RCPT To:<[EMAIL PROTECTED]> <<< 550 Invalid recipient: <[EMAIL PROTECTED]> 550 <[EMAIL PROTECTED]>... User unknown You might want to get that fixed. >Here comes the output of /tmp/amanda/sendsize*debug - >... >sendsize: running "/sbin/dump 0sf 1048576 - /etc" >... > DUMP: Dumping /dev/hda9 (/ (dir etc)) to standard output > DUMP: Label: none >/dev/hda9: Permission denied while opening filesystem You cannot use dump to back up a subdirectory of a file system with Amanda. You must use GNU tar. See the "program" directive in the "dumptype" section of amanda.conf (or pick one of the dumptypes already set up to use GNU tar). Make sure you have either GNU tar 1.12 plus the Amanda patches, or at least 1.13.17 (1.13.19 is probably even better). >Suman John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Strange dump summary...
>Date: Fri, 2 Feb 2001 11:51:37 -0800 (PST) >From: smallA <[EMAIL PROTECTED]> >/usr/local/libexec/sendsize: version 2.4.1p1 >calculating for amname '/etc', dirname '/etc' >sendsize: getting size via dump for /etc level 0 >sendsize: running "/sbin/dump 0sf 1048576 - /etc" >running /usr/local/libexec/killpgrp > DUMP: Date of this level 0 dump: Thu Feb 1 23:45:01 2001 > DUMP: Date of last level 0 dump: the epoch > DUMP: Dumping /dev/hda9 (/ (dir etc)) to standard output > DUMP: Label: none >/dev/hda9: Permission denied while opening filesystem Is the amanda user a member of a group that has read access to the raw disk device? Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: Strange dump summary...
Thank you all for your prompt reply. Here comes the output of /tmp/amanda/sendsize*debug - /usr/local/libexec/sendsize: version 2.4.1p1 calculating for amname '/etc', dirname '/etc' sendsize: getting size via dump for /etc level 0 sendsize: running "/sbin/dump 0sf 1048576 - /etc" running /usr/local/libexec/killpgrp DUMP: Date of this level 0 dump: Thu Feb 1 23:45:01 2001 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/hda9 (/ (dir etc)) to standard output DUMP: Label: none /dev/hda9: Permission denied while opening filesystem . (no size line match in above dump output) - Suman On Fri, 02 Feb 2001 13:57:22 -0500, [EMAIL PROTECTED] wrote: > >got result for host mogadon disk /etc: 0 -> -1K, -1 -> -1K, -1 -> -1K > > What's in /tmp/amanda/sendsize*debug on mogadon? > > >smallA > > John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] ___ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/
Re: Strange dump summary...
>got result for host mogadon disk /etc: 0 -> -1K, -1 -> -1K, -1 -> -1K What's in /tmp/amanda/sendsize*debug on mogadon? >smallA John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Strange dump summary...
Hi Suman, Did you check on the client to see what's in the debug files of the /tmp/amanda directory? Check the permissions on /usr/local/libexec/runtar--it must be owned by root and SUID like this: -rwsr-x---1 root amanda 78334 Nov 13 15:32 /usr/local/libexec/runtar I had a problem recently where some genius decided to something like: chown -R foobar.silly /usr/local and backups of his machines stopped working because of it. If possible, you may just want to run "make install" again to make sure that the permissions of everything are set correctly. I imagine that it's also possible that you could have some sort of security patched kernel which blocks SUID execution which would stop runtar from working--I vaguely remember hearing of some sort of kernel patch like that, but it wouldn't be in some stock kernel eg. from Red Hat or another major distribution. Suman Malla wrote: > > Hi there, > > Could someone pls enlighten me? I am trying to backup a filesystem on redhat > server (mogadon) but in vain. amcheck doesn't complain at all though. Amanda > is backing up 8 other servers without any problem for > the last 4-5 months but with this server somehow it fails. > > Messages from log files - > > Amanda report: > = > FAILURE AND STRANGE DUMP SUMMARY: > > mogadon/etc lev 0 FAILED [disk /etc offline on mogadon?] > [snip]... > mogadon /etc 0 FAILED > [snip]... > > amdump.1: > > setting up estimates for mogadon:/etc > mogadon:/etc overdue 11355 days for level 0 > setup_estimate: mogadon:/etc: command 0, options: > last_level -1 next_level0 -11355 level_days 0 > getting estimates 0 (0) -1 (-1) -1 (-1) > got result for host mogadon disk /etc: 0 -> -1K, -1 -> -1K, -1 -> -1K > FAILED QUEUE: > 0: mogadon/etc > > Any hint, point would be greatly appreciated. > > TIA. > - > smallA > > ___ > Send a cool gift with your E-Card > http://www.bluemountain.com/giftcenter/ -- "Jonathan F. Dill" ([EMAIL PROTECTED])
Re: strange dump summary - can you explain this?
>? DUMP: bread: lseek fails >? DUMP: short read error from /dev/sda10: [block >-2122605784]: count=2048, got=0 This is typical of dumping an active file system. In particular, if the dump program knows it needs to read an indirect block of disk addresses and the file is removed/reallocated and that block reused for data, all those pointers (disk block addresses) are garbage and dump gets real unhappy. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: strange dump summary - can you explain this?
At 04:50 PM 1/11/01 +0100, Jens Bech Madsen wrote: >Denise Ives <[EMAIL PROTECTED]> writes: > > > There was a huge amount of output - so I will only forward you part > > of the dump summary from the Amanda Mail Report - > > > > ? DUMP: More than 32 block read errors from 134577504 > > ? DUMP: This is an unrecoverable error. > > ? DUMP: fopen on /dev/tty fails: Device not configured > > | DUMP: The ENTIRE dump is aborted. > > sendbackup: error [/sbin/dump returned 3] > > \ > >Looks like a failing disk to me. I would suspect the same thing. I occasionally get similar errors from one disk partition on a DEC Unix workstation. Usually vdump will complain about a particular file. I can replace the file with a copy from a similar workstation, and the backups will run fine for a few more weeks. I suspect my disk may be starting to have problems. One trick I've found to investigate these errors is to run dump (vdump in my case) by hand: vdump -0f - /offending_file_system | cat > /dev/null Andrew Robinson * Andrew W. Robinson | Voice: +1 (504)-889-2784 * * Computerized Processes Unlimited, Inc. | FAX:+1 (504)-889-2799 * * 4200 S. I-10 Service Rd., Suite 205| E-Mail: [EMAIL PROTECTED] * * Metairie, LA 70001 | WWW: http://www.cpu.com * * "Consulting System Integrators" *
Re: strange dump summary - can you explain this?
Denise Ives <[EMAIL PROTECTED]> writes: > There was a huge amount of output - so I will only forward you part > of the dump summary from the Amanda Mail Report - > > ? DUMP: More than 32 block read errors from 134577504 > ? DUMP: This is an unrecoverable error. > ? DUMP: fopen on /dev/tty fails: Device not configured > | DUMP: The ENTIRE dump is aborted. > sendbackup: error [/sbin/dump returned 3] > \ Looks like a failing disk to me. -- Jens Bech Madsen The Stibo Group, Denmark
