Strange dump summary
Dump gives a strange dump summary if file system is not mounted - is this required or a bug ? To illustrate in my disk list: tx5019 /mnt /dev/lofi/2 comp-root STRANGE DUMP DETAILS: /-- tx5019 /mnt lev 1 STRANGE sendbackup: start [tx5019:/mnt level 1] sendbackup: info BACKUP=/usr/sbin/ufsdump sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/usr/sbin/ufsrestore -xpGf - ... sendbackup: info COMPRESS_SUFFIX=.gz sendbackup: info end ? Unable to create temporary directory in any of the directories listed below: ? /tmp/ ? /var/tmp/ ? / ? Please correct this problem and rerun the program. | DUMP: Date of this level 1 dump: Mon Jul 19 13:40:30 2010 | DUMP: Date of last level 0 dump: Mon Jul 19 13:36:28 2010 | DUMP: Dumping /dev/rlofi/2 to standard output. | DUMP: Mapping (Pass I) [regular files] | DUMP: Mapping (Pass II) [directories] | DUMP: Writing 32 Kilobyte records | DUMP: Estimated 326 blocks (163KB) on 0.00 tapes. | DUMP: Dumping (Pass III) [directories] | DUMP: Dumping (Pass IV) [regular files] | DUMP: 190 blocks (95KB) on 1 volume at 9500 KB/sec | DUMP: DUMP IS DONE | DUMP: Level 1 dump on Mon Jul 19 13:40:30 2010 sendbackup: size 95 sendbackup: end If file system is mounted dump works as expexted. Thanks Gunnar Gunnarsson
failure and strange dump summary : lev 0 FAILED [no size line match..
Hello, i'm testing amanda 2.5.2p1. i never used amanda before. my server runs Red Hat Enterprize Linux 4. my testing client runs OS x (10.4.10). i installed and configured amanda on both (server version for server and client for client), but cannot backup. i am using vtapes, and i plan to keep on using them not just for the test. when i run "amcheck daily": Amanda Tape Server Host Check - Holding disk /Programs/daily/data: 10871836 kB disk space available, using 10485760 kB as requested slot 5: read label `daily5', date `20070816123833' cannot overwrite active tape daily5 slot 6: read label `daily6', date `20070814' NOTE: skipping tape-writable test Tape daily6 label ok NOTE: host info dir /etc/amanda/daily/curinfo/myclient.mydomain.com does not exist NOTE: it will be created on the next run. NOTE: index dir /etc/amanda/daily/index/myclient.mydomain.com/ _Users_amanda_sync does not exist NOTE: it will be created on the next run. Server check took 0.244 seconds Amanda Backup Client Hosts Check Client check: 1 host checked in 0.114 seconds, 0 problems found (brought to you by Amanda 2.5.2p1) when i run "amdump daily", i get this email message: Hostname: myserver.mydomain.com Org : localhost Config : daily Date: August 16, 2007 These dumps were to tape daily5. The next tape Amanda expects to use is: daily6. FAILURE AND STRANGE DUMP SUMMARY: myclient.mydomain.com /Users/amanda/sync lev 0 FAILED [no size line match in /sbin/dump output] STATISTICS: Total Full Incr. Estimate Time (hrs:min)0:00 Run Time (hrs:min) 0:00 Dump Time (hrs:min)0:00 0:00 0:00 Output Size (meg) 0.00.00.0 Original Size (meg) 0.00.00.0 Avg Compressed Size (%) -- -- -- Filesystems Dumped0 0 0 Avg Dump Rate (k/s) -- -- -- Tape Time (hrs:min)0:00 0:00 0:00 Tape Size (meg) 0.00.00.0 Tape Used (%) 0.00.00.0 Filesystems Taped 0 0 0 Chunks Taped 0 0 0 Avg Tp Write Rate (k/s) -- -- -- USAGE BY TAPE: LabelTime Size %NbNc daily5 0:000k0.0 0 0 NOTES: planner: Adding new disk myclient.mydomain.com:/Users/amanda/sync. driver: WARNING: got empty schedule from planner taper: tape daily5 kb 0 fm 0 [OK] DUMP SUMMARY: DUMPER STATS TAPER STATS HOSTNAME DISK L ORIG-kB OUT-kB COMP% MMM:SS KB/s MMM:SS KB/s --- - - myclient.mydomain /Users/amanda/sync 0 FAILED this is my server's "amanda.config": mailto "[EMAIL PROTECTED] <http://uk.f230.mail.yahoo.com/ym/[EMAIL PROTECTED]&YY=24699&y5beta=y es&y5beta=yes&order=down&sort=date&pos=0&view=a&head=b> " dumpuser "amandabackup" inparallel 6 dumporder "sssS" dumpcycle 1 week runspercycle 1 dtimeout 3600 columnspec "Disk=1:18,HostName=0:10,OutKB=1:7" holdingdisk hda2 { directory "/Programs/daily/data" use 10Gb } define dumptype global { comment "Global definitions" } define tapetype BIOST1 { comment "Dump onto hard disk" length 3072 mbytes # specified in mbytes to get the exact size of 3GB } usetimestamps yes tapecycle 6 tapetype BIOST1 tpchanger "chg-disk" changerfile "/usr/local/etc/amanda/daily/changer" tapedev "file:/data3/biost1" autoflush no logdir "/etc/amanda/daily"# log directory infofile "/etc/amanda/daily/curinfo"# database filename indexdir "/etc/amanda/daily/index" # index directory i'll appreciate any help at all, Maya
Re: FAILURE AND STRANGE DUMP SUMMARY
On 2007-06-18 20:53, Robert Echlin wrote: > FAILURE AND STRANGE DUMP SUMMARY: > cpu.ind.com /var/lib/mysql lev 0 FAILED [mesg read: Connection reset > by peer] Have you read/understood/checked: http://wiki.zmanda.com/index.php/Mesg_read:_Connection_reset_by_peer > cpu.ind.com /var/lib/mysql lev 0 FAILED [cannot read header: got 0 > instead of 32768] > cpu.ind.com /var/lib/mysql lev 0 was successfully retried > > Olivier notes that the network connection failed, at least before the > estimate was finished. > Also note the third line: "Successfully retried". > Check out what happens after that, as it may have gone on to > successfully backup cpu.ind.com:/var/lib/mysql > > Rob > > -- > Rob Echlin > Software Development Environment Prime > Espial IPTV > rechlin -at- espial.com > Phone: +1 613-230-4770 ext 1150 > www.espial.com > > Espial Group Inc. Confidential > Important Notice: This communication is intended to be received only by > the individual or entity to whom or to which it is addressed and may > contain information that is privileged, confidential and/or subject to > copyright. Any unauthorized use, copying, review or disclosure of this > communication is strictly prohibited. If you have received this > communication in error, please delete the message and notify the sender > by reply email. Thank you for your cooperation. > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of fedora > Sent: Monday, June 18, 2007 12:23 AM > To: amanda-users@amanda.org > Subject: Re: FAILURE AND STRANGE DUMP SUMMARY > > > > > fedora wrote: >> Hi guys. I am newbie here. I got problem with my Amanda. >> >> here is the result in mail report: >> >> FAILURE AND STRANGE DUMP SUMMARY: >> ind.ayo.com/var/lib/mysql lev 0 STRANGE >> >> >> STATISTICS: All OK. Showed the progress >> >> >> FAILED AND STRANGE DUMP DETAILS: >> >> /-- ind.ayo.com /var/lib/mysql lev 0 STRANGE >> sendbackup: start [ind.ayo.com:/var/lib/mysql level 0] >> sendbackup: info BACKUP=/bin/tar >> sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f - ... >> sendbackup: info COMPRESS_SUFFIX=.gz >> sendbackup: info end >> | gtar: ./mysql.sock: socket ignored >> ? gtar: ./mysql/general_log.CSV: file changed as we read it >> | Total bytes written: 562432000 (537MiB, 7.7MiB/s) >> sendbackup: size 549250 >> sendbackup: end >> >> >> NOTES: >> planner: Full dump of ind.ayo.com:/var/lib/mysql promoted from 5 > days >> ahead. >> taper: tape DailySet1-04 kb 2727712 fm 10 [OK] >> >> DUMP SUMMARY: >>DUMPER STATS > TAPER >> STATS >> HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s > MMM:SS >> KB/s >> -- - >> - >> ind.ayo -/lib/mysql 0 549250 301765.51:10 429.8 0:00 >> 154753.5 >> >> Nothing errors in debug files. Can u guys tell me how come Amanda > still >> complaining failed and strange whereas dump summary looks OK even I > can >> recover the backup files. >> >> Any ideas guys?? >> >> >> > > I got new problem: > > These dumps were to tape DailySet1-13. > The next tape Amanda expects to use is: DailySet1-14. > > FAILURE AND STRANGE DUMP SUMMARY: > cpu.ind.com /var/lib/mysql lev 0 FAILED [mesg read: Connection reset > by > peer] > cpu.ind.com /var/lib/mysql lev 0 FAILED [cannot read header: got 0 > instead of 32768] > cpu.ind.com /var/lib/mysql lev 0 was successfully retried > > can anyone explain to me? -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
RE: FAILURE AND STRANGE DUMP SUMMARY
FAILURE AND STRANGE DUMP SUMMARY: cpu.ind.com /var/lib/mysql lev 0 FAILED [mesg read: Connection reset by peer] cpu.ind.com /var/lib/mysql lev 0 FAILED [cannot read header: got 0 instead of 32768] cpu.ind.com /var/lib/mysql lev 0 was successfully retried Olivier notes that the network connection failed, at least before the estimate was finished. Also note the third line: "Successfully retried". Check out what happens after that, as it may have gone on to successfully backup cpu.ind.com:/var/lib/mysql Rob -- Rob Echlin Software Development Environment Prime Espial IPTV rechlin -at- espial.com Phone: +1 613-230-4770 ext 1150 www.espial.com Espial Group Inc. Confidential Important Notice: This communication is intended to be received only by the individual or entity to whom or to which it is addressed and may contain information that is privileged, confidential and/or subject to copyright. Any unauthorized use, copying, review or disclosure of this communication is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender by reply email. Thank you for your cooperation. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of fedora Sent: Monday, June 18, 2007 12:23 AM To: amanda-users@amanda.org Subject: Re: FAILURE AND STRANGE DUMP SUMMARY fedora wrote: > > Hi guys. I am newbie here. I got problem with my Amanda. > > here is the result in mail report: > > FAILURE AND STRANGE DUMP SUMMARY: > ind.ayo.com/var/lib/mysql lev 0 STRANGE > > > STATISTICS: All OK. Showed the progress > > > FAILED AND STRANGE DUMP DETAILS: > > /-- ind.ayo.com /var/lib/mysql lev 0 STRANGE > sendbackup: start [ind.ayo.com:/var/lib/mysql level 0] > sendbackup: info BACKUP=/bin/tar > sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f - ... > sendbackup: info COMPRESS_SUFFIX=.gz > sendbackup: info end > | gtar: ./mysql.sock: socket ignored > ? gtar: ./mysql/general_log.CSV: file changed as we read it > | Total bytes written: 562432000 (537MiB, 7.7MiB/s) > sendbackup: size 549250 > sendbackup: end > > > NOTES: > planner: Full dump of ind.ayo.com:/var/lib/mysql promoted from 5 days > ahead. > taper: tape DailySet1-04 kb 2727712 fm 10 [OK] > > DUMP SUMMARY: >DUMPER STATS TAPER > STATS > HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS > KB/s > -- - > - > ind.ayo -/lib/mysql 0 549250 301765.51:10 429.8 0:00 > 154753.5 > > Nothing errors in debug files. Can u guys tell me how come Amanda still > complaining failed and strange whereas dump summary looks OK even I can > recover the backup files. > > Any ideas guys?? > > > I got new problem: These dumps were to tape DailySet1-13. The next tape Amanda expects to use is: DailySet1-14. FAILURE AND STRANGE DUMP SUMMARY: cpu.ind.com /var/lib/mysql lev 0 FAILED [mesg read: Connection reset by peer] cpu.ind.com /var/lib/mysql lev 0 FAILED [cannot read header: got 0 instead of 32768] cpu.ind.com /var/lib/mysql lev 0 was successfully retried can anyone explain to me? -- View this message in context: http://www.nabble.com/FAILURE-AND-STRANGE-DUMP-SUMMARY-tf3788077.html#a1 1169793 Sent from the Amanda - Users mailing list archive at Nabble.com.
Re: FAILURE AND STRANGE DUMP SUMMARY
Thanks Marc. Marc Muehlfeld wrote: > > Hi, > > fedora schrieb: >> cpu.ind.com /var/lib/mysql lev 0 FAILED [mesg read: Connection reset >> by >> peer] > Maybe the client was rebooted during the backup or xinetd restarted. > > >> cpu.ind.com /var/lib/mysql lev 0 FAILED [cannot read header: got 0 >> instead of 32768] > The server didn't send an estimate or backup, because of a maybe reboot. > > >> cpu.ind.com /var/lib/mysql lev 0 was successfully retried > Everything was done fine. Amanda retried successfully. > > > Regards > Marc > > > > -- > Marc Muehlfeld (Leitung Systemadministration) > Zentrum fuer Humangenetik und Laboratoriumsmedizin Dr. Klein und Dr. Rost > Lochhamer Str. 29 - D-82152 Martinsried > Telefon: +49(0)89/895578-0 - Fax: +49(0)89/895578-78 > http://www.medizinische-genetik.de > > > > -- View this message in context: http://www.nabble.com/FAILURE-AND-STRANGE-DUMP-SUMMARY-tf3788077.html#a11170958 Sent from the Amanda - Users mailing list archive at Nabble.com.
Re: FAILURE AND STRANGE DUMP SUMMARY
Hi, fedora schrieb: cpu.ind.com /var/lib/mysql lev 0 FAILED [mesg read: Connection reset by peer] Maybe the client was rebooted during the backup or xinetd restarted. cpu.ind.com /var/lib/mysql lev 0 FAILED [cannot read header: got 0 instead of 32768] The server didn't send an estimate or backup, because of a maybe reboot. cpu.ind.com /var/lib/mysql lev 0 was successfully retried Everything was done fine. Amanda retried successfully. Regards Marc -- Marc Muehlfeld (Leitung Systemadministration) Zentrum fuer Humangenetik und Laboratoriumsmedizin Dr. Klein und Dr. Rost Lochhamer Str. 29 - D-82152 Martinsried Telefon: +49(0)89/895578-0 - Fax: +49(0)89/895578-78 http://www.medizinische-genetik.de
Re: FAILURE AND STRANGE DUMP SUMMARY
> FAILURE AND STRANGE DUMP SUMMARY: > cpu.ind.com /var/lib/mysql lev 0 FAILED [mesg read: Connection reset by > peer] Means that Amanda client on cpu.ind.com closed connection with Amanda server before the dump (or estimate was finished). Olivier
Re: FAILURE AND STRANGE DUMP SUMMARY
fedora wrote: > > Hi guys. I am newbie here. I got problem with my Amanda. > > here is the result in mail report: > > FAILURE AND STRANGE DUMP SUMMARY: > ind.ayo.com/var/lib/mysql lev 0 STRANGE > > > STATISTICS: All OK. Showed the progress > > > FAILED AND STRANGE DUMP DETAILS: > > /-- ind.ayo.com /var/lib/mysql lev 0 STRANGE > sendbackup: start [ind.ayo.com:/var/lib/mysql level 0] > sendbackup: info BACKUP=/bin/tar > sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f - ... > sendbackup: info COMPRESS_SUFFIX=.gz > sendbackup: info end > | gtar: ./mysql.sock: socket ignored > ? gtar: ./mysql/general_log.CSV: file changed as we read it > | Total bytes written: 562432000 (537MiB, 7.7MiB/s) > sendbackup: size 549250 > sendbackup: end > > > NOTES: > planner: Full dump of ind.ayo.com:/var/lib/mysql promoted from 5 days > ahead. > taper: tape DailySet1-04 kb 2727712 fm 10 [OK] > > DUMP SUMMARY: >DUMPER STATS TAPER > STATS > HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS > KB/s > -- - > - > ind.ayo -/lib/mysql 0 549250 301765.51:10 429.8 0:00 > 154753.5 > > Nothing errors in debug files. Can u guys tell me how come Amanda still > complaining failed and strange whereas dump summary looks OK even I can > recover the backup files. > > Any ideas guys?? > > > I got new problem: These dumps were to tape DailySet1-13. The next tape Amanda expects to use is: DailySet1-14. FAILURE AND STRANGE DUMP SUMMARY: cpu.ind.com /var/lib/mysql lev 0 FAILED [mesg read: Connection reset by peer] cpu.ind.com /var/lib/mysql lev 0 FAILED [cannot read header: got 0 instead of 32768] cpu.ind.com /var/lib/mysql lev 0 was successfully retried can anyone explain to me? -- View this message in context: http://www.nabble.com/FAILURE-AND-STRANGE-DUMP-SUMMARY-tf3788077.html#a11169793 Sent from the Amanda - Users mailing list archive at Nabble.com.
Re: FAILURE AND STRANGE DUMP SUMMARY
fedora wrote: > Almost files which is the extension ./databasename/*.MYI changed not only > ./mysql/general_log.CSV > Of course they changed. I usually try to avoid "Read the documentation" type responses, but I think this might be a good time to suggest it. The mysql docs tell you pretty clearly that backing up the database files directly is not going to work. You need to either dump the databases and back those up (a number of methods have been presented) or use a tool specifically designed to do them on the fly. Dustin posted a link to that a couple of days ago. LP
Re: FAILURE AND STRANGE DUMP SUMMARY
Almost files which is the extension ./databasename/*.MYI changed not only ./mysql/general_log.CSV Olivier Nicole wrote: > >> Is there any proper mysql backup that can backup database without >> stopping >> it?? >> If so, I don't have to worry about it? Of course it wasn't failed but I >> just >> worried if I recover it and the database or tables might be corrupt just >> because Amanda detected strange. Please advice. > > I remember I have seen something about backuping MySQL database, look > at Amanda web site. > > Now what is the file ./mysql/general_log.CSV ? > > In my run of MySQL (version 4) I do not have such a file. Is it > important or not if you loose it? If it is only a log file, like the > name suggests, maybe loosing it would not be so dramatic. > > Best regards, > > Olivier > > -- View this message in context: http://www.nabble.com/FAILURE-AND-STRANGE-DUMP-SUMMARY-tf3788077.html#a11056985 Sent from the Amanda - Users mailing list archive at Nabble.com.
Re: FAILURE AND STRANGE DUMP SUMMARY
On Fri, Jun 08, 2007 at 01:15:51AM -0700, fedora wrote: > Is there any proper mysql backup that can backup database without stopping > it?? You've already had a number of suggestions, so I'll just add one (and a shameless one, at that): ZRM for MySQL can back up MySQL databases without the need to dump them first or take them offline. See http://mysqlbackup.zmanda.com/ for documentation and downloads. For the other folks who posted scripts (wow! I haven't seen a response like that in a while!), please feel free to add the scripts and descriptions of them to http://wiki.zmanda.com, for those that are not already posted there. Dustin -- Dustin J. Mitchell Storage Software Engineer, Zmanda, Inc. http://www.zmanda.com/
Re: FAILURE AND STRANGE DUMP SUMMARY
Hi, fedora schrieb: Is there any proper mysql backup that can backup database without stopping it?? If so, I don't have to worry about it? Of course it wasn't failed but I just worried if I recover it and the database or tables might be corrupt just because Amanda detected strange. Please advice. I use a script for exporting the databases to an extra partition some time before amanda collect the data for backup. The script backup every database into a single file, using mysqldump. Also it write me a small logfile and send me an eMail if an error occured. All this is done while the MySQL server is running. Only for backup the BinaryLogs I have to lock the tables for a second. For me this is the best solution. See my script below. Regards Marc -- Marc Muehlfeld (Leitung Systemadministration) Zentrum fuer Humangenetik und Laboratoriumsmedizin Dr. Klein und Dr. Rost Lochhamer Str. 29 - D-82152 Martinsried Telefon: +49(0)89/895578-0 - Fax: +49(0)89/895578-78 http://www.medizinische-genetik.de #!/bin/bash ## # # Backup mysql tables, binary logs (if enabled) and configuration # # Created: 2002-11-21, Marc Muehlfeld # Last edited: 2007-01-23, Marc Muehlfeld # ## ## # Configuration area ## # MySQL password for root user MYSQLPASSWD={password} # Keep old backup $KEEP days KEEP=2 # Path where you want to put the backup DESTINATION="/BACKUP/mysql" # Logfile LOG="/var/log/`basename "$0"`.log" # Set path for required tools PATH=$PATH:/bin:/usr/bin # Whitespace separated list of all configuration files you want to save CONFIGS="/etc/my.cnf" ## # Here begins the program ## # Logging function to stdout and logfile function logging () { echo -e "`date +%d.%m.%Y" "%H:%M:%S` $1" | tee -a "$LOG" } logging "Starting backup" # Create destination directory if it doesn't exist and secure it. umask 0027 test ! -d "$DESTINATION" && mkdir -p "$DESTINATION" chown root:root "$DESTINATION" # Create temporary directory TMPDIR="$DESTINATION/MySQL_`date +%d-%m-%Y_%H-%M-%S`" mkdir "$TMPDIR" # Create list with database names logging "Create list with database names" DATABASES=`mysql -u root --password=$MYSQLPASSWD < "$TMPDIR/db_exports/$DB.sql" done # Copy configs logging "Backup configuration" mkdir -p "$TMPDIR/configs" cp -p "$CONFIGS" "$TMPDIR/configs" # Check if there are binary logs enabled egrep ^log-bin /etc/my.cnf > /dev/null 2>&1 if [ $? -eq 0 ] ; then logging "Copy binary logs" # Preparing mysql -u root -p$MYSQLPASSWD << EOF FLUSH TABLES WITH READ LOCK; FLUSH LOGS; EOF # Copy binlog mkdir -p "$TMPDIR/bin_log" BINLOGDIR="`dirname $(egrep ^log-bin /etc/my.cnf | sed -e 's/^.*=//g')`" cp -p -r "$BINLOGDIR" "$TMPDIR/bin_log" # Remove old binlogs mysql -u root -p$MYSQLPASSWD <
Re: FAILURE AND STRANGE DUMP SUMMARY
We use the following script (via a cron job) to get a distinct file for each database. We then only back up the /var/spool/mysqldumps directory. We run the script about an hour before the backups kick off. LP #!/bin/bash # Daily database dumps for inclusion in amanda backups. MYU="/mysql user with appropriate permissions/" MYP="/mysql users password/" MYDBS=`mysql -e "show databases;" -u $MYU -p$MYP|sed -e 's/|//g' |sed -e '1d'` for d in $MYDBS; do mysqldump --user=$MYU --password=$MYP $d > /var/spool/mysqldumps/$d.sql done
Re: FAILURE AND STRANGE DUMP SUMMARY
On Jun 8, 2007, at 1:15 AM, fedora wrote: Is there any proper mysql backup that can backup database without stopping it?? If so, I don't have to worry about it? Of course it wasn't failed but I just worried if I recover it and the database or tables might be corrupt just because Amanda detected strange. Please advice. In my opinion your best bet is to regularly back up you MySQL databases and let those backups be stored by Amanda. There is a script http://sourceforge.net/projects/automysqlbackup/ that when run daily from cron will do daily, weekly and monthly backups of all or some of your MySQL databases. On my server, I exclude the raw MySQL databases and back up the MySQL backups. In the event of a restore, the backups can be easily applied to the new installation of MySQL and you're back up and running. Cheers, Bruce. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: FAILURE AND STRANGE DUMP SUMMARY
> Is there any proper mysql backup that can backup database without stopping > it?? > If so, I don't have to worry about it? Of course it wasn't failed but I just > worried if I recover it and the database or tables might be corrupt just > because Amanda detected strange. Please advice. I remember I have seen something about backuping MySQL database, look at Amanda web site. Now what is the file ./mysql/general_log.CSV ? In my run of MySQL (version 4) I do not have such a file. Is it important or not if you loose it? If it is only a log file, like the name suggests, maybe loosing it would not be so dramatic. Best regards, Olivier
Re: FAILURE AND STRANGE DUMP SUMMARY
Hi, fedora schrieb: > Is there any proper mysql backup that can backup database without stopping > it?? > If so, I don't have to worry about it? Of course it wasn't failed but I just > worried if I recover it and the database or tables might be corrupt just > because Amanda detected strange. Please advice. I use a script for exporting the databases to an extra partition some time before amanda collect the data for backup. The script backup every database into a single file, using mysqldump. Also it write me a small logfile and send me an eMail if an error occured. All this is done while the MySQL server is running. Only for backup the BinaryLogs I have to lock the tables for a second. For me this is the best solution. Regards Marc -- Marc Muehlfeld (Leitung Systemadministration) Zentrum fuer Humangenetik und Laboratoriumsmedizin Dr. Klein und Dr. Rost Lochhamer Str. 29 - D-82152 Martinsried Telefon: +49(0)89/895578-0 - Fax: +49(0)89/895578-78 http://www.medizinische-genetik.de
Re: FAILURE AND STRANGE DUMP SUMMARY
Is there any proper mysql backup that can backup database without stopping it?? If so, I don't have to worry about it? Of course it wasn't failed but I just worried if I recover it and the database or tables might be corrupt just because Amanda detected strange. Please advice. Olivier Nicole wrote: > >> FAILED AND STRANGE DUMP DETAILS: >> >> /-- ind.ayo.com /var/lib/mysql lev 0 STRANGE >> sendbackup: start [ind.ayo.com:/var/lib/mysql level 0] >> sendbackup: info BACKUP=/bin/tar >> sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f - ... >> sendbackup: info COMPRESS_SUFFIX=.gz >> sendbackup: info end >> | gtar: ./mysql.sock: socket ignored >> ? gtar: ./mysql/general_log.CSV: file changed as we read it > > Means that the file mysql/general_log.CSV was getting modified while > tar was trying to save it. Most probably this file has not been > included (or included wrongly) in your amanda backup. > > You have to understand that it takes some amount of time for tar to > make a copy of a *big* file. If that big file is changing often, it is > very likely it will be changing while tar is trying to copy it. There > is very little you can make about it, except stopping mysql while you > are doing th backup :) > > Actually, this is only a STRANGE, not a FAIL. > > A bit of auto promotion, this page > https://wwws.cs.ait.ac.th/amanda/operator.shtml reccords a number of > Amanda error message and the explanation for it, and possible recovery > action. > > Olivier > > -- View this message in context: http://www.nabble.com/FAILURE-AND-STRANGE-DUMP-SUMMARY-tf3788077.html#a11022275 Sent from the Amanda - Users mailing list archive at Nabble.com.
Re: FAILURE AND STRANGE DUMP SUMMARY
> FAILED AND STRANGE DUMP DETAILS: > > /-- ind.ayo.com /var/lib/mysql lev 0 STRANGE > sendbackup: start [ind.ayo.com:/var/lib/mysql level 0] > sendbackup: info BACKUP=/bin/tar > sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f - ... > sendbackup: info COMPRESS_SUFFIX=.gz > sendbackup: info end > | gtar: ./mysql.sock: socket ignored > ? gtar: ./mysql/general_log.CSV: file changed as we read it Means that the file mysql/general_log.CSV was getting modified while tar was trying to save it. Most probably this file has not been included (or included wrongly) in your amanda backup. You have to understand that it takes some amount of time for tar to make a copy of a *big* file. If that big file is changing often, it is very likely it will be changing while tar is trying to copy it. There is very little you can make about it, except stopping mysql while you are doing th backup :) Actually, this is only a STRANGE, not a FAIL. A bit of auto promotion, this page https://wwws.cs.ait.ac.th/amanda/operator.shtml reccords a number of Amanda error message and the explanation for it, and possible recovery action. Olivier
Re: FAILURE AND STRANGE DUMP SUMMARY
any solutions for me? fedora wrote: > > Hi guys. I am newbie here. I got problem with my Amanda. > > here is the result in mail report: > > FAILURE AND STRANGE DUMP SUMMARY: > ind.ayo.com/var/lib/mysql lev 0 STRANGE > > > STATISTICS: All OK. Showed the progress > > > FAILED AND STRANGE DUMP DETAILS: > > /-- ind.ayo.com /var/lib/mysql lev 0 STRANGE > sendbackup: start [ind.ayo.com:/var/lib/mysql level 0] > sendbackup: info BACKUP=/bin/tar > sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f - ... > sendbackup: info COMPRESS_SUFFIX=.gz > sendbackup: info end > | gtar: ./mysql.sock: socket ignored > ? gtar: ./mysql/general_log.CSV: file changed as we read it > | Total bytes written: 562432000 (537MiB, 7.7MiB/s) > sendbackup: size 549250 > sendbackup: end > > > NOTES: > planner: Full dump of ind.ayo.com:/var/lib/mysql promoted from 5 days > ahead. > taper: tape DailySet1-04 kb 2727712 fm 10 [OK] > > DUMP SUMMARY: >DUMPER STATS TAPER > STATS > HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS > KB/s > -- - > - > ind.ayo -/lib/mysql 0 549250 301765.51:10 429.8 0:00 > 154753.5 > > Nothing errors in debug files. Can u guys tell me how come Amanda still > complaining failed and strange whereas dump summary looks OK even I can > recover the backup files. > > Any ideas guys?? > > > -- View this message in context: http://www.nabble.com/FAILURE-AND-STRANGE-DUMP-SUMMARY-tf3788077.html#a11021151 Sent from the Amanda - Users mailing list archive at Nabble.com.
Re: FAILURE AND STRANGE DUMP SUMMARY:
On Thursday 29 September 2005 07:15, Jon LaBadie wrote: >On Thu, Sep 29, 2005 at 11:13:01AM +0100, Chuck Amadi Systems Administrator wrote: >> Hi all I note that a FAILURE AND STRANGE DUMP SUMMARY: occurred and I >> assume that from the message at the bottom of the report that - file >> changed as we read it has caused a FAILURE AND STRANGE DUMP. >> >> Have I got anything to worry about here!. >> >> On the myserver machine, the file _.1.tmp: has changed while it was >> getting saved. >> >> and I have read that GNU tar is able to recover from this error. > >You may not be able to recover that one file. But it was a temporary, >probably only partially complete, file anyway so why care about it. > >Should not impact the rest of the dump. That was the holding disk Jon. It should either be excluded, or specifically not named in a disklist entry. He's probably backing up '/', rather than naming the subdirs in his disklist. -- 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) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Re: FAILURE AND STRANGE DUMP SUMMARY:
Hi Cheers for the reassurance. I will make note of your comments to file. Thanks On Thu, 2005-09-29 at 07:15 -0400, Jon LaBadie wrote: > On Thu, Sep 29, 2005 at 11:13:01AM +0100, Chuck Amadi Systems Administrator > wrote: > > Hi all I note that a FAILURE AND STRANGE DUMP SUMMARY: occurred and I > > assume that from the message at the bottom of the report that - file > > changed as we read it has caused a FAILURE AND STRANGE DUMP. > > > > Have I got anything to worry about here!. > > > > On the myserver machine, the file _.1.tmp: has changed while it was > > getting saved. > > > > and I have read that GNU tar is able to recover from this error. > > You may not be able to recover that one file. But it was a temporary, > probably only partially complete, file anyway so why care about it. > > Should not impact the rest of the dump. > -- Unix/ Linux Systems Administrator Chuck Amadi The Surgical Material Testing Laboratory (SMTL), Princess of Wales Hospital Coity Road Bridgend, United Kingdom, CF31 1RQ. Email chuck.smtl.co.uk Tel: +44 1656 752820 Fax: +44 1656 752830
Re: FAILURE AND STRANGE DUMP SUMMARY:
On Thu, Sep 29, 2005 at 11:13:01AM +0100, Chuck Amadi Systems Administrator wrote: > Hi all I note that a FAILURE AND STRANGE DUMP SUMMARY: occurred and I > assume that from the message at the bottom of the report that - file > changed as we read it has caused a FAILURE AND STRANGE DUMP. > > Have I got anything to worry about here!. > > On the myserver machine, the file _.1.tmp: has changed while it was > getting saved. > > and I have read that GNU tar is able to recover from this error. You may not be able to recover that one file. But it was a temporary, probably only partially complete, file anyway so why care about it. Should not impact the rest of the dump. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
FAILURE AND STRANGE DUMP SUMMARY:
Hi all I note that a FAILURE AND STRANGE DUMP SUMMARY: occurred and I assume that from the message at the bottom of the report that - file changed as we read it has caused a FAILURE AND STRANGE DUMP. Have I got anything to worry about here!. On the myserver machine, the file _.1.tmp: has changed while it was getting saved. and I have read that GNU tar is able to recover from this error. These dumps were to tape MYDailySet109. The next tape Amanda expects to use is: MYDailySet110. FAILURE AND STRANGE DUMP SUMMARY: myserver.co.uk / lev 1 STRANGE STATISTICS: Total Full Daily Estimate Time (hrs:min)0:27 Run Time (hrs:min) 1:39 Dump Time (hrs:min)1:12 1:06 0:06 Output Size (meg) 11238.311181.1 57.2 Original Size (meg) 11238.311181.1 57.2 Avg Compressed Size (%) -- -- -- (level:#disks ...) Filesystems Dumped8 4 4 (1:4) Avg Dump Rate (k/s) 2660.5 2906.8 151.5 Tape Time (hrs:min)1:07 1:06 0:01 Tape Size (meg) 11238.311181.1 57.2 Tape Used (%) 57.6 57.30.3 (level:#disks ...) Filesystems Taped 8 4 4 (1:4) Avg Tp Write Rate (k/s) 2871.9 2885.2 1507.1 USAGE BY TAPE: LabelTime Size %Nb MYDailySet109 1:07 11238.3 57.6 8 FAILED AND STRANGE DUMP DETAILS: /-- nemesis.co.co.uk / lev 1 STRANGE sendbackup: start [myserver.co.co.uk:/ level 1] sendbackup: info BACKUP=/bin/tar sendbackup: info RECOVER_CMD=/bin/tar -f... - sendbackup: info end ? gtar: ./dumps/amanda/20050928/myserver.co.co.uk._.1.tmp: file changed as we read it | Total bytes written: 26163200 (25MB, 218kB/s) sendbackup: size 25550 sendbackup: end \ NOTES: planner: Full dump of myserver.co.co.uk:/home promoted from 27 days ahead. planner: Full dump of myserver.co.co.uk:/data promoted from 22 days ahead. planner: Full dump of myserver.co.co.uk:/tmp promoted from 26 days ahead. planner: Full dump of myserver.co.co.uk:/var promoted from 27 days ahead. taper: tape MYDailySet109 kb 11508384 fm 8 [OK] DUMP SUMMARY: DUMPER STATSTAPER STATS HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- - myserver.co / 1 25550 25550 --1:57 217.6 0:221185.3 myserver.co /backup 16070 6070 --0:46 131.7 0:032114.0 myserver.co /data 0 45434804543480 -- 25:302970.3 25:302969.7 myserver.co /home 0 63069406306940 -- 37:242810.9 37:242810.6 myserver.co /projects 1 12590 12590 --1:18 160.8 0:071815.0 myserver.co /share 1 14370 14370 --2:25 99.2 0:081913.8 myserver.co /tmp0 181530 181530 --0:305965.2 0:593086.0 myserver.co /var0 417500 417500 --2:153091.1 2:163080.8 (brought to you by Amanda version 2.4.4p2) Cheers -- Unix/ Linux Systems Administrator Chuck Amadi The Surgical Material Testing Laboratory (SMTL), Princess of Wales Hospital Coity Road Bridgend, United Kingdom, CF31 1RQ. Email chuck.smtl.co.uk Tel: +44 1656 752820 Fax: +44 1656 752830
Re: Failed and strange dump summary
On Wed, 21 Sep 2005 at 11:11am, Gene Heskett wrote > That mans your indices and such are all out of date by one run. I On tape, they are, yes. But I store the taballs on a couple of different servers with multi-disk-failure-proof RAIDs. It's not perfect, but it's worked well me for this far. > didn't like that when I got to thinking about os I go ahead and append > them to the same tape Joshua. When I was using tape, I had to reduce > the tapetype size to make sure there was room for the 2 extra files, > in my case about 100 megs. Now useing vtapes, I just watch the df > report, trying to keep the drive at 90% or so. > > So my backup has its uptodate indices on the same tape or in the same > dir of a vtape. I sleep better. :-) That is a rather good idea as well. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Failed and strange dump summary
>Looks like some temporary compressed index files from the current run >should be there but are not. ... > >Do you see similar behavior ? As Joshua said, this is to be expected. Amanda is creating those files and removing them during the time GNU tar is also backing them up. You *might* (haven't test this) be able to use an exclude pattern to make GNU tar ignore those files: ./usr/local/var/amanda/idx/DailySet1/index/*.tmp JJ
Re: Failed and strange dump summary
On Wednesday 21 September 2005 09:31, Joshua Baker-LePain wrote: >On Wed, 21 Sep 2005 at 9:04am, Guy Dallaire wrote > >> It's very rare that I don't come up here in the morning and don't see >> failed and strange dumps in my 10 machines backup. > >FAILED is a lot different than STRANGE. > >> Most of the time, this occurs because some housekeeping/cleaning is >> between the time the estimates and backups are done. >> >> Most of the time, the message is there because a file disapeared, or >> changed in size. >> >> I can live with it. >> >> Since I've put my amanda indexes and log elsewhere (in >> /usr/local/var/amanda) I often get the following kind of messages: >> >> /-- lnx-que-am / lev 2 STRANGE >> sendbackup: start [lnx-que-amanda:/ level 2] >> sendbackup: info BACKUP=/bin/gtar >> sendbackup: info RECOVER_CMD=/bin/gtar -f... - >> sendbackup: info end >> ? gtar: >> ./usr/local/var/amanda/idx/DailySet1/index/chablis/_/20050921_1.gz.tmp >>: Warning: Cannot stat: No such file or directory >> ? gtar: >> ./usr/local/var/amanda/idx/DailySet1/index/lnx-que-wforms1-dev/_WEB__D >>EP__6i/20050921_1.gz.tmp: Warning: Cannot stat: No such file or >> directory >> >> | Total bytes written: 372920320 (356MiB, 2.7MiB/s) >> >> sendbackup: size 364180 >> sendbackup: end >> \ >> >> Looks like some temporary compressed index files from the current run >> should be there but are not. Could there be a problem here ? If not, >> is there a way to stop amanda from complaining about missing files ? >> >> Do you see similar behavior ? > >You're always going to see that when trying to back up the index > directory of an active amanda setup. What I do is run a script after > the backups are done which tars up all the config and index dirs and > puts them in a few different locations which then get backed up that > night. That mans your indices and such are all out of date by one run. I didn't like that when I got to thinking about os I go ahead and append them to the same tape Joshua. When I was using tape, I had to reduce the tapetype size to make sure there was room for the 2 extra files, in my case about 100 megs. Now useing vtapes, I just watch the df report, trying to keep the drive at 90% or so. So my backup has its uptodate indices on the same tape or in the same dir of a vtape. I sleep better. :-) -- 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) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Re: Failed and strange dump summary
On Wed, 21 Sep 2005 at 9:04am, Guy Dallaire wrote > It's very rare that I don't come up here in the morning and don't see > failed and strange dumps in my 10 machines backup. FAILED is a lot different than STRANGE. > Most of the time, this occurs because some housekeeping/cleaning is > between the time the estimates and backups are done. > > Most of the time, the message is there because a file disapeared, or > changed in size. > > I can live with it. > > Since I've put my amanda indexes and log elsewhere (in > /usr/local/var/amanda) I often get the following kind of messages: > > /-- lnx-que-am / lev 2 STRANGE > sendbackup: start [lnx-que-amanda:/ level 2] > sendbackup: info BACKUP=/bin/gtar > sendbackup: info RECOVER_CMD=/bin/gtar -f... - > sendbackup: info end > ? gtar: > ./usr/local/var/amanda/idx/DailySet1/index/chablis/_/20050921_1.gz.tmp: > Warning: Cannot stat: No such file or directory > ? gtar: > ./usr/local/var/amanda/idx/DailySet1/index/lnx-que-wforms1-dev/_WEB__DEP__6i/20050921_1.gz.tmp: > Warning: Cannot stat: No such file or directory > | Total bytes written: 372920320 (356MiB, 2.7MiB/s) > sendbackup: size 364180 > sendbackup: end > \ > > Looks like some temporary compressed index files from the current run > should be there but are not. Could there be a problem here ? If not, > is there a way to stop amanda from complaining about missing files ? > > Do you see similar behavior ? You're always going to see that when trying to back up the index directory of an active amanda setup. What I do is run a script after the backups are done which tars up all the config and index dirs and puts them in a few different locations which then get backed up that night. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Failed and strange dump summary
It's very rare that I don't come up here in the morning and don't see failed and strange dumps in my 10 machines backup. Most of the time, this occurs because some housekeeping/cleaning is between the time the estimates and backups are done. Most of the time, the message is there because a file disapeared, or changed in size. I can live with it. Since I've put my amanda indexes and log elsewhere (in /usr/local/var/amanda) I often get the following kind of messages: /-- lnx-que-am / lev 2 STRANGE sendbackup: start [lnx-que-amanda:/ level 2] sendbackup: info BACKUP=/bin/gtar sendbackup: info RECOVER_CMD=/bin/gtar -f... - sendbackup: info end ? gtar: ./usr/local/var/amanda/idx/DailySet1/index/chablis/_/20050921_1.gz.tmp: Warning: Cannot stat: No such file or directory ? gtar: ./usr/local/var/amanda/idx/DailySet1/index/lnx-que-wforms1-dev/_WEB__DEP__6i/20050921_1.gz.tmp: Warning: Cannot stat: No such file or directory | Total bytes written: 372920320 (356MiB, 2.7MiB/s) sendbackup: size 364180 sendbackup: end \ Looks like some temporary compressed index files from the current run should be there but are not. Could there be a problem here ? If not, is there a way to stop amanda from complaining about missing files ? Do you see similar behavior ?
RE: failure and strange dump summary -- disk offline
--On Friday, October 29, 2004 12:06:07 -0500 Brian Tima <[EMAIL PROTECTED]> wrote: > I don't understand what you are asking by "All the ones relevant to > /dev/sda3 ?" > > I've tried with DUMP and GNUTAR, currently configured to run gnutar. Tar deals with filesystems, not devices, so you need to either use dump on /dev/sda3 or use tar on the path where it it is mounted. Even with tar on a device you should still get a tar image, it just won't be what your expecting, so you still have a problem. . > > are any switches needed in the "grep /dev/sda3" command ? > > > I have cleared /tmp/amanda and running it now Let us know what's in /tmp/amanda on the client when it's done. Frank > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Paul Bijnens > Sent: Friday, October 29, 2004 10:56 AM > To: Brian Tima > Cc: Amanda Mailing List > Subject: Re: failure and strange dump summary -- disk offline > > > Brian Tima wrote: > >> File system is ext3 >> Which debug file do I check? >> >> Here are the files showing in the directory /tmp/amanda > > All the ones relevant to /dev/sda3 ? > You never posted (afaik) which program you used to > dump the filesystem (dump or gnutar). > Do a grep of /dev/sda3 or the mountpoint for gnutar > in the files. > > Another easy one: the middle numbers are datatime stamps. > If that is still too much work, remove all those files in > /tmp/amanda, then run it once, and look through all files > that just got created. > > Remember ON THE CLIENT, not on the amanda server. > > > -- > Paul Bijnens, XplanationTel +32 16 397.511 > Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 > http://www.xplanation.com/ email: [EMAIL PROTECTED] > *** > * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * > * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * > * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * > * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * > * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* > * ... "Are you sure?" ... YES ... Phew ... I'm out * > *** > -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
RE: failure and strange dump summary -- disk offline
I don't understand what you are asking by "All the ones relevant to /dev/sda3 ?" I've tried with DUMP and GNUTAR, currently configured to run gnutar. are any switches needed in the "grep /dev/sda3" command ? I have cleared /tmp/amanda and running it now -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Paul Bijnens Sent: Friday, October 29, 2004 10:56 AM To: Brian Tima Cc: Amanda Mailing List Subject: Re: failure and strange dump summary -- disk offline Brian Tima wrote: > File system is ext3 > Which debug file do I check? > > Here are the files showing in the directory /tmp/amanda All the ones relevant to /dev/sda3 ? You never posted (afaik) which program you used to dump the filesystem (dump or gnutar). Do a grep of /dev/sda3 or the mountpoint for gnutar in the files. Another easy one: the middle numbers are datatime stamps. If that is still too much work, remove all those files in /tmp/amanda, then run it once, and look through all files that just got created. Remember ON THE CLIENT, not on the amanda server. -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: failure and strange dump summary -- disk offline
Brian Tima wrote: Does anyone have any more suggestions I can look into for resolving my sda3 disk? What filesystem is sda? ext2 reiserfs? ... What is in the debug file on the client: /tmp/amanda/*.debug concerning this DLE ? (I thought someone already asked, but I never saw the answer.) -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: failure and strange dump summary -- disk offline
Brian Tima wrote: File system is ext3 Which debug file do I check? Here are the files showing in the directory /tmp/amanda All the ones relevant to /dev/sda3 ? You never posted (afaik) which program you used to dump the filesystem (dump or gnutar). Do a grep of /dev/sda3 or the mountpoint for gnutar in the files. Another easy one: the middle numbers are datatime stamps. If that is still too much work, remove all those files in /tmp/amanda, then run it once, and look through all files that just got created. Remember ON THE CLIENT, not on the amanda server. -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: failure and strange dump summary -- disk offline
Hi, Brian Tima, on Freitag, 29. Oktober 2004 at 17:20 you wrote to amanda-users: BT> Does anyone have any more suggestions I can look into for resolving my sda3 BT> disk? BT> amcheck does not report any problems. BT> my amanda user is part of the disk group BT> /dev/sda1 BT> performs without missing a beat, /dev/sda3 BT> continuously reports /dev/sda3 lev 0 FAILED [disk /dev/sda3 offline on BT> mn-py-linuxsvr?] Look up the logfiles (/tmp/amanda, /var/adm/amanda) Did you configure and make AMANDA as AMANDA-user? Installed it as root? What does "amadmin version" say? -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
RE: failure and strange dump summary -- disk offline
Does anyone have any more suggestions I can look into for resolving my sda3 disk? amcheck does not report any problems. my amanda user is part of the disk group /dev/sda1 performs without missing a beat, /dev/sda3 continuously reports /dev/sda3 lev 0 FAILED [disk /dev/sda3 offline on mn-py-linuxsvr?] DUMP SUMMARY: DUMPER STATSTAPER STATS HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- - mn-py-linuxs /dev/sda3 0 FAILED --- -Original Message- From: Stefan G. Weichinger [mailto:[EMAIL PROTECTED] Sent: Thursday, October 28, 2004 6:46 PM To: Brian Tima Subject: Re: failure and strange dump summary Hi, Brian, on Freitag, 29. Oktober 2004 at 01:33 you wrote to amanda-users: BT> I've been messing with AMANDA now for a couple months, I keep putting BT> off trying to resolve my issues. But once again, here I am. BT> Attempting BT> to inquire if anyone has some direction for me on what I must do to BT> correct my disk being offline? What does amcheck report? Is /dev/sda3 readable for the AMANDA-user? What does "ll /dev/sda[13]" tell you? -- best regards, Stefan G. Weichinger
RE: failure and strange dump summary
--On Thursday, October 28, 2004 19:11:41 -0500 Brian Tima <[EMAIL PROTECTED]> wrote: > Is /dev/sda3 readable for the AMANDA-user? > > How do I check if /dev/sda3 is readable by the amanda user? > > What does "ll /dev/sda[13]" tell you? > > It tells me > brw-rwx--- 1 root disk8, 1 Mar 19 2002 /dev/sda1 > brw-rwx--- 1 root disk8, 3 Mar 19 2002 /dev/sda3 Check to make sure your amanda user a member of the group 'disk' on that server. Frank > > > -Original Message- > From: Stefan G. Weichinger [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 28, 2004 6:46 PM > To: Brian Tima > Subject: Re: failure and strange dump summary > > > Hi, Brian, > > on Freitag, 29. Oktober 2004 at 01:33 you wrote to amanda-users: > > BT> I've been messing with AMANDA now for a couple months, I keep putting > BT> off trying to resolve my issues. But once again, here I am. > BT> Attempting > BT> to inquire if anyone has some direction for me on what I must do to > BT> correct my disk being offline? > > What does amcheck report? > Is /dev/sda3 readable for the AMANDA-user? > What does "ll /dev/sda[13]" tell you? > > -- > > best regards, > Stefan G. Weichinger > > -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
RE: failure and strange dump summary
Is /dev/sda3 readable for the AMANDA-user? How do I check if /dev/sda3 is readable by the amanda user? What does "ll /dev/sda[13]" tell you? It tells me brw-rwx--- 1 root disk8, 1 Mar 19 2002 /dev/sda1 brw-rwx--- 1 root disk8, 3 Mar 19 2002 /dev/sda3 -Original Message- From: Stefan G. Weichinger [mailto:[EMAIL PROTECTED] Sent: Thursday, October 28, 2004 6:46 PM To: Brian Tima Subject: Re: failure and strange dump summary Hi, Brian, on Freitag, 29. Oktober 2004 at 01:33 you wrote to amanda-users: BT> I've been messing with AMANDA now for a couple months, I keep putting BT> off trying to resolve my issues. But once again, here I am. BT> Attempting BT> to inquire if anyone has some direction for me on what I must do to BT> correct my disk being offline? What does amcheck report? Is /dev/sda3 readable for the AMANDA-user? What does "ll /dev/sda[13]" tell you? -- best regards, Stefan G. Weichinger
RE: failure and strange dump summary
Hi Stefan. Amcheck reports Amanda Tape Server Host Check - Holding disk /var/tmp: 26486092 KB disk space available, that's plenty NOTE: skipping tape-writable test Tape LinM label ok Server check took 7.524 seconds Amanda Backup Client Hosts Check Client check: 1 host checked in 0.017 seconds, 0 problems found -Original Message- From: Stefan G. Weichinger [mailto:[EMAIL PROTECTED] Sent: Thursday, October 28, 2004 6:46 PM To: Brian Tima Subject: Re: failure and strange dump summary Hi, Brian, on Freitag, 29. Oktober 2004 at 01:33 you wrote to amanda-users: BT> I've been messing with AMANDA now for a couple months, I keep putting BT> off trying to resolve my issues. But once again, here I am. BT> Attempting BT> to inquire if anyone has some direction for me on what I must do to BT> correct my disk being offline? What does amcheck report? Is /dev/sda3 readable for the AMANDA-user? What does "ll /dev/sda[13]" tell you? -- best regards, Stefan G. Weichinger
failure and strange dump summary
I've been messing with AMANDA now for a couple months, I keep putting off trying to resolve my issues. But once again, here I am. Attempting to inquire if anyone has some direction for me on what I must do to correct my disk being offline? These dumps were to tape LinA. The next tape Amanda expects to use is: LinC. FAILURE AND STRANGE DUMP SUMMARY: mn-py-linu /dev/sda3 lev 0 FAILED [disk /dev/sda3 offline on mn-py-linuxsvr?] STATISTICS: Total Full Daily Estimate Time (hrs:min)0:00 Run Time (hrs:min) 0:01 Dump Time (hrs:min)0:00 0:00 0:00 Output Size (meg) 14.5 14.50.0 Original Size (meg)24.2 24.20.0 Avg Compressed Size (%)59.7 59.7-- Filesystems Dumped1 1 0 Avg Dump Rate (k/s) 6891.2 6891.2-- Tape Time (hrs:min)0:00 0:00 0:00 Tape Size (meg)14.5 14.50.0 Tape Used (%) 0.10.10.0 Filesystems Taped 1 1 0 Avg Tp Write Rate (k/s) 994.6 994.6-- NOTES: planner: Adding new disk mn-py-linuxsvr:/dev/sda1. planner: Adding new disk mn-py-linuxsvr:/dev/sda3. taper: tape LinA kb 14848 fm 1 [OK] DUMP SUMMARY: DUMPER STATSTAPER STATS HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- - mn-py-linuxs /dev/sda1 0 24830 14816 59.7 0:026890.9 0:15 994.6 mn-py-linuxs /dev/sda3 0 FAILED --- (brought to you by Amanda version 2.4.2p2) Thanks in advance! Brian TimaTechnology @ All Cities Mortgage & Financial Ph:(952)746-8170TF:(800)488-0772FX:(952)746-8179 www.ALLCITIES.com
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
strange dump summary
Hi, I recently upgraded a system from RHL8 to RHL9 and am seeing the following errors from Amanda's mailed backup report. I'm not sure if it's Amanda or some of the underlying tools like dump(1) involved here: FAILURE AND STRANGE DUMP SUMMARY: localhost feff9f0 lev 0 ERROR [not in disklist] localhost feff9f0 lev 0 ERROR [not in disklist] localhost feff9f0 lev 0 ERROR [not in disklist] localhost feff9f0 lev 0 ERROR [not in disklist] localhost feff9f0 lev 0 ERROR [not in disklist] localhost feff9f0 lev 0 ERROR [not in disklist] localhost feff9f0 lev 0 ERROR [not in disklist] localhost feff9f0 lev 0 ERROR [not in disklist] The dumping and taping seems to proceed correctly in spite of these strange errors. Has anyone seen this before? Thanks, Ben pgp0.pgp Description: PGP signature
Help with STRANGE DUMP SUMMARY
I'm a newbie to amanda and I'm having problems with my backups. Sometimes they work but more often they don't. The report I get is: FAILURE AND STRANGE DUMP SUMMARY: localhost /usr/local lev 0 FAILED [data timeout] localhost /usr/local lev 0 FAILED [dump to tape failed] I am trying to configure it as simply as possible to begin with. I'm dumping 1 file system on the local host to a single tape using RedHat 7.1 and amanda from the rpm. The tapedrive is a Compaq DLT 8000. Thanks in advance for any help. - Matt - --- Matt MooreN3LPH Bucks County Community College E-mail: [EMAIL PROTECTED] 275 Swamp Rd. Newtown PA 18940 ---
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
Strange DUMP Summary
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 mov/usr RESULTS MISSING mov/home/mp1 RESULTS MISSING mov/home/mp2 RESULTS MISSING mov/home/mp5 RESULTS MISSING mov/home/mp3 RESULTS MISSING mov/home/mp4 RESULTS MISSING mov/home/mp6 RESULTS MISSING rst/ RESULTS MISSING rst/usr RESULTS MISSING rst/home/rp3 RESULTS MISSING rst/home/rp4 RESULTS MISSING rst/home/rp6 RESULTS MISSING
Re: Failure and Strange Dump Summary
On Fri, 3 May 2002 at 2:52pm, Michael Kopach wrote > FAILURE AND STRANGE DUMP SUMMARY: > localhost hda5a lev 0 FAILED [missing result for hda5a in localhost response] Two things: o You want to use a hostname. Even if you don't think you do, you do. localhost will more than likely come back to bite you. o Are you sure hda5a is correct? Are you sure it shouldn't just be hda5? o You may want to try using directory names (e.g. /home), rather than devices. It comes in handy if you add disks or move stuff around. OK, fine, so that was 3. > (brought to you by Amanda 2.4.3b3 b is for beta. If you don't need the new features, you probably want to stick with 2.4.2p2 plus patches. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Failure and Strange Dump Summary
Ok, now I will wave the white flag I am trying to get amanda working for the first time, but am running into same problem over and over. The particulars are: O/S is Slackware 8.0, amanda version is 2.4.3b3. Amcheck runs fine, but when I do an amdump, the following is what I end up with: Subject: aug AMANDA MAIL REPORT FOR May 2, 2002 These dumps were to tape 3117. The next tape Amanda expects to use is: a new tape. FAILURE AND STRANGE DUMP SUMMARY: localhost hda5a lev 0 FAILED [missing result for hda5a in localhost response] STATISTICS: Total Full Daily Estimate Time (hrs:min)0:00 Run Time (hrs:min) 0:02 Dump Time (hrs:min)0:00 0:00 0:00 Output Size (meg) 0.00.00.0 Original Size (meg) 0.00.00.0 Avg Compressed Size (%) -- -- -- Filesystems Dumped0 0 0 Avg Dump Rate (k/s) -- -- -- Tape Time (hrs:min)0:00 0:00 0:00 Tape Size (meg) 0.00.00.0 Tape Used (%) 0.00.00.0 Filesystems Taped 0 0 0 Avg Tp Write Rate (k/s) -- -- -- NOTES: planner: Adding new disk localhost:hda5a. driver: WARNING: got empty schedule from planner taper: tape 3117 kb 0 fm 0 [OK] DUMP SUMMARY: DUMPER STATSTAPER STATS HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- - localhosthda5a 0 FAILED --- (brought to you by Amanda 2.4.3b3 I'm hoping someone out there has some ideas?? Michael A. Kopach System Administrator Augustana University College 4901 - 46 Ave. Camrose, AB T4V-2R3 Tel 780-679-1572 [EMAIL PROTECTED]
Re: FAILURE AND STRANGE DUMP SUMMARY:
On Tue, 29 Jan 2002 16:12:17 -0500 "John R. Jackson" <[EMAIL PROTECTED]> wrote: [..] > I looked at the code and that error only comes from one place, when driver > has tried doing a dump once and it failed but was requeued to "TRYAGAIN", > then the second attempt also failed. I'm not sure the message means what > it says, that there really was a problem connecting to the host. That may > have been what it originally meant, but now it might mean other things > (in case it isn't obvious, this code gets a little confusing to navigate). > > I'm pretty sure it has nothing to do with starting a new tapecycle, > except in an indirect way (if at all). My best guess is it has something > to do with the amount of holding disk space you have, or possibly other > activity going on in the holding disk at the same time Amanda is running > (e.g. Amanda thought it had N MBytes but when it actually tried to use > the space, less than that was really there). > > I would need to see the corresponding amdump. file that goes along > with one of these errors, and possibly all the client logs for that same > run. If you want to contact me offline of the list for this, that's OK. > > In the meantime, you might try dropping maxdumps back to 1. That may > or may not help -- it's just a guess. Hi John, you are right about the "TRYAGAIN", take a look ath an excerpt of /var/log/amanda/DailySet1/amdump.3 at the backup server ---cut-on--- driver: adding holding disk 0 dir /amanda_holding_disk size 512000 reserving 512000 out of 512000 for degraded-mode dumps driver: start time 27.648 inparallel 10 bandwidth 600 diskspace 512000 dir OBSOLETE datestamp 20020126 driver: drain-ends tapeq LFFO big-dumpers 7 driver: result time 27.648 from taper: TAPER-OK driver: send-cmd time 27.648 to dumper0: FILE-DUMP 00-1 /amanda_holding_disk/20020126/heiner.buero-till.de._usr_samba1_ing__buero.1 heiner.buero-till.de /usr/s amba1/ing_buero 1 2002:1:23:23:46:49 1073741824 GNUTAR 96 |;bsd-auth;compress-fast;index;exclude-list=/etc/amanda/exclude.gtar; driver: state time 27.649 free kps: 590 space: 511904 taper: idle idle-dumpers: 9 qlen tapeq: 0 runq: 13 roomq: 0 wakeup: 15 driver-idle: start-wait driver: interface-state time 27.649 if : free 590 driver: hdisk-state time 27.649 hdisk 0: free 511904 dumpers 1 driver: send-cmd time 42.641 to dumper1: FILE-DUMP 01-2 /amanda_holding_disk/20020126/heiner.buero-till.de._usr_samba_fax__eingang.1 heiner.buero-till.de /usr/ samba/fax_eingang 1 2002:1:23:23:45:48 1073741824 GNUTAR 96 |;bsd-auth;compress-fast;index;exclude-list=/etc/amanda/exclude.gtar; driver: state time 42.642 free kps: 580 space: 511808 taper: idle idle-dumpers: 8 qlen tapeq: 0 runq: 12 roomq: 0 wakeup: 15 driver-idle: start-wait driver: interface-state time 42.642 if : free 580 driver: hdisk-state time 42.642 hdisk 0: free 511808 dumpers 2 driver: result time 42.643 from dumper1: TRY-AGAIN 01-2 nak error:amandad busy dumper: stream_client: connected to 192.168.1.25.41043 ---cut-off--- Your guess about the holding disk might be right, because I have only about 500 MB space left which is configured for this amount at amanda.conf. The data to backup are a few :) GB, is there a calculation for the size of the holding disk corresponding to the amount of data to backup? Sorry, I haven't found any amdump.* file neither at the server nor at the client. Well, don't blame me as I am a new user, but what do you mean with "dropping maxdumps back to 1" and how to do that? BTW, the server is a debian with a pentium II cpu at 400 MHz and amanda been installed from source, because debian doesn't have packages for the actual bugfixed release and it has no other jobs to do at night than amanda. ... I hope, that you can tell me to get a bigger holding disk and that this would fix my "could not connect to client" - problem. ... if not, I'll have to ask my boss, if he agrees about giving more information to your hands if you are willing to get them to help me :) :) adTHANXvance Sascha
Re: FAILURE AND STRANGE DUMP SUMMARY:
>Checking running processes is a nightshift job, I'd like to avoid :) Understood. I'm on a first name basis with all three Operations shifts (plus weekends) here, and I'm not sure that's necessarily a good thing. They're nice people, but at 3 AM ... :-) :-) >Any more tips left? I looked at the code and that error only comes from one place, when driver has tried doing a dump once and it failed but was requeued to "TRYAGAIN", then the second attempt also failed. I'm not sure the message means what it says, that there really was a problem connecting to the host. That may have been what it originally meant, but now it might mean other things (in case it isn't obvious, this code gets a little confusing to navigate). I'm pretty sure it has nothing to do with starting a new tapecycle, except in an indirect way (if at all). My best guess is it has something to do with the amount of holding disk space you have, or possibly other activity going on in the holding disk at the same time Amanda is running (e.g. Amanda thought it had N MBytes but when it actually tried to use the space, less than that was really there). I would need to see the corresponding amdump. file that goes along with one of these errors, and possibly all the client logs for that same run. If you want to contact me offline of the list for this, that's OK. In the meantime, you might try dropping maxdumps back to 1. That may or may not help -- it's just a guess. >Sascha John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: FAILURE AND STRANGE DUMP SUMMARY:
On Mon, 28 Jan 2002 13:01:40 -0500 "John R. Jackson" <[EMAIL PROTECTED]> wrote: > >... suddenly 3 of 14 mountpoints on the same machine failed > >for reasons I don't get. > >... > >machine /some/mountpoint_1 lev 1 FAILED [could not connect to machine] > > Some things to check: > > * See if there are left over amandad (or dumper) processes laying > around still running from a previous failure. > > * Verify that the amandad service in inetd.conf/xinetd is set to > "wait" (the default is "nowait"). > > * Make sure you don't have multiple cron jobs running at the same time. > Thanks John, - client's inetd.conf says: amanda dgram udp wait backup /usr/local/lib/amanda/amandad amandad - server's inetd.conf says: amandaidx stream tcp nowait backup /usr/local/lib/amanda/amindexd amindexd amidxtape stream tcp nowait backup /usr/local/lib/amanda/amidxtaped amidxtaped ...that's what the doc/INSTALL told me to do, which was pretty good working the first cycle of 11 tapes. Now, just after reusing the very first tape, those errors occured so suddenly. Obviously it was good to ask, because the new backup has even more faliures of this kind! I checked the cronjobs, there are the two like advised (one to check tape, the other one to run amanda) for the backup-user, none for root or any other at the same time. Checking running processes is a nightshift job, I'd like to avoid :) Any more tips left? adTHANXvance Sascha
Re: FAILURE AND STRANGE DUMP SUMMARY:
>... suddenly 3 of 14 mountpoints on the same machine failed >for reasons I don't get. >... >machine /some/mountpoint_1 lev 1 FAILED [could not connect to machine] Some things to check: * See if there are left over amandad (or dumper) processes laying around still running from a previous failure. * Verify that the amandad service in inetd.conf/xinetd is set to "wait" (the default is "nowait"). * Make sure you don't have multiple cron jobs running at the same time. >Sascha John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
FAILURE AND STRANGE DUMP SUMMARY:
Hi Helpers, as you can see, I am currently backing up just one client using gnutar. Now, having one tapecycle run, suddenly 3 of 14 mountpoints on the same machine failed for reasons I don't get. The mail from today, report from the night 25.-26. ---cut-on--- ... machine /some/mountpoint_1 lev 1 FAILED [could not connect to machine] machine /some/mountpoint_2 lev 1 FAILED [could not connect to machine] machine /some/mountpoint_3 lev 1 FAILED [could not connect to machine] STATISTICS: ... DUMP SUMMARY: DUMPER STATSTAPER STATS HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- - ... machine -mountpoint_8 0 880720 352416 40.0 5:411033.4 7:03 833.0 machine -mountpoint_9 FAILED --- machine -mountpoint_A FAILED --- machine -mountpoint_B 1 10 32 320.0 0:00 589.5 0:02 36.8 machine -mountpoint_C FAILED --- machine -mountpoint_D 1 679990 78272 11.5 1:061188.4 1:30 865.6 ... (brought to you by Amanda version 2.4.2p2) ---cut-off--- On the client-machine in /tmp/amanda I found no information leading to errors at sendsize.20020126004755.debug, nor at runtar.20020126???.debug but at amandad.20020126004937.debug: ---cut-on--- ... got packet: Amanda 2.4 REQ HANDLE 000-90B80708 SEQ 1012002305 ... sending ack: Amanda 2.4 ACK HANDLE 000-90B80708 SEQ 1012002305 ... amandad: got packet: Amanda 2.4 REQ HANDLE 000-78BA0708 SEQ 1012002304 amandad: received other packet, NAKing it addr: peer 192.168.1.15 dup 192.168.1.15, port: peer 854 dup 855 sending nack: Amanda 2.4 NAK HANDLE 000-78BA0708 SEQ 1012002304 ERROR amandad busy ... ... ... ---cut-off--- Why is amandad still busy? Or why ist the backup-server requesting a former sequenz? adTHANXvance Sascha
Re: FAILURE AND STRANGE DUMP SUMMARY:
Hi, Thks for zour former helps.. I do a special configuration with only the host that I'm having a problem with (atalante). and amanda success to do this. So i'm kind of puzzled about it. To give you more information I would like to tell you that -atalante is the "backup client host" and the "Tape Server Host" in the same time furthermore I'd like to ask some other questions - I don't really understand how you guys are nominating the clients and the servers I thought that amanda was composed of -many serverS on each host where we would like to backup data from -one client orchestrating the download and where we can found the programs amdump - Is there a way to force the planner to not do a level 0 on a host - Amrmtape: considering I'm using a configuration for many times and that I would like to do some changes on it. I thought that I can launch an amdump and if the result failed , I have just to launch an amrmtape to discard the last amdump and to have all the databases at the same point that before the tests (if I do the amrmtapes on all tapes used during the tests) > > >I get the fellowing error after launching amdump. > >... > >sendbackup: info BACKUP=/usr/sbin/ufsdump > >... > >| DUMP: SIGBUS() ABORTING! > >? DUMP: bread: dev_seek error: Invalid argument > > Actually, Amanda gets it after it launches ufsdump. This is not an > Amanda problem -- it's a ufsdump problem. If you ran that command > yourself the same way Amanda does, it would also fail. > > The first thing I'd do is contact Sun (I assume that's what the client > is running) and get the latest ufsdump/ufsrestore patches. > > John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: FAILURE AND STRANGE DUMP SUMMARY:
>I do a special configuration with only the host that I'm having a >problem with (atalante). >and amanda success to do this. >So i'm kind of puzzled about it. That could just mean whatever made ufsdump upset doesn't happen to be active at the moment. > -atalante is the "backup client host" and the "Tape Server Host" in the >same time OK. That's a normal situation. > - I don't really understand how you guys are nominating the clients and >the servers Yeah, that confuses people, and I agree the terminology could easily be considered "backward". But it is the way it is and to start calling things by the other names would only make matters worse. > I thought that amanda was composed of > -many serverS on each host where we would like to > backup data from Those are called "Amanda clients". > -one client orchestrating the download and where we can found > the programs amdump And that's called the "Amanda server". > - Is there a way to force the planner to not do a level 0 on a host Use "strategy nofull" or "strategy incronly" in the dumptype. But read about them in the amanda(8) man page. > - Amrmtape: considering I'm using a configuration for many times and >that > I would like to do some changes on it. I thought that I can launch an >amdump > and if the result failed , I have just to launch an amrmtape to discard >the > last amdump and to have all the databases at the same point that before >the tests > (if I do the amrmtapes on all tapes used during the tests) That should be correct. Why? Is it not working? You might also consider backing up (e.g. with GNU tar by hand) the curinfo database and tapelist files yourself before a test run, and then just restore them to start again. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: FAILURE AND STRANGE DUMP SUMMARY:
>I get the fellowing error after launching amdump. >... >sendbackup: info BACKUP=/usr/sbin/ufsdump >... >| DUMP: SIGBUS() ABORTING! >? DUMP: bread: dev_seek error: Invalid argument Actually, Amanda gets it after it launches ufsdump. This is not an Amanda problem -- it's a ufsdump problem. If you ran that command yourself the same way Amanda does, it would also fail. The first thing I'd do is contact Sun (I assume that's what the client is running) and get the latest ufsdump/ufsrestore patches. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
FAILURE AND STRANGE DUMP SUMMARY:
Hi, I get the fellowing error after launching amdump. Stuff to know: -atalante is the server that contains the holding disk on /export/diskE/amanda -in the disklist (atalante /export/diskE/ comp-user) FAILURE AND STRANGE DUMP SUMMARY: atalante /export/diskD lev 0 FAILED [/usr/sbin/ufsdump returned 3] ... ... ... ... FAILED AND STRANGE DUMP DETAILS: /-- atalante /export/diskD lev 0 FAILED [/usr/sbin/ufsdump returned 3] sendbackup: start [atalante:/export/diskD level 0] sendbackup: info BACKUP=/usr/sbin/ufsdump sendbackup: info RECOVER_CMD=//bin/gzip -dc |/usr/sbin/ufsrestore -f... - sendbackup: info COMPRESS_SUFFIX=.gz sendbackup: info end | DUMP: Writing 32 Kilobyte records | DUMP: Date of this level 0 dump: Sat Jul 28 04:05:34 2001 | DUMP: Date of last level 0 dump: the epoch | DUMP: Dumping /dev/rdsk/c0t10d0s6 (atalante:/export/diskD) to standard output. | DUMP: Mapping (Pass I) [regular files] | DUMP: Mapping (Pass II) [directories] | DUMP: Estimated 19926922 blocks (9729.94MB) on 0.14 tapes. | DUMP: Dumping (Pass III) [directories] | DUMP: Dumping (Pass IV) [regular files] | DUMP: 13.61% done, finished in 1:03 | DUMP: 28.10% done, finished in 0:51 | DUMP: 41.97% done, finished in 0:41 | DUMP: 53.98% done, finished in 0:34 | DUMP: 66.68% done, finished in 0:24 | DUMP: 78.91% done, finished in 0:16 | DUMP: 85.90% done, finished in 0:11 | DUMP: SIGBUS() ABORTING! | DUMP: SIGBUS() ABORTING! ? DUMP: bread: dev_seek error: Invalid argument ? DUMP: Error reading command pipe: Error 0 | DUMP: The ENTIRE dump is aborted. sendbackup: error [/usr/sbin/ufsdump returned 3] \
Strange dump summary
- What does this mean?(extract from a amdump report) FAILURE AND STRANGE DUMP SUMMARY: planner: FATAL protocol out of handles - When amanda tells that it is "expecting a new tape", what do i have to do? Giving an already labeled or unlabeled tape it's the same. - Is there any chance that amanda is capable of working only making dumps to hard drive? Thanks for your attention PS: I don't know if it's just me, but i haven't seen such a difficult backup software to install in my whole life. Please write a better help and documentation (?and tutorials?).
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.
"STRANGE DUMP SUMMARY"
HI, I got the following, and was wondering what the "Strange" meant, and what I could do about the "File too large" failures : ... FAILURE AND STRANGE DUMP SUMMARY: pipe10 /dev/hda1 lev 1 STRANGE workshop /dev/hdc lev 0 FAILED ["data write: File too large"] workshop /dev/hda1 lev 0 FAILED ["data write: File too large"] ... FAILED AND STRANGE DUMP DETAILS: /-- pipe10.pcp /dev/hda1 lev 1 STRANGE sendbackup: start [pipe10:/dev/hda1 level 1] sendbackup: info BACKUP=/sbin/dump sendbackup: info RECOVER_CMD=/sbin/restore -f... - sendbackup: info end | DUMP: Date of this level 1 dump: Tue Apr 24 07:59:26 2001 | DUMP: Date of last level 0 dump: Thu Apr 19 15:48:15 2001 | DUMP: Dumping /dev/hda1 (/) to standard output | DUMP: mapping (Pass I) [regular files] | DUMP: mapping (Pass II) [directories] | DUMP: estimated 469381 tape blocks. | DUMP: Volume 1 started at: Tue Apr 24 08:00:05 2001 | DUMP: dumping (Pass III) [directories] | DUMP: dumping (Pass IV) [regular files] ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: short read error from /dev/hda1: [block -892547938]: count=1024, got=0? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/hda1: [sector -892547938]: count=512, got=0? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/hda1: [sector -892547937]: count=512, got=0? DUMP: bread: lseek fails ? DUMP: short read error from /dev/hda1: [block -1032166684]: count=1024, got=0 ? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/hda1: [sector -1032166684]: count=512, got=0 ? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/hda1: [sector -1032166683]: count=512, got=0 ? DUMP: bread: lseek fails ? DUMP: short read error from /dev/hda1: [block -556603194]: count=1024, got=0? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/hda1: [sector -556603194]: count=512, got=0? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/hda1: [sector -556603193]: count=512, got=0? DUMP: bread: lseek fails | DUMP: 32.21% done, finished in 0:10 | DUMP: 46.60% done, finished in 0:11 | DUMP: 69.02% done, finished in 0:06 | DUMP: DUMP: 476474 tape blocks | DUMP: finished in 1143 seconds, throughput 416 KBytes/sec | DUMP: Volume 1 completed at: Tue Apr 24 08:19:09 2001 | DUMP: Volume 1 took 0:19:04 | DUMP: Volume 1 transfer rate: 416 KB/s | DUMP: level 1 dump on Tue Apr 24 07:59:26 2001 | DUMP: DUMP: Date of this level 1 dump: Tue Apr 24 07:59:26 2001 | DUMP: DUMP: Date this dump completed: Tue Apr 24 08:19:09 2001 | DUMP: DUMP: Average transfer rate: 416 KB/s | DUMP: DUMP IS DONE sendbackup: size 476474 sendbackup: end \ /-- workshop.p /dev/hdc lev 0 FAILED ["data write: File too large"] sendbackup: start [workshop:/dev/hdc level 0] sendbackup: info BACKUP=/sbin/dump sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/sbin/restore -f... - sendbackup: info COMPRESS_SUFFIX=.gz sendbackup: info end | DUMP: Date of this level 0 dump: Tue Apr 24 04:20:30 2001 | DUMP: Date of last level 0 dump: the epoch | DUMP: Dumping /dev/hdc (/ddisk) to standard output | DUMP: mapping (Pass I) [regular files] | DUMP: mapping (Pass II) [directories] | DUMP: estimated 22438288 tape blocks. | DUMP: dumping (Pass III) [directories] | DUMP: dumping (Pass IV) [regular files] | DUMP: 0.80% done, finished in 35:54 | DUMP: 3.84% done, finished in 9:19 | DUMP: 6.88% done, finished in 6:09 | DUMP: 10.03% done, finished in 4:49 | DUMP: 12.65% done, finished in 4:17 | DUMP: 15.35% done, finished in 3:53 | DUMP: 18.41% done, finished in 3:29 | DUMP: 20.39% done, finished in 3:24 | DUMP: 22.80% done, finished in 3:13 | DUMP: 25.57% done, finished in 3:01 | DUMP: 27.39% done, finished in 2:58 | DUMP: 29.50% done, finished in 2:52 | DUMP: 31.21% done, finished in 2:50 | DUMP: 32.65% done, finished in 2:49 | DUMP: 35.02% done, finished in 2:41 | DUMP: 38.16% done, finished in 2:29 | DUMP: 40.78% done, finished in 2:21 | DUMP: 43.64% done, finished in 2:12 | DUMP: 46.15% done, finished in 2:05 | DUMP: 48.80% done, finished in 1:57 \ /-- workshop.p /dev/hda1 lev 0 FAILED ["data write: File too large"] sendbackup: start [workshop:/dev/hda1 level 0] sendbackup: info BACKUP=/sbin/dump sendbackup: info RECOVER_CMD=/sbin/restore -f... - sendbackup: info end | DUMP: Date of this level 0 dump: Tue Apr 24 06:21:14 2001 | DUMP: Date of last level 0 dump: the epoch | DUMP: Dumping /dev/hda1 (/) to standard output | DUMP: mapping (Pass I) [regular files] | DUMP: mapping (Pass II) [directories] | DUMP: estimated 4673779 tape blocks. | DUMP: dumping (Pass III) [directories] | DUMP: dumping (Pass IV) [regular files] | DUMP: 4.42% done, finished in 1:48 | DUMP: 13.60% done, finished in 1:03 | DUMP: 23.01% done, finished in 0:50 | DUMP: 32.63% done, finis
Re: Failure and strange dump summary
>when i run the "new" amcheck utility "/usr/local/sbin/amcheck " i got >the error: > >/usr/local/etc/amanda//amanda.conf", line 85: configuration keyword >expected >"/usr/local/etc/amanda//amanda.conf", line 85: end of line expected >"/usr/local/etc/amanda//amanda.conf", line 88: configuration keyword >expected >"/usr/local/etc/amanda//amanda.conf", line 88: end of line expected So what's on lines 85 and 88? >has the amanda.conf file syntax changed from previous versions of amanda ?? I don't think so. You need to look at the lines it doesn't like and compare them to amanda(8) and/or post them here. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Failure and strange dump summary
Yop again! i sucessfully upgraded to amanda 2.4.2 but my original path to the am* binaries changed from /usr/sbin to /usr/local/sbin so i copied my /etc/amanda/ files to /usr/local/etc/amanda/ when i run the "new" amcheck utility "/usr/local/sbin/amcheck " i got the error: /usr/local/etc/amanda//amanda.conf", line 85: configuration keyword expected "/usr/local/etc/amanda//amanda.conf", line 85: end of line expected "/usr/local/etc/amanda//amanda.conf", line 88: configuration keyword expected "/usr/local/etc/amanda//amanda.conf", line 88: end of line expected my question is : has the amanda.conf file syntax changed from previous versions of amanda ?? my previus version was 2.4.2-19991216-beta1 - Original Message - From: "Alexandre Oliva" <[EMAIL PROTECTED]> To: "FFx" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, February 20, 2001 12:51 PM Subject: Re: Failure and strange dump summary > On Feb 20, 2001, "FFx" <[EMAIL PROTECTED]> wrote: > > > my exact version is : amanda 2.4.2-19991216-beta1 > > Then yours pre-dates the patch. Time to upgrade :-) > > -- > Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ > Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} > CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org} > Free Software Evangelist*Please* write to mailing lists, not to me >
Re: Failure and strange dump summary
On Feb 20, 2001, "FFx" <[EMAIL PROTECTED]> wrote: > my exact version is : amanda 2.4.2-19991216-beta1 Then yours pre-dates the patch. Time to upgrade :-) -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist*Please* write to mailing lists, not to me
Re: Failure and strange dump summary
my exact version is : amanda 2.4.2-19991216-beta1 - Original Message - From: "Alexandre Oliva" <[EMAIL PROTECTED]> To: "FFx" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, February 20, 2001 11:23 AM Subject: Re: Failure and strange dump summary > On Feb 20, 2001, "FFx" <[EMAIL PROTECTED]> wrote: > > > ? gtar: ./dev/log: socket ignored > > Are you sure the client is running Amanda 2.4.2? The patch that > ignored this message went in on May 28 last year. > > -- > Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ > Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} > CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org} > Free Software Evangelist*Please* write to mailing lists, not to me >
Re: Failure and strange dump summary
On Feb 20, 2001, "FFx" <[EMAIL PROTECTED]> wrote: > ? gtar: ./dev/log: socket ignored Are you sure the client is running Amanda 2.4.2? The patch that ignored this message went in on May 28 last year. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist*Please* write to mailing lists, not to me
Failure and strange dump summary
Hi ! i have installed amanda 2.4.2 with Debian 2.2 core 2.2.16fix1 in a compaq proliant server i created the host list, tape labels, volume index and configured my changer ( autoloader 7x DAT DDS-3) all dumps complete successfully but one fails with the following error : /-- luisinII / lev 1 STRANGEsendbackup: start [luisinII:/ level 1]sendbackup: info BACKUP=/bin/tarsendbackup: info RECOVER_CMD=/bin/tar -f... -sendbackup: info end? gtar: ./dev/log: socket ignored| Total bytes written: 143360 (140kB, ?B/s)sendbackup: size 140sendbackup: end\ Can someone explain to me what this log means and what's the problem ? Regards. José
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])
Strange dump summary...
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/
RE: FAILURE AND STRANGE DUMP SUMMARY
We had a similar problem (well, the exact same problem) but ended up getting the computer in question to backup to a share, and getting amanda to backup the share which contained 1 big file because I was getting annoyed with it. Only problem is, that smbclient doesn't know how to read files > 2G or thereabouts, which means it returns a file size of -197M to the planner. Obviously, the planner feels this is an unusual state of affairs, not being versed with an imagination, and refuses to try and backup -197M. Apparently it's a samba problem; unfortunately not one we've worked out - if you do suss it then please let me know! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mitch Collinsworth Sent: Wednesday, 24 January 2001 02:14 To: Gerald T. Freymann Cc: [EMAIL PROTECTED] Subject: Re: FAILURE AND STRANGE DUMP SUMMARY On Tue, 23 Jan 2001, Gerald T. Freymann wrote: > FAILURE AND STRANGE DUMP SUMMARY: > amanda file://xxx/PAP2 lev 0 STRANGE > > And then what follows is a line by line blow of each and every file that > got backed up. > > How do you make Amanda think these PC shares are no longer "Strange?" You didn't say what versions of amanda and samba you're using. I used to see this with old versions when I had samba configured with too high a logging level. It's been so long since I've looked at this I don't now remember what the correct level is, but this is where I'd suggest looking first. -Mitch P.S. You have a very catchy name. Well to me anyhow, since I have an uncle named Jerry Freyman. :-)
Re: FAILURE AND STRANGE DUMP SUMMARY
Gerald T. Freymann <[EMAIL PROTECTED]> wrote: > I'm using Amanda 2.4.1p1 and Samba 2.0.7 You should apply the patch http://www.amanda.org/patches/2.4.1p1/samba2-2418.diff or upgrade to amanda-2.4.2 HTH, Lipo -- Roland E. Lipovits Vienna, Austria
Re: FAILURE AND STRANGE DUMP SUMMARY
> You didn't say what versions of amanda and samba you're using. I > used to see this with old versions when I had samba configured with > too high a logging level. I'm using Amanda 2.4.1p1 and Samba 2.0.7 > P.S. You have a very catchy name. Well to me anyhow, since I > have an uncle named Jerry Freyman. :-) Oh? We're from Lithuanian (sp?) originally... Grandma landed in Toronto, Ontario, Canada many moons ago. Grandfather was left behind as a POW. -Gerry
Re: FAILURE AND STRANGE DUMP SUMMARY
On Tue, 23 Jan 2001, Gerald T. Freymann wrote: > FAILURE AND STRANGE DUMP SUMMARY: > amanda file://xxx/PAP2 lev 0 STRANGE > > And then what follows is a line by line blow of each and every file that > got backed up. > > How do you make Amanda think these PC shares are no longer "Strange?" You didn't say what versions of amanda and samba you're using. I used to see this with old versions when I had samba configured with too high a logging level. It's been so long since I've looked at this I don't now remember what the correct level is, but this is where I'd suggest looking first. -Mitch P.S. You have a very catchy name. Well to me anyhow, since I have an uncle named Jerry Freyman. :-)
FAILURE AND STRANGE DUMP SUMMARY
Now that I finally have my rebuilt Amanda server working again, there is one item that I'd like to check in on. When it backs up the PC shares on our Win2K, WinNT and Win95 boxes, I get this: FAILURE AND STRANGE DUMP SUMMARY: amanda file://xxx/PAP2 lev 0 STRANGE amanda file://xxx/EAGLE lev 0 STRANGE amanda file://xxx/OUTLOOK lev 0 STRANGE amanda file://xx3/d lev 0 STRANGE amanda file://xx2/d lev 0 STRANGE amanda file://x/d lev 0 STRANGE And then what follows is a line by line blow of each and every file that got backed up. The email message we get sent to us can be up to 6 megabytes in size, and is darn right painful to even attempt to view and has been know to crash Outlook 2000/Express when received. How do you make Amanda think these PC shares are no longer "Strange?" -Gerry
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
strange dump summary - can you explain this?
There was a huge amount of output - so I will only forward you part of the dump summary from the Amanda Mail Report - FAILURE AND STRANGE DUMP SUMMARY: admin1.cor sda10 lev 1 FAILED [/sbin/dump returned 3] STATISTICS: Total Full Daily Dump Time (hrs:min)0:02 0:00 0:00 (0:02 start) Output Size (meg)1828.2 1705.0 123.2 Original Size (meg) 1828.2 1705.0 123.2 Avg Compressed Size (%) -- -- -- Tape Used (%) 5.14.80.3 (level:#disks ...) Filesystems Dumped7 4 3 (1:3) Avg Dump Rate (k/s) 2076.1 2464.8 652.4 Avg Tp Write Rate (k/s) -- -- -- ? FAILED AND STRANGE DUMP DETAILS: /-- admin1.cor sda10 lev 1 FAILED [/sbin/dump returned 3] sendbackup: start [admin1.corp.walid.com:sda10 level 1] sendbackup: info BACKUP=/sbin/dump sendbackup: info RECOVER_CMD=/sbin/restore -f... - sendbackup: info end | DUMP: Date of this level 1 dump: Thu Jan 11 06:23:46 2001 | DUMP: Date of last level 0 dump: Sat Jan 6 07:28:54 2001 | DUMP: Dumping /dev/sda10 (/home) to standard output | DUMP: Label: none | DUMP: mapping (Pass I) [regular files] | DUMP: mapping (Pass II) [directories] | DUMP: estimated 2364864 tape blocks. | DUMP: Volume 1 started at: Thu Jan 11 06:24:56 2001 | DUMP: dumping (Pass III) [directories] | DUMP: dumping (Pass IV) [regular files] | DUMP: 40.91% done, finished in 0:07 ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: short read error from /dev/sda10: [block -2122605784]: count=2048, got=0 ? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/sda10: [sector -2122605784]: count=512, got=0 ? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/sda10: [sector -2122605783]: count=512, got=0 ? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/sda10: [sector -2122605782]: count=512, got=0 ? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/sda10: [sector -2122605781]: count=512, got=0 ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: bread: lseek fails ? DUMP: short read error from /dev/sda10: [block -1452170888]: count=4096, got=0 ? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/sda10: [sector -1452170888]: count=512, got=0 ? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/sda10: [sector -1452170887]: count=512, got=0 ? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/sda10: [sector -1452170886]: count=512, got=0 ? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/sda10: [sector -1452170885]: count=512, got=0 ? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/sda10: [sector -1452170884]: count=512, got=0 ? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/sda10: [sector -1452170883]: count=512, got=0 ? DUMP: bread: lseek2 fails! ? DUMP: short read error from /dev/sda10: [block -1989041720]: count=4096, got=0 ? 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] \ DUMP SUMMARY: DUMPER STATS TAPER STATS HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- -- -- admin1.co sda10 1 FAILED admin1.co sda2 0 1294208 1294208 -- 8:00 2697.8N/A N/A admin1.co sda3 0 6048 6048 -- 0:03 2335.3N/A N/A admin1.co sda5 1 5248 5248 -- 0:23 227.5N/A N/A admin1.co sda6 0 161856 161856 -- 1:10 2327.5N/A N/A sundev1.c c0t0d0s0 1 2560 2560 -- 0:38 67.3N/A N/A sundev1.c c0t0d0s3 0 283776 283776 -- 2:36 1813.7N/A N/A sundev1.c c0t0d0s7 1 118368 118368 -- 2:12 894.5N/A N/A (brought to you by Amanda version 2.4.1p1)