Re: Backups fail on new client: too many dumper retry
> The normal conversation for "sendbackup" goes like this: In the view of repeated problem like this (I recently got hit on the head myself), shouldn't it be tested by amcheck too? I understand that amcheck of the clients done only a check of the UDP connection. Maybe it should launch the TCP connections on the client and have the server try to connect to it. That way it could present a complete diagnostic. Should I set-up a client 6 months from now, I am sure that on the first run, I will fail due to the TCP ports are not reachable. I will know what I did wrong, but I am pretty certain the first run will fail, because current amcheck reports no problem for that TCP part. OK that's my 2 satang. Olivier
Re: Backups fail on new client: too many dumper retry
On Wed, Jun 21, 2006 at 10:24:49PM +0200, Paul Bijnens wrote: > Charles Curley schreef: > > > >Nothing other than the problem I've already asked about & to which > >I've gotten no answer: Is the client trying to connect to > >0.0.0.0.50509? And if so, where is that set up? > > 0.0.0.0 means the amandad process is listening on any interface > (not only 127.0.0.1 or not only 192.169.0.1 etc.). Thank you. that helps. > > The normal conversation for "sendbackup" goes like this: > The server sends a UDP packet "sendbackup" request, and the DLE that it > wants to do, together with some options used, e.g. if it wants indexes > generated too. > The client then prepares two or three tcp-connections: one for data, for > error messages (which also contains the "Total size" line), and, if > needed, a connections transferring the indexes. > The client responds with a UDP packet on which ports these TCP > connections will be listening. > The server then needs to connect to each of these ports on the client. > > And there is seems to fail. Thank you. > > As you said, you are using iptables, so problably the the packets are > being blocked by iptables. > > To solve: > > 1. Easiest: load iptables helper module ip_conntrack_amanda: > modprobe ip_conntrack_amanda >(which will inspect the conversation above and open those two or >three ports selectively as needed). Thank you. That solved the problem. It never occured to me to look for such a beast. I'd have responded sooner, but I waited until I had four level 0 backups from the client completed in order to be sure. -- Charles Curley /"\ASCII Ribbon Campaign Looking for fine software \ /Respect for open standards and/or writing? X No HTML/RTF in email http://www.charlescurley.com/ \No M$ Word docs in email Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB pgpgDqh3sFSEo.pgp Description: PGP signature
Re: amandad process defunct
Joe Donner (sent by Nabble.com) schreef: Hi, I'm running Amanda in a test lab, and every several days or so the backup job to virtual tape fails because a process called amandad becomes unresponsive on the backup client. When doing an amcheck from the Amanda server it tells me that amandad on the client is "busy". When having a look at the client with the ps command, it lists two diferent amandad processes, with one showing as being "defunct". I cannot kill this process, but when I kill the other amandad process I can get rid of both, but then have to reboot the client to get the backup job to work again. Do you know how I can avoid doing this reboot, or what may be going on here? Reboot is a pretty drastic remedy :-) When the amandad process is killed, doesn't xinetd listen on port 10080/udp again? Do you have any idea what is "failing"? Usually in the debug files in /tmp/amanda on the client there should be more clues about what is going on. The error "amandad" busy actually indicates to me that the amandad is still active on that client: that is the response you get from the first amandad when you want to start another dump or check. -- 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: Backups fail on new client: too many dumper retry
On Wed, Jun 21, 2006 at 01:26:53PM -0600, Charles Curley wrote: > On Wed, Jun 21, 2006 at 01:50:58PM -0400, Jon LaBadie wrote: > > > > What is in the client's amandad debug files? Anything of interest? > > From the client: > > -- > amandad: debug 1 pid 6541 ruid 33 euid 33: start at Wed Jun 21 08:26:53 2006 > amandad: version 2.4.5p1 > amandad: build: VERSION="Amanda-2.4.5p1" > amandad:BUILT_DATE="Fri Feb 10 21:44:52 EST 2006" [snip] Awfully similar to one from a successful run on one of my similar clients. Hopefully someone else will chime in. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Backups fail on new client: too many dumper retry
Charles Curley schreef: On Wed, Jun 21, 2006 at 02:06:28PM -0400, Jon LaBadie wrote: On Wed, Jun 21, 2006 at 11:43:31AM -0600, Charles Curley wrote: On Wed, Jun 21, 2006 at 12:51:45PM -0400, Jon LaBadie wrote: runtar is called from other programs and they write debug info to things like sendsize and sendbackup. Anything interesting there? Nothing that jumps out. Here's a recent sendbackup: -- sendbackup: debug 1 pid 7550 ruid 33 euid 33: start at Wed Jun 21 11:40:12 2006 /usr/lib/amanda/sendbackup: version 2.4.5p1 parsed request as: program `GNUTAR' disk `/etc' device `/etc' level 0 since 1970:1:1:0:0:0 options `|;bsd-auth;compress-fast;index;' sendbackup: try_socksize: send buffer size is 65536 sendbackup: time 0.001: stream_server: waiting for connection: 0.0.0.0.44983 sendbackup: time 0.001: stream_server: waiting for connection: 0.0.0.0.37243 sendbackup: time 0.001: stream_server: waiting for connection: 0.0.0.0.50509 sendbackup: time 0.001: waiting for connect on 44983, then 37243, then 50509 sendbackup: time 30.002: stream_accept: timeout after 30 seconds sendbackup: time 30.002: timeout on data port 44983 sendbackup: time 60.000: stream_accept: timeout after 30 seconds sendbackup: time 60.000: timeout on mesg port 37243 sendbackup: time 90.000: stream_accept: timeout after 30 seconds sendbackup: time 90.001: timeout on index port 50509 sendbackup: time 90.001: pid 7550 finish time Wed Jun 21 11:41:42 2006 -- Uhhh, Nothing stands out? Nothing like trying to set up the 3 needed connections and not connecting, but timing out instead? Nothing other than the problem I've already asked about & to which I've gotten no answer: Is the client trying to connect to 0.0.0.0.50509? And if so, where is that set up? 0.0.0.0 means the amandad process is listening on any interface (not only 127.0.0.1 or not only 192.169.0.1 etc.). The normal conversation for "sendbackup" goes like this: The server sends a UDP packet "sendbackup" request, and the DLE that it wants to do, together with some options used, e.g. if it wants indexes generated too. The client then prepares two or three tcp-connections: one for data, for error messages (which also contains the "Total size" line), and, if needed, a connections transferring the indexes. The client responds with a UDP packet on which ports these TCP connections will be listening. The server then needs to connect to each of these ports on the client. And there is seems to fail. As you said, you are using iptables, so problably the the packets are being blocked by iptables. To solve: 1. Easiest: load iptables helper module ip_conntrack_amanda: modprobe ip_conntrack_amanda (which will inspect the conversation above and open those two or three ports selectively as needed). 2. If you cannot use that module (e.g. because the firewall is not iptables or not recent enough), recompile amanda with a restricted portrange and open that range in the firewall. Details can be found in: http://wiki.zmanda.com/index.php/Configuration_with_iptables -- 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: Backups fail on new client: too many dumper retry
On Wed, Jun 21, 2006 at 01:07:40PM -0600, Charles Curley wrote: > On Wed, Jun 21, 2006 at 02:06:28PM -0400, Jon LaBadie wrote: > > On Wed, Jun 21, 2006 at 11:43:31AM -0600, Charles Curley wrote: > > > On Wed, Jun 21, 2006 at 12:51:45PM -0400, Jon LaBadie wrote: > > > > > > > runtar is called from other programs and they write debug info to > > > > things like sendsize and sendbackup. Anything interesting there? > > > > > > Nothing that jumps out. Here's a recent sendbackup: > > > -- > > > sendbackup: debug 1 pid 7550 ruid 33 euid 33: start at Wed Jun 21 > > > 11:40:12 2006 > > > /usr/lib/amanda/sendbackup: version 2.4.5p1 > > > parsed request as: program `GNUTAR' > > > disk `/etc' > > > device `/etc' > > > level 0 > > > since 1970:1:1:0:0:0 > > > options `|;bsd-auth;compress-fast;index;' > > > sendbackup: try_socksize: send buffer size is 65536 > > > sendbackup: time 0.001: stream_server: waiting for connection: > > > 0.0.0.0.44983 > > > sendbackup: time 0.001: stream_server: waiting for connection: > > > 0.0.0.0.37243 > > > sendbackup: time 0.001: stream_server: waiting for connection: > > > 0.0.0.0.50509 > > > sendbackup: time 0.001: waiting for connect on 44983, then 37243, then > > > 50509 > > > sendbackup: time 30.002: stream_accept: timeout after 30 seconds > > > sendbackup: time 30.002: timeout on data port 44983 > > > sendbackup: time 60.000: stream_accept: timeout after 30 seconds > > > sendbackup: time 60.000: timeout on mesg port 37243 > > > sendbackup: time 90.000: stream_accept: timeout after 30 seconds > > > sendbackup: time 90.001: timeout on index port 50509 > > > sendbackup: time 90.001: pid 7550 finish time Wed Jun 21 11:41:42 2006 > > > -- > > > > Uhhh, Nothing stands out? Nothing like trying to set up the 3 needed > > connections and not connecting, but timing out instead? > > > > Nothing other than the problem I've already asked about & to which > I've gotten no answer: Is the client trying to connect to > 0.0.0.0.50509? And if so, where is that set up? My networking is pretty weak, so hopefully someone else will jump in. That log is from the server, correct? What I think is happening is that the server is creating 3 sockets as shown. Then asking the client to do the same, attaching to the new sockets and ?perhaps? receiving the clients socket numbers in return. Except that it is not getting any response from the client. Whether the problem is the request is not sent properly, not received properly, refused with no acknowledgement, or the reply doesn't get received properly by the server I don't know. Perhaps a network traffic monitor like netcat/tcpdump/snoop might pinpoint where the problem lies. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Backups fail on new client: too many dumper retry
On Wed, Jun 21, 2006 at 01:50:58PM -0400, Jon LaBadie wrote: > On Wed, Jun 21, 2006 at 11:31:01AM -0600, Charles Curley wrote: > > On Wed, Jun 21, 2006 at 12:55:15PM -0400, Jon LaBadie wrote: > > > > > > Forgot to mention, I looked through some old reports, from last month > > > when I was setting up a FC4 installation. Early on there were some > > > "too many dumper retry" messages. When it happened all DLE for that > > > host had same report. > > > > Same here. > > > > > It was a connectivity problem, firewall (check both client and > > > server), > > > > The client amandad is called from xinetd, and that is working, or > > amcheck would fail. Wouldn't it? > > > > What is in the client's amandad debug files? Anything of interest? From the client: -- amandad: debug 1 pid 6541 ruid 33 euid 33: start at Wed Jun 21 08:26:53 2006 amandad: version 2.4.5p1 amandad: build: VERSION="Amanda-2.4.5p1" amandad:BUILT_DATE="Fri Feb 10 21:44:52 EST 2006" amandad:BUILT_MACH="Linux hs20-bc1-6.build.redhat.com 2.6.9-22.18.bz155725.ELsmp #1 SMP Thu Nov 17 15:34:08 EST 2005 i686 i686 i386 GNU/Linux" amandad:CC="i386-redhat-linux-gcc" amandad:CONFIGURE_COMMAND="'./configure' '--build=i386-redhat-linux' '--host=i386-redhat-linux' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/lib/amanda' '--localstatedir=/var/lib' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--enable-shared' '--disable-dependency-tracking' '--with-index-server=localhost' '--with-tape-server=localhost' '--with-config=DailySet1' '--with-gnutar-listdir=/var/lib/amanda/gnutar-lists' '--with-smbclient=/usr/bin/smbclient' '--with-amandahosts' '--with-user=amanda' '--with-group=disk' '--with-tmpdir=/var/log/amanda' '--with-gnutar=/bin/tar'" amandad: paths: bindir="/usr/bin" sbindir="/usr/sbin" amandad:libexecdir="/usr/lib/amanda" mandir="/usr/share/man" amandad:AMANDA_TMPDIR="/var/log/amanda" amandad:AMANDA_DBGDIR="/var/log/amanda" CONFIG_DIR="/etc/amanda" amandad:DEV_PREFIX="/dev/" RDEV_PREFIX="/dev/r" amandad:DUMP="/sbin/dump" RESTORE="/sbin/restore" VDUMP=UNDEF amandad:VRESTORE=UNDEF XFSDUMP=UNDEF XFSRESTORE=UNDEF VXDUMP=UNDEF amandad:VXRESTORE=UNDEF SAMBA_CLIENT="/usr/bin/smbclient" amandad:GNUTAR="/bin/tar" COMPRESS_PATH="/usr/bin/gzip" amandad:UNCOMPRESS_PATH="/usr/bin/gzip" LPRCMD="/usr/bin/lpr" amandad:MAILER="/usr/bin/Mail" amandad:listed_incr_dir="/var/lib/amanda/gnutar-lists" amandad: defs: DEFAULT_SERVER="localhost" DEFAULT_CONFIG="DailySet1" amandad:DEFAULT_TAPE_SERVER="localhost" amandad:DEFAULT_TAPE_DEVICE="/dev/null" HAVE_MMAP HAVE_SYSVSHM 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.4 REQ HANDLE 000-487B1309 SEQ 1150899849 SECURITY USER amanda SERVICE sendbackup OPTIONS features=feff9ffe7f;hostname=themoose.localdomain; GNUTAR /var 0 1970:1:1:0:0:0 OPTIONS |;bsd-auth;compress-fast;index; amandad: time 0.000: sending ack: Amanda 2.4 ACK HANDLE 000-487B1309 SEQ 1150899849 amandad: time 0.004: bsd security: remote host charlesc.localdomain user amanda local user amanda amandad: time 0.015: amandahosts security check passed amandad: time 0.015: running service "/usr/lib/amanda/sendbackup" amandad: time 0.018: sending REP packet: Amanda 2.4 REP HANDLE 000-487B1309 SEQ 1150899849 CONNECT DATA 40885 MESG 35734 INDEX 33697 OPTIONS features=feff9ffe7f; amandad: time 0.020: got packet: Amanda 2.4 ACK HANDLE 000-487B1309 SEQ 1150899849 amandad: time 0.020: pid 6541 finish time Wed Jun 21 08:26:53 2006 -- > > > Do I need 10080, 10082 and 10083 open on the server's firewall? I have > > them open on the client. I just opened them up on the server, and got > > the same results. There are no firewalls between the two machines. > > I thought that too until I checked FC's defaults include iptables running. > That in combo with selinux blocked return info to the server. Selinux is disabled on both boxes. > > > > > bad entry in .amandahosts, > > -- > > [EMAIL PROTECTED] DailySet1]# cat /var/lib/amanda/.amandahosts > > charlesc amanda > > charlesc.localdomain amanda > > ;) localdomain is not literal is it? Yes, it is. I run a range of private IP addresses behind a na
Re: Backups fail on new client: too many dumper retry
On Wed, Jun 21, 2006 at 02:06:28PM -0400, Jon LaBadie wrote: > On Wed, Jun 21, 2006 at 11:43:31AM -0600, Charles Curley wrote: > > On Wed, Jun 21, 2006 at 12:51:45PM -0400, Jon LaBadie wrote: > > > > > runtar is called from other programs and they write debug info to > > > things like sendsize and sendbackup. Anything interesting there? > > > > Nothing that jumps out. Here's a recent sendbackup: > > -- > > sendbackup: debug 1 pid 7550 ruid 33 euid 33: start at Wed Jun 21 11:40:12 > > 2006 > > /usr/lib/amanda/sendbackup: version 2.4.5p1 > > parsed request as: program `GNUTAR' > > disk `/etc' > > device `/etc' > > level 0 > > since 1970:1:1:0:0:0 > > options `|;bsd-auth;compress-fast;index;' > > sendbackup: try_socksize: send buffer size is 65536 > > sendbackup: time 0.001: stream_server: waiting for connection: 0.0.0.0.44983 > > sendbackup: time 0.001: stream_server: waiting for connection: 0.0.0.0.37243 > > sendbackup: time 0.001: stream_server: waiting for connection: 0.0.0.0.50509 > > sendbackup: time 0.001: waiting for connect on 44983, then 37243, then 50509 > > sendbackup: time 30.002: stream_accept: timeout after 30 seconds > > sendbackup: time 30.002: timeout on data port 44983 > > sendbackup: time 60.000: stream_accept: timeout after 30 seconds > > sendbackup: time 60.000: timeout on mesg port 37243 > > sendbackup: time 90.000: stream_accept: timeout after 30 seconds > > sendbackup: time 90.001: timeout on index port 50509 > > sendbackup: time 90.001: pid 7550 finish time Wed Jun 21 11:41:42 2006 > > -- > > Uhhh, Nothing stands out? Nothing like trying to set up the 3 needed > connections and not connecting, but timing out instead? > Nothing other than the problem I've already asked about & to which I've gotten no answer: Is the client trying to connect to 0.0.0.0.50509? And if so, where is that set up? -- Charles Curley /"\ASCII Ribbon Campaign Looking for fine software \ /Respect for open standards and/or writing? X No HTML/RTF in email http://www.charlescurley.com/ \No M$ Word docs in email Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB pgpWZb5uSfe88.pgp Description: PGP signature
Re: Backups fail on new client: too many dumper retry
On Wed, Jun 21, 2006 at 11:43:31AM -0600, Charles Curley wrote: > On Wed, Jun 21, 2006 at 12:51:45PM -0400, Jon LaBadie wrote: > > > runtar is called from other programs and they write debug info to > > things like sendsize and sendbackup. Anything interesting there? > > Nothing that jumps out. Here's a recent sendbackup: > -- > sendbackup: debug 1 pid 7550 ruid 33 euid 33: start at Wed Jun 21 11:40:12 > 2006 > /usr/lib/amanda/sendbackup: version 2.4.5p1 > parsed request as: program `GNUTAR' > disk `/etc' > device `/etc' > level 0 > since 1970:1:1:0:0:0 > options `|;bsd-auth;compress-fast;index;' > sendbackup: try_socksize: send buffer size is 65536 > sendbackup: time 0.001: stream_server: waiting for connection: 0.0.0.0.44983 > sendbackup: time 0.001: stream_server: waiting for connection: 0.0.0.0.37243 > sendbackup: time 0.001: stream_server: waiting for connection: 0.0.0.0.50509 > sendbackup: time 0.001: waiting for connect on 44983, then 37243, then 50509 > sendbackup: time 30.002: stream_accept: timeout after 30 seconds > sendbackup: time 30.002: timeout on data port 44983 > sendbackup: time 60.000: stream_accept: timeout after 30 seconds > sendbackup: time 60.000: timeout on mesg port 37243 > sendbackup: time 90.000: stream_accept: timeout after 30 seconds > sendbackup: time 90.001: timeout on index port 50509 > sendbackup: time 90.001: pid 7550 finish time Wed Jun 21 11:41:42 2006 > -- Uhhh, Nothing stands out? Nothing like trying to set up the 3 needed connections and not connecting, but timing out instead? Time for more digging into network connections. Have you checked the trouble shooting files on amanda.org or zmanda.com to see common reasons for this? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Backups fail on new client: too many dumper retry
On Wed, Jun 21, 2006 at 11:31:01AM -0600, Charles Curley wrote: > On Wed, Jun 21, 2006 at 12:55:15PM -0400, Jon LaBadie wrote: > > > > Forgot to mention, I looked through some old reports, from last month > > when I was setting up a FC4 installation. Early on there were some > > "too many dumper retry" messages. When it happened all DLE for that > > host had same report. > > Same here. > > > It was a connectivity problem, firewall (check both client and > > server), > > The client amandad is called from xinetd, and that is working, or > amcheck would fail. Wouldn't it? > What is in the client's amandad debug files? Anything of interest? > Do I need 10080, 10082 and 10083 open on the server's firewall? I have > them open on the client. I just opened them up on the server, and got > the same results. There are no firewalls between the two machines. I thought that too until I checked FC's defaults include iptables running. That in combo with selinux blocked return info to the server. > > > inetd not started, > > running, as a "ps aux" on the client confirms. > > > bad entry in .amandahosts, > -- > [EMAIL PROTECTED] DailySet1]# cat /var/lib/amanda/.amandahosts > charlesc amanda > charlesc.localdomain amanda ;) localdomain is not literal is it? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Backups fail on new client: too many dumper retry
On Wed, Jun 21, 2006 at 12:55:15PM -0400, Jon LaBadie wrote: > On Wed, Jun 21, 2006 at 10:05:35AM -0600, Charles Curley wrote: > > On Wed, Jun 21, 2006 at 11:11:36AM -0400, Jon LaBadie wrote: > > > > Forgot to mention, I looked through some old reports, from last month > when I was setting up a FC4 installation. Early on there were some > "too many dumper retry" messages. When it happened all DLE for that > host had same report. It was a connectivity problem, firewall (check > both client and server), inetd not started, bad entry in .amandahosts, > ... Those types of problems. > My server backup DLEs which work are all as localhost, not the hostname. I added one via hostname, and it failed. I can telnet into the host at port 10082, so it appears that is working. -- Charles Curley /"\ASCII Ribbon Campaign Looking for fine software \ /Respect for open standards and/or writing? X No HTML/RTF in email http://www.charlescurley.com/ \No M$ Word docs in email Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB pgp7Hc4p6awXM.pgp Description: PGP signature
Re: Backups fail on new client: too many dumper retry
On Wed, Jun 21, 2006 at 12:51:45PM -0400, Jon LaBadie wrote: > On Wed, Jun 21, 2006 at 10:05:35AM -0600, Charles Curley wrote: > > On Wed, Jun 21, 2006 at 11:11:36AM -0400, Jon LaBadie wrote: > > > > > > > > > > Looking at the log files, I see a typical runtar log as follows: > > > > > > > > -- > > > > runtar: debug 1 pid 6507 ruid 33 euid 0: start at Wed Jun 21 08:24:02 > > > > 2006 > > > > /bin/tar: version 2.4.5p1 > > > > running: /bin/tar: /bin/tar --create --file /dev/null --directory /var > > > > --one-file-system --listed-incremental > > > > /var/lib/amanda/gnutar-lists/themoose.localdomain_var_0.new --sparse > > > > --ignore-failed-read --totals . > > > > runtar: pid 6507 finish time Wed Jun 21 08:24:02 2006 > > > > -- > > > > > > > > I notice that the file is /dev/null. Is that correct? > > > > > > > > > > During estimates is it. > > > > > > If gnutar outputs to /dev/null, it goes through all the > > > normal steps without actually reading the ordinary file > > > data blocks. Saves mucho time for estimates. > > > > I checked all the runtar log files; they all indicate the same output > > file. Where do I look to see the results of a backup, if any? The > > amandad...debug files seem to be the right place, but the sizes are > > all way too small. > > Didn't you say you had amanda working to backup the server. > In that case some should have had "-file -" instead of "-file /dev/null". Ah. I was referring to the logs on the client only. I haven't checked the server's logs. > > Sounds like things are failing before even the estimates are done. > Are you even connection to the client? Yes. > Are there debug files on > the client? Yes. > Does amcheck indicate you can connect? Yes. > runtar is called from other programs and they write debug info to > things like sendsize and sendbackup. Anything interesting there? Nothing that jumps out. Here's a recent sendbackup: -- sendbackup: debug 1 pid 7550 ruid 33 euid 33: start at Wed Jun 21 11:40:12 2006 /usr/lib/amanda/sendbackup: version 2.4.5p1 parsed request as: program `GNUTAR' disk `/etc' device `/etc' level 0 since 1970:1:1:0:0:0 options `|;bsd-auth;compress-fast;index;' sendbackup: try_socksize: send buffer size is 65536 sendbackup: time 0.001: stream_server: waiting for connection: 0.0.0.0.44983 sendbackup: time 0.001: stream_server: waiting for connection: 0.0.0.0.37243 sendbackup: time 0.001: stream_server: waiting for connection: 0.0.0.0.50509 sendbackup: time 0.001: waiting for connect on 44983, then 37243, then 50509 sendbackup: time 30.002: stream_accept: timeout after 30 seconds sendbackup: time 30.002: timeout on data port 44983 sendbackup: time 60.000: stream_accept: timeout after 30 seconds sendbackup: time 60.000: timeout on mesg port 37243 sendbackup: time 90.000: stream_accept: timeout after 30 seconds sendbackup: time 90.001: timeout on index port 50509 sendbackup: time 90.001: pid 7550 finish time Wed Jun 21 11:41:42 2006 -- -- Charles Curley /"\ASCII Ribbon Campaign Looking for fine software \ /Respect for open standards and/or writing? X No HTML/RTF in email http://www.charlescurley.com/ \No M$ Word docs in email Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB pgpZLOVuv2oP2.pgp Description: PGP signature
Re: amandad process defunct
Joe, Which version of Amanda are you using? Please take a look at the log files in /tmp/amanda/ on the client system. You might have an idea which process exited and was not "waited" for (look for timestamps in the logs). Are you using compression or client side encryption? Thanks, Paddy On 6/21/06, Joe Donner (sent by Nabble.com) <[EMAIL PROTECTED]> wrote: Hi, I'm running Amanda in a test lab, and every several days or so the backup job to virtual tape fails because a process called amandad becomes unresponsive on the backup client. When doing an amcheck from the Amanda server it tells me that amandad on the client is "busy". When having a look at the client with the ps command, it lists two diferent amandad processes, with one showing as being "defunct". I cannot kill this process, but when I kill the other amandad process I can get rid of both, but then have to reboot the client to get the backup job to work again. Do you know how I can avoid doing this reboot, or what may be going on here? I'd appreciate your help as I'm pretty new to Amanda and Linux, but have been asked to look into Amanda as an alternative backup solution for our 5 Linux servers. Thanks in advance! Joe -- View this message in context: http://www.nabble.com/amandad-process-defunct-t1825006.html#a4977961 Sent from the Amanda - Users forum at Nabble.com. -- Amanda documentation: http://wiki.zmanda.com Amanda forums: http://forums.zmanda.com
Re: Backups fail on new client: too many dumper retry
On Wed, Jun 21, 2006 at 12:55:15PM -0400, Jon LaBadie wrote: > > Forgot to mention, I looked through some old reports, from last month > when I was setting up a FC4 installation. Early on there were some > "too many dumper retry" messages. When it happened all DLE for that > host had same report. Same here. > It was a connectivity problem, firewall (check both client and > server), The client amandad is called from xinetd, and that is working, or amcheck would fail. Wouldn't it? Do I need 10080, 10082 and 10083 open on the server's firewall? I have them open on the client. I just opened them up on the server, and got the same results. There are no firewalls between the two machines. > inetd not started, running, as a "ps aux" on the client confirms. > bad entry in .amandahosts, -- [EMAIL PROTECTED] DailySet1]# cat /var/lib/amanda/.amandahosts charlesc amanda charlesc.localdomain amanda [EMAIL PROTECTED] DailySet1]# ll /var/lib/amanda/.amandahosts -rw-rw 1 amanda disk 44 Jun 17 19:09 /var/lib/amanda/.amandahosts -- > ... Those types of problems. > > YMMV > > -- > Jon H. LaBadie [EMAIL PROTECTED] > JG Computing > 4455 Province Line Road(609) 252-0159 > Princeton, NJ 08540-4322 (609) 683-7220 (fax) -- Charles Curley /"\ASCII Ribbon Campaign Looking for fine software \ /Respect for open standards and/or writing? X No HTML/RTF in email http://www.charlescurley.com/ \No M$ Word docs in email Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB pgplkGJ7F6yf0.pgp Description: PGP signature
Re: Failed dumps with new amanda client
On Wed, Jun 21, 2006 at 11:23:28AM -0400, [EMAIL PROTECTED] wrote:
> On Wed, 21 Jun 2006, Jon LaBadie wrote:
>
> > On Wed, Jun 21, 2006 at 08:23:57AM -0400, Joshua Baker-LePain wrote:
> > > On Tue, 20 Jun 2006 at 10:59pm, [EMAIL PROTECTED] wrote
> > >
> > > >Here's the complete report, now that it finally finished:
> > > >
> > > >su-2.05a$ amtapetype -f /dev/nrsa0
> > > >Writing 256 Mbyte compresseable data: 92 sec
> > > >Writing 256 Mbyte uncompresseable data: 90 sec
> > > >Estimated time to write 2 * 1024 Mbyte: 720 sec = 0 h 12 min
> > > >wrote 763218 32Kb blocks in 2334 files in 13153 seconds (short write)
> > > >wrote 757298 32Kb blocks in 4646 files in 20125 seconds (short write)
> > > >define tapetype unknown-tapetype {
> > > > comment "just produced by tapetype prog (hardware compression off)"
> > > > length 24034 mbytes
> > > > filemark 81 kbytes
> > > > speed 1530 kps
> > > >}
> > > >
> > > >Does this mean that this 35GB uncompressed tape is only yeilding 24GB?
> > >
> > > Yep, which means it's not an amanda issue. And I have no idea why it's
> > > doing that. Good luck with it. ;)
> > >
> >
> > 24GB, that is just about where it ran out during amdump too.
> >
> > I've no idea either; just a possible coincidence.
> >
> > In my tapechart DLT IV tape is shown as 1800 inches long
> > while DLT III tape is 1200 inches long.
> > That ratio , 1200/1800 is pretty close to the
> > 24GB (observed)/35GB (expected) ratio.
> >
> > Any chance these are just short tapes?
>
> If so, I've been defrauded...they are clearly stamped "FujiFilm DLT IV"
>
> > For all I know about DLT, the physical cartridge may have
> > changed between DLT III and DLT IV so my question is silly.
> >
> > I note your speed is pretty low compared to my chart listing,
> > 1.5 vs 5.0 MB/sec. Is DLT capacity affected by slow feed?
>
> Not sure...I noticed the speed as well. I had raised the conf parameter:
>
> From: netusage 1600 Kbps
> To:netusage 7200 Kbps
>
> I can't recall if that's bits or bytes (small b should be bits, right?).
> But I'll try raising it alot more, since all dumps are over 100mbit
> ethernet.
You are not running amtapetype across a network,
so the dump network usage parameter has no impact.
It is how fast your system can feed your tapedrive.
I'd look into your scsi system, check system logs for errors, try the
usual culprits, cables, terminators, ... Even with a mediocre scsi
card I can drive my lto-1 at about 90% of its rated speed. Even with
the ancient card I was first using I was getting nearly 7 MB/sec.
Something seems amiss with your setup.
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Failed dumps with new amanda client
On Wed, 21 Jun 2006 at 11:23am, [EMAIL PROTECTED] wrote On Wed, 21 Jun 2006, Jon LaBadie wrote: I note your speed is pretty low compared to my chart listing, 1.5 vs 5.0 MB/sec. Is DLT capacity affected by slow feed? Not sure...I noticed the speed as well. I had raised the conf parameter: From: netusage 1600 Kbps To:netusage 7200 Kbps I can't recall if that's bits or bytes (small b should be bits, right?). But I'll try raising it alot more, since all dumps are over 100mbit ethernet. That parameter is only a guide to amanda. If amanda sees that the current backups coming over the network are using more than 'netusage' bandwidth, it won't start another one. But it doesn't throttle running backups to fit within netusage. Besides that, amtapetype only showed the slow speed. That means the cause has to be your tape drive, tapes, or the SCSI chain the tape drive is on. Those are the only things involved in running amtapetype. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Backups fail on new client: too many dumper retry
On Wed, Jun 21, 2006 at 10:05:35AM -0600, Charles Curley wrote: > On Wed, Jun 21, 2006 at 11:11:36AM -0400, Jon LaBadie wrote: > > > > > > > Looking at the log files, I see a typical runtar log as follows: > > > > > > -- > > > runtar: debug 1 pid 6507 ruid 33 euid 0: start at Wed Jun 21 08:24:02 2006 > > > /bin/tar: version 2.4.5p1 > > > running: /bin/tar: /bin/tar --create --file /dev/null --directory /var > > > --one-file-system --listed-incremental > > > /var/lib/amanda/gnutar-lists/themoose.localdomain_var_0.new --sparse > > > --ignore-failed-read --totals . > > > runtar: pid 6507 finish time Wed Jun 21 08:24:02 2006 > > > -- > > > > > > I notice that the file is /dev/null. Is that correct? > > > > > > > During estimates is it. > > > > If gnutar outputs to /dev/null, it goes through all the > > normal steps without actually reading the ordinary file > > data blocks. Saves mucho time for estimates. > > I checked all the runtar log files; they all indicate the same output > file. Where do I look to see the results of a backup, if any? The > amandad...debug files seem to be the right place, but the sizes are > all way too small. Forgot to mention, I looked through some old reports, from last month when I was setting up a FC4 installation. Early on there were some "too many dumper retry" messages. When it happened all DLE for that host had same report. It was a connectivity problem, firewall (check both client and server), inetd not started, bad entry in .amandahosts, ... Those types of problems. YMMV -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Backups fail on new client: too many dumper retry
On Wed, Jun 21, 2006 at 10:05:35AM -0600, Charles Curley wrote: > On Wed, Jun 21, 2006 at 11:11:36AM -0400, Jon LaBadie wrote: > > > > > > > Looking at the log files, I see a typical runtar log as follows: > > > > > > -- > > > runtar: debug 1 pid 6507 ruid 33 euid 0: start at Wed Jun 21 08:24:02 2006 > > > /bin/tar: version 2.4.5p1 > > > running: /bin/tar: /bin/tar --create --file /dev/null --directory /var > > > --one-file-system --listed-incremental > > > /var/lib/amanda/gnutar-lists/themoose.localdomain_var_0.new --sparse > > > --ignore-failed-read --totals . > > > runtar: pid 6507 finish time Wed Jun 21 08:24:02 2006 > > > -- > > > > > > I notice that the file is /dev/null. Is that correct? > > > > > > > During estimates is it. > > > > If gnutar outputs to /dev/null, it goes through all the > > normal steps without actually reading the ordinary file > > data blocks. Saves mucho time for estimates. > > I checked all the runtar log files; they all indicate the same output > file. Where do I look to see the results of a backup, if any? The > amandad...debug files seem to be the right place, but the sizes are > all way too small. Didn't you say you had amanda working to backup the server. In that case some should have had "-file -" instead of "-file /dev/null". Sounds like things are failing before even the estimates are done. Are you even connection to the client? Are there debug files on the client? Does amcheck indicate you can connect? runtar is called from other programs and they write debug info to things like sendsize and sendbackup. Anything interesting there? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Failed dumps with new amanda client
On Wed, 21 Jun 2006, Jon LaBadie wrote:
> On Wed, Jun 21, 2006 at 08:23:57AM -0400, Joshua Baker-LePain wrote:
> > On Tue, 20 Jun 2006 at 10:59pm, [EMAIL PROTECTED] wrote
> >
> > >Here's the complete report, now that it finally finished:
> > >
> > >su-2.05a$ amtapetype -f /dev/nrsa0
> > >Writing 256 Mbyte compresseable data: 92 sec
> > >Writing 256 Mbyte uncompresseable data: 90 sec
> > >Estimated time to write 2 * 1024 Mbyte: 720 sec = 0 h 12 min
> > >wrote 763218 32Kb blocks in 2334 files in 13153 seconds (short write)
> > >wrote 757298 32Kb blocks in 4646 files in 20125 seconds (short write)
> > >define tapetype unknown-tapetype {
> > > comment "just produced by tapetype prog (hardware compression off)"
> > > length 24034 mbytes
> > > filemark 81 kbytes
> > > speed 1530 kps
> > >}
> > >
> > >Does this mean that this 35GB uncompressed tape is only yeilding 24GB?
> >
> > Yep, which means it's not an amanda issue. And I have no idea why it's
> > doing that. Good luck with it. ;)
> >
>
> 24GB, that is just about where it ran out during amdump too.
>
> I've no idea either; just a possible coincidence.
>
> In my tapechart DLT IV tape is shown as 1800 inches long
> while DLT III tape is 1200 inches long.
> That ratio , 1200/1800 is pretty close to the
> 24GB (observed)/35GB (expected) ratio.
>
> Any chance these are just short tapes?
If so, I've been defrauded...they are clearly stamped "FujiFilm DLT IV"
> For all I know about DLT, the physical cartridge may have
> changed between DLT III and DLT IV so my question is silly.
>
> I note your speed is pretty low compared to my chart listing,
> 1.5 vs 5.0 MB/sec. Is DLT capacity affected by slow feed?
Not sure...I noticed the speed as well. I had raised the conf parameter:
From: netusage 1600 Kbps
To:netusage 7200 Kbps
I can't recall if that's bits or bytes (small b should be bits, right?).
But I'll try raising it alot more, since all dumps are over 100mbit
ethernet.
James Smallacombe PlantageNet, Inc. CEO and Janitor
[EMAIL PROTECTED]
http://3.am
=
amandad process defunct
Hi, I'm running Amanda in a test lab, and every several days or so the backup job to virtual tape fails because a process called amandad becomes unresponsive on the backup client. When doing an amcheck from the Amanda server it tells me that amandad on the client is "busy". When having a look at the client with the ps command, it lists two diferent amandad processes, with one showing as being "defunct". I cannot kill this process, but when I kill the other amandad process I can get rid of both, but then have to reboot the client to get the backup job to work again. Do you know how I can avoid doing this reboot, or what may be going on here? I'd appreciate your help as I'm pretty new to Amanda and Linux, but have been asked to look into Amanda as an alternative backup solution for our 5 Linux servers. Thanks in advance! Joe -- View this message in context: http://www.nabble.com/amandad-process-defunct-t1825006.html#a4977961 Sent from the Amanda - Users forum at Nabble.com.
Re: Backups fail on new client: too many dumper retry
On Wed, Jun 21, 2006 at 10:05:35AM -0600, Charles Curley wrote: > On Wed, Jun 21, 2006 at 11:11:36AM -0400, Jon LaBadie wrote: > > > > > > > Looking at the log files, I see a typical runtar log as follows: > > > > > > -- > > > runtar: debug 1 pid 6507 ruid 33 euid 0: start at Wed Jun 21 08:24:02 2006 > > > /bin/tar: version 2.4.5p1 > > > running: /bin/tar: /bin/tar --create --file /dev/null --directory /var > > > --one-file-system --listed-incremental > > > /var/lib/amanda/gnutar-lists/themoose.localdomain_var_0.new --sparse > > > --ignore-failed-read --totals . > > > runtar: pid 6507 finish time Wed Jun 21 08:24:02 2006 > > > -- > > > > > > I notice that the file is /dev/null. Is that correct? > > > > > > > During estimates is it. > > > > If gnutar outputs to /dev/null, it goes through all the > > normal steps without actually reading the ordinary file > > data blocks. Saves mucho time for estimates. > > I checked all the runtar log files; they all indicate the same output > file. Where do I look to see the results of a backup, if any? The > amandad...debug files seem to be the right place, but the sizes are > all way too small. I get to answer my own question. The results I want are in the sendbackupdebug files. Here is one: -- sendbackup: debug 1 pid 6542 ruid 33 euid 33: start at Wed Jun 21 08:26:53 2006 /usr/lib/amanda/sendbackup: version 2.4.5p1 parsed request as: program `GNUTAR' disk `/var' device `/var' level 0 since 1970:1:1:0:0:0 options `|;bsd-auth;compress-fast;index;' sendbackup: try_socksize: send buffer size is 65536 sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.40885 sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.35734 sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.33697 sendbackup: time 0.001: waiting for connect on 40885, then 35734, then 33697 sendbackup: time 30.001: stream_accept: timeout after 30 seconds sendbackup: time 30.002: timeout on data port 40885 sendbackup: time 60.002: stream_accept: timeout after 30 seconds sendbackup: time 60.002: timeout on mesg port 35734 sendbackup: time 90.003: stream_accept: timeout after 30 seconds sendbackup: time 90.003: timeout on index port 33697 sendbackup: time 90.004: pid 6542 finish time Wed Jun 21 08:28:23 2006 -- It looks like the client is misinformed about the server's IP address if it is waiting for a connection at 0.0.0.0.40885. On the client, I have /var/lib/amanda/.amandahosts, with two different names for the server. -- charlesc amanda charlesc.localdomain amanda -- Both resolve correctly. I can su to the amanda user on the server. -- Charles Curley /"\ASCII Ribbon Campaign Looking for fine software \ /Respect for open standards and/or writing? X No HTML/RTF in email http://www.charlescurley.com/ \No M$ Word docs in email Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB pgpbN6VGoUkh8.pgp Description: PGP signature
Re: Backups fail on new client: too many dumper retry
On Wed, Jun 21, 2006 at 11:11:36AM -0400, Jon LaBadie wrote: > > > > Looking at the log files, I see a typical runtar log as follows: > > > > -- > > runtar: debug 1 pid 6507 ruid 33 euid 0: start at Wed Jun 21 08:24:02 2006 > > /bin/tar: version 2.4.5p1 > > running: /bin/tar: /bin/tar --create --file /dev/null --directory /var > > --one-file-system --listed-incremental > > /var/lib/amanda/gnutar-lists/themoose.localdomain_var_0.new --sparse > > --ignore-failed-read --totals . > > runtar: pid 6507 finish time Wed Jun 21 08:24:02 2006 > > -- > > > > I notice that the file is /dev/null. Is that correct? > > > > During estimates is it. > > If gnutar outputs to /dev/null, it goes through all the > normal steps without actually reading the ordinary file > data blocks. Saves mucho time for estimates. I checked all the runtar log files; they all indicate the same output file. Where do I look to see the results of a backup, if any? The amandad...debug files seem to be the right place, but the sizes are all way too small. -- Charles Curley /"\ASCII Ribbon Campaign Looking for fine software \ /Respect for open standards and/or writing? X No HTML/RTF in email http://www.charlescurley.com/ \No M$ Word docs in email Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB pgpGhNKD3WUai.pgp Description: PGP signature
Re: stinit.def configuration for PowerVault 124T
On Wed, Jun 21, 2006 at 11:01:52AM -0400, Ronald Vincent Vazquez wrote:
> Hello list:
>
> I have been looking for a way configure stinit for our unit. This is what
> I have so far (missing manufacturer and model):
>
> => stinit.def <=
> # PowerVault 124T LTO-2
> manufacturer="??" model = "??" {
> scsi2logical=1
> can-bsr=1
> auto-lock=0
> two-fms=0
> drive-buffering=1
> buffer-writes
> read-ahead=1
> async-writes=1
> can-partitions=1
> fast-mteom=1
> mode1 blocksize=0 density=0x42 compression=1# 400 GB, native
> mode2 blocksize=0 density=0x42 compression=0# 200 GB, LTO
> }
>
> Could anybody tell me how to improve this entry?
Replace the "?"s ;)
I think I used what mt status gave me.
Why don't you want the door locked when the tape is in use?
Generally sysv or bsd style actions don't affect amanda.
But where they do, sysv style is assumed. You might
consider adding sysv=1
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Backups fail on new client: too many dumper retry
On Wed, Jun 21, 2006 at 08:45:37AM -0600, Charles Curley wrote: > I have a new installation on Fedora Core 5, amanda 2.4.5p1-3.2. The > server can back itself up, and I can access the backups. The storage > device is an external hard drive. > > I have just added a client to the setup. For its backups, I get: > > -- > FAILURE AND STRANGE DUMP SUMMARY: > themoose.localdomain /etc lev 0 FAILED 20060621 [too many > dumper retry] > themoose.localdomain /home lev 0 FAILED 20060621 [too many > dumper retry] > themoose.localdomain /var lev 0 FAILED 20060621 [too many > dumper retry] > -- > > Looking at the log files, I see a typical runtar log as follows: > > -- > runtar: debug 1 pid 6507 ruid 33 euid 0: start at Wed Jun 21 08:24:02 2006 > /bin/tar: version 2.4.5p1 > running: /bin/tar: /bin/tar --create --file /dev/null --directory /var > --one-file-system --listed-incremental > /var/lib/amanda/gnutar-lists/themoose.localdomain_var_0.new --sparse > --ignore-failed-read --totals . > runtar: pid 6507 finish time Wed Jun 21 08:24:02 2006 > -- > > I notice that the file is /dev/null. Is that correct? > During estimates is it. If gnutar outputs to /dev/null, it goes through all the normal steps without actually reading the ordinary file data blocks. Saves mucho time for estimates. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
stinit.def configuration for PowerVault 124T
Hello list:
I have been looking for a way configure stinit for our unit. This is what
I have so far (missing manufacturer and model):
=> stinit.def <=
# PowerVault 124T LTO-2
manufacturer="??" model = "??" {
scsi2logical=1
can-bsr=1
auto-lock=0
two-fms=0
drive-buffering=1
buffer-writes
read-ahead=1
async-writes=1
can-partitions=1
fast-mteom=1
mode1 blocksize=0 density=0x42 compression=1# 400 GB, native
mode2 blocksize=0 density=0x42 compression=0# 200 GB, LTO
}
Could anybody tell me how to improve this entry?
Thanks,
/
Ronald Vincent Vazquez
Vice President of Technology Group
Senior Unix Systems Administrator
Senior Network Manager
Christ Tabernacle Church Ministries
http://www.ctcministries.org/
(301) 540-9394 Home
(240) 401-9192 Cell
Backups fail on new client: too many dumper retry
I have a new installation on Fedora Core 5, amanda 2.4.5p1-3.2. The server can back itself up, and I can access the backups. The storage device is an external hard drive. I have just added a client to the setup. For its backups, I get: -- FAILURE AND STRANGE DUMP SUMMARY: themoose.localdomain /etc lev 0 FAILED 20060621 [too many dumper retry] themoose.localdomain /home lev 0 FAILED 20060621 [too many dumper retry] themoose.localdomain /var lev 0 FAILED 20060621 [too many dumper retry] -- Looking at the log files, I see a typical runtar log as follows: -- runtar: debug 1 pid 6507 ruid 33 euid 0: start at Wed Jun 21 08:24:02 2006 /bin/tar: version 2.4.5p1 running: /bin/tar: /bin/tar --create --file /dev/null --directory /var --one-file-system --listed-incremental /var/lib/amanda/gnutar-lists/themoose.localdomain_var_0.new --sparse --ignore-failed-read --totals . runtar: pid 6507 finish time Wed Jun 21 08:24:02 2006 -- I notice that the file is /dev/null. Is that correct? -- Charles Curley /"\ASCII Ribbon Campaign Looking for fine software \ /Respect for open standards and/or writing? X No HTML/RTF in email http://www.charlescurley.com/ \No M$ Word docs in email Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB pgpptfCPZfx9L.pgp Description: PGP signature
Re: Failed dumps with new amanda client
On Wed, Jun 21, 2006 at 08:23:57AM -0400, Joshua Baker-LePain wrote:
> On Tue, 20 Jun 2006 at 10:59pm, [EMAIL PROTECTED] wrote
>
> >Here's the complete report, now that it finally finished:
> >
> >su-2.05a$ amtapetype -f /dev/nrsa0
> >Writing 256 Mbyte compresseable data: 92 sec
> >Writing 256 Mbyte uncompresseable data: 90 sec
> >Estimated time to write 2 * 1024 Mbyte: 720 sec = 0 h 12 min
> >wrote 763218 32Kb blocks in 2334 files in 13153 seconds (short write)
> >wrote 757298 32Kb blocks in 4646 files in 20125 seconds (short write)
> >define tapetype unknown-tapetype {
> > comment "just produced by tapetype prog (hardware compression off)"
> > length 24034 mbytes
> > filemark 81 kbytes
> > speed 1530 kps
> >}
> >
> >Does this mean that this 35GB uncompressed tape is only yeilding 24GB?
>
> Yep, which means it's not an amanda issue. And I have no idea why it's
> doing that. Good luck with it. ;)
>
24GB, that is just about where it ran out during amdump too.
I've no idea either; just a possible coincidence.
In my tapechart DLT IV tape is shown as 1800 inches long
while DLT III tape is 1200 inches long.
That ratio , 1200/1800 is pretty close to the
24GB (observed)/35GB (expected) ratio.
Any chance these are just short tapes?
For all I know about DLT, the physical cartridge may have
changed between DLT III and DLT IV so my question is silly.
I note your speed is pretty low compared to my chart listing,
1.5 vs 5.0 MB/sec. Is DLT capacity affected by slow feed?
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Failed dumps with new amanda client
On Tue, 20 Jun 2006 at 10:59pm, [EMAIL PROTECTED] wrote
Here's the complete report, now that it finally finished:
su-2.05a$ amtapetype -f /dev/nrsa0
Writing 256 Mbyte compresseable data: 92 sec
Writing 256 Mbyte uncompresseable data: 90 sec
Estimated time to write 2 * 1024 Mbyte: 720 sec = 0 h 12 min
wrote 763218 32Kb blocks in 2334 files in 13153 seconds (short write)
wrote 757298 32Kb blocks in 4646 files in 20125 seconds (short write)
define tapetype unknown-tapetype {
comment "just produced by tapetype prog (hardware compression off)"
length 24034 mbytes
filemark 81 kbytes
speed 1530 kps
}
Does this mean that this 35GB uncompressed tape is only yeilding 24GB?
Yep, which means it's not an amanda issue. And I have no idea why it's
doing that. Good luck with it. ;)
--
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University
