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.
How to Extract Same Database in Two Different Virtual Tapes??
Hi Guys, Here is my way to do recover: . output truncated . amrecover add Ayofun_CSite Added dir /Ayofun_CSite/ at date 2007-06-07-00-30-01 Added dir /Ayofun_CSite/ at date 2007-06-11-00-30-02 amrecover list TAPE DailySet1-07:8 LEVEL 0 DATE 2007-06-07-00-30-01 /Ayofun_CSite TAPE DailySet1-11:5 LEVEL 1 DATE 2007-06-11-00-30-02 /Ayofun_CSite amrecover settape backup.mydomain.com:file:/data/amandadumps/tape07 Using tape file:/data/amandadumps/tape07 from server backup.mydomain.com. amrecover settape backup.mydomain.com:file:/data/amandadumps/tape11 Using tape file:/data/amandadumps/tape11 from server backup.mydomain.com. amrecover extract Extracting files using tape drive file:/data/amandadumps/tape11 on host backup.mydomain.com. The following tapes are needed: DailySet1-07 DailySet1-11 Restoring files into directory /data/amandarecover Continue [?/Y/n]? y Extracting files using tape drive file:/data/amandadumps/tape11 on host backup.mydomain.com. Load tape DailySet1-07 now Continue [?/Y/n/s/t]? y Label mismatch, got DailySet1-11 and expected DailySet1-07 Load tape DailySet1-07 now Continue [?/Y/n/t]? y Label mismatch, got DailySet1-11 and expected DailySet1-07 Label mismatch, got DailySet1-11 and expected DailySet1-07 Load tape DailySet1-07 now Continue [?/Y/n/t]? y Label mismatch, got DailySet1-11 and expected DailySet1-07 Label mismatch, got DailySet1-11 and expected DailySet1-07 Load tape DailySet1-07 now Continue [?/Y/n/t]? y Label mismatch, got DailySet1-11 and expected DailySet1-07 Label mismatch, got DailySet1-11 and expected DailySet1-07 If U see the Ayofun_CSite database appeared in two different virtual tapes. I can recover for just one virtual tape. How to recover both of different virtual tapes? Pls help. -- View this message in context: http://www.nabble.com/How-to-Extract-Same-Database-in-Two-Different-Virtual-Tapes---tf3900338.html#a11057128 Sent from the Amanda - Users mailing list archive at Nabble.com.
Re: How to Extract Same Database in Two Different Virtual Tapes??
Label mismatch, got DailySet1-11 and expected DailySet1-07 Label mismatch, got DailySet1-11 and expected DailySet1-07 If U see the Ayofun_CSite database appeared in two different virtual tapes. I can recover for just one virtual tape. How to recover both of different virtual tapes? Pls help. It looks like a tape changer problem to me. Olivier
Re: How to Extract Same Database in Two Different Virtual Tapes??
Hi, If U see the Ayofun_CSite database appeared in two different virtual tapes. I can recover for just one virtual tape. How to recover both of different virtual tapes? Pls help. -- I use a tape changer configuration for my vtapes, too. When I restore files that are on more than one vtape, then amrecover ask me to insert tape1 (the changer does this by hisself when I hit yes), and later for tape2 (same procedure). No need to change the tapes by myself or something else. I think something is wrong with your changer configuration. Take a look at http://www.amanda.org/docs/howto-filedriver.html If you don't find the problem with the documentation, you can send your changer configuration to the list, so we can try to find the problem. 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: How to Extract Same Database in Two Different Virtual Tapes??
On 2007-06-11 12:17, Marc Muehlfeld wrote: Hi, If U see the Ayofun_CSite database appeared in two different virtual tapes. I can recover for just one virtual tape. How to recover both of different virtual tapes? Pls help. -- I use a tape changer configuration for my vtapes, too. When I restore files that are on more than one vtape, then amrecover ask me to insert tape1 (the changer does this by hisself when I hit yes), and later for tape2 (same procedure). No need to change the tapes by myself or something else. I think something is wrong with your changer configuration. Take a look at http://www.amanda.org/docs/howto-filedriver.html See also: http://wiki.zmanda.com/index.php/File_driver#Recovery wich has a much updated version of that text, including how to load the tapes automatically, instead of manually. -- 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
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
estimate timeouts at 6hrs?
Hi,
A new problem that has me stumped: all the amdumps from client to server
(same host runing 2.5.2-20070623) have failed due to estimate timing
out after 6:00h. This happened in all the multiple config that I run,
even though the etimeout in each of the amanda config is set to
ridiculous value: in one case etimeout=5600 and I have 77 DLEs which
should not timeout for ~120h! Anything else could cause this:
FAILURE AND STRANGE DUMP SUMMARY:
yorick /data/bigml/bigml1 lev 0 FAILED [disk
/data/bigml/bigml1, all estimate timed out]
...
yorick /data/nih/nih1/ lev 0 FAILED [disk
/data/nih/nih1/, all estimate timed out]
planner: ERROR Request to yorick failed: EOF on read from yorick
STATISTICS:
Total Full Incr.
Estimate Time (hrs:min)6:00
Run Time (hrs:min)15:07
Dump Time (hrs:min) 15:14 14:59 0:15
jf
--
°
Re: estimate timeouts at 6hrs?
* Jean-Francois Malouin [EMAIL PROTECTED] [20070611 09:01]:
Hi,
A new problem that has me stumped: all the amdumps from client to server
(same host runing 2.5.2-20070623) have failed due to estimate timing
^^^make that 2.5.2-20070523
out after 6:00h. This happened in all the multiple config that I run,
even though the etimeout in each of the amanda config is set to
ridiculous value: in one case etimeout=5600 and I have 77 DLEs which
should not timeout for ~120h! Anything else could cause this:
FAILURE AND STRANGE DUMP SUMMARY:
yorick /data/bigml/bigml1 lev 0 FAILED [disk
/data/bigml/bigml1, all estimate timed out]
...
yorick /data/nih/nih1/ lev 0 FAILED [disk
/data/nih/nih1/, all estimate timed out]
planner: ERROR Request to yorick failed: EOF on read from yorick
STATISTICS:
Total Full Incr.
Estimate Time (hrs:min)6:00
Run Time (hrs:min)15:07
Dump Time (hrs:min) 15:14 14:59 0:15
jf
--
°
--
°
Re: estimate timeouts at 6hrs?
amandad have a hard limit of 6h (see REP_TIMEOUT in amandad-src/amandad.c)
in waiting for the reply from sendsize.
Try the attached patch, it reset the timeout after each estimates.
Jean-Louis
Jean-Francois Malouin wrote:
Hi,
A new problem that has me stumped: all the amdumps from client to server
(same host runing 2.5.2-20070623) have failed due to estimate timing
out after 6:00h. This happened in all the multiple config that I run,
even though the etimeout in each of the amanda config is set to
ridiculous value: in one case etimeout=5600 and I have 77 DLEs which
should not timeout for ~120h! Anything else could cause this:
FAILURE AND STRANGE DUMP SUMMARY:
yorick /data/bigml/bigml1 lev 0 FAILED [disk
/data/bigml/bigml1, all estimate timed out]
...
yorick /data/nih/nih1/ lev 0 FAILED [disk
/data/nih/nih1/, all estimate timed out]
planner: ERROR Request to yorick failed: EOF on read from yorick
STATISTICS:
Total Full Incr.
Estimate Time (hrs:min)6:00
Run Time (hrs:min)15:07
Dump Time (hrs:min) 15:14 14:59 0:15
jf
diff -u -r --show-c-function --new-file --exclude-from=/home/martinea/src.orig/amanda.diff --ignore-matching-lines='$Id:' amanda-2.5.2p1/amandad-src/amandad.c amanda-2.5.2p1.amandad/amandad-src/amandad.c
--- amanda-2.5.2p1/amandad-src/amandad.c 2007-05-04 07:39:06.0 -0400
+++ amanda-2.5.2p1.amandad/amandad-src/amandad.c 2007-06-11 09:56:32.0 -0400
@@ -901,8 +901,13 @@ s_repwait(
do_sendpkt(as-security_handle, as-rep_pkt);
amfree(as-rep_pkt.body);
pkt_init_empty(as-rep_pkt, P_REP);
- }
+ assert(as-ev_reptimeout != NULL);
+ event_release(as-ev_reptimeout);
+ as-ev_reptimeout = event_register(REP_TIMEOUT, EV_TIME,
+ timeout_repfd, as);
+ }
+
return (A_PENDING);
}
Re: estimate timeouts at 6hrs?
* Jean-Louis Martineau [EMAIL PROTECTED] [20070611 10:00]:
amandad have a hard limit of 6h (see REP_TIMEOUT in amandad-src/amandad.c)
in waiting for the reply from sendsize.
Try the attached patch, it reset the timeout after each estimates.
Thanks Jean-Louis.
Would that explains why I see a lot of runaway processes after
sendsize times out? Over the weekend I had a situation where over +90
gnutar processes were left around with init as parent like the
following:
UIDPID PPID CSTIMETTY TIME CMD
root 23243074 1 016:22:41 ? 11:40 gtar --create --file -
--directory /data/mafalda/mafalda1/susanita/jen/anxiety_
The relevent debug file showed:
runtar.20070610162241.debug
runtar: debug 1 pid 23243074 ruid 666 euid 0: start at Sun Jun 10
16:22:41 2007
runtar: time 0.002: version 2.5.2-20070523
/usr/freeware/bin/tar version: tar (GNU tar) 1.13.25
config: stk_80-conf1
runtar: debug 1 pid 23243074 ruid 0 euid 0: rename at Sun Jun 10
16:22:41 2007
running: /usr/freeware/bin/tar: 'gtar' '--create' '--file' '-'
'--directory'
'/data/mafalda/mafalda1/susanita/jen/anxiety_version1/sub115'
'--one-file-system' '--listed-incremental'
'/opt/amanda/amanda1/var/amanda/gnutar-lists/yoricksub115_1.new'
'--sparse'
'--ignore-failed-read' '--totals' '.'
runtar: time 0.020: pid 23243074 finish time Sun Jun 10 16:22:41 2007
I've this with both xfsdump and gnutar.
thanks, jf
Jean-Louis
Jean-Francois Malouin wrote:
Hi,
A new problem that has me stumped: all the amdumps from client to server
(same host runing 2.5.2-20070623) have failed due to estimate timing
out after 6:00h. This happened in all the multiple config that I run,
even though the etimeout in each of the amanda config is set to
ridiculous value: in one case etimeout=5600 and I have 77 DLEs which
should not timeout for ~120h! Anything else could cause this:
FAILURE AND STRANGE DUMP SUMMARY:
yorick /data/bigml/bigml1 lev 0 FAILED [disk
/data/bigml/bigml1, all estimate timed out]
...
yorick /data/nih/nih1/ lev 0 FAILED [disk
/data/nih/nih1/, all estimate timed out]
planner: ERROR Request to yorick failed: EOF on read from yorick
STATISTICS:
Total Full Incr.
Estimate Time (hrs:min)6:00
Run Time (hrs:min)15:07
Dump Time (hrs:min) 15:14 14:59 0:15
jf
--
°
one client stopped
I'm stumped. A few days ago, 6/6, one client stopped backing up completely, all DLE's. The basic error message(s) are cannot read header: got 0 instead of 32768 data timeout Of course I made no changes to either client or server around that date :)) (big smiley just in case) Estimates are done on the server, so I assume the timeout is waiting for the tar data. Matching this is that the previously successful amdump runs would complete in 60-90 minutes, now amdump doesn't finish for 5-6 hours, waiting for data no doubt. Server logs show the command being prepared but the holding disk temp file is empty at at the timeout. A surprise to me was the /tmp/amanda debug files on the client. On the successful days only two types of file are present: sendbackup.*.exclude (empty) runtar.*.debug On the failing days neither of those are present, instead there are: amandad.*.debug (1 included below) selfcheck.*.debug selfcheck.*.exclude sendbackup.*.debug(1 included below) amcheck is clean client is Sol 9 x86 running amanda 2.4.4 server is Fedora 4 running amanda 2.5.0.p2 === amandad.20070609063322.debug === amandad: debug 1 pid 7008 ruid 27 euid 27: start at Sat Jun 9 06:33:22 2007 amandad: version 2.4.4-20030529 amandad: build: VERSION=Amanda-2.4.4-20030529 amandad:BUILT_DATE=Thu May 29 10:57:59 EDT 2003 amandad:BUILT_MACH=SunOS butch 5.9 Generic_112234-04 i86pc i386 i86pc amandad:CC=gcc amandad:CONFIGURE_COMMAND='./configure' '--prefix=/usr/local' '--enable-shared' '--with-user=amanda' '--with-group=backup' '--with-config=DS1' '--with-includes=/opt/sfw/include' '--with-libraries=/opt/sfw/lib' '--with-amandahosts' '--with-tape-device=/dev/rmt/0ln' '--with-changer-device=/dev/rmt/1ln' '--with-readline' '--with-mmap' '--with-gnutar=/usr/local/libexec/amgtar' '--with-pid-debug-files' '--without-termcap' '--without-ltermcap' '--without-LIBTERMCAP' '--with-ncurses=yes' '--with-lncurses=yes' '--with-LIBNCURSES=yes' amandad: paths: bindir=/usr/local/bin sbindir=/usr/local/sbin amandad:libexecdir=/usr/local/libexec mandir=/usr/local/man amandad:AMANDA_TMPDIR=/tmp/amanda AMANDA_DBGDIR=/tmp/amanda amandad:CONFIG_DIR=/usr/local/etc/amanda DEV_PREFIX=/dev/dsk/ amandad:RDEV_PREFIX=/dev/rdsk/ DUMP=/usr/sbin/ufsdump amandad:RESTORE=/usr/sbin/ufsrestore amandad:SAMBA_CLIENT=/usr/sfw/bin/smbclient amandad:GNUTAR=/usr/local/libexec/amgtar amandad:COMPRESS_PATH=/usr/bin/gzip amandad:UNCOMPRESS_PATH=/usr/bin/gzip MAILER=/usr/ucb/Mail amandad:listed_incr_dir=/usr/local/var/amanda/gnutar-lists amandad: defs: DEFAULT_SERVER=butch DEFAULT_CONFIG=DS1 amandad:DEFAULT_TAPE_SERVER=butch amandad:DEFAULT_TAPE_DEVICE=/dev/rmt/0ln HAVE_MMAP amandad:LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE amandad:AMANDA_DEBUG_DAYS=4 BSD_SECURITY USE_AMANDAHOSTS amandad:CLIENT_LOGIN=amanda FORCE_USERID HAVE_GZIP amandad:COMPRESS_SUFFIX=.gz COMPRESS_FAST_OPT=--fast amandad:COMPRESS_BEST_OPT=--best UNCOMPRESS_OPT=-dc amandad: time 0.000: got packet: Amanda 2.5 REQ HANDLE 000-0011 SEQ 1181629152 SECURITY USER amandabackup SERVICE sendbackup OPTIONS features=feff9ffe07;hostname=butch; GNUTAR HOME /home 4 2007:6:4:7:9:20 OPTIONS |;auth=BSD;compress-fast;index;exclude-list=/usr/local/lib/amanda/exclude.gtar;exclude-optional; amandad: time 0.000: sending ack: Amanda 2.4 ACK HANDLE 000-0011 SEQ 1181629152 amandad: time 0.001: bsd security: remote host bigcow.jgcomp.com user amandabackup local user amanda amandad: time 0.002: amandahosts security check passed amandad: time 0.002: running service /usr/local/libexec/sendbackup amandad: time 0.019: sending REP packet: Amanda 2.4 REP HANDLE 000-0011 SEQ 1181629152 CONNECT DATA 35365 MESG 35366 INDEX 35367 OPTIONS features=feff9ffe0f; amandad: time 0.019: got packet: Amanda 2.5 ACK HANDLE 000-0011 SEQ 1181629152 amandad: time 0.019: pid 7008 finish time Sat Jun 9 06:33:22 2007 === sendbackup.20070609053322.debug === sendbackup: debug 1 pid 6593 ruid 27 euid 27: start at Sat Jun 9 05:33:22 2007 /usr/local/libexec/sendbackup: version 2.4.4-20030529 parsed request as: program `GNUTAR' disk `OPT' device `/opt' level 2 since 2007:6:4:7:5:45 options `|;auth=BSD;compress-fast;index;exclude-list=/usr/local/lib/amanda/exclude.gtar;exclude-optional;' sendbackup: try_socksize: send buffer size is 65536 sendbackup: time 0.005: stream_server: waiting for connection: 0.0.0.0.35282 sendbackup: time 0.005: stream_server: waiting for connection: 0.0.0.0.35283 sendbackup: time 0.006: stream_server: waiting for connection: 0.0.0.0.35284 sendbackup: time 0.006: waiting for connect on 35282, then 35283, then 35284
Re: one client stopped
On Mon, Jun 11, 2007 at 03:27:04PM -0400, Jon LaBadie wrote: I'm stumped. A few days ago, 6/6, one client stopped backing up completely, all DLE's. The basic error message(s) are cannot read header: got 0 instead of 32768 data timeout Of course I made no changes to either client or server around that date :)) (big smiley just in case) Well, it will stay an unknown. As I looked further, I found there were tons of gzip's and sendbackup's still around from several days runs. As an unrelated issue, there were several updatedb's and it related programs hanging around too. I killed them off and tried to run amdump for just that one client. It hung without getting even one estimate. So I did the unusual, I rebooted the client. First time this year. After that I ran an amdump for that client and it ran fine. So looks like I'm back in business but with mystery unsolved. jl -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: one client stopped
Of course I made no changes to either client or server around that date :)) (big smiley just in case) Sorry for the delay but I just started work and am reading my nightly email. I had the same delay problem recently, one client suddenly would finish in 30 hours (yes I let it run) instead of 20 minutes. I had not changed anything on the client nor the server. Though it happened that I had rebooted the network gears. When the client reconnected to the network switch, Ethernet connection was poorly negociated, hence the degradated network and dump performance. Dunno if it was your case, just a thought. Olivier
