Re: Amanda refusing to reuse old tapes
Here is the tapelist: 20040817 DailyDLT-07 reuse 20040817 DailyDLT-06 reuse 20040817 DailyDLT-05 reuse 20040816 DailyDLT-04 reuse 20040815 DailyDLT-03 reuse 20040814 DailyDLT-02 reuse 20040814 DailyDLT-01 reuse 20040813 DailyDLT-35 reuse 20040813 DailyDLT-34 reuse 20040813 DailyDLT-33 reuse 20040811 DailyDLT-32 reuse 20040811 DailyDLT-31 reuse 20040811 DailyDLT-30 reuse 20040811 DailyDLT-29 reuse 20040810 DailyDLT-25 reuse 20040810 DailyDLT-23 reuse 20040809 DailyDLT-27 reuse 20040805 DailyDLT-10 reuse 20040805 DailyDLT-09 reuse 20040805 DailyDLT-08 reuse 20040805 DailyDLT-14 reuse 0 DailyDLT-21 reuse 0 DailyDLT-20 reuse 0 DailyDLT-19 reuse 0 DailyDLT-18 reuse 0 DailyDLT-17 reuse 0 DailyDLT-16 reuse 0 DailyDLT-15 reuse 0 DailyDLT-28 reuse 0 DailyDLT-12 reuse 0 DailyDLT-11 reuse 0 DailyDLT-13 reuse Tapelist is out of whack since I've been having to amrmtape the tapes and relabel them to get amanda to work. -- jay - Original Message - From: Paul Bijnens <[EMAIL PROTECTED]> Date: Tue, 17 Aug 2004 17:54:33 +0200 To: Jay Ted <[EMAIL PROTECTED]> Subject: Re: Amanda refusing to reuse old tapes > Jay Ted wrote: > > > Yes, I do have 35 tapes labeled. > > What is the output of: > > $ grep -v no-reuse tapelist | wc -l > > It should greater than or equal 35. > > > >>>Am I correct in understanding that by setting the dumpcycle > >>>to one week that amanda should happily reuse any tape older > >>>than seven days provided there > >>>were not any errors in the previous weeks run? > > No, just tapecycle is important. However you will get a > warning in advance when amanda will overwrite the last full dump > of some DLE. But she will not refuse such a tape. > > > > > -- > 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 * > *** > > -- __ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze
RE: Amanda refusing to reuse old tapes
Yes, I do have 35 tapes labeled. - Original Message - From: "Dege, Robert C." <[EMAIL PROTECTED]> Date: Tue, 17 Aug 2004 07:03:03 -0700 To: 'Jay Ted' <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: RE: Amanda refusing to reuse old tapes > > I'm just thinking out loud here . > > In your amanda.conf, you show "tapecycle 35 tapes", but do you actually have 35 > tapes labeled & listed in tapelist? > > I ran into this problem with amanda at one point. I had tapecycle 40, but only had > 20 tapes labeled. As a result, > amanda was looking for the 21st tape, instead of looping back to tape #1. Lowering > the tapecycle to 20 fixed the > problem. > > -Rob > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, August 17, 2004 9:38 AM > > To: [EMAIL PROTECTED] > > Subject: Amanda refusing to reuse old tapes > > > > > > Am I missing something really easy here > > > > I have 35 tapes in rotation with a Dell Powervault 120T 7 > > tape autochanger. > > > > Usually the backups only take about 2 or 3 tapes, I have > > runtapes set to 4 just in case. This is still a work in > > progress. The problem that I am having is that when amanda > > uses the the last set of tapes (DailyDLT-29-35) > > and the next available tapes (DailyDLT-01-07) are loaded, > > amanda thinks they are active and refuses to use them. For > > example, even though the tape list shows an entry like > > "20040801 DailyDLT-01 reuse " well over > > the 7 day dumpcycle and not even containing data that is > > needed for a full dump, amanda still thinks the tape is > > active and won't use it. For a workaround i keep having to > > amrmtape and amlabel to relabel it and set > > tapelist right- I know I must be missing something simple... > > Am I correct in understanding that by setting the dumpcycle > > to one week that amanda should happily reuse any tape older > > than seven days provided there > > were not any errors in the previous weeks run? > > > > Here's an excerpt from my amanda.conf: > > dumpcycle 7 days > > runspercycle 7 > > tapecycle 35 tapes > > bumpsize 20 Mb > > bumpdays 1 > > bumpmult 4 > > etimeout -3600 > > dtimeout 1800 > > ctimeout 1300 > > tapebufs 20 > > runtapes 4 > > > > Thanks for any help!! > > > > Jay > > -- > > __ > > Check out the latest SMS services @ http://www.linuxmail.org > > This allows you to send and receive SMS through your mailbox. > > > > > > Powered by Outblaze > > -- __ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze
Amanda refusing to reuse old tapes
Am I missing something really easy here I have 35 tapes in rotation with a Dell Powervault 120T 7 tape autochanger. Usually the backups only take about 2 or 3 tapes, I have runtapes set to 4 just in case. This is still a work in progress. The problem that I am having is that when amanda uses the the last set of tapes (DailyDLT-29-35) and the next available tapes (DailyDLT-01-07) are loaded, amanda thinks they are active and refuses to use them. For example, even though the tape list shows an entry like "20040801 DailyDLT-01 reuse " well over the 7 day dumpcycle and not even containing data that is needed for a full dump, amanda still thinks the tape is active and won't use it. For a workaround i keep having to amrmtape and amlabel to relabel it and set tapelist right- I know I must be missing something simple... Am I correct in understanding that by setting the dumpcycle to one week that amanda should happily reuse any tape older than seven days provided there were not any errors in the previous weeks run? Here's an excerpt from my amanda.conf: dumpcycle 7 days runspercycle 7 tapecycle 35 tapes bumpsize 20 Mb bumpdays 1 bumpmult 4 etimeout -3600 dtimeout 1800 ctimeout 1300 tapebufs 20 runtapes 4 Thanks for any help!! Jay -- __ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze
Help with computing dump cycle
Hello, I need help on figuring out how to set up the dump cycle. The way I have previously done backups is a full dump on Friday night with incremental dumps Saturday through Thursday. I keep the full dumps for the past 5 Fridays, and full dumps done on the last Friday of the previous 3 months. I short, I want to have the ability to restore a system to its previous state for the last 7 days, 5 weeks, and 3 months. I have an Powervault 120T/DLT7000 that holds 7 tapes. With compression off each tape holds about 35G. A full dump of all of my systems uncompressed will fill nearly 6 tapes. I have plenty of tapes to swap out all tapes daily. Is there an easy way to set amanda.conf up to backup like this in only one configuration? Or do I need multiple configs? I have already read the Amanda chapter of the O'Reilly Backup book. I would just like to see someone's example config who may be doing something similar to what I am trying to do. Thanks! Jay -- __ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze
Re: sendbackup connection problems
That did it! All of the iptables options were compiled into the kernel, changed them to modules and that fixed it! Thanks! Jay > Jay Ted wrote: > > Greetings, > > > > I'm having trouble with one of my amanda servers. I have one server running > > 2.4.4p3 compiled from source on a LFS box with 2.6.7. My other server is 2.4.4p3 > > compiled from source on Slack9.1 with 2.6.7. My clients are a handful of RH with > > rpm'ed versions of amanda installed and a few others with clients compiled from > > source. My LFS server can back up all of the clients with out any problems. The > > Slack box can only backup one of the clients (rpm'd 2.4.2p2-9 on RH8.0). Any other > > clients (regardless of OS or amanda version) I try to backup using the Slack box > > get to the point where sendbackup opens up the three ports and waits for the > > server to connect, as seen here: > > > > cat /tmp/amada/sendbackup.20040624103525.debug > > > > sendbackup: debug 1 pid 1787 ruid 33 euid 33: start at Thu Jun 24 10:35:25 2004 > > /usr/local/libexec/sendbackup: version 2.4.4p3 > > parsed request as: program `DUMP' > > disk `/boot' > > device `/boot' > > level 0 > > since 1970:1:1:0:0:0 > > options `|;bsd-auth;srvcomp-best;index;' > > sendbackup: try_socksize: send buffer size is 65536 > > sendbackup: time 0.001: stream_server: waiting for connection: 0.0.0.0.1121 > > sendbackup: time 0.001: stream_server: waiting for connection: 0.0.0.0.1122 > > sendbackup: time 0.002: stream_server: waiting for connection: 0.0.0.0.1123 > > sendbackup: time 0.002: waiting for connect on 1121, then 1122, then 1123 > > sendbackup: time 30.002: stream_accept: timeout after 30 seconds > > sendbackup: time 30.002: timeout on data port 1121 > > sendbackup: time 60.002: stream_accept: timeout after 30 seconds > > sendbackup: time 60.002: timeout on mesg port 1122 > > sendbackup: time 90.002: stream_accept: timeout after 30 seconds > > sendbackup: time 90.002: timeout on index port 1123 > > sendbackup: time 90.002: pid 1787 finish time Thu Jun 24 10:36:55 2004 > > > > This is where it eventually times out waiting for the server. > > > > Here is a tcpdump of all traffic between the server and that client: > > > > 10:34:48.949371 slack.domain.com.522 > amclient.domain.com.10080: udp 117 (DF) > > 0x 4500 0091 0004 4000 4011 eeb1 ac10 8d79[EMAIL PROTECTED]@..y > > 0x0010 ac10 660c 020a 2760 007d 1aec 416d 616e..f...'`.}..Aman > > 0x0020 6461 2032 2e34 2052 4551 2048 414e 444cda.2.4.REQ.HANDL > > 0x0030 4520 3030 322d 3638 3739 3036 3038 2053E.002-68790608.S > > 0x0040 4551 2031 3038 3830 3931 3239 310a 5345EQ.1088091291.SE > > 0x0050 4355 CU > > 10:34:48.956599 amclient.domain.com.10080 > slack.domain.com.522: udp 50 (DF) > > 0x 4500 004e 4000 3f11 eff8 ac10 660c[EMAIL PROTECTED] > > 0x0010 ac10 8d79 2760 020a 003a 2b47 416d 616e...y'`...:+GAman > > 0x0020 6461 2032 2e34 2041 434b 2048 414e 444cda.2.4.ACK.HANDL > > 0x0030 4520 3030 322d 3638 3739 3036 3038 2053E.002-68790608.S > > 0x0040 4551 2031 3038 3830 3931 3239 310a EQ.1088091291. > > 10:34:48.961428 amclient.domain.com.10080 > slack.domain.com.522: udp 83 (DF) > > 0x 4500 006f 4000 3f11 efd7 ac10 660c[EMAIL PROTECTED] > > 0x0010 ac10 8d79 2760 020a 005b 2e82 416d 616e...y'`...[..Aman > > 0x0020 6461 2032 2e34 2052 4550 2048 414e 444cda.2.4.REP.HANDL > > 0x0030 4520 3030 322d 3638 3739 3036 3038 2053E.002-68790608.S > > 0x0040 4551 2031 3038 3830 3931 3239 310a 4f50EQ.1088091291.OP > > 0x0050 5449 TI > > 10:34:48.961641 slack.domain.com.522 > amclient.domain.com.10080: udp 50 (DF) > > 0x 4500 004e 0006 4000 4011 eef2 ac10 8d79[EMAIL PROTECTED]@..y > > 0x0010 ac10 660c 020a 2760 003a 2b47 416d 616e..f...'`.:+GAman > > 0x0020 6461 2032 2e34 2041 434b 2048 414e 444cda.2.4.ACK.HANDL > > 0x0030 4520 3030 322d 3638 3739 3036 3038 2053E.002-68790608.S > > 0x0040 4551 2031 3038 3830 3931 3239 310a EQ.1088091291. > > 10:34:48.962779 slack.domain.com.522 > amclient.domain.com.10080: udp 237 (DF) > > 0x 4500 0109 0007 4000 4011 ee36 ac10 8d79[EMAIL PROTECTED]@..6...y > > 0x001
sendbackup connection problems
Greetings, I'm having trouble with one of my amanda servers. I have one server running 2.4.4p3 compiled from source on a LFS box with 2.6.7. My other server is 2.4.4p3 compiled from source on Slack9.1 with 2.6.7. My clients are a handful of RH with rpm'ed versions of amanda installed and a few others with clients compiled from source. My LFS server can back up all of the clients with out any problems. The Slack box can only backup one of the clients (rpm'd 2.4.2p2-9 on RH8.0). Any other clients (regardless of OS or amanda version) I try to backup using the Slack box get to the point where sendbackup opens up the three ports and waits for the server to connect, as seen here: cat /tmp/amada/sendbackup.20040624103525.debug sendbackup: debug 1 pid 1787 ruid 33 euid 33: start at Thu Jun 24 10:35:25 2004 /usr/local/libexec/sendbackup: version 2.4.4p3 parsed request as: program `DUMP' disk `/boot' device `/boot' level 0 since 1970:1:1:0:0:0 options `|;bsd-auth;srvcomp-best;index;' sendbackup: try_socksize: send buffer size is 65536 sendbackup: time 0.001: stream_server: waiting for connection: 0.0.0.0.1121 sendbackup: time 0.001: stream_server: waiting for connection: 0.0.0.0.1122 sendbackup: time 0.002: stream_server: waiting for connection: 0.0.0.0.1123 sendbackup: time 0.002: waiting for connect on 1121, then 1122, then 1123 sendbackup: time 30.002: stream_accept: timeout after 30 seconds sendbackup: time 30.002: timeout on data port 1121 sendbackup: time 60.002: stream_accept: timeout after 30 seconds sendbackup: time 60.002: timeout on mesg port 1122 sendbackup: time 90.002: stream_accept: timeout after 30 seconds sendbackup: time 90.002: timeout on index port 1123 sendbackup: time 90.002: pid 1787 finish time Thu Jun 24 10:36:55 2004 This is where it eventually times out waiting for the server. Here is a tcpdump of all traffic between the server and that client: 10:34:48.949371 slack.domain.com.522 > amclient.domain.com.10080: udp 117 (DF) 0x 4500 0091 0004 4000 4011 eeb1 ac10 8d79[EMAIL PROTECTED]@..y 0x0010 ac10 660c 020a 2760 007d 1aec 416d 616e..f...'`.}..Aman 0x0020 6461 2032 2e34 2052 4551 2048 414e 444cda.2.4.REQ.HANDL 0x0030 4520 3030 322d 3638 3739 3036 3038 2053E.002-68790608.S 0x0040 4551 2031 3038 3830 3931 3239 310a 5345EQ.1088091291.SE 0x0050 4355 CU 10:34:48.956599 amclient.domain.com.10080 > slack.domain.com.522: udp 50 (DF) 0x 4500 004e 4000 3f11 eff8 ac10 660c[EMAIL PROTECTED] 0x0010 ac10 8d79 2760 020a 003a 2b47 416d 616e...y'`...:+GAman 0x0020 6461 2032 2e34 2041 434b 2048 414e 444cda.2.4.ACK.HANDL 0x0030 4520 3030 322d 3638 3739 3036 3038 2053E.002-68790608.S 0x0040 4551 2031 3038 3830 3931 3239 310a EQ.1088091291. 10:34:48.961428 amclient.domain.com.10080 > slack.domain.com.522: udp 83 (DF) 0x 4500 006f 4000 3f11 efd7 ac10 660c[EMAIL PROTECTED] 0x0010 ac10 8d79 2760 020a 005b 2e82 416d 616e...y'`...[..Aman 0x0020 6461 2032 2e34 2052 4550 2048 414e 444cda.2.4.REP.HANDL 0x0030 4520 3030 322d 3638 3739 3036 3038 2053E.002-68790608.S 0x0040 4551 2031 3038 3830 3931 3239 310a 4f50EQ.1088091291.OP 0x0050 5449 TI 10:34:48.961641 slack.domain.com.522 > amclient.domain.com.10080: udp 50 (DF) 0x 4500 004e 0006 4000 4011 eef2 ac10 8d79[EMAIL PROTECTED]@..y 0x0010 ac10 660c 020a 2760 003a 2b47 416d 616e..f...'`.:+GAman 0x0020 6461 2032 2e34 2041 434b 2048 414e 444cda.2.4.ACK.HANDL 0x0030 4520 3030 322d 3638 3739 3036 3038 2053E.002-68790608.S 0x0040 4551 2031 3038 3830 3931 3239 310a EQ.1088091291. 10:34:48.962779 slack.domain.com.522 > amclient.domain.com.10080: udp 237 (DF) 0x 4500 0109 0007 4000 4011 ee36 ac10 8d79[EMAIL PROTECTED]@..6...y 0x0010 ac10 660c 020a 2760 00f5 125b 416d 616e..f...'`...[Aman 0x0020 6461 2032 2e34 2052 4551 2048 414e 444cda.2.4.REQ.HANDL 0x0030 4520 3030 322d 3338 3839 3036 3038 2053E.002-38890608.S 0x0040 4551 2031 3038 3830 3931 3239 330a 5345EQ.1088091293.SE 0x0050 4355 CU 10:34:48.969593 amclient.domain.com.10080 > slack.domain.com.522: udp 50 (DF) 0x 4500 004e 4000 3f11 eff8 ac10 660c[EMAIL PROTECTED] 0x0010 ac10 8d79 2760 020a 003a 2b47 416d 616e...y'`...:+GAman 0x0020 6461 2032 2e34 2041 434b 2048 414e 444cda.2.4.ACK.HANDL 0x0030 4520 3030 322d 3338 3839 3036 3038 2053E.002-38890608.S 0x0040 4551 2031 3038 3830 3931 3239 330a EQ.1088091293. 10:34:50.540198 amclient.domain.com.10080 > slack.domain.com.522: udp 102 (DF) 0x 4500 0082 4000 3f11 efc4 a